Network Working Group
Independent Submission                                       L. Cailleux
Internet-Draft
Request for Comments: 7508                                        DGA MI
Intended status:
Category: Experimental                                        C. Bonatti
Expires: 22 July 2015
ISSN: 2070-1721                                                     IECA
                                                  22 January
                                                              April 2015

                   Securing Header Fields with S/MIME
                  draft-cailleux-secure-headers-08

Abstract

   This document describes how the S/MIME protocol can be extended in
   order to secure message header fields. fields defined in RFC 5322.  This
   technology provides security services such as data integrity,
  non-repudiation non-
   repudiation, and confidentiality.  This extension is referred to as
   'Secure Headers'.

Status of this This Memo

   This Internet-Draft document is submitted in full conformance with the
  provisions of BCP 78 not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and BCP 79.

  Internet-Drafts are working documents of
   evaluation.

   This document defines an Experimental Protocol for the Internet
  Engineering Task Force (IETF).  Note that
   community.  This is a contribution to the RFC Series, independently
   of any other groups may
  also distribute working documents as Internet-Drafts. RFC stream.  The
  list of current Internet-Drafts is RFC Editor has chosen to publish this
   document at
  http://datatracker.ietf.org/drafts/current/.

  Internet-Drafts are draft documents valid its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a maximum candidate for any level of six
  months 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 updated, replaced, or obsoleted by other
  documents obtained at any time.  It is inappropriate to use Internet-
  Drafts as reference material or to cite them other than as
  "work in progress."

  This Internet-Draft will expire on 22 July 2015.
   http://www.rfc-editor.org/info/rfc7508.

Copyright Notice

   Copyright (c) 2014 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.  Code Components
  extracted from this document MUST include Simplified BSD
  License text as described in Section 4.e of the Trust Legal
  Provisions and are provided without warranty as described in
  the Simplified BSD License.

Table of Contents

   1. Introduction..............................................3 Introduction ....................................................2
   2. Terminology and conventions used Conventions Used in this document.........3 This Document ...............3
   3. Context...................................................5 Context .........................................................4
   4. Mechanisms to secure message header fields................7 Secure Message Header Fields ......................6
      4.1. ASN.1 syntax Syntax of secure header fields.................9 Secure Header Fields .......................7
      4.2. Secure header fields length Header Fields Length and format..............10 Format .....................8
      4.3. Canonization algorithm..............................10 Canonicalization Algorithm .................................8
      4.4. Header fields statuses..............................10 Field Statuses ......................................8
      4.5. Signature Process...................................11 Process ..........................................9
           4.5.1. Signature Generation Process...................11 Process ........................9
           4.5.2. Signature verification process.................12 Verification Process .....................10
      4.6. Encryption and Decryption Processes.................14 Processes .......................11
           4.6.1. Encryption Process.............................14 Process .................................11
           4.6.2. Decryption Process.............................15 Process .................................12
   5. Case of triple wrapping..................................16 Triple Wrapping ........................................13
   6. Security Gateways........................................16 Gateways ..............................................13
   7. Security Considerations..................................17 Considerations ........................................13
   8. IANA Considerations......................................18 Considerations ............................................14
   9. References...............................................18 References .....................................................14
      9.1. Normative References................................18 References ......................................14
      9.2. Informative References..............................19 References ....................................15
   Appendix A. Formal syntax Syntax of Secure Header..................20 Header ........................16
   Appendix B. Example of Secure Header Fields example....................22
   Appendix C. Acknowledgements................................24 .......................18
   Acknowledgements ..................................................19
   Authors' Addresses ................................................19

