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

The information below is for an old version of the document that is already published as an RFC
Document Type RFC Internet-Draft (individual)
Authors Laurent Cailleux  , Chris Bonatti 
Last updated 2020-01-21 (latest revision 2015-01-22)
Stream Independent Submission
Formats pdf htmlized (tools) htmlized bibtex
IETF conflict review conflict-review-cailleux-secure-headers
Stream ISE state Published RFC
Consensus Boilerplate Unknown
Document shepherd Adrian Farrel
Shepherd write-up Show (last changed 2014-08-11)
IESG IESG state RFC 7508 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack
Network Working Group                                 L. Cailleux 
Internet-Draft                                             DGA MI 
Intended status: Experimental                          C. Bonatti 
Expires: 22 July 2015                                        IECA 
                                                  22 January 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. 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 Internet-Draft is submitted in full conformance with the 
  provisions of BCP 78 and BCP 79. 
   
  Internet-Drafts are working documents of the Internet 
  Engineering Task Force (IETF).  Note that other groups may 
  also distribute working documents as Internet-Drafts.  The 
  list of current Internet-Drafts is at 
  http://datatracker.ietf.org/drafts/current/. 
   
  Internet-Drafts are draft documents valid for a maximum of six 
  months and may be updated, replaced, or obsoleted by other 
  documents 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. 
   

 
 
 
Cailleux & Bonatti       Expires 22 July 2015            [Page 1] 
 
    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

Copyright Notice 

  Copyright (c) 2014 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 
   2. Terminology and conventions used in this document.........3 
   3. Context...................................................5 
   4. Mechanisms to secure message header fields................7 
      4.1. ASN.1 syntax of secure header fields.................9 
      4.2. Secure header fields length and format..............10 
      4.3. Canonization algorithm..............................10 
      4.4. Header fields statuses..............................10 
      4.5. Signature Process...................................11 
         4.5.1. Signature Generation Process...................11 
         4.5.2. Signature verification process.................12 
      4.6. Encryption and Decryption Processes.................14 
         4.6.1. Encryption Process.............................14 
         4.6.2. Decryption Process.............................15 
   5. Case of triple wrapping..................................16 
   6. Security Gateways........................................16 
   7. Security Considerations..................................17 
   8. IANA Considerations......................................18 
   9. References...............................................18 
      9.1. Normative References................................18 
      9.2. Informative References..............................19 
   Appendix A. Formal syntax of Secure Header..................20 
 
 
Cailleux & Bonatti       Expires 22 July 2015            [Page 2] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

   Appendix B. Secure Header Fields example....................22 
   Appendix C. Acknowledgements................................24 
    

1. Introduction 

  S/MIME [RFC 5751] 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 [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 supplement S/MIME features, 
  but fail to address the target requirement set of this draft.  
  Such other security standards include DKIM [RFC 6376], 
  STARTTLS [RFC 3207], TLS with IMAP [RFC 2595], and an internet 
  draft referred to as PROTECTED HEADERS.  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 fields mechanisms compliant with S/MIME standard. This 
  technique is based on the signed attribute fields of a 
  Cryptographic Message Syntax (CMS) [RFC 5652] 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 
 
 
Cailleux & Bonatti       Expires 22 July 2015            [Page 3] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

  "OPTIONAL" in this document are to be interpreted as described 
  in [RFC 2119]. 
   
  The terms Message User Agent (MUA), Message Submission Agent 
  (MSA) and Message Transfer Agent (MTA) terms are defined in 
  Email architecture document [RFC 5598]. 
   
  The term Domain Confidentiality Authority (DCA) is defined in 
  the S/MIME Domain Security specification [RFC 3183]. 
   
  End-to-end Internet Mail exchanges are performed between 
  message originators and recipients. 
   
  The term "message header fields" is described in [RFC 5322].  
  A header field is composed of a name and a value. 
   
  Secure Headers technology uses header fields 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 will also be 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 non-compliant MUA 
 
 
Cailleux & Bonatti       Expires 22 July 2015            [Page 4] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

     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 
  [RFC 5751].  It is recognized that this term carries with it 
  much baggage, and that there is some disagreement as to it's 
  proper meaning and usage.  However, in the context of this 
  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 has grown and today represents 
  a fundamental service. Meanwhile, continually increasing 
  threat levels are motivating the implementation of security 
  services. 
   
  Historically, SMTP [RFC 5321] and IMF [RFC 5322] don't 
  provide, by default, security services. The S/MIME standard 
  [RFC 5751] was published in order to encompass 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. 
   
  S/MIME defines an encapsulation mechanism, chapter 3.1: "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 
 
 
Cailleux & Bonatti       Expires 22 July 2015            [Page 5] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

  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. 
   
  Some partial header protection is provided by the S/MIME 
  Certificate Handling specification [RFC 5750].  "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 RFC 5750 solution only provides a 
  matching mechanism between email addresses, and provides no 
  protection to other header fields. 
   
  Other security standards (introduced below) exist such as 
  DKIM, STARTTLS and TLS with IMAP but meet other needs (signing 
  domain, secure channels...). 
   
  STARTTLS and TLS with IMAP provide secure channels between 
  components of email system (MUA, MSA, MTA...) 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 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 as part of 
  the signed message headers of this fact.)  DKIM is also 
  deficient for our purposes as it does not provide a 
  confidentially service. 
   
 
 
