idnits 2.17.1 draft-cailleux-secure-headers-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (30 July 2013) is 3915 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC 3501' is defined on line 634, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 5750 (Obsoleted by RFC 8550) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Cailleux 3 Internet-Draft DGA MI 4 Intended status: Experimental C. Bonatti 5 Expires: 30 January 2014 IECA 6 30 July 2013 8 Securing Header Fields with S/MIME 9 draft-cailleux-secure-headers-03 11 Abstract 13 This document describes how the S/MIME protocol can be 14 extended in order to secure message header fields. This 15 technology provides security services such as data integrity, 16 non-repudiation and confidentiality. This extension is 17 referred to as 'Secure Headers'. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet 25 Engineering Task Force (IETF). Note that other groups may 26 also distribute working documents as Internet-Drafts. The 27 list of current Internet-Drafts is at 28 http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet- 33 Drafts as reference material or to cite them other than as 34 "work in progress." 36 This Internet-Draft will expire on 30 January 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as 41 the document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date 46 of publication of this document. Please review these 47 documents carefully, as they describe your rights and 48 restrictions with respect to this document. Code Components 49 extracted from this document MUST include Simplified BSD 50 License text as described in Section 4.e of the Trust Legal 51 Provisions and are provided without warranty as described in 52 the Simplified BSD License. 54 Table of Contents 56 1. Introduction..............................................2 57 2. Terminology and conventions used in this document.........3 58 3. Context...................................................4 59 4. Mechanisms to secure message header fields................6 60 4.1. ASN.1 syntax of secure header fields.................7 61 4.2. Secure header fields length and format...............8 62 4.3. Canonization algorithm...............................8 63 4.4. Header fields statuses...............................8 64 4.5. Signature Process....................................9 65 4.5.1. Signature Generation Process....................9 66 4.5.2. Signature verification process.................10 67 4.6. Encryption and Decryption Processes.................12 68 4.6.1. Encryption Process.............................12 69 4.6.2. Decryption Process.............................13 70 5. Case of triple wrapping..................................14 71 6. Security Gateways........................................14 72 7. Security Considerations..................................14 73 8. IANA Considerations......................................15 74 9. References...............................................15 75 9.1. Normative References................................15 76 9.2. Informative References..............................16 77 Appendix A. Formal syntax of Secure Header..................17 78 Appendix B. Secure Header Fields example....................18 79 Appendix C. Acknowledgements................................20 81 1. Introduction 83 S/MIME [RFC 5751] standard defines a data encapsulation format 84 for the achievement of end to end security services such as 85 integrity, authentication, non-repudiation and 86 confidentiality. By default, S/MIME secures message body 87 parts, at the exclusion of the message header fields. 89 S/MIME provides an alternative solution to secure header 90 fields. "The sending client MAY wrap a full MIME [RFC 2045] 91 message in a message/rfc822 wrapper in order to apply S/MIME 92 security services to header fields". However, the S/MIME 93 solution doesn't allow selection of a subset of message header 94 fields to secure. In addition, confidentiality service can not 95 be implemented for message header fields. The solution 96 described herein overcomes those limitations. 98 Several security standards exist such as DKIM [RFC 6376], 99 STARTTLS [RFC 3207] and TLS with IMAP [RFC 2595] but meet 100 other needs (signing domain, secure channels). An internet 101 draft referred to as PROTECTED HEADERS has been proposed, but 102 doesn't address all the requirements. These different 103 solutions are explained in the next chapters. 105 The goal of this document is to define end to end secure 106 header fields mechanisms compliant with S/MIME standard. This 107 technique is based on the signed attribute fields of a CMS 108 [RFC 5652] signature. 110 2. Terminology and conventions used in this document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 113 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described 115 in [RFC 2119]. 117 MUA, MSA and MTA terms are defined in Email architecture 118 document [RFC 5598]. 120 DCA term is defined in the S/MIME Domain Security 121 specification [RFC 3183]. 123 End-to-end Internet Mail exchanges are performed between 124 message originators and recipients. 126 Description of message header fields are described in [RFC 127 5322]. A header field is composed of a name and a value. 129 3. Context 131 Over the Internet, email usage has grown and today represents 132 a fundamental service. Meanwhile, continually increasing 133 threat levels are motivating the implementation of security 134 services. 136 Historically, SMTP [RFC 5321] and IMF [RFC 5322] don't 137 provide, by default, security services. The S/MIME standard 138 [RFC 5751] was published in order to encompass these needs. 139 S/MIME defines a data encapsulation format for the provision 140 of end to end security services such as integrity, 141 authentication, non-repudiation and confidentiality. By 142 default, S/MIME secures message body parts, at the exclusion 143 of the message header fields. In order to protect message 144 header fields (for instance, the "Subject", "To", "From" or 145 customized fields), several solutions exist. 147 S/MIME defines an encapsulation mechanism, chapter 3.1: "The 148 sending client may wrap a full MIME message in a 149 message/rfc822 wrapper in order to apply S/MIME security 150 services to these header fields. It is up to the receiving 151 client to decide how to present this inner header along with 152 the unprotected outer header". However, some use cases are not 153 addressed, especially in the case of message encryption. What 154 happens when header fields are encrypted? How does the 155 receiving client display these header fields? How can a subset 156 of header fields be secured? S/MIME doesn't address these 157 issues. 159 An alternative solution is described in [RFC 5750]. "Receiving 160 agents MUST check that the address in the From or Sender 161 header of a mail message matches an Internet mail address, if 162 present, in the signer's certificate, if mail addresses are 163 present in the certificate". However, this solution only 164 provides a matching mechanism between email addresses, and 165 provides no protection to other header fields. 167 Other security standards (introduced below) exist such as 168 DKIM, STARTTLS and TLS with IMAP but meet other needs (signing 169 domain, secure channels...). 171 STARTTLS and TLS with IMAP provide secure channels between 172 components of email system (MUA, MSA, MTA...) but end to end 173 integrity cannot be guaranteed. 175 DKIM defines a domain-level authentication framework for email 176 to permit verification of the source and contents of messages. 177 It provides mechanisms to secure message header fields and 178 message body but it doesn't guarantee non-repudiation and 179 originator authentication. In addition, it doesn't provide 180 confidentiality. 182 An internet draft referred to as Protected Headers (PRHDRS) 183 has been proposed. Mechanisms described in this draft are the 184 following. "A digest value is computed over the canonicalized 185 version of some selected header fields. This technique 186 resembles header protection in DKIM. Then the digest value is 187 included in a signed attribute field of a CMS signature". This 188 specification doesn't address all conceivable requirements as 189 noted below. If the protected header field has been altered, 190 the original value cannot be determined by the recipient. In 191 addition, the encryption service cannot provide 192 confidentiality for fields that must remain present in the 193 message header during transport. 195 This document proposes a technology for securing message 196 header fields. It's referred to as Secure Headers. It is based 197 on S/MIME and CMS standards. It provides security services 198 such as data integrity, confidentiality and non-repudiation of 199 sender. Secure Headers is backward compatible with other 200 S/MIME clients. S/MIME clients who have not implemented 201 Secure Headers technology need merely ignore specific signed 202 attributes fields in a CMS signature (which is the default 203 behavior). 205 4. Mechanisms to secure message header fields 207 Secure Headers technology involves the description of a 208 security policy. This policy MUST describe a secure message 209 profile and list the header fields to secure. 211 Secure headers are based on the signed attributes field as 212 defined in CMS. The details are as follows. The message header 213 fields to be secured are integrated in a structure (secure 214 header structure) which is encapsulated in the signed 215 attributes structure of the SignerInfo object. See Appendix A 216 for an example. For each header field present in the secure 217 signature, a status can be set. Then, as described in chapter 218 5.4 of CMS, the message digest calculation process computes a 219 message digest on the content together with the signed 220 attributes. Details of the signature generation process are 221 described in chapter 4.5.1 of this document. 223 Verification of secure header fields is based on signature 224 verification process described in CMS. At the end of this 225 process, a comparison between the secure header fields and the 226 corresponding message header fields is performed. If they 227 match, the signature is valid. Otherwise, the signature is 228 invalid. Details of the signature verification process are 229 described in chapter 4.5.2 of this document. 231 Non-conforming S/MIME clients will ignore the signed attribute 232 containing the secure headers structure, and only perform the 233 verification process described in CMS. This guarantees 234 backward compatibility. 236 Secure headers provide security services such as data 237 integrity, non-repudiation and confidentiality. 239 For different reasons (e.g., usability, limits of IMAP [RFC 240 3501]), encryption and decryption processes are performed by a 241 third party. The third party that performs these processes is 242 referred to in Domain Security specification as a "Domain 243 Confidentiality Authority" (DCA). Details of the encryption 244 and decryption processes are described in chapters 4.6.1 and 245 4.6.2 of this document. 247 The architecture of Secure Headers is presented below. The MUA 248 performs the signature generation process (C) and signature 249 verification process (F). The DCA performs the message 250 encryption process (D) and message decryption process (E). The 251 encryption and decryption processes are optional. 253 A Domain B Domain 254 +----------------------+ +----------------------+ 256 +-----+ +-----+ +-----+ +-----+ 257 | MUA | -------> | DCA | ----------> | DCA |--------> | MUA | 258 | C | | D | | E | | F | 259 +-----+ +-----+ +-----+ +-----+ 260 SignedMsg EncryptedMsg SignedMsg 262 Figure 1: Architecture of Secure Headers 264 4.1. ASN.1 syntax of secure header fields 266 ASN.1 notation [X.680] of secure header structure is the 267 follow: 269 SecureHeaderFields ::= SET { 270 canonAlgorithm Algorithm, 271 secHeaderFields HeaderFields } 273 id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= 274 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 275 pkcs-9(9) smime(16) id-aa(2) secure-headers (to be 276 defined)} 278 Algorithm ::= ENUMERATED { 279 canonAlgorithmSimple(0), 280 canonAlgorithmRelaxed(1) } 282 HeaderFields ::= SET SIZE (1..max-header-fields) OF 283 HeaderField max-header-fields INTEGER ::= MAX 285 HeaderField ::= SEQUENCE { 286 field-Name HeaderFieldName, 287 field-Value HeaderFieldValue, 288 field-Status HeaderFieldStatus DEFAULT duplicated } 290 HeaderFieldName ::= IA5String 292 HeaderFieldValue ::= IA5String 294 HeaderFieldStatus ::= INTEGER { 295 duplicated(0), deleted(1), modified(2) } 297 4.2. Secure header fields length and format 299 This specification requires MUA security capabilities in order 300 to process well formed headers, as specified in IMF. Notice 301 that it includes long header fields and folded header fields. 303 4.3. Canonization algorithm 305 During a message transfer through a messaging system, some 306 components might modify headers (i.e., space adding or 307 deletion, lowercase/uppercase rewriting...). This might lead 308 to header fields comparison mismatch. This emphasizes the need 309 of a conversion process in order to transform data to their 310 canonical form. This process is named canonization process. 312 Two canonization algorithms are considered here, according to 313 DKIM specification, chapter 3.4. The simple algorithm doesn't 314 allow any modification whereas the relaxed algorithm accepts 315 slight modifications like spaces replacement or line 316 reformatting. Given the scope of this document, canonization 317 mechanisms only involve header fields. 319 4.4. Header fields statuses 321 Header fields statuses are required to provide a 322 confidentiality service toward message headers. Since this 323 mechanism is OPTIONAL, the status field is also OPTIONAL. The 324 three following statuses MUST be used: 326 - Duplicated (default). When this status is present or if no 327 status is specified, the signature process MUST embed the 328 header field in the signature. 330 - Deleted. When this status is present, the signature 331 process MUST embed the header field in the signature. Then, 332 the encryption process MUST delete this field from the 333 message. This guarantees header confidentiality during the 334 message transfer. Mandatory header fields, as specified in 335 IMF MUST be kept in the message. 337 - Modified. When this status is present, the signature 338 process MUST embed the header field in the signature. Then, 339 the encryption process MUST modify the value of the header 340 field in the message. This guarantees header confidentiality 341 during the message transfer. Furthermore, modified values 342 MAY inform a receiver's non-compliant MUA that secure 343 headers are being used. The new value for each field is 344 configured by the sender (i.e., this header is secured, use 345 a compliant client). Mandatory header fields, as specified 346 in IMF MUST be kept well formed after the modification 347 process. For example, Date field MUST be compliant with the 348 IMF specification. 350 4.5. Signature Process 352 4.5.1. Signature Generation Process 354 During the signature generation process, the sender's MUA MUST 355 embed the SecureHeaderFields structure in the signed 356 attributes, as described in CMS. SecureHeaderFields structure 357 MUST include a canonization algorithm. 359 The sender's MUA MUST have a list of header fields to secure, 360 statuses and a canonization algorithm, as defined by the 361 security policy. 363 Header fields (names and values) embedded in signed attributes 364 MUST be the same as the ones included in the initial message. 366 If different headers share the same name, all instances MUST 367 be included in the SecureHeaderFields structure. 369 If multiple signatures are used, as explained in CMS and 370 MULTISIGN [RFC 4853] specifications, SecureHeaderFields 371 structure MUST be the same in each SignerInfos object. 373 If a header field is present and its value is empty, 374 HeaderFieldValue MUST have a zero-length field-value. 376 Considering secure headers mechanisms, the signature 377 generation process MUST perform the following steps: 379 1) Select the relevant header fields to secure. This subset 380 of headers is defined according the security policy. 382 2) Apply the canonization algorithm for each selected 383 header field. 385 3) Complete the following fields in SecureHeaderFields 386 structure according to the initial message: HeaderFieldName, 387 HeaderFieldValue, HeaderFieldStatus (OPTIONAL). 389 4) Complete the algorithm field according to the 390 canonization algorithm configured. 392 5) Embed the SecureHeaderFields structure in the signed 393 attributes of the SignerInfos object. 395 6) Compute the signature generation process as described in 396 CMS, chapter 5.5 398 4.5.2. Signature verification process 400 During the signature verification process, the receiver's MUA 401 compares header fields embedded in the SecureHeaderFields 402 structure with those present in the message. For this purpose, 403 it uses the canonization algorithm identified in the signed 404 attributes. If a mismatch appears during the comparison 405 process, the receiver's MUA MUST invalidate the signature. The 406 MUA MUST display information on the validity of each header 407 field. It MUST also display the values embedded in the 408 signature. 410 The receiver's MUA MUST know the list of mandatory header 411 fields in order to verify their presence in the message. If a 412 header field defined in a message is in the secure header 413 list, it MUST be included in the SecureHeaderFields structure. 414 Otherwise, the receiver's MUA MUST warn the user that a non- 415 secure header is present. 417 Considering secure headers mechanisms, the signature 418 verification process MUST perform the following steps: 420 1) Execute the signature verification process as described 421 in CMS, chapter 5.6. If the signature appears to be invalid, 422 the process ends. Otherwise, the process continues. 424 2) Read the type of canonization algorithm specified in 425 SecureHeaderFields structure. 427 3) For each field present in the signature, find the 428 matching header in the message. If there is no matching 429 header, the verification process MUST warn the user, 430 specifying the missing header name. The signature is tagged as 431 invalid. 433 4) Compute the canonization algorithm for each header field 434 value in the message. If the simple algorithm is used, the 435 steps described in DKIM, chapter 3.4.1, are performed. If the 436 relaxed algorithm is used, the steps described in DKIM, 437 chapter 3.4.2, are performed. 439 5) For each field, compare the value stored in the 440 SecureHeaderFields structure with the value returned by the 441 canonization algorithm. If values don't match, the 442 verification process MUST warn the user. This warning MUST 443 mention mismatching fields. The signature is tagged as 444 invalid. If all the comparisons succeed, the verification 445 process MUST also notify the user (i.e., using an appropriate 446 icon). 448 6) Verify that no secure header has been added to the 449 message header, given the initial fields. If an extra header 450 field has been added, the verification process MUST warn the 451 user. This warning MUST mention extra fields. The signature is 452 tagged as invalid. 454 7) Verify that every mandatory headers in the security 455 policy and present in the message are also embedded in the 456 SecureHeaderFields structure. If such headers are missing, the 457 verification process MUST warn the user and indicate the names 458 of the missing headers. 460 The MUA MUST display features for each secure header field 461 (name, value and status) and canonization algorithm used. 463 4.6. Encryption and Decryption Processes 465 Encryption and decryption operations are not performed by 466 MUAs. This is mainly justified by IMAP limitations. The 467 solution developed here relies on concepts explained in Domain 468 Security specification, chapter 4. A fundamental component of 469 the architecture is the Domain Confidentiality Authority 470 (DCA). Its purpose is to encrypt and decrypt messages instead 471 of (respectively) senders and receivers. 473 4.6.1. Encryption Process 475 All the computations presented in this chapter MUST be 476 performed only if the following conditions are verified: 478 - The content to be encrypted MUST consist of a signature 479 object or a multipart object, where one part is a detached 480 signature, as shown in S/MIME specification, chapter 3.4. 482 - A SecureHeaderFields structure MUST be included in the 483 signedAttrs field of the SignerInfo object of the signature. 485 All the mechanisms described below MUST start at the beginning 486 of the encryption process, as explained in CMS. They are 487 performed by the sender's DCA. The following steps MUST be 488 performed for each field included in the SecureHeaderFields 489 structure: 491 1. Extraction of the field status; 493 1.1 If the status is Duplicated, the field is left at its 494 existing value. 496 1.2 If the status is Deleted, the header field (name and 497 value) is removed from the message. Mandatory header fields 498 specified in [RFC 5322] MUST be kept. 500 1.3 If the status is Modified, the header value is replaced 501 by a new value, as configured in the DCA. 503 4.6.2. Decryption Process 505 All the computations presented in this chapter MUST be 506 performed only if the following conditions are verified: 508 - The decrypted content MUST consist of a signature 509 object or a multipart object, where one part is a detached 510 signature, as shown in S/MIME specification, chapter 3.4. 512 - A SecureHeaderFields structure MUST be included in the 513 SignerInfo object of the signature. 515 All the mechanisms described below MUST start at the end of 516 the decryption process, as explained in CMS. They are executed 517 by the receiver's DCA. The following steps MUST be performed 518 for each field included in the SecureHeaderFields structure: 520 1. If the status is Duplicated, the field is left at its 521 existing value. 523 2. If the status is Deleted, the DCA MUST write a header 524 field (name and value) in the message. This header MUST be 525 compliant with the information embedded in the signature. 527 3. If the status is Modified, the DCA MUST rewrite a header 528 field in the message. This header MUST be compliant with the 529 SecureHeaderFields structure. 531 5. Case of triple wrapping 533 Secure Headers mechanisms MAY be used with triple wrapping, as 534 described in ESS [RFC 2634]. In this case, a 535 SecureHeaderFields structure MAY be present in the inner 536 signature, in the outer signature, or both. In the last case, 537 the two structure SecureHeaderFields MAY differ. One MAY 538 consider the encapsulation of a header field in the inner 539 signature in order to satisfy confidentiality needs. On the 540 contrary, an outer signature encapsulation MAY help for 541 delivery purpose. Header fields processing, given the 542 signature type (inner or outer), is out of the scope of this 543 document. 545 6. Security Gateways 547 Some security gateways sign or verify messages that pass 548 through them. Compliant gateways MUST apply the process 549 described in chapter 4.5. 551 For non-compliant gateways, the presence of SecureHeaderFields 552 structure do not change their behavior. 554 In some case, gateways MUST generate new signature or insert 555 signerInfos into the signedData block. The format of 556 signatures generated by gateways is outside the scope of this 557 document. 559 7. Security Considerations 561 This specification describes an extension of the S/MIME 562 standard. It provides message headers integrity, non- 563 repudiation and confidentiality. The signature and encryption 564 processes are complementary. However, according to the 565 security policy, only the signature mechanism MAY be 566 prescribed. In this case, the signature process is implemented 567 between MUAs. The encryption process requires signed messages 568 with Secure Headers extension. If required, the encryption 569 process is implemented by DCAs. 571 This specification doesn't address end-to-end confidentiality 572 for message header fields. Sent and received messages by MUAs 573 MAY appear in plaintext. In order to avoid interception, the 574 use of TLS is recommended between MUAs and DCAs (uplink and 575 downlink). Another solution might be the use of S/MIME between 576 MUAs and DCAs in the same domain. 578 For the header field confidentiality mechanism to be effective 579 all DCAs supporting confidentiality must support SH 580 processing. Otherwise, there is a risk in the case where 581 headers are not obscured upon encryption, or not restored upon 582 decryption process. In the former case confidentiality of the 583 header fields is compromised. In the latter case the integrity 584 of the headers will appear to be compromised. 586 8. IANA Considerations 588 This document has no IANA actions. 590 9. References 592 9.1. Normative References 594 [RFC 2045] Borenstein, N., "Multipurpose Internet Mail 595 Extensions Part One", RFC 2045, November 1996. 597 [RFC 2119] Bradner, S., "Key words for use in RFCs to 598 indicate requirement levels", RFC 2119, March 599 1997. 601 [RFC 2634] Hoffman, P., "Enhanced Security Services for 602 S/MIME", RFC 2634, June 1999. 604 [RFC 4853] Housley, R., "Cryptographic Message Syntax (CMS), 605 Multiple Signer Clarification", RFC 4853, April 606 2007. 608 [RFC 5322] Resnick, P., "Internet Message Format", RFC 5322, 609 October 2008. 611 [RFC 5652] Housley, R., "Cryptographic Message Syntax (CMS)", 612 RFC 5652, September 2009. 614 [RFC 6376] Crocker, D., Hansen, T., Kucherawy, M., 615 "DomainKeys Identified Mail (DKIM) Signatures", 616 RFC 6376, September 2011. 618 [X.680] ITU-T. Recommendation X.680 : Abstract Syntax 619 Notation One (ASN.1): Specification of basic 620 notation, November 2008. 622 9.2. Informative References 624 [RFC 2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 625 RFC 2595, June 1999. 627 [RFC 3183] Dean, T., Ottaway, W., "Domain security services 628 using S/MIME", RFC 3183, October 2001. 630 [RFC 3207] Hoffman, P., "SMTP Service Extension for secure 631 SMTP over Transport Layer Security", RFC 3207, 632 February 2002. 634 [RFC 3501] Crispin, M., "Internet Message Access Protocol, 635 version 4rev1", RFC 3501, March 2003. 637 [RFC 5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 638 5321, October 2008. 640 [RFC 5598] Crocker, D., "Internet Mail Architecture", RFC 641 5598, July 2009. 643 [RFC 5750] Ramsdell, B., Turner, S., "Secure/Multipurpose 644 Internet Mail Extensions (S/MIME) Version 3.2 645 Certificate Handling", RFC 5750, January 2010. 647 [RFC 5751] Ramsdell, B., Turner, S., "Secure/Multipurpose 648 Internet Mail Extensions (S/MIME) Version 3.2, 649 Message Specification", RFC 5751, January 2010. 651 Appendix A. Formal syntax of Secure Header 653 ASN.1 notation [X.680] of secure header structure is the 654 follow: 656 SecureHeaderFields ::= SET { 657 canonAlgorithm Algorithm, 658 secHeaderFields HeaderFields } 660 id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= 661 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 662 pkcs-9(9) smime(16) id-aa(2) secure-headers (to be 663 defined)} 665 Algorithm ::= ENUMERATED { 666 canonAlgorithmSimple(0), 667 canonAlgorithmRelaxed(1) } 669 HeaderFields ::= SET SIZE (1..max-header-fields) OF 670 HeaderField max-header-fields INTEGER ::= MAX 672 HeaderField ::= SEQUENCE { 673 field-Name HeaderFieldName, 674 field-Value HeaderFieldValue, 675 field-Status HeaderFieldStatus DEFAULT duplicated } 677 HeaderFieldName ::= IA5String 679 HeaderFieldValue ::= IA5String 681 HeaderFieldStatus ::= INTEGER { 682 duplicated(0), deleted(1), modified(2) } 684 Appendix B. Secure Header Fields example 686 In the following example, header fields subject, from, to and 687 x-ximf-primary-precedence are secured and integrated in a 688 SecureHeaders structure. 690 Extract of message header fields 692 From: John Doe 693 To: Mary Smith 694 Subject: This is a test 695 X-ximf-primary-precedence: priority 697 SecureHeaders structure extracted from signature: 699 2286 163: SEQUENCE { 700 2289 11: OBJECT IDENTIFIER 701 '1 2 840 113549 1 9 16 2 80' 702 2302 147: SET { 703 2305 144: SET { 704 2308 4: ENUMERATED 1 705 2314 135: SET { 706 2317 40: SEQUENCE { 707 2319 25: IA5String 'x-ximf-primary- 708 precedence' 709 2346 8: IA5String 'priority' 710 2356 1: INTEGER 0 711 : } 712 2359 25: SEQUENCE { 713 2361 2: IA5String 'to' 714 2365 16: IA5String 'mary@example.com' 715 2383 1: INTEGER 0 716 : } 717 2386 34: SEQUENCE { 718 2388 4: IA5String 'from' 719 2394 23: IA5String 'jdoe 720 ' 721 2419 1: INTEGER 0 722 : } 723 2422 28: SEQUENCE { 724 2424 7: IA5String 'subject' 725 2433 14: IA5String 'This is a test' 726 2449 1: INTEGER 0 727 : } 728 : } 729 : } 730 : } 731 : } 733 Example is displayed as an output of Peter Gutmann's 734 "dumpasn1" program. 736 OID used in this example is non-official. 738 Appendix C. Acknowledgements 740 The author would like to thank Damien Roque, Thibault 741 Cassan, William Ottaway, and Sean Turner who kindly provided 742 reviews of the document and/or suggestions for improvement. 743 As always, all errors and omissions are the responsibility of 744 the authors. 746 Authors' Addresses 748 Laurent CAILLEUX 749 DGA Maitrise de l'information 750 BP 7 751 35998 Rennes Armees 752 France 753 Email: laurent.cailleux@dga.defense.gouv.fr 755 Chris Bonatti 756 IECA, Inc. 757 3057 Nutley Street, Suite 106 758 Fairfax, VA 22031 759 USA 760 Email: bonatti252@ieca.com