1.  Introduction

   The S/MIME [RFC 5751] [RFC5751] standard defines a data encapsulation format for
   the achievement of end to end end-to-end security services such as integrity,
   authentication, non-repudiation 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 fields: "the
   sending client MAY wrap a full MIME [RFC 2045] 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 standards specifications supplement S/MIME features, features but
   fail to address the target requirement set of this draft. document.  Such
   other security standards specifications include DKIM [RFC 6376], DomainKeys Identified Mail
   (DKIM) [RFC6376], STARTTLS [RFC 3207], [RFC3207], TLS with IMAP [RFC 2595], [RFC2595], and an internet
  draft
   Internet-Draft referred to as PROTECTED HEADERS. "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 end-to-end secure header fields field
   mechanisms compliant with S/MIME standard.  This technique is based
   on the signed attribute fields of a Cryptographic Message Syntax
   (CMS) [RFC 5652] [RFC5652] signature.

2.  Terminology and conventions used Conventions Used in this document 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 [RFC 2119]. [RFC2119].

   The terms Message User Agent (MUA), Message Submission Agent
  (MSA) (MSA),
   and Message Transfer Agent (MTA) terms are defined in
  Email the email
   architecture document [RFC 5598]. [RFC5598].

   The term Domain Confidentiality Authority (DCA) is defined in the
   S/MIME Domain Security specification [RFC 3183]. [RFC3183].

   End-to-end Internet Mail exchanges are performed between message
   originators and recipients.

   The term "message message header fields" fields is described in [RFC 5322]. [RFC5322].  A header
   field is composed of a name and a value.

   Secure Headers technology uses header fields field statuses required to
   provide a confidentiality service toward message headers.  The
   following three terms are used to describe the field statuses:

   - Duplicated  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 will also be
      present in the message header fields.

   - Deleted.  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.  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 non-compliant
      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, secured; use a compliant client"). client.").

   The term "non-repudiation" non-repudiation is used throughout this document in
   deference to the usage in the S/MIME Message Specification
  [RFC 5751]. [RFC5751].
   It is recognized that this term carries with it much baggage, and
   that there is some disagreement as to it's its proper meaning and usage.
   However, in the context of this
  document document, the term merely refers to
   one of a 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 usage use has grown and today represents a
   fundamental service.  Meanwhile, continually increasing threat levels
   are motivating the implementation of security services.

   Historically, SMTP [RFC 5321] [RFC5321] and IMF [RFC 5322] the Internet Message Format (IMF)
   [RFC5322] don't provide, by default, security services.  The S/MIME
   standard
  [RFC 5751] [RFC5751] was published in order to encompass address these needs.
   S/MIME defines a data encapsulation format for the provision of end to end end-
   to-end security services such as integrity, authentication, non-repudiation 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"
   "From", or customized fields), several solutions exist.

   In Section 3.1 of [RFC5751], S/MIME defines an encapsulation mechanism, chapter 3.1: "The
   mechanism:

      [...] the sending client may 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 "inner" header along with the
      unprotected outer header". "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.

   Some partial header protection is provided by the S/MIME Certificate
   Handling specification [RFC 5750].  "Receiving [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". certificate.

   In some cases cases, this may provide assurance of the integrity of the
   From or Sender header values.  However, the solution in RFC 5750 solution only
   provides a matching mechanism between email addresses, addresses and provides no
   protection to other header fields.

   Other security standards specifications (introduced below) exist such as DKIM,
   STARTTLS and TLS with IMAP IMAP, but they meet other needs (signing
   domain, secure channels...). channels, etc.).

   STARTTLS and TLS with IMAP provide secure channels between components
   of the email system (MUA, MSA, MTA...) MTA, etc.), but end to end 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 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 of this fact.) headers.)  DKIM
   is also deficient for our purposes purposes, as it does not provide a
   confidentially service.

   An internet draft Internet-Draft referred to as Protected Headers (PRHDRS) "Protected Headers" [PRHDRS] has
   been proposed.  Mechanisms described in this draft that document are the
  following. "A
   following:

      [...] a digest value is computed over the canonicalized version of
      some selected header fields.  This technique resembles header
      protection in DKIM. [RFC4871].  Then the digest value is included in a
      signed attribute field of a CMS signature". This 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.

   This document proposes a technology for securing message header
   fields.  It's referred to as Secure Headers. "Secure Headers".  It is based on S/MIME
   and CMS standards.  It provides security services such as data
   integrity, confidentiality 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 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 (secure
  header (SecureHeaderFields structure) which
   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 chapter Section 5.4 of CMS, 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
  described in chapter 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
  described in chapter Section 4.5.2 of this document.

   Non-conforming S/MIME clients will ignore the signed attribute
   containing the secure headers 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 non-
   repudiation, and confidentiality.

   For different reasons (e.g., usability, limits of IMAP [RFC
  3501]), [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 Domain Confidentiality Authority" Authority
   (DCA).  Details of the encryption and decryption processes are described in chapters
   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 Syntax of secure header fields Secure Header Fields

   The ASN.1 notation syntax [ASN1-88] of secure header the SecureHeaderFields structure is the
  follow: 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) secure-headers (to be
      defined) 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 }
      HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":")))
           -- This description matches with the description of
           -- field name in the chapters Sections 2.2 and 3.6.8 of RFC 5322

      HeaderFieldValue ::= UTF8String
           -- This description matches with the description of
           -- field body in the chapter Section 2.2 of RFC 5322 as
           -- extended by chapter Section 3.1 of RFC 6532.

      HeaderFieldStatus ::= INTEGER {
         duplicated(0), deleted(1), modified(2) }

