[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 7508

     Network Working Group                                       L. Cailleux
     Internet-Draft                                                   DGA MI
     Intended status: Experimental                                C. Bonatti
     Expires: 16 April 2012                                             IECA
                                                             16 October 2011
     
     
                         Securing Header Fields with S/MIME
                          draft-cailleux-secure-headers-00
     
     
     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 16 April 2012.
     
       Draft Version 0.26 (20110728)
     
     Copyright Notice
     
       Copyright (c) 2011 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
     
     
     
     Cailleux                Expires 16 April 2012                  [Page 1]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
       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...................................................2
        2. Terminology and conventions used in this document..............3
        3. Context........................................................3
        4. Mechanisms to secure message header fields.....................5
           4.1. ASN.1 syntax of secure header fields......................6
           4.2. Secure header fields length and format....................7
           4.3. Canonization algorithm....................................7
           4.4. Header fields statuses....................................8
           4.5. Signature Process.........................................8
              4.5.1. Signature Generation Process.........................8
              4.5.2. Signature verification process.......................9
           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 Considerations.......................................13
        7. References....................................................13
           7.1. Normative References.....................................13
           7.2. Informative References...................................14
        Appendix A. Formal syntax of Secure Header.......................15
        Appendix B. Secure Header Fields example.........................16
        Appendix C. Acknowledgements.....................................18
     
     
     1. Introduction
     
       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 [RFC2045] message in a
       message/rfc822 wrapper in order to apply S/MIME security services to
       header fields". However, the S/MIME solution doesn't allow selection
     
     
     
     Cailleux & Bonatti                                             [Page 2]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
       of a subset of message header fields to secure. In addition,
       confidentiality service can not be implemented for message header
       fields. The solution described herein overcomes those limitations.
     
       Several security standards exist such as DKIM [RFC4871], STARTTLS
       [RFC3207] and TLS with IMAP [RFC2595] but meet other needs (signing
       domain, secure channels). An internet draft referred to as PROTECTED
       HEADERS has been proposed, but doesn't address all the requirements.
       These different solutions are explained in the next chapters.
     
       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 signed attribute fields of a CMS [RFC5652] signature.
     
     2. Terminology and conventions used in this document
     
       The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
       and "MAY" in this document are to be interpreted as described in "Key
       words for use in RFCs to Indicate Requirement Levels" [RFC2119].
     
       MUA, MSA and MTA terms are defined in Email architecture document
       [RFC5598].
     
       DCA term is defined in Domain Security specification [RFC3183].
     
       End-to-end Internet Mail exchanges are performed between message
       originators and recipients.
     
       Description of message header fields are described in [RFC5322]. A
       header field is composed of a name and a value.
     
     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 [RFC5321] and IMF [RFC5322] don't provide, by
       default, security services. The S/MIME standard [RFC5751] 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
     
     
     Cailleux & Bonatti                                             [Page 3]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
       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 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 receiving client
       display these header fields? How can a subset of header fields be
       secured? S/MIME doesn't address these issues.
     
       An alternative solution is described in [RFC3850]. "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".
       However, this 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 to
       permit verification of the source and contents of messages. It
       provides mechanisms to secure message header fields and message body
       but it doesn't guarantee non-repudiation and originator
       authentication. In addition, it doesn't provide confidentiality
       service.
     
       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
     
     
     Cailleux & Bonatti                                             [Page 4]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
       DKIM. Then the digest value is included in a signed attribute field
       of a CMS signature". This specification doesn't address all the
       requirements. If protected header field has been altered, the
       original value cannot be determined by the recipient. In addition,
       encryption service cannot be applied on protected header fields.
     
       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.
     
       Secure headers are based on 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 signed attributes structure of SignerInfo object.
       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 secure header fields (in signature) and 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
       contains a secure headers structure, and only perform the
     
     
     
     Cailleux & Bonatti                                             [Page 5]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
       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 [RFC3501]),
       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.
     
                A Domain                                B Domain
       +------------------------+               +------------------------+
     
       +-----+            +-----+               +-----+            +-----+
       | MUA | ---------> | DCA | ------------> | DCA |----------> | MUA |
       |  C  | SignedMsg  |  D  | EncryptedMsg  |  E  | SignedMsg  |  F  |
       +-----+            +-----+               +-----+            +-----+
     
                    Figure 1: Architecture of Secure Headers
     
     4.1. ASN.1 syntax of secure header fields
     
       ASN.1 notation [X.680] 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),
     
     
     Cailleux & Bonatti                                             [Page 6]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
           canonAlgorithmRelaxed(1)}
     
        HeaderFields ::= SET SIZE (1..max-header-fields) OF HeaderField
        max-header-fields INTEGER ::= MAX
     
     
        HeaderField ::= SEQUENCE {
           field-Name HeaderFieldName,
           field-Value HeaderFieldValue,
           field-Status HeaderFieldStatus OPTIONAL
           }
     
        HeaderFieldName ::= IA5String
        HeaderFieldValue ::= IA5String
     
        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 leads 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, 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.
     
     
     
     
     
     
     Cailleux & Bonatti                                             [Page 7]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
     4.4. Header fields statuses
     
       Header fields statuses are required to provide a confidentiality
       service toward message headers. Since this mechanism is OPTIONAL, the
       status field is also OPTIONAL. The three following statuses MUST be
       used:
     
          - Duplicated (default). When this status is present or if no status
          is specified, the signature process MUST embed the header field in
          the signature.
     
     
          - Deleted. When this status is present, the signature process MUST
          embed the header field in the signature. Then, the encryption
          process MUST delete this field from the message. This guarantees
          header confidentiality during the message transfer. Mandatory
          header fields, as specified in IMF MUST be kept in the message.
     
     
          - Modified. When this status is present, the signature process MUST
          embed the header field in the signature. Then, the encryption
          process MUST modify the value of the header field in the message.
          This guarantees header confidentiality during the message transfer.
          Furthermore, modified values MAY inform a receiver's non-compliant
          MUA that secure headers are being used. The new value for each
          field is configured by the sender (i.e., this header is secured,
          use a compliant client). Mandatory header fields, as specified in
          IMF MUST be kept well formed after the modification process. For
          example, Date field MUST be compliant with the IMF specification.
     
     
     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.
     
     
     
     Cailleux & Bonatti                                             [Page 8]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
       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
       [RFC4853] 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.
     
       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 (OPTIONAL).
     
          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
     
     
     
     Cailleux & Bonatti                                             [Page 9]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
       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 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.
     
          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                                            [Page 10]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
          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.
     
          7) Verify that every mandatory headers in the security policy and
       present in the message are also embedded in the SecureHeaderField
       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 IMAP limitations. 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 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
       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;
     
     
     
     Cailleux & Bonatti                                            [Page 11]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
          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
       [RFC5322] 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 SecureHeaderFileds 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                                            [Page 12]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
     5. Case of triple wrapping
     
       Secure Headers mechanisms MAY be used with triple wrapping, as
       described in 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 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. Header fields
       processing, given the signature type (inner or outer), is out of the
       scope of this document.
     
     6. 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 MAY be prescribed. 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. Sent and received messages by MUAs MAY appear
       in 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.
     
     7. References
     
     
     7.1. Normative References
     
        [RFC2045] Borenstein, N., "Multipurpose Internet Mail Extensions Part
                  One", RFC 2045, November 1996.
     
        [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
                  requirement levels", RFC 2119, March 1997.
     
     
     
     
     Cailleux & Bonatti                                            [Page 13]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
        [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC
                  2634, June 1999.
     
        [RFC4853] Housley, R., "Cryptographic Message Syntax (CMS), Multiple
                  Signer Clarification", RFC 4853, April 2007.
     
        [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J.
                  and Thomas, M., "DomainKeys Identified Mail (DKIM)
                  Signatures", RFC 4871, May 2007.
     
        [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, October
                  2008.
     
        [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
                  5652, September 2009.
     
        [X.680]  ITU-T. Recommendation X.680 : Abstract Syntax Notation One
                  (ASN.1): Specification of basic notation, November 2008.
     
     
     7.2. Informative References
     
        [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
                  June 1999.
     
        [RFC3183] Dean, T., Ottaway, W., "Domain security services using
                  S/MIME", RFC 3183, October 2001.
     
        [RFC3207] Hoffman, P., "SMTP Service Extension for secure SMTP over
                  Transport Layer Security", RFC 3207, February 2002.
     
        [RFC3501] Crispin, M., "Internet Message Access Protocol, version
                  4rev1", RFC 3501, March 2003.
     
        [RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
                  (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July
                  2004.
     
        [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
                  October 2008.
     
        [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
                  2009.
     
        [RFC5751] Ramsdell, B., Turner, S., "Secure/Multipurpose Internet
                  Mail Extensions (S/MIME) Version 3.2, Message
                  Specification", RFC 5751, January 2010.
     
     
     Cailleux & Bonatti                                            [Page 14]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
     Appendix A. Formal syntax of Secure Header
     
       ASN.1 notation [X.680] 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 ::= SET SIZE (1..max-header-fields) OF HeaderField
        max-header-fields INTEGER ::= MAX
     
     
        HeaderField ::= SEQUENCE {
           field-Name HeaderFieldName,
           field-Value HeaderFieldValue,
           field-Status HeaderFieldStatus OPTIONAL
           }
     
        HeaderFieldName ::= IA5String
        HeaderFieldValue ::= IA5String
     
        HeaderFieldStatus ::= INTEGER
           {
           duplicated(0), deleted(1), modified(2)
           }
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Cailleux & Bonatti                                            [Page 15]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
     Appendix B. Secure Header Fields example
     
        In the following example, header fields subject, from, to and x-ximf-
        primary-precedence are secured and integrated in a SecureHeaders
        structure.
     
        Extract of message header fields
     
            From: John Doe <jdoe@example.com>
            To: Mary Smith <mary@example.com>
            Subject: This is a test
            X-ximf-primary-precedence: priority
     
     SecureHeaders structure extracted from signature:
     
       2286  163:         SEQUENCE {
       2289   11:           OBJECT IDENTIFIER '1 2 840 113549 1 9 16 2 80'
       2302  147:           SET {
       2305  144:             SET {
       2308    4:               ENUMERATED 1
       2314  135:                 SET {
       2317   40:                   SEQUENCE {
       2319   25:                     IA5String 'x-ximf-primary-precedence'
       2346    8:                     IA5String 'priority'
       2356    1:                     INTEGER 0
                :                     }
       2359   25:                   SEQUENCE {
       2361    2:                     IA5String 'to'
       2365   16:                     IA5String 'mary@example.com'
       2383    1:                     INTEGER 0
                :                     }
       2386   34:                   SEQUENCE {
       2388    4:                     IA5String 'from'
       2394   23:                     IA5String 'jdoe <jdoe@example.com>'
       2419    1:                     INTEGER 0
                :                     }
       2422   28:                   SEQUENCE {
       2424    7:                     IA5String 'subject'
       2433   14:                     IA5String 'This is a test'
       2449    1:                     INTEGER 0
                :                     }
                :                   }
     
     
     Cailleux & Bonatti                                            [Page 16]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
                :                 }
                :              }
                :           }
     
     
        Example is displayed as an output of Peter Gutmann's "dumpasn1"
        program.
     
        OID used in this example is non official.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Cailleux & Bonatti                                            [Page 17]


     Internet-Draft    Securing Header Fields with S/MIME       October 2011
     
     
     Appendix C. Acknowledgements
     
     
       The author would like to thank Damien Roque and Thibault Cassan
       kindly provided reviews of the document and/or suggestions for
       improvement. As always, all errors and omissions are the
       responsibility of the authors.
     
     
     
     
       Author's addresses
     
        Laurent CAILLEUX
        DGA Maitrise de l'information
        BP 7
        35998 Rennes Armees
        France
        Email: laurent.cailleux@dga.defense.gouv.fr
     
        Chris Bonatti
        IECA, Inc.
        3057 Nutley Street, Suite 106
        Fairfax, VA  22031
        USA
        Email: bonattic@ieca.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Cailleux & Bonatti                                            [Page 18]
     

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/