RFC 7508

Securing Header Fields with S/MIME

📅 published April 2015, from ietf

🎀 RFC 7508: Securing Header Fields with S/MIME 💌

Okay bestie, this one is an Experimental RFC 💅. It came in as an Independent Submission, which means it's a contribution to the RFC Series that isn't tied to any other stream. Written by L. Cailleux (DGA MI) and C. Bonatti (IECA), it was published in April 2015 with ISSN 2070-1721. The title block doesn't say it obsoletes or updates any other RFC, so it's a standalone doc 🦋.

Abstract

Okay so this doc explains how S/MIME can be extended to secure the message header fields defined in RFC 5322 🔐. The security services on offer are data integrity, non-repudiation, and confidentiality ✨. The extension is called 'Secure Headers' and it's giving main character energy 👑.

Status of This Memo

Not gonna lie, this part is important 🫶. This document is not an Internet Standards Track specification. It's published so people can examine it, try it out as an experimental implementation, and evaluate it 🧪.

It defines an Experimental Protocol for the Internet community. It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents the RFC Editor approves aren't candidates for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 📚.

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7508 🌸.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved ©️.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜.

Table of Contents

1. Introduction ....................................................2
2. Terminology and Conventions Used in This Document ...............3
3. Context .........................................................4
4. Mechanisms to Secure Message Header Fields ......................6
   4.1. ASN.1 Syntax of Secure Header Fields .......................7
   4.2. Secure Header Fields Length and Format .....................8
   4.3. Canonicalization Algorithm .................................8
   4.4. Header Field Statuses ......................................8
   4.5. Signature Process ..........................................9
        4.5.1. Signature Generation Process ........................9
        4.5.2. Signature Verification Process .....................10
   4.6. Encryption and Decryption Processes .......................11
        4.6.1. Encryption Process .................................11
        4.6.2. Decryption Process .................................12
5. Case of Triple Wrapping ........................................13
6. Security Gateways ..............................................13
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. References .....................................................14
   9.1. Normative References ......................................14
   9.2. Informative References ....................................15
Appendix A. Formal Syntax of Secure Header ........................16
Appendix B. Example of Secure Header Fields .......................18
Acknowledgements ..................................................19
Authors' Addresses ................................................19

1. Introduction ✨

So the S/MIME [RFC5751] standard defines a data encapsulation format for end-to-end security services like integrity, authentication, non-repudiation, and confidentiality 🔒. The catch is that by default, S/MIME secures the message body parts and skips the message header fields entirely 🙈.

S/MIME does offer a workaround for headers: "the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S/MIME security services to header fields". The problem is that S/MIME doesn't say which header fields to secure, how clients should reconcile the "inner" and "outer" headers, or how clients should interpret or display failures 😭.

A few other security specs help S/MIME out but don't hit the target this doc is going for 🧐. They include DomainKeys Identified Mail (DKIM) [RFC6376], STARTTLS [RFC3207], TLS with IMAP [RFC2595], and an Internet-Draft called "Protected Headers" [PRHDRS]. We'll get into what each of them does and why they don't solve this in the later sections 💜.

The goal here is to define end-to-end secure header field mechanisms that stay compliant with the S/MIME standard 🎯. The technique is built on the signed attribute fields of a Cryptographic Message Syntax (CMS) [RFC5652] signature 🌈.

2. Terminology and Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those are the official requirement words, so pay attention to them 🧾.

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

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

End-to-end Internet Mail exchanges happen between message originators and recipients 💌.

The term message header fields is described in [RFC5322]. A header field is made up of a name and a value 🧩.

Secure Headers technology uses header field statuses that are required to provide a confidentiality service for message headers 🔐. There are three terms for these field statuses:

  • duplicated (the default status). When this status is present, or if no status is specified, the signature process embeds the header field value in the digital signature, but the value is also still 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 then the encryption process deletes this field from the message to keep it confidential 🗑️.
  • modified. When this status is present, the signature process embeds the header field value in the digital signature, and the encryption process changes the value of the header field in the message. This keeps things confidential and also tells a receiver's noncompliant MUA that secure headers are being used. The sender can configure new values for each field, like "This header is secured; use a compliant client." 🩷.

The term non-repudiation is used throughout this document because that's how the S/MIME Message Specification [RFC5751] uses it 🫢. Everyone knows this term comes with a lot of baggage, and people don't fully agree on what it properly means. In this context, though, it only refers to one set of security services that a conforming implementation might be able to provide. This document specifies no normative requirements for non-repudiation 🙅‍♀️.

  1. Context ✨

