doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc7508.txt b/doc/rfc/rfc7508.txt
new file mode 100644
index 0000000..2a5153d
--- /dev/null
+++ b/doc/rfc/rfc7508.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Independent Submission                                       L. Cailleux
+Request for Comments: 7508                                        DGA MI
+Category: Experimental                                        C. Bonatti
+ISSN: 2070-1721                                                     IECA
+                                                              April 2015
+
+
+                   Securing Header Fields with S/MIME
+
+Abstract
+
+   This document describes how the S/MIME protocol can be extended in
+   order to secure message header fields defined in RFC 5322.  This
+   technology provides security services such as data integrity, non-
+   repudiation, and confidentiality.  This extension is referred to as
+   'Secure Headers'.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This is a contribution to the RFC Series, independently
+   of any other RFC stream.  The RFC Editor has chosen to publish this
+   document at its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7508.
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+
+
+
+
+Cailleux & Bonatti            Experimental                      [Page 1]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology and Conventions Used in This Document ...............3
+   3. Context .........................................................4
+   4. Mechanisms to Secure Message Header Fields ......................6
+      4.1. ASN.1 Syntax of Secure Header Fields .......................7
+      4.2. Secure Header Fields Length and Format .....................8
+      4.3. Canonicalization Algorithm .................................8
+      4.4. Header Field Statuses ......................................8
+      4.5. Signature Process ..........................................9
+           4.5.1. Signature Generation Process ........................9
+           4.5.2. Signature Verification Process .....................10
+      4.6. Encryption and Decryption Processes .......................11
+           4.6.1. Encryption Process .................................11
+           4.6.2. Decryption Process .................................12
+   5. Case of Triple Wrapping ........................................13
+   6. Security Gateways ..............................................13
+   7. Security Considerations ........................................13
+   8. IANA Considerations ............................................14
+   9. References .....................................................14
+      9.1. Normative References ......................................14
+      9.2. Informative References ....................................15
+   Appendix A. Formal Syntax of Secure Header ........................16
+   Appendix B. Example of Secure Header Fields .......................18
+   Acknowledgements ..................................................19
+   Authors' Addresses ................................................19
+
+1.  Introduction
+
+   The S/MIME [RFC5751] standard defines a data encapsulation format for
+   the achievement of end-to-end security services such as integrity,
+   authentication, non-repudiation, and confidentiality.  By default,
+   S/MIME secures message body parts, at the exclusion of the message
+   header fields.
+
+   S/MIME provides an alternative solution to secure header fields: "the
+   sending client MAY wrap a full MIME message in a message/rfc822
+   wrapper in order to apply S/MIME security services to header fields".
+   However, the S/MIME solution doesn't provide any guidance regarding
+   what subset of message header fields to secure, procedures for
+   clients to reconcile the "inner" and "outer" headers, or procedures
+   for client interpretation or display of any failures.
+
+   Several other security specifications supplement S/MIME features but
+   fail to address the target requirement set of this document.  Such
+   other security specifications include DomainKeys Identified Mail
+   (DKIM) [RFC6376], STARTTLS [RFC3207], TLS with IMAP [RFC2595], and an
+
+
+
+Cailleux & Bonatti            Experimental                      [Page 2]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+   Internet-Draft referred to as "Protected Headers" [PRHDRS].  An
+   explanation of what these services accomplish and why they do not
+   solve this problem can be found in subsequent sections.
+
+   The goal of this document is to define end-to-end secure header field
+   mechanisms compliant with S/MIME standard.  This technique is based
+   on the signed attribute fields of a Cryptographic Message Syntax
+   (CMS) [RFC5652] signature.
+
+2.  Terminology and Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   The terms Message User Agent (MUA), Message Submission Agent (MSA),
+   and Message Transfer Agent (MTA) are defined in the email
+   architecture document [RFC5598].
+
+   The term Domain Confidentiality Authority (DCA) is defined in the
+   S/MIME Domain Security specification [RFC3183].
+
+   End-to-end Internet Mail exchanges are performed between message
+   originators and recipients.
+
+   The term message header fields is described in [RFC5322].  A header
+   field is composed of a name and a value.
+
+   Secure Headers technology uses header field statuses required to
+   provide a confidentiality service toward message headers.  The
+   following three terms are used to describe the field statuses:
+
+   -  duplicated (the default status).  When this status is present or
+      if no status is specified, the signature process embeds the header
+      field value in the digital signature, but the value is also
+      present in the message header fields.
+
+   -  deleted.  When this status is present, the signature process
+      embeds the header field value in the digital signature, and the
+      encryption process deletes this field from the message to preserve
+      its confidentiality.
+
+   -  modified.  When this status is present, the signature process
+      embeds the header field value in the digital signature, and the
+      encryption process modifies the value of the header field in the
+      message.  This preserves confidentiality and informs a receiver's
+
+
+
+
+
+Cailleux & Bonatti            Experimental                      [Page 3]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+      noncompliant MUA that secure headers are being used.  New values
+      for each field might be configured by the sender (i.e., "This
+      header is secured; use a compliant client.").
+
+   The term non-repudiation is used throughout this document in
+   deference to the usage in the S/MIME Message Specification [RFC5751].
+   It is recognized that this term carries with it much baggage, and
+   that there is some disagreement as to its proper meaning and usage.
+   However, in the context of this document, the term merely refers to
+   one set of possible security services that a conforming
+   implementation might be able to provide.  This document specifies no
+   normative requirements for non-repudiation.
+
+3.  Context
+
+   Over the Internet, email use has grown and today represents a
+   fundamental service.  Meanwhile, continually increasing threat levels
+   are motivating the implementation of security services.
+
+   Historically, SMTP [RFC5321] and the Internet Message Format (IMF)
+   [RFC5322] don't provide, by default, security services.  The S/MIME
+   standard [RFC5751] was published in order to address these needs.
+   S/MIME defines a data encapsulation format for the provision of end-
+   to-end security services such as integrity, authentication, non-
+   repudiation, and confidentiality.  By default, S/MIME secures message
+   body parts, at the exclusion of the message header fields.  In order
+   to protect message header fields (for instance, the "Subject", "To",
+   "From", or customized fields), several solutions exist.
+
+   In Section 3.1 of [RFC5751], S/MIME defines an encapsulation
+   mechanism:
+
+      [...] the sending client MAY wrap a full MIME message in a
+      message/rfc822 wrapper in order to apply S/MIME security services
+      to these header fields.  It is up to the receiving client to
+      decide how to present this "inner" header along with the
+      unprotected "outer" header.
+
+   However, some use cases are not addressed, especially in the case of
+   message encryption.  What happens when header fields are encrypted?
+   How does the receiving client display these header fields?  How can a
+   subset of header fields be secured?  S/MIME doesn't address these
+   issues.
+
+
+
+
+
+
+
+
+Cailleux & Bonatti            Experimental                      [Page 4]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+   Some partial header protection is provided by the S/MIME Certificate
+   Handling specification [RFC5750]:
+
+      Receiving agents MUST check that the address in the From or Sender
+      header of a mail message matches an Internet mail address, if
+      present, in the signer's certificate, if mail addresses are
+      present in the certificate.
+
+   In some cases, this may provide assurance of the integrity of the
+   From or Sender header values.  However, the solution in RFC 5750 only
+   provides a matching mechanism between email addresses and provides no
+   protection to other header fields.
+
+   Other security specifications (introduced below) exist such as DKIM,
+   STARTTLS and TLS with IMAP, but they meet other needs (signing
+   domain, secure channels, etc.).
+
+   STARTTLS and TLS with IMAP provide secure channels between components
+   of the email system (MUA, MSA, MTA, etc.), but end-to-end integrity
+   cannot be guaranteed.
+
+   DKIM defines a domain-level authentication framework for email.
+   While this permits integrity and origination checks on message header
+   fields and the message body, it does this for a domain actor (usually
+   the SMTP service or equivalent) and not for the entity that is
+   sending, and thus signing, the message.  (Extensions to DKIM might be
+   able to solve this issue by authenticating the sender and making a
+   statement of this fact as part of the signed message headers.)  DKIM
+   is also deficient for our purposes, as it does not provide a
+   confidentially service.
+
+   An Internet-Draft referred to as "Protected Headers" [PRHDRS] has
+   been proposed.  Mechanisms described in that document are the
+   following:
+
+      [...] a digest value is computed over the canonicalized version of
+      some selected header fields.  This technique resembles header
+      protection in [RFC4871].  Then the digest value is included in a
+      signed attribute field of a CMS signature.
+
+   (Note that RFC 4871 has been obsoleted by RFC 6376.)
+
+   That specification doesn't address all conceivable requirements as
+   noted below.  If the protected header field has been altered, the
+   original value cannot be determined by the recipient.  In addition,
+   the encryption service cannot provide confidentiality for fields that
+   must remain present in the message header during transport.
+
+
+
+
+Cailleux & Bonatti            Experimental                      [Page 5]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+   This document proposes a technology for securing message header
+   fields.  It's referred to as "Secure Headers".  It is based on S/MIME
+   and CMS standards.  It provides security services such as data
+   integrity, confidentiality, and non-repudiation of the sender.
+   Secure Headers is backward compatible with other S/MIME clients.
+   S/MIME clients who have not implemented Secure Headers technology
+   need merely ignore specific signed attributes fields in a CMS
+   signature (which is the default behavior).
+
+4.  Mechanisms to Secure Message Header Fields
+
+   Secure Headers technology involves the description of a security
+   policy.  This policy MUST describe a secure message profile and list
+   the header fields to secure.  How this security policy is agreed upon
+   or communicated is beyond the scope of this document.
+
+   Secure headers are based on the signed attributes field as defined in
+   CMS.  The details are as follows.  The message header fields to be
+   secured are integrated in a structure (SecureHeaderFields structure)
+   that is encapsulated in the signed attributes structure of the
+   SignerInfo object.  There is only one value of HeaderFields encoded
+   into a single SignedAttribute in a signature.  See Appendix A for an
+   example.  For each header field present in the secure signature, a
+   status can be set.  Then, as described in Section 5.4 of CMS
+   [RFC5652], the message digest calculation process computes a message
+   digest on the content together with the signed attributes.  Details
+   of the signature generation process are in Section 4.5.1 of this
+   document.
+
+   Verification of secure header fields is based on the signature
+   verification process described in CMS.  At the end of this process, a
+   comparison between the secure header fields and the corresponding
+   message header fields is performed.  If they match, the signature is
+   valid.  Otherwise, the signature is invalid.  Details of the
+   signature verification process are in Section 4.5.2 of this document.
+
+   Non-conforming S/MIME clients will ignore the signed attribute
+   containing the SecureHeaderFields structure, and only perform the
+   verification process described in CMS.  This guarantees backward
+   compatibility.
+
+   Secure headers provide security services such as data integrity, non-
+   repudiation, and confidentiality.
+
+
+
+
+
+
+
+
+Cailleux & Bonatti            Experimental                      [Page 6]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+   For different reasons (e.g., usability, limits of IMAP [RFC3501]),
+   encryption and decryption processes are performed by a third party.
+   The third party that performs these processes is referred to in the
+   Domain Security specification as a Domain Confidentiality Authority
+   (DCA).  Details of the encryption and decryption processes are in
+   Sections 4.6.1 and 4.6.2 of this document.
+
+   The architecture of Secure Headers is presented below.  The MUA
+   performs the signature generation process (C) and signature
+   verification process (F).  The DCA performs the message encryption
+   process (D) and message decryption process (E).  The encryption and
+   decryption processes are optional.
+
+             A Domain                             B Domain
+     +----------------------+             +----------------------+
+
+     +-----+          +-----+             +-----+          +-----+
+     | MUA | -------> | DCA | ----------> | DCA |--------> | MUA |
+     |  C  |          |  D  |             |  E  |          |  F  |
+     +-----+          +-----+             +-----+          +-----+
+             SignedMsg        EncryptedMsg        SignedMsg
+
+                  Figure 1: Architecture of Secure Headers
+
+4.1.  ASN.1 Syntax of Secure Header Fields
+
+   The ASN.1 syntax [ASN1-88] of the SecureHeaderFields structure is as
+   follows:
+
+      SecureHeaderFields ::= SET {
+         canonAlgorithm Algorithm,
+         secHeaderFields HeaderFields }
+
+      id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= {
+         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+         pkcs-9(9) smime(16) id-aa(2) secureHeaderFieldsIdentifier(55) }
+
+      Algorithm ::= ENUMERATED {
+         canonAlgorithmSimple(0),
+         canonAlgorithmRelaxed(1) }
+
+      HeaderFields ::= SEQUENCE SIZE (1..MAX) OF HeaderField
+
+      HeaderField ::= SEQUENCE {
+         field-Name HeaderFieldName,
+         field-Value HeaderFieldValue,
+         field-Status HeaderFieldStatus DEFAULT duplicated }
+
+
+
+
+Cailleux & Bonatti            Experimental                      [Page 7]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+      HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":")))
+           -- This description matches the description of
+           -- field name in Sections 2.2 and 3.6.8 of RFC 5322
+
+      HeaderFieldValue ::= UTF8String
+           -- This description matches the description of
+           -- field body in Section 2.2 of RFC 5322 as
+           -- extended by Section 3.1 of RFC 6532.
+
+      HeaderFieldStatus ::= INTEGER {
+         duplicated(0), deleted(1), modified(2) }
+
+4.2.  Secure Header Fields Length and Format
+
+   This specification requires MUA security capabilities in order to
+   process well-formed headers, as specified in IMF.  Notice that it
+   includes long header fields and folded header fields.
+
+4.3.  Canonicalization Algorithm
+
+   During a message transfer through a messaging system, some components
+   might modify headers (i.e., adding or deleting space, changing or
+   lowercase or uppercase).  This might lead to a comparison mismatch of
+   header fields.  This emphasizes the need of a conversion process in
+   order to transform data to their canonical form.  This process is
+   named the canonicalization process.
+
+   Two canonicalization algorithms are considered here, according to
+   Section 3.4 of the DKIM specification [RFC6376].  The "simple"
+   algorithm doesn't allow any modification, whereas the "relaxed"
+   algorithm accepts slight modifications like space replacement or line
+   reformatting.  Given the scope of this document, canonicalization
+   mechanisms only involve header fields.
+
+   Implementations SHOULD use the "relaxed" algorithm to promote
+   interoperability with non-conforming SMTP products.
+
+4.4.  Header Field Statuses
+
+   Header field statuses are necessary to provide a confidentiality
+   service for message headers.  In this specification, the
+   confidentiality of header fields is provided by the DCA.  This point
+   is described in Section 4.  The DCA performs the message encryption
+   process and message decryption process; these processes are described
+   in detail in Sections 4.6.1 and 4.6.2.  Although header field
+   statuses are embedded in the signature, the signature processes
+
+
+
+
+
+Cailleux & Bonatti            Experimental                      [Page 8]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+   (generation and verification) ignore them.  The header field status
+   defaults to "duplicated".  If the header field is confidential, the
+   header field status MUST be either "deleted" or "modified".
+
+4.5.  Signature Process
+
+4.5.1.  Signature Generation Process
+
+   During the signature generation process, the sender's MUA MUST embed
+   the SecureHeaderFields structure in the signed attributes, as
+   described in CMS.  The SecureHeaderFields structure MUST include a
+   canonicalization algorithm.
+
+   The sender's MUA MUST have a list of header fields to secure,
+   statuses, and a canonicalization algorithm, as defined by the
+   security policy.
+
+   Header fields (names and values) embedded in signed attributes MUST
+   be the same as those included in the initial message.
+
+   If different headers share the same name, all instances MUST be
+   included in the SecureHeaderFields structure.
+
+   If multiple signatures are used, as explained in the CMS and Multiple
+   Signer [RFC4853] specifications, the SecureHeaderFields structure
+   MUST be the same in each SignerInfos object.
+
+   If a header field is present and its value is empty, HeaderFieldValue
+   MUST have a zero-length field-Value.
+
+   Considering secure header mechanisms, the signature generation
+   process MUST perform the following steps:
+
+      1) Select the relevant header fields to secure.  This subset of
+         headers is defined according the security policy.
+
+      2) Apply the canonicalization algorithm for each selected header
+         field.
+
+      3) Complete the following fields in the SecureHeaderFields
+         structure according to the initial message: HeaderFieldName,
+         HeaderFieldValue, and HeaderFieldStatus.
+
+      4) Complete the algorithm field according to the canonicalization
+         algorithm configured.
+
+      5) Embed the SecureHeaderFields structure in the signed attributes
+         of the SignerInfos object.
+
+
+
+Cailleux & Bonatti            Experimental                      [Page 9]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+      6) Compute the signature generation process as described in
+         Section 5.5 of CMS [RFC5652].
+
+4.5.2.  Signature Verification Process
+
+   During the signature verification process, the receiver's MUA
+   compares header fields embedded in the SecureHeaderFields structure
+   with those present in the message.  For this purpose, it uses the
+   canonicalization algorithm identified in the signed attributes.  If a
+   mismatch appears during the comparison process, the receiver's MUA
+   MUST invalidate the signature.  The MUA MUST display information on
+   the validity of each header field.  It MUST also display the values
+   embedded in the signature.
+
+   The receiver's MUA MUST know the list of mandatory header fields in
+   order to verify their presence in the message.  If a header field
+   defined in a message is in the secure header list, it MUST be
+   included in the SecureHeaderFields structure.  Otherwise, the
+   receiver's MUA MUST warn the user that a non-secure header is
+   present.
+
+   Considering secure header mechanisms, the signature verification
+   process MUST perform the following steps:
+
+      1) Execute the signature verification process as described Section
+         5.6 of CMS [RFC5652].  If the signature appears to be invalid,
+         the process ends.  Otherwise, the process continues.
+
+      2) Read the type of canonicalization algorithm specified in the
+         SecureHeaderFields structure.
+
+      3) For each field present in the signature, find the matching
+         header in the message.  If there is no matching header, the
+         verification process MUST warn the user, specifying the missing
+         header name.  The signature is tagged as invalid.  Note that
+         any header fields encrypted as per Section 4.6 (i.e., status of
+         "deleted" or "modified") have been are already restored by the
+         DCA when the signature verification process is performed by the
+         MUA.
+
+      4) Compute the canonicalization algorithm for each header field
+         value in the message.  If the "simple" algorithm is used, the
+         steps described in Section 3.4.1 of DKIM [RFC6376] are
+         performed.  If the relaxed algorithm is used, the steps
+         described in Section 3.4.2 of DKIM [RFC6376] are performed.
+
+
+
+
+
+
+Cailleux & Bonatti            Experimental                     [Page 10]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+      5) For each field, compare the value stored in the
+         SecureHeaderFields structure with the value returned by the
+         canonicalization algorithm.  If the values don't match, the
+         verification process MUST warn the user.  This warning MUST
+         mention mismatching fields.  The signature is tagged as
+         invalid.  If all the comparisons succeed, the verification
+         process MUST also notify the user (i.e., using an appropriate
+         icon).
+
+      6) Verify that no secure header has been added to the message
+         header, given the initial fields.  If an extra header field has
+         been added, the verification process MUST warn the user.  This
+         warning MUST mention extra fields.  The signature is tagged as
+         invalid.  This step is only performed if the sender and the
+         recipient share the same security policy.
+
+      7) Verify that each mandatory header in the security policy and
+         present in the message is also embedded in the
+         SecureHeaderFields structure.  If such headers are missing, the
+         verification process MUST warn the user and indicate the names
+         of the missing headers.
+
+   The MUA MUST display the properties of each secure header field
+   (name, value, and status) and the canonicalization algorithm used.
+
+4.6.  Encryption and Decryption Processes
+
+   Encryption and decryption operations are not performed by MUAs.  This
+   is mainly justified by limitations of existing email delivery
+   protocols, for example, IMAP.  The solution developed here relies on
+   concepts explained in Section 4 of the Domain Security specification
+   [RFC3183].  A fundamental component of the architecture is the Domain
+   Confidentiality Authority (DCA).  Its purpose is to encrypt and
+   decrypt messages instead of that being performed by senders and
+   receivers (respectively).
+
+4.6.1.  Encryption Process
+
+   All the computations presented in this section MUST be performed only
+   if the following conditions are verified:
+
+      -  The content to be encrypted MUST consist of a signed message
+         (application/pkcs7-mime with SignedData, or multipart/signed)
+         as shown in Section 3.4 of the S/MIME specification [RFC5751].
+
+      -  A SecureHeaderFields structure MUST be included in the
+         signedAttrs field of the SignerInfo object of the signature.
+
+
+
+
+Cailleux & Bonatti            Experimental                     [Page 11]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+   All the mechanisms described below MUST start at the beginning of the
+   encryption process, as explained in CMS.  They are performed by the
+   sender's DCA.  For extraction of the field status, the following
+   steps MUST be performed for each field included in the
+   SecureHeaderFields structure:
+
+      1. If the status is "duplicated", the field is left at its
+         existing value.
+
+      2. If the status is "deleted", the header field (name and value)
+         is removed from the message.  Mandatory header fields specified
+         in [RFC5322] MUST be kept.
+
+      3. If the status is "modified", the header value is replaced by a
+         new value, as configured in the DCA.
+
+4.6.2.  Decryption Process
+
+   All the computations presented in this section MUST be performed only
+   if the following conditions are verified:
+
+      -  The decrypted content MUST consist of a signature object or a
+         multipart object, where one part is a detached signature, as
+         shown in Section 3.4 of the S/MIME specification [RFC5751].
+
+      -  A SecureHeaderFields structure MUST be included in the
+         SignerInfo object of the signature.
+
+   All the mechanisms described below MUST start at the end of the
+   decryption process, as explained in CMS.  They are executed by the
+   receiver's DCA.  The following steps MUST be performed for each field
+   included in the SecureHeaderFields structure:
+
+      1. If the status is "duplicated", the field is left at its
+         existing value.
+
+      2. If the status is "deleted", the DCA MUST write a header field
+         (name and value) in the message.  This header MUST be compliant
+         with the information embedded in the signature.
+
+      3. If the status is "modified", the DCA MUST rewrite a header
+         field in the message.  This header MUST be compliant with the
+         SecureHeaderFields structure.
+
+
+
+
+
+
+
+
+Cailleux & Bonatti            Experimental                     [Page 12]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+5.  Case of Triple Wrapping
+
+   Secure Headers mechanisms MAY be used with triple wrapping, as
+   described in Enhanced Security Services (ESS) [RFC2634].  In this
+   case, a SecureHeaderFields structure MAY be present in the inner
+   signature, the outer signature, or both.  In the last case, the two
+   SecureHeaderFields structures MAY differ.  One MAY consider the
+   encapsulation of a header field in the inner signature in order to
+   satisfy confidentiality needs.  On the contrary, an outer signature
+   encapsulation MAY help for delivery purposes.  The sender's MUA and
+   receiver's MUA must have a security policy for triple wrapping.  This
+   security policy MUST be composed of two parts -- one for the inner
+   signature and the other for the outer signature.
+
+6.  Security Gateways
+
+   Some security gateways sign or verify messages that pass through
+   them.  Compliant gateways MUST apply the process described in Section
+   4.5.
+
+   For noncompliant gateways, the presence of a SecureHeaderFields
+   structure does not change their behavior.
+
+   In some case, gateways MUST generate a new signature or insert
+   signerInfos into the signedData block.  The format of signatures
+   generated by gateways is outside the scope of this document.
+
+7.  Security Considerations
+
+   This specification describes an extension of the S/MIME standard.  It
+   provides message header integrity, non-repudiation, and
+   confidentiality.  The signature and encryption processes are
+   complementary.  However, according to the security policy, only the
+   signature mechanism is applicable.  In this case, the signature
+   process is implemented between MUAs.  The encryption process requires
+   signed messages with the Secure Headers extension.  If required, the
+   encryption process is implemented by DCAs.
+
+   This specification doesn't address end-to-end confidentiality for
+   message header fields.  Messages sent and received by MUAs could be
+   transmitted as plaintext.  In order to avoid interception, the use of
+   TLS is recommended between MUAs and DCAs (uplink and downlink).
+   Another solution might be the use of S/MIME between MUAs and DCAs in
+   the same domain.
+
+   For the header field confidentiality mechanism to be effective, all
+   DCAs supporting confidentiality must support Secure Headers
+   processing.  Otherwise, there is a risk that headers are not obscured
+
+
+
+Cailleux & Bonatti            Experimental                     [Page 13]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+   upon encryption or not restored upon decryption.  In the former case,
+   confidentiality of the header fields is compromised.  In the latter
+   case, the integrity of the headers will appear to be compromised.
+
+8.  IANA Considerations
+
+   IANA has registered value 65, mod-sMimeSecureHeadersV1, in the "SMI
+   Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)"
+   registry.
+
+   IANA has also registered value 55,
+   id-aa-secureHeaderFieldsIdentifier, in the "SMI Security for S/MIME
+   Attributes (1.2.840.113549.1.9.16.2)" registry.  This value will be
+   used to identify an authenticated attribute carried within a CMS
+   wrapper [RFC5652].  This attribute OID appears in Section 4.1 and
+   again in the reference definition in Appendix A.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2634]  Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
+              RFC 2634, June 1999,
+              <http://www.rfc-editor.org/info/rfc2634>.
+
+   [RFC4853]  Housley, R., "Cryptographic Message Syntax (CMS) Multiple
+              Signer Clarification", RFC 4853, April 2007,
+              <http://www.rfc-editor.org/info/rfc4853>.
+
+   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
+              October 2008, <http://www.rfc-editor.org/info/rfc5322>.
+
+   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+              RFC 5652, September 2009,
+              <http://www.rfc-editor.org/info/rfc5652>.
+
+   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
+              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
+              RFC 6376, September 2011,
+              <http://www.rfc-editor.org/info/rfc6376>.
+
+   [ASN1-88]  CCITT, Recommendation X.208: Specification of Abstract
+              Syntax Notation One (ASN.1), 1988.
+
+
+
+
+Cailleux & Bonatti            Experimental                     [Page 14]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+9.2.  Informative References
+
+   [PRHDRS]   Liao, L. and J. Schwenk, "Header Protection for S/MIME",
+              draft-liao-smimeheaderprotect-05, Work in Progress, June
+              2009.
+
+   [RFC2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
+              2595, June 1999, <http://www.rfc-editor.org/info/rfc2595>.
+
+   [RFC3183]  Dean, T. and W. Ottaway, "Domain Security Services using
+              S/MIME", RFC 3183, October 2001,
+              <http://www.rfc-editor.org/info/rfc3183>.
+
+   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
+              Transport Layer Security", RFC 3207, February 2002,
+              <http://www.rfc-editor.org/info/rfc3207>.
+
+   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+              4rev1", RFC 3501, March 2003,
+              <http://www.rfc-editor.org/info/rfc3501>.
+
+   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+              October 2008, <http://www.rfc-editor.org/info/rfc5321>.
+
+   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598, July
+              2009, <http://www.rfc-editor.org/info/rfc5598>.
+
+   [RFC5750]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+              Mail Extensions (S/MIME) Version 3.2 Certificate
+              Handling", RFC 5750, January 2010,
+              <http://www.rfc-editor.org/info/rfc5750>.
+
+   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+              Mail Extensions (S/MIME) Version 3.2 Message
+              Specification", RFC 5751, January 2010,
+              <http://www.rfc-editor.org/info/rfc5751>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cailleux & Bonatti            Experimental                     [Page 15]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+Appendix A.  Formal Syntax of Secure Header
+
+   Note: The ASN.1 module contained herein uses the 1988 version of
+   ASN.1 notation [ASN1-88] for the purposes of alignment with the
+   existing S/MIME specifications.  The SecureHeaderFields structure is
+   defined as follows:
+
+     mod-SMimeSecureHeadersV1
+       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+       pkcs-9(9) smime(16) modules(0) secure-headers-v1(65) }
+
+     DEFINITIONS IMPLICIT TAGS ::=
+
+     BEGIN
+
+     IMPORTS
+
+       id-aa
+            FROM SecureMimeMessageV3dot1
+                 { iso(1) member-body(2) us(840) rsadsi(113549)
+                 pkcs(1) pkcs-9(9) smime(16) modules(0)
+                 msg-v3dot1(21) };
+
+     -- id-aa is the arc with all new authenticated and
+     -- unauthenticated attributes produced by the S/MIME
+     -- Working Group
+
+      id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= {
+         id-aa secure-headers(55) }
+
+      SecureHeaderFields ::= SET {
+           canonAlgorithm Algorithm,
+           secHeaderFields HeaderFields }
+
+      Algorithm ::= ENUMERATED {
+           canonAlgorithmSimple(0),
+           canonAlgorithmRelaxed(1) }
+
+      HeaderFields ::= SEQUENCE SIZE (1..MAX) OF HeaderField
+
+      HeaderField ::= SEQUENCE {
+           field-Name HeaderFieldName,
+           field-Value HeaderFieldValue,
+           field-Status HeaderFieldStatus DEFAULT duplicated }
+
+      HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":")))
+           -- This description matches with the description of
+           -- field name in the Sections 2.2 and 3.6.8 of RFC 5322
+
+
+
+Cailleux & Bonatti            Experimental                     [Page 16]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+      HeaderFieldValue ::= UTF8String
+           -- This description matches with the description of
+           -- field body in the Section 2.2 of RFC 5322 as
+           -- extended by Section 3.1 of RFC 6532.
+
+      HeaderFieldStatus ::= INTEGER {
+           duplicated(0), deleted(1), modified(2) }
+
+      END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cailleux & Bonatti            Experimental                     [Page 17]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+Appendix B.  Example of Secure Header Fields
+
+   In the following example, the header fields subject,
+   x-ximf-primary-precedence, and x-ximf-correspondance-type are secured
+   and integrated in a SecureHeaderFields structure.  This example
+   should produce a valid signature.
+
+   Extract from the message header fields:
+
+      From: John Doe <jdoe@example.com>
+      To: Mary Smith <mary@example.com>
+      subject: This is a test of Ext.
+      x-ximf-primary-precedence: priority
+      x-ximf-correspondance-type: official
+
+   The SecureHeaderFields structure extracted from the signature:
+
+   2286  150: SEQUENCE {
+   2289   11:   OBJECT IDENTIFIER '1 2 840 113549 1 9 16 2 80'
+   2302  134:   SET {
+   2305  131:     SET {
+   2308    4:       ENUMERATED 1
+   2314  123:       SEQUENCE {
+   2316   40:         SEQUENCE {
+   2318   25:           VisibleString 'x-ximf-primary-precedence'
+   2345    8:           UTF8String 'priority'
+   2355    1:           INTEGER 0
+            :           }
+   2358   41:         SEQUENCE {
+   2360   26:           VisibleString 'x-ximf-correspondance-type'
+   2388    8:           UTF8String 'official'
+   2398    1:           INTEGER 0
+            :           }
+   2401   36:         SEQUENCE {
+   2403    7:           VisibleString 'subject'
+   2412   22:           UTF8String 'This is a test of Ext.'
+   2436    1:           INTEGER 0
+            :           }
+            :         }
+            :       }
+            :     }
+            :   }
+
+   The example is displayed as an output of Peter Gutmann's "dumpasn1"
+   program.
+
+   OID used in this example is nonofficial.
+
+
+
+
+Cailleux & Bonatti            Experimental                     [Page 18]
+
+RFC 7508           Securing Header Fields with S/MIME         April 2015
+
+
+Acknowledgements
+
+   The authors would like to thank Jim Schaad, Alexey Melnikov, Damien
+   Roque, Thibault Cassan, William Ottaway, and Sean Turner who kindly
+   provided reviews of the document and/or suggestions for improvement.
+   As always, all errors and omissions are the responsibility of the
+   authors.
+
+Authors' Addresses
+
+   Laurent CAILLEUX
+   DGA MI
+   BP 7
+   35998 RENNES CEDEX 9
+   France
+
+   EMail: laurent.cailleux@intradef.gouv.fr
+
+
+   Chris Bonatti
+   IECA, Inc.
+   3057 Nutley Street, Suite 106
+   Fairfax, VA  22031
+   United States
+
+   EMail: bonatti252@ieca.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cailleux & Bonatti            Experimental                     [Page 19]
+