Cailleux & Bonatti       Expires 22 July 2015            [Page 6] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

  An internet draft referred to as Protected Headers (PRHDRS) 
  has been proposed. Mechanisms described in this draft are the 
  following. "A digest value is computed over the canonicalized 
  version of some selected header fields. This technique 
  resembles header protection in DKIM. Then the digest value is 
  included in a signed attribute field of a CMS signature". This 
  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. It is based 
  on S/MIME and CMS standards. It provides security services 
  such as data integrity, confidentiality and non-repudiation of 
  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 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 structure) which is encapsulated in the signed 
  attributes structure of the SignerInfo object.  There is only 
  one value of HeaderFields encoded into a single 
 
 
Cailleux & Bonatti       Expires 22 July 2015            [Page 7] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

  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 
  5.4 of CMS, 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 4.5.1 of this document. 
   
  Verification of secure header fields is based on 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 4.5.2 of this document. 
   
  Non-conforming S/MIME clients will ignore the signed attribute 
  containing the secure headers 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. 
   
  For different reasons (e.g., usability, limits of IMAP [RFC 
  3501]), encryption and decryption processes are performed by a 
  third party. The third party that performs these processes is 
  referred to in Domain Security specification as a "Domain 
  Confidentiality Authority" (DCA). Details of the encryption 
  and decryption processes are described in chapters 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. 
 
 
Cailleux & Bonatti       Expires 22 July 2015            [Page 8] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

   
          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 

  ASN.1 notation [ASN1-88] of secure header structure is the 
  follow: 
   
   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) } 
    
   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 2.2 and 3.6.8 of RFC 5322 
 
 
Cailleux & Bonatti       Expires 22 July 2015            [Page 9] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

    
   HeaderFieldValue ::= UTF8String 
        -- This description matches with the description of 
        -- field body in the chapter 2.2 of RFC 5322 as 
        -- extended by chapter 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. Canonization algorithm 

  During a message transfer through a messaging system, some 
  components might modify headers (i.e., space adding or 
  deletion, lowercase/uppercase rewriting...). This might lead 
  to header fields comparison mismatch. This emphasizes the need 
  of a conversion process in order to transform data to their 
  canonical form. This process is named canonization process. 
   
  Two canonization algorithms are considered here, according to 
  DKIM specification [RFC 6376], chapter 3.4. The simple 
  algorithm doesn't allow any modification whereas the relaxed 
  algorithm accepts slight modifications like spaces replacement 
  or line reformatting. Given the scope of this document, 
  canonization mechanisms only involve header fields. 
   
  Implementations SHOULD use the relaxed algorithm to promote 
  interoperability with non-conforming SMTP products. 

4.4. Header fields statuses 

  Header fields statuses are necessary to provide a 
  confidentiality service toward message headers. In this 
  specification, the confidentiality of header fields is 
 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 10] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

  provided by the DCA. This point is described in chapter 4. The 
  DCA performs the message encryption process and message 
  decryption process and these processes are described in 
  details in the chapters 4.6.1 and 4.6.2. Although header 
  fields statuses are embedded in the signature, the signature 
  processes (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. SecureHeaderFields structure 
  MUST include a canonization algorithm. 
   
  The sender's MUA MUST have a list of header fields to secure, 
  statuses and a canonization algorithm, as defined by the 
  security policy. 
   
  Header fields (names and values) embedded in signed attributes 
  MUST be the same as the ones 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 CMS and 
  MULTISIGN [RFC 4853] specifications, 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. 
   

 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 11] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

  Considering secure headers 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 algorithm for each selected header 
     field. 
      
     3) Complete the following fields in SecureHeaderFields 
     structure according to the initial message: HeaderFieldName, 
     HeaderFieldValue, HeaderFieldStatus. 
      
     4) Complete the algorithm field according to the 
     canonization 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 5.5 

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 canonization 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 
 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 12] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

  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 headers mechanisms, the signature 
  verification process MUST perform the following steps: 
   
     1) Execute the signature verification process as described 
     in CMS, chapter 5.6. If the signature appears to be invalid, 
     the process ends. Otherwise, the process continues. 
      
     2) Read the type of canonization algorithm specified in 
     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 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 canonization algorithm for each header field 
     value in the message. If the simple algorithm is used, the 
     steps described in DKIM, chapter 3.4.1, are performed. If 
     the relaxed algorithm is used, the steps described in DKIM, 
     chapter 3.4.2, are performed. 
      
     5) For each field, compare the value stored in the 
     SecureHeaderFields structure with the value returned by the 
     canonization algorithm. If 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). 
 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 13] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

      
     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 mandatory headers in the security 
     policy and present in the message are 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 each secure header field 
  (name, value and status) and canonization 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 Domain Security 
   specification, chapter 4. A fundamental component of the 
   architecture is the Domain Confidentiality Authority (DCA). 
   Its purpose is to encrypt and decrypt messages instead of 
   (respectively) senders and receivers. 