Okay so the internet has become, like, the place where email lives now, and it's a fundamental service 💌 Meanwhile the threat levels keep climbing, which is why security services keep getting implemented. Main character energy for security, honestly 🛡️

Historically, SMTP [RFC5321] and the Internet Message Format (IMF) [RFC5322] don't provide, by default, security services. 💀 The S/MIME standard [RFC5751] was published to address these needs. S/MIME defines a data encapsulation format for end-to-end security services such as integrity, authentication, non-repudiation, and confidentiality. The catch is that by default S/MIME secures message body parts and not the message header fields 🙈 So if you want to protect things like the "Subject", "To", "From", or customized fields, you need some other solution. Several exist!

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

[...] the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S/MIME security services to these header fields. It is up to the receiving client to decide how to present this "inner" header along with the unprotected "outer" header.

But some use cases still aren't addressed, especially message encryption. 😭 What happens when header fields are encrypted? How does the receiving client display them? How can a subset of header fields be secured? S/MIME doesn't address these issues, bestie.

Some partial header protection comes from the S/MIME Certificate Handling specification [RFC5750]:

Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address, if present, in the signer's certificate, if mail addresses are present in the certificate.

In some cases this gives assurance of the integrity of the From or Sender header values, which is cute 🎀 But the solution in RFC 5750 only provides a matching mechanism between email addresses and gives zero protection to any other header fields. Not enough!

Other security specifications exist too, like DKIM, STARTTLS and TLS with IMAP, but they meet other needs (signing domains, secure channels, etc.) 🌸

STARTTLS and TLS with IMAP provide secure channels between components of the email system (MUA, MSA, MTA, etc.), but end-to-end integrity cannot be guaranteed. 💔

DKIM defines a domain-level authentication framework for email. It permits integrity and origination checks on message header fields and the message body, which is giving good. But it does this for a domain actor (usually the SMTP service or equivalent) and not for the entity that is actually sending, and therefore signing, the message 🤔 (Extensions to DKIM might be able to solve this by authenticating the sender and stating that fact as part of the signed message headers.) And DKIM is also deficient for our purposes, because it does not provide a confidentiality service. Not the vibe 💅

An Internet-Draft referred to as "Protected Headers" [PRHDRS] has been proposed. Its mechanisms are the following:

[...] a digest value is computed over the canonicalized version of some selected header fields. This technique resembles header protection in [RFC4871]. Then the digest value is included in a signed attribute field of a CMS signature.

(Note that RFC 4871 has been obsoleted by RFC 6376.) 📝

That specification doesn't address all conceivable requirements, as noted below. If the protected header field has been altered, the recipient cannot determine the original value. Also, the encryption service cannot provide confidentiality for fields that must remain present in the message header during transport. Ugh, so relatable 😩

This document proposes a technology for securing message header fields, called "Secure Headers" ✨ It is based on S/MIME and CMS standards and provides security services such as data integrity, confidentiality, and non-repudiation of the sender. Secure Headers is backward compatible with other S/MIME clients. S/MIME clients that haven't implemented Secure Headers need merely ignore specific signed attributes fields in a CMS signature, which is the default behaviour. Iconic 👑

  1. Mechanisms to Secure Message Header Fields 🔐

Secure Headers technology involves describing 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, so don't ask me 🫶

Secure headers are based on the signed attributes field as defined in CMS. The details go like this: the message header fields to be secured are integrated in a structure (SecureHeaderFields structure) that is encapsulated in the signed attributes structure of the SignerInfo object. There is only one value of HeaderFields encoded into a single SignedAttribute in a signature. See Appendix A for an example. For each header field present in the secure signature, a status can be set. Then, as described in Section 5.4 of CMS [RFC5652], the message digest calculation process computes a message digest on the content together with the signed attributes. Details of the signature generation process are in Section 4.5.1 of this document.

Verification of secure header fields is based on the signature verification process described in CMS. At the end of this process, the secure header fields are compared with the corresponding message header fields. If they match, the signature is valid. Otherwise, the signature is invalid. Details of the signature verification process are in Section 4.5.2 of this document.

Non-conforming S/MIME clients will ignore the signed attribute containing the SecureHeaderFields structure, and only perform the verification process described in CMS. This guarantees backward compatibility, which is so important 🥹

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 are performed by a third party. The third party doing this is referred to in the Domain Security specification as a Domain Confidentiality Authority (DCA). Details of the encryption and decryption processes are in Sections 4.6.1 and 4.6.2 of this document.