4.2.  Secure header fields length Header Fields Length and format Format

   This specification requires MUA security capabilities in order to
   process well formed well-formed headers, as specified in IMF.  Notice that it
   includes long header fields and folded header fields.

4.3. Canonization algorithm  Canonicalization Algorithm

   During a message transfer through a messaging system, some components
   might modify headers (i.e., space adding or
  deletion, lowercase/uppercase rewriting...). deleting space, changing or
   lowercase or uppercase).  This might lead to header fields a comparison mismatch. 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 canonization the canonicalization process.

   Two canonization canonicalization algorithms are considered here, according to
   Section 3.4 of the DKIM specification [RFC 6376], chapter 3.4. [RFC6376].  The simple "simple"
   algorithm doesn't allow any modification modification, whereas the relaxed "relaxed"
   algorithm accepts slight modifications like spaces space replacement or line
   reformatting.  Given the scope of this document,
  canonization canonicalization
   mechanisms only involve header fields.

   Implementations SHOULD use the relaxed "relaxed" algorithm to promote
   interoperability with non-conforming SMTP products.

4.4.  Header fields statuses Field Statuses

   Header fields field statuses are necessary to provide a confidentiality
   service toward for message headers.  In this specification, the
   confidentiality of header fields is provided by the DCA.  This point
   is described in chapter Section 4.  The DCA performs the message encryption
   process and message decryption process and process; these processes are described
   in
  details detail in the chapters Sections 4.6.1 and 4.6.2.  Although header
  fields field
   statuses are embedded in the signature, the signature processes
   (generation and verification) ignore them.  The header field status
   defaults to duplicated. "duplicated".  If the header field is confidential, the
   header field status MUST be either
  deleted "deleted" or modified. "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 canonization
   canonicalization algorithm.

   The sender's MUA MUST have a list of header fields to secure,
  statuses
   statuses, and a canonization canonicalization algorithm, as defined by the
   security policy.

   Header fields (names and values) embedded in signed attributes MUST
   be the same as the ones 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
  MULTISIGN [RFC 4853] 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. field-Value.

   Considering secure headers 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 canonization 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
     canonization canonicalization
         algorithm configured.

      5) Embed the SecureHeaderFields structure in the signed attributes
         of the SignerInfos object.

      6) Compute the signature generation process as described in
     CMS, chapter
         Section 5.5 of CMS [RFC5652].