4.6.1. Encryption Process 

  All the computations presented in this chapter 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 

 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 14] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

     multipart/signed) as shown in S/MIME specification, chapter 
     3.4. 
      
     - 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 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, the field is left at its 
     existing value. 
      
     1.2 If the status is Deleted, the header field (name and 
     value) is removed from the message. Mandatory header fields 
     specified in [RFC 5322] MUST be kept. 
      
     1.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 chapter 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 S/MIME specification, chapter 3.4. 
      
     - A SecureHeaderFields structure MUST be included in the 
     SignerInfo object of the signature. 
   
 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 15] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

  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. 

5. Case of triple wrapping 

  Secure Headers mechanisms MAY be used with triple wrapping, as 
  described in ESS [RFC 2634]. 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 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 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 for the 
  inner signature and one part dedicated 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 4.5. 

 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 16] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

   
  For non-compliant gateways, the presence of SecureHeaderFields 
  structure do not change their behavior. 
   
  In some case, gateways MUST generate 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 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 
  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 SH 
  processing. Otherwise, there is a risk in the case where 
  headers are not obscured upon encryption, or not restored upon 
  decryption process. 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. 

 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 17] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

8. IANA Considerations 

  IANA must register a suitable Object Identifier (OID) value 
  for the identifier id-aa-secureHeaderFieldsIdentifier.  This 
  value will be used to identify an authenticated attribute 
  carried within a CMS [RFC 5652] wrapper.  This attribute OID 
  appears in Section 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]  Bradner, S., "Key words for use in RFCs to 
               indicate requirement levels", RFC 2119, March 
               1997.  

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

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

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

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

   [RFC 6376]  Crocker, D., Hansen, T., Kucherawy, M., DomainKeys 
               Identified Mail (DKIM) Signatures", RFC 6376, 
               September 2011.  

   [ASN1-88]   CCITT. Recommendation X.208: Specification of 
               Abstract Syntax Notation One (ASN.1), 1988. 
 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 18] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

9.2. Informative References 

   [RFC 2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", 
               RFC 2595, June 1999.  

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

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

   [RFC 3501]  Crispin, M., "Internet Message Access Protocol, 
               version 4rev1", RFC 3501, March 2003.  

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

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

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

   [RFC 5751]  Ramsdell, B., Turner, S., "Secure/Multipurpose 
               Internet Mail Extensions (S/MIME) Version 3.2, 
               Message Specification", RFC 5751, January 2010. 

 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 19] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 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 
  th existing S/MIME specifications. The secure header structure 
  is defined as follows: 
   
  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) } 
   
  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) } 
    
   SecureHeaderFields ::= SET { 
        canonAlgorithm Algorithm, 
        secHeaderFields HeaderFields } 
    
   Algorithm ::= ENUMERATED { 
        canonAlgorithmSimple(0), 
        canonAlgorithmRelaxed(1) } 
 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 20] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

    
   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 2.2 and 3.6.8 of RFC 5322 
    
   HeaderFieldValue ::= UTF8String 
        -- This description matches with the description of 
        -- field body in the chapter 2.2 of RFC 5322 as 
        -- extended by chapter 3.1 of RFC 6532. 
    
   HeaderFieldStatus ::= INTEGER { 
        duplicated(0), deleted(1), modified(2) } 
    
   END 
    

 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 21] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

Appendix B. Secure Header Fields example 

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

   Extract of 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 
 
SecureHeaders structure extracted from 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 
           :           } 
 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 22] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

           :         } 
           :       } 
           :     } 
           :   } 
 
 
   Example is displayed as an output of Peter Gutmann's 
   "dumpasn1" program. 

   OID used in this example is non-official. 

   

 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 23] 
    

    

Internet-Draft    Securing Header Fields with S/MIME     Jan 2015 
    

    

Appendix C. 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 
  USA 
  Email: bonatti252@ieca.com 
   

 
 
Cailleux & Bonatti       Expires 22 July 2015           [Page 24]