The architecture of Secure Headers is shown below. The MUA performs the signature generation process (C) and signature verification process (F). The DCA performs the message encryption process (D) and message decryption process (E). The encryption and decryption processes are optional. 🦋

         A Domain                             B Domain
 +----------------------+             +----------------------+

 +-----+          +-----+             +-----+          +-----+
 | MUA | -------> | DCA | ----------> | DCA |--------> | MUA |
 |  C  |          |  D  |             |  E  |          |  F  |
 +-----+          +-----+             +-----+          +-----+
         SignedMsg        EncryptedMsg        SignedMsg

              Figure 1: Architecture of Secure Headers

4.1. ASN.1 Syntax of Secure Header Fields 🧚

The ASN.1 syntax [ASN1-88] of the SecureHeaderFields structure is as follows:

SecureHeaderFields ::= SET {
   canonAlgorithm Algorithm,
   secHeaderFields HeaderFields }

id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= {
   iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
   pkcs-9(9) smime(16) id-aa(2) secureHeaderFieldsIdentifier(55) }

Algorithm ::= ENUMERATED {
   canonAlgorithmSimple(0),
   canonAlgorithmRelaxed(1) }

HeaderFields ::= SEQUENCE SIZE (1..MAX) OF HeaderField

HeaderField ::= SEQUENCE {
   field-Name HeaderFieldName,
   field-Value HeaderFieldValue,
   field-Status HeaderFieldStatus DEFAULT duplicated }

HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":")))
     -- This description matches the description of
     -- field name in Sections 2.2 and 3.6.8 of RFC 5322

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

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

4.2. Secure Header Fields Length and Format 💅

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

4.3. Canonicalization Algorithm ✨

During a message transfer through a messaging system, some components might modify headers (adding or deleting space, changing lowercase or uppercase, etc.). This can lead to a comparison mismatch of header fields. That's why we need a conversion process to transform data into its canonical form. This process is called the canonicalization process 🔥

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

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

4.4. Header Field Statuses 🎀