4.5.2.  Signature verification process 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 canonization
   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 non-secure header is
   present.

   Considering secure headers header mechanisms, the signature verification
   process MUST perform the following steps:

      1) Execute the signature verification process as described
     in CMS, chapter 5.6. 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 canonization 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 headers header fields encrypted as per
     section 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 canonization canonicalization algorithm for each header field
         value in the message.  If the simple "simple" algorithm is used, the
         steps described in DKIM, chapter 3.4.1, Section 3.4.1 of DKIM [RFC6376] are
         performed.  If the relaxed algorithm is used, the steps
         described in DKIM,
     chapter 3.4.2, Section 3.4.2 of DKIM [RFC6376] are performed.

      5) For each field, compare the value stored in the
         SecureHeaderFields structure with the value returned by the
     canonization
         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 every each mandatory headers header in the security policy and
         present in the message are 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 features for the properties of each secure header field
   (name, value value, and status) and canonization 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 example, IMAP.  The solution developed here relies on
   concepts explained in Section 4 of the Domain Security
   specification, chapter 4. specification
   [RFC3183].  A fundamental component of the architecture is the Domain
   Confidentiality Authority (DCA).  Its purpose is to encrypt and
   decrypt messages instead of
   (respectively) that being performed by senders and receivers.
   receivers (respectively).

4.6.1.  Encryption Process

   All the computations presented in this chapter 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 SignedData, or multipart/signed)
         as shown in Section 3.4 of the S/MIME specification, chapter
     3.4. specification [RFC5751].

      -  A SecureHeaderFields structure MUST be included in the
         signedAttrs field of the SignerInfo object of the signature.

   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. The  For extraction of the field status, the following
   steps MUST be performed for each field included in the
   SecureHeaderFields structure:

      1. Extraction of the field status;

     1.1 If the status is Duplicated, "duplicated", the field is left at its
         existing value.

     1.2

      2. If the status is Deleted, "deleted", the header field (name and value)
         is removed from the message.  Mandatory header fields specified
         in [RFC 5322] [RFC5322] MUST be kept.

     1.3

      3. If the status is Modified, "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 chapter 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, chapter 3.4. 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, "duplicated", the field is left at its
         existing value.

      2. If the status is Deleted, "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, "modified", the DCA MUST rewrite a header
         field in the message.  This header MUST be compliant with the
         SecureHeaderFields structure.

5.  Case of triple wrapping Triple Wrapping

   Secure Headers mechanisms MAY be used with triple wrapping, as
   described in ESS [RFC 2634]. Enhanced Security Services (ESS) [RFC2634].  In this
   case, a SecureHeaderFields structure MAY be present in the inner
   signature, in the outer signature, or both.  In the last case, the two structure
   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 purpose.  Sender's 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 part dedicated parts -- one for the inner
   signature and one part dedicated 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 chapter Section
   4.5.

   For non-compliant noncompliant gateways, the presence of a SecureHeaderFields
   structure do 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 headers header integrity, non-
  repudiation 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 effective, all
   DCAs supporting confidentiality must support SH Secure Headers
   processing.  Otherwise, there is a risk in the case where that headers are not obscured
   upon encryption, encryption or not restored upon
  decryption process. decryption.  In the former case case,
   confidentiality of the header fields is compromised.  In the latter case
   case, the integrity of the headers will appear to be compromised.

8.  IANA Considerations

   IANA must register a suitable Object Identifier (OID) 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 identifier id-aa-secureHeaderFieldsIdentifier. "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 [RFC 5652] wrapper.
   wrapper [RFC5652].  This attribute OID appears in Section 4.1, 4.1 and
   again in the reference definition in Appendix A.  An appropriate registry arc is suggested in
  those instances of the draft text.

9.  References