Header field statuses are necessary to provide a confidentiality service for message headers. In this specification, the confidentiality of header fields is provided by the DCA. This point is described in Section 4. The DCA performs the message encryption and decryption processes, which are described in detail in Sections 4.6.1 and 4.6.2. Although header field statuses are embedded in the signature, the signature processes (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 ✨

okay so this is where the sender's MUA actually signs the message 🖊️. During the signature generation process, the sender's MUA MUST embed the SecureHeaderFields structure in the signed attributes, as described in CMS. The SecureHeaderFields structure MUST include a canonicalization algorithm. 💅

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

Header fields (names and values) embedded in signed attributes MUST be the same as those in the initial message. 🫶

If different headers share the same name, all instances MUST be included in the SecureHeaderFields structure. 👯

If multiple signatures are used, as explained in the CMS and Multiple Signer [RFC4853] specifications, the SecureHeaderFields structure MUST be the same in each SignerInfos object. 🔁

If a header field is present and its value is empty, HeaderFieldValue MUST have a zero-length field-Value. 🫧

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

  1. Select the relevant header fields to secure. This subset of headers is defined according to the security policy. 🎯
  2. Apply the canonicalization algorithm for each selected header field. 🧼
  3. Complete the following fields in the SecureHeaderFields structure according to the initial message: HeaderFieldName, HeaderFieldValue, and HeaderFieldStatus. ✍️
  4. Complete the algorithm field according to the canonicalization algorithm configured. ⚙️
  5. Embed the SecureHeaderFields structure in the signed attributes of the SignerInfos object. 📦
  6. Compute the signature generation process as described in Section 5.5 of CMS [RFC5652]. 🖋️

4.5.2. Signature Verification Process 🔍

now the receiver's side, where the MUA plays detective 🕵️‍♀️. 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, it uses the canonicalization algorithm identified in the signed attributes. If a mismatch shows up during the comparison, 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 so it can verify they're present in the message. If a header field defined in a message is in the secure header list, it MUST be included in the SecureHeaderFields structure. Otherwise, the receiver's MUA MUST warn the user that a non-secure header is present. ⚠️

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

  1. Execute the signature verification process as described in Section 5.6 of CMS [RFC5652]. If the signature appears to be invalid, the process ends. Otherwise, the process continues. 🛑➡️
  2. Read the type of canonicalization algorithm specified in the SecureHeaderFields structure. 📖
  3. For each field present in the signature, find the matching header in the message. If there is no matching header, the verification process MUST warn the user, specifying the missing header name. The signature is tagged as invalid. Note that any header fields encrypted as per Section 4.6 (i.e., status of "deleted" or "modified") have already been restored by the DCA when the signature verification process is performed by the MUA. 🕵️
  4. Compute the canonicalization algorithm for each header field value in the message. If the "simple" algorithm is used, the steps described in Section 3.4.1 of DKIM [RFC6376] are performed. If the relaxed algorithm is used, the steps described in Section 3.4.2 of DKIM [RFC6376] are performed. 🧮
  5. For each field, compare the value stored in the SecureHeaderFields structure with the value returned by the canonicalization algorithm. If the values don't match, the verification process MUST warn the user. This warning MUST mention mismatching fields. The signature is tagged as invalid. If all the comparisons succeed, the verification process MUST also notify the user (for example, with an appropriate icon). ✅❌
  6. Verify that no secure header has been added to the message header, given the initial fields. If an extra header field has been added, the verification process MUST warn the user. This warning MUST mention extra fields. The signature is tagged as invalid. This step is only performed if the sender and the recipient share the same security policy. 🕳️
  7. Verify that each mandatory header in the security policy and present in the message is also embedded in the SecureHeaderFields structure. If such headers are missing, the verification process MUST warn the user and indicate the names of the missing headers. 📝

The MUA MUST display the properties of each secure header field (name, value, and status) and the canonicalization algorithm used. 👀✨

4.6. Encryption and Decryption Processes 🔐

here's the plot twist: MUAs don't do encryption or decryption at all 🙈. This is mainly because of limitations in existing email delivery protocols, like IMAP. The solution relies on concepts explained in Section 4 of the Domain Security specification [RFC3183]. The key player is the Domain Confidentiality Authority (DCA). Its job is to encrypt and decrypt messages, instead of senders and receivers doing it themselves. 🦸‍♀️

4.6.1. Encryption Process 🧁

All the computations in this section MUST be performed only if the following conditions are verified:

  • The content to be encrypted MUST consist of a signed message (application/pkcs7-mime with SignedData, or multipart/signed) as shown in Section 3.4 of the S/MIME specification [RFC5751].
  • A SecureHeaderFields structure MUST be included in the signedAttrs field of the SignerInfo object of the signature.

All the mechanisms described below MUST start at the beginning of the encryption process, as explained in CMS. They are performed by the sender's DCA. For extraction of the field status, the following steps MUST be performed for each field included in the SecureHeaderFields structure:

  1. If the status is "duplicated", the field is left at its existing value. 📎
  2. If the status is "deleted", the header field (name and value) is removed from the message. Mandatory header fields specified in [RFC5322] MUST be kept. 🗑️
  3. If the status is "modified", the header value is replaced by a new value, as configured in the DCA. ✏️

4.6.2. Decryption Process 🔓

All the computations in this section MUST be performed only if the following conditions are verified:

  • The decrypted content MUST consist of a signature object or a multipart object, where one part is a detached signature, as shown in Section 3.4 of the S/MIME specification [RFC5751].
  • A SecureHeaderFields structure MUST be included in the SignerInfo object of the signature.

All the mechanisms described below MUST start at the end of the decryption process, as explained in CMS. They are executed by the receiver's DCA. The following steps MUST be performed for each field included in the SecureHeaderFields structure:

  1. If the status is "duplicated", the field is left at its existing value. 📎
  2. If the status is "deleted", the DCA MUST write a header field (name and value) in the message. This header MUST be compliant with the information embedded in the signature. 🪄
  3. If the status is "modified", the DCA MUST rewrite a header field in the message. This header MUST be compliant with the SecureHeaderFields structure. 🔁

5. Case of Triple Wrapping 🎀

Secure Headers mechanisms MAY be used with triple wrapping, as described in Enhanced Security Services (ESS) [RFC2634]. In this case, a SecureHeaderFields structure MAY be present in the inner signature, the outer signature, or both. In the last case, the two SecureHeaderFields structures MAY differ. One MAY consider encapsulating a header field in the inner signature to meet confidentiality needs. On the other hand, outer signature encapsulation MAY help with delivery purposes. The sender's MUA and receiver's MUA need a security policy for triple wrapping. This security policy MUST be composed of two parts: one for the inner signature and one for the outer signature. 🪆

6. Security Gateways 🚪

some security gateways sign or verify messages as they pass through. Compliant gateways MUST apply the process described in Section 4.5.

For noncompliant gateways, the presence of a SecureHeaderFields structure does not change their behavior. 🙃

In some cases, 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 🚨💀

okay this part is SERIOUS bestie 😭. This specification describes an extension of the S/MIME standard. It provides message header integrity, non-repudiation, and confidentiality. The signature and encryption processes are complementary. However, depending on the security policy, only the signature mechanism may be applicable. In that 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. To avoid interception, the use of TLS is recommended between MUAs and DCAs (uplink and downlink). Another solution might be the use of S/MIME between MUAs and DCAs in the same domain. 🔒

For the header field confidentiality mechanism to be effective, all DCAs supporting confidentiality must support Secure Headers processing. Otherwise, there is a risk that headers are not obscured upon encryption or not restored upon decryption. In the former case, confidentiality of the header fields is compromised. In the latter case, the integrity of the headers will appear to be compromised. 💔

8. IANA Considerations 🦋

IANA has registered value 65, mod-sMimeSecureHeadersV1, in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry. 🌸

IANA has also registered value 55, id-aa-secureHeaderFieldsIdentifier, in the "SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2)" registry. This value will be used to identify an authenticated attribute carried within a CMS wrapper [RFC5652]. This attribute OID appears in Section 4.1 and again in the reference definition in Appendix A. 🧚

9. References 📚

9.1. Normative References 📚

Okay bestie, these are the must-read docs the spec leans on, so your brain needs them to make sense of it 🧠✨

9.2. Informative References 🌸

These ones are extra reading, not required, but they're seriously good for going deeper 🦋

Appendix A. Formal Syntax of Secure Header 🧚

Heads up 💅: the ASN.1 module below uses the 1988 version of ASN.1 notation [ASN1-88] so it lines up with the existing S/MIME specs. The SecureHeaderFields structure is defined like this:

  mod-SMimeSecureHeadersV1
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-9(9) smime(16) modules(0) secure-headers-v1(65) }

  DEFINITIONS IMPLICIT TAGS ::=

  BEGIN

  IMPORTS

    id-aa
         FROM SecureMimeMessageV3dot1
              { iso(1) member-body(2) us(840) rsadsi(113549)
              pkcs(1) pkcs-9(9) smime(16) modules(0)
              msg-v3dot1(21) };

  -- id-aa is the arc with all new authenticated and
  -- unauthenticated attributes produced by the S/MIME
  -- Working Group

   id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= {
      id-aa secure-headers(55) }

   SecureHeaderFields ::= SET {
        canonAlgorithm Algorithm,
        secHeaderFields HeaderFields }

   Algorithm ::= ENUMERATED {
        canonAlgorithmSimple(0),
        canonAlgorithmRelaxed(1) }

   HeaderFields ::= SEQUENCE SIZE (1..MAX) OF HeaderField

   HeaderField ::= SEQUENCE {
        field-Name HeaderFieldName,
        field-Value HeaderFieldValue,
        field-Status HeaderFieldStatus DEFAULT duplicated }

   HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":")))
        -- This description matches with the description of
        -- field name in the Sections 2.2 and 3.6.8 of RFC 5322

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

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

   END

Appendix B. Example of Secure Header Fields 🎀

In this example, subject, x-ximf-primary-precedence, and x-ximf-correspondance-type get secured and bundled up into a SecureHeaderFields structure. This example should produce a valid signature ✨

Here's the extract from the message header fields:

From: John Doe <jdoe@example.com>
To: Mary Smith <mary@example.com>
subject: This is a test of Ext.
x-ximf-primary-precedence: priority
x-ximf-correspondance-type: official

And this is the SecureHeaderFields structure pulled out of 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
            :           }
            :         }
            :       }
            :     }
            :   }

This example was printed out by Peter Gutmann's "dumpasn1" program 💜 Also, heads up: the OID used in this example is nonofficial 🙈

Acknowledgements 🫶

Huge shoutout to Jim Schaad, Alexey Melnikov, Damien Roque, Thibault Cassan, William Ottaway, and Sean Turner, who reviewed the document and/or dropped suggestions to make it better 🌈 The authors are the ones on the hook for any errors and omissions, so that part's on them 💅

Authors' Addresses 🦋

Laurent CAILLEUX

DGA MI
BP 7
35998 RENNES CEDEX 9
France

EMail: laurent.cailleux@intradef.gouv.fr

Chris Bonatti

IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA  22031
United States

EMail: bonatti252@ieca.com
📦 where this page comes from