9.1.  Normative References

   [RFC 2045]  Borenstein, N., "Multipurpose Internet Mail
               Extensions Part One", RFC 2045, November 1996.

   [RFC 2119]

   [RFC2119]  Bradner, S., "Key words for use in RFCs to
               indicate requirement levels", Indicate
              Requirement Levels", BCP 14, RFC 2119, March
               1997.

   [RFC 2634] 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2634]  Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
              RFC 2634, June 1999.

   [RFC 4853] 1999,
              <http://www.rfc-editor.org/info/rfc2634>.

   [RFC4853]  Housley, R., "Cryptographic Message Syntax (CMS), (CMS) Multiple
              Signer Clarification", RFC 4853, April
               2007.

   [RFC 5322] 2007,
              <http://www.rfc-editor.org/info/rfc4853>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

   [RFC 5652] 2008, <http://www.rfc-editor.org/info/rfc5322>.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, September 2009.

   [RFC 6376] 2009,
              <http://www.rfc-editor.org/info/rfc5652>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, M., DomainKeys Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, September 2011. 2011,
              <http://www.rfc-editor.org/info/rfc6376>.

   [ASN1-88]   CCITT.  CCITT, Recommendation X.208: Specification of Abstract
              Syntax Notation One (ASN.1), 1988.

9.2.  Informative References

   [RFC 2595]

   [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.

   [RFC 3183] 1999, <http://www.rfc-editor.org/info/rfc2595>.

   [RFC3183]  Dean, T., T. and W. Ottaway, W., "Domain security services Security Services using
              S/MIME", RFC 3183, October 2001.

   [RFC 3207] 2001,
              <http://www.rfc-editor.org/info/rfc3183>.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for secure Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

   [RFC 3501] 2002,
              <http://www.rfc-editor.org/info/rfc3207>.

   [RFC3501]  Crispin, M., "Internet Message Access Protocol,
               version "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

   [RFC 5321] 2003,
              <http://www.rfc-editor.org/info/rfc3501>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC 5598] 2008, <http://www.rfc-editor.org/info/rfc5321>.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.

   [RFC 5750]
              2009, <http://www.rfc-editor.org/info/rfc5598>.

   [RFC5750]  Ramsdell, B., B. and S. Turner, S., "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Certificate
              Handling", RFC 5750, January 2010.

   [RFC 5751] 2010,
              <http://www.rfc-editor.org/info/rfc5750>.

   [RFC5751]  Ramsdell, B., B. and S. Turner, S., "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2, 3.2 Message
              Specification", RFC 5751, January 2010. 2010,
              <http://www.rfc-editor.org/info/rfc5751>.

Appendix A.  Formal syntax 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
  th the
   existing S/MIME specifications.  The secure header SecureHeaderFields structure is
   defined as follows:

  SMimeSecureHeadersV1

     mod-SMimeSecureHeadersV1
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
       pkcs-9(9) smime(16) modules(0) secure-headers-v1(to be
  defined) 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 (to be defined) 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 chapters Sections 2.2 and 3.6.8 of RFC 5322
      HeaderFieldValue ::= UTF8String
           -- This description matches with the description of
           -- field body in the chapter Section 2.2 of RFC 5322 as
           -- extended by chapter Section 3.1 of RFC 6532.

      HeaderFieldStatus ::= INTEGER {
           duplicated(0), deleted(1), modified(2) }

      END

Appendix B.  Example of Secure Header Fields example

   In the following example, the header fields subject, x-ximf-
   primary-precedence
   x-ximf-primary-precedence, and x-ximf-correspondance-type are secured
   and integrated in a SecureHeaders SecureHeaderFields structure.  This example
   should produce a valid signature.

   Extract of from the message header fields 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

SecureHeaders

   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
            :           }
            :         }
            :       }
            :     }
            :   }

   Example

   The example is displayed as an output of Peter Gutmann's "dumpasn1"
   program.

   OID used in this example is non-official.

Appendix C. nonofficial.

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:

   EMail: laurent.cailleux@intradef.gouv.fr

   Chris Bonatti
   IECA, Inc.
   3057 Nutley Street, Suite 106
   Fairfax, VA  22031
  USA
  Email:
   United States

   EMail: bonatti252@ieca.com