idnits 2.17.1 draft-cailleux-secure-headers-05.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 (9 April 2014) is 3670 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC 3501' is defined on line 629, 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: 10 October 2014 IECA 6 9 April 2014 8 Securing Header Fields with S/MIME 9 draft-cailleux-secure-headers-05 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 24 October 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..............................................3 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.................8 61 4.2. Secure header fields length and format...............9 62 4.3. Canonization algorithm...............................9 63 4.4. Header fields statuses...............................9 64 4.5. Signature Process...................................10 65 4.5.1. Signature Generation Process...................10 66 4.5.2. Signature verification process.................11 67 4.6. Encryption and Decryption Processes.................13 68 4.6.1. Encryption Process.............................13 69 4.6.2. Decryption Process.............................14 70 5. Case of triple wrapping..................................15 71 6. Security Gateways........................................15 72 7. Security Considerations..................................15 73 8. IANA Considerations......................................16 74 9. References...............................................16 75 9.1. Normative References................................16 76 9.2. Informative References..............................17 77 Appendix A. Formal syntax of Secure Header..................19 78 Appendix B. Secure Header Fields example....................20 79 Appendix C. Acknowledgements................................22 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 108 Cryptographic Message Syntax (CMS) [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 Secure 201 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 261 Figure 1: Architecture of Secure Headers 263 4.1. ASN.1 syntax of secure header fields 265 ASN.1 notation [X.680] of secure header structure is the 266 follow: 268 SecureHeaderFields ::= SET { 269 canonAlgorithm Algorithm, 270 secHeaderFields HeaderFields } 272 id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= 273 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 274 pkcs-9(9) smime(16) id-aa(2) secure-headers (to be 275 defined) } 277 Algorithm ::= ENUMERATED { 278 canonAlgorithmSimple(0), 279 canonAlgorithmRelaxed(1) } 281 HeaderFields ::= SET SIZE (1..max-header-fields) OF 282 HeaderField 284 max-header-fields INTEGER ::= MAX 286 HeaderField ::= SEQUENCE { 287 field-Name HeaderFieldName, 288 field-Value HeaderFieldValue, 289 field-Status HeaderFieldStatus DEFAULT duplicated } 291 HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":"))) 292 -- This description matches with the description of 293 -- field name in the chapters 2.2 and 3.6.8 of RFC 5322 295 HeaderFieldValue ::= IA5String (FROM (ALL EXCEPT ( 296 { 0, 0 }..{ 0, 9 } | { 0, 11 } | { 0, 12 } | 297 { 0, 14 }..{ 1, 15 } | { 7, 15 }))) 298 -- This description matches with the description of 299 -- field body in the chapter 2.2 of RFC 5322 301 HeaderFieldStatus ::= INTEGER { 302 duplicated(0), deleted(1), modified(2) } 304 4.2. Secure header fields length and format 306 This specification requires MUA security capabilities in order 307 to process well formed headers, as specified in IMF. Notice 308 that it includes long header fields and folded header fields. 310 4.3. Canonization algorithm 312 During a message transfer through a messaging system, some 313 components might modify headers (i.e., space adding or 314 deletion, lowercase/uppercase rewriting...). This might lead 315 to header fields comparison mismatch. This emphasizes the need 316 of a conversion process in order to transform data to their 317 canonical form. This process is named canonization process. 319 Two canonization algorithms are considered here, according to 320 DKIM specification [RFC 6376], chapter 3.4. The simple 321 algorithm doesn't allow any modification whereas the relaxed 322 algorithm accepts slight modifications like spaces replacement 323 or line reformatting. Given the scope of this document, 324 canonization mechanisms only involve header fields. 326 4.4. Header fields statuses 328 Header fields statuses are necessary to provide a 329 confidentiality service toward message headers. In this 330 specification, the confidentiality of header fields is 331 provided by the DCA. This point is described in chapter 4. The 332 DCA performs the message encryption process and message 333 decryption process and these processes are described in 334 details in the chapters 4.6.1 and 4.6.2. Although header 335 fields statuses are embedded in the signature, the signature 336 processes (generation and verification) ignore them. Since the 337 confidentiality service is OPTIONAL, the status field is also 338 OPTIONAL. 340 4.5. Signature Process 342 4.5.1. Signature Generation Process 344 During the signature generation process, the sender's MUA MUST 345 embed the SecureHeaderFields structure in the signed 346 attributes, as described in CMS. SecureHeaderFields structure 347 MUST include a canonization algorithm. 349 The sender's MUA MUST have a list of header fields to secure, 350 statuses and a canonization algorithm, as defined by the 351 security policy. 353 Header fields (names and values) embedded in signed attributes 354 MUST be the same as the ones included in the initial message. 356 If different headers share the same name, all instances MUST 357 be included in the SecureHeaderFields structure. 359 If multiple signatures are used, as explained in CMS and 360 MULTISIGN [RFC 4853] specifications, SecureHeaderFields 361 structure MUST be the same in each SignerInfos object. 363 If a header field is present and its value is empty, 364 HeaderFieldValue MUST have a zero-length field-value. 366 Considering secure headers mechanisms, the signature 367 generation process MUST perform the following steps: 369 1) Select the relevant header fields to secure. This subset 370 of headers is defined according the security policy. 372 2) Apply the canonization algorithm for each selected header 373 field. header field. 375 3) Complete the following fields in SecureHeaderFields 376 structure according to the initial message: HeaderFieldName, 377 HeaderFieldValue, HeaderFieldStatus (OPTIONAL). 379 4) Complete the algorithm field according to the 380 canonization algorithm configured. 382 5) Embed the SecureHeaderFields structure in the signed 383 attributes of the SignerInfos object. 385 6) Compute the signature generation process as described in 386 CMS, chapter 5.5 388 4.5.2. Signature verification process 390 During the signature verification process, the receiver's MUA 391 compares header fields embedded in the SecureHeaderFields 392 structure with those present in the message. For this purpose, 393 it uses the canonization algorithm identified in the signed 394 attributes. If a mismatch appears during the comparison 395 process, the receiver's MUA MUST invalidate the signature. The 396 MUA MUST display information on the validity of each header 397 field. It MUST also display the values embedded in the 398 signature. 400 The receiver's MUA MUST know the list of mandatory header 401 fields in order to verify their presence in the message. If a 402 header field defined in a message is in the secure header 403 list, it MUST be included in the SecureHeaderFields structure. 404 Otherwise, the receiver's MUA MUST warn the user that a non- 405 secure header is present. 407 Considering secure headers mechanisms, the signature 408 verification process MUST perform the following steps: 410 1) Execute the signature verification process as described 411 in CMS, chapter 5.6. If the signature appears to be invalid, 412 the process ends. Otherwise, the process continues. 414 2) Read the type of canonization algorithm specified in 415 SecureHeaderFields structure. 417 3) For each field present in the signature, find the 418 matching header in the message. If there is no matching 419 header, the verification process MUST warn the user, 420 specifying the missing header name. The signature is tagged 421 as invalid. 423 4) Compute the canonization algorithm for each header field 424 value in the message. If the simple algorithm is used, the 425 steps described in DKIM, chapter 3.4.1, are performed. If 426 the relaxed algorithm is used, the steps described in DKIM, 427 chapter 3.4.2, are performed. 429 5) For each field, compare the value stored in the 430 SecureHeaderFields structure with the value returned by the 431 canonization algorithm. If values don't match, the 432 verification process MUST warn the user. This warning MUST 433 mention mismatching fields. The signature is tagged as 434 invalid. If all the comparisons succeed, the verification 435 process MUST also notify the user (i.e., using an 436 appropriate icon). 438 6) Verify that no secure header has been added to the 439 message header, given the initial fields. If an extra header 440 field has been added, the verification process MUST warn the 441 user. This warning MUST mention extra fields. The signature 442 is tagged as invalid. 444 7) Verify that every mandatory headers in the security 445 policy and present in the message are also embedded in the 446 SecureHeaderFields structure. If such headers are missing, 447 the verification process MUST warn the user and indicate the 448 names of the missing headers. 450 The MUA MUST display features for each secure header field 451 (name, value and status) and canonization algorithm used. 453 4.6. Encryption and Decryption Processes 455 Encryption and decryption operations are not performed by 456 MUAs. This is mainly justified by IMAP limitations. The 457 solution developed here relies on concepts explained in Domain 458 Security specification, chapter 4. A fundamental component of 459 the architecture is the Domain Confidentiality Authority 460 (DCA). Its purpose is to encrypt and decrypt messages instead 461 of (respectively) senders and receivers. 463 4.6.1. Encryption Process 465 All the computations presented in this chapter MUST be 466 performed only if the following conditions are verified: 468 - The content to be encrypted MUST consist of a signature 469 object or a multipart object, where one part is a detached 470 signature, as shown in S/MIME specification, chapter 3.4. 472 - A SecureHeaderFields structure MUST be included in the 473 signedAttrs field of the SignerInfo object of the signature. 475 All the mechanisms described below MUST start at the beginning 476 of the encryption process, as explained in CMS. They are 477 performed by the sender's DCA. The following steps MUST be 478 performed for each field included in the SecureHeaderFields 479 structure: 481 1. Extraction of the field status; 482 1.1 If the status is Duplicated, the field is left at its 483 existing value. 485 1.2 If the status is Deleted, the header field (name and 486 value) is removed from the message. Mandatory header fields 487 specified in [RFC 5322] MUST be kept. 489 1.3 If the status is Modified, the header value is replaced 490 by a new value, as configured in the DCA. 492 4.6.2. Decryption Process 494 All the computations presented in this chapter MUST be 495 performed only if the following conditions are verified: 497 - The decrypted content MUST consist of a signature object 498 or a multipart object, where one part is a detached 499 signature, as shown in S/MIME specification, chapter 3.4. 501 - A SecureHeaderFields structure MUST be included in the 502 SignerInfo object of the signature. 504 All the mechanisms described below MUST start at the end of 505 the decryption process, as explained in CMS. They are executed 506 by the receiver's DCA. The following steps MUST be performed 507 for each field included in the SecureHeaderFields structure: 509 1. If the status is Duplicated, the field is left at its 510 existing value. 512 2. If the status is Deleted, the DCA MUST write a header 513 field (name and value) in the message. This header MUST be 514 compliant with the information embedded in the signature. 516 3. If the status is Modified, the DCA MUST rewrite a header 517 field in the message. This header MUST be compliant with the 518 SecureHeaderFields structure. 520 5. Case of triple wrapping 522 Secure Headers mechanisms MAY be used with triple wrapping, as 523 described in ESS [RFC 2634]. In this case, a 524 SecureHeaderFields structure MAY be present in the inner 525 signature, in the outer signature, or both. In the last case, 526 the two structure SecureHeaderFields MAY differ. One MAY 527 consider the encapsulation of a header field in the inner 528 signature in order to satisfy confidentiality needs. On the 529 contrary, an outer signature encapsulation MAY help for 530 delivery purpose. Header fields processing, given the 531 signature type (inner or outer), is out of the scope of this 532 document. 534 6. Security Gateways 536 Some security gateways sign or verify messages that pass 537 through them. Compliant gateways MUST apply the process 538 described in chapter 4.5. 540 For non-compliant gateways, the presence of SecureHeaderFields 541 structure do not change their behavior. 543 In some case, gateways MUST generate new signature or insert 544 signerInfos into the signedData block. The format of 545 signatures generated by gateways is outside the scope of this 546 document. 548 7. Security Considerations 550 This specification describes an extension of the S/MIME 551 standard. It provides message headers integrity, non- 552 repudiation and confidentiality. The signature and encryption 553 processes are complementary. However, according to the 554 security policy, only the signature mechanism MAY be 555 prescribed. In this case, the signature process is implemented 556 between MUAs. The encryption process requires signed messages 557 with Secure Headers extension. If required, the encryption 558 process is implemented by DCAs. 560 This specification doesn't address end-to-end confidentiality 561 for message header fields. Sent and received messages by MUAs 562 MAY appear in plaintext. In order to avoid interception, the 563 use of TLS is recommended between MUAs and DCAs (uplink and 564 downlink). Another solution might be the use of S/MIME between 565 MUAs and DCAs in the same domain. 567 For the header field confidentiality mechanism to be effective 568 all DCAs supporting confidentiality must support SH 569 processing. Otherwise, there is a risk in the case where 570 headers are not obscured upon encryption, or not restored upon 571 decryption process. In the former case confidentiality of the 572 header fields is compromised. In the latter case the integrity 573 of the headers will appear to be compromised. 575 8. IANA Considerations 577 IANA must register a suitable Object Identifier (OID) value 578 for the identifier id-aa-secureHeaderFieldsIdentifier. This 579 value will be used to identify an authenticated attribute 580 carried within a CMS [RFC 5652] wrapper. This attribute OID 581 appears in Section 4.1, and again in the reference definition 582 in Appendix A. An appropriate registry arc is suggested in 583 those instances of the draft text. 585 9. References 587 9.1. Normative References 589 [RFC 2045] Borenstein, N., "Multipurpose Internet Mail 590 Extensions Part One", RFC 2045, November 1996. 592 [RFC 2119] Bradner, S., "Key words for use in RFCs to 593 indicate requirement levels", RFC 2119, March 594 1997. 596 [RFC 2634] Hoffman, P., "Enhanced Security Services for 597 S/MIME", RFC 2634, June 1999. 599 [RFC 4853] Housley, R., "Cryptographic Message Syntax (CMS), 600 Multiple Signer Clarification", RFC 4853, April 601 2007. 603 [RFC 5322] Resnick, P., "Internet Message Format", RFC 5322, 604 October 2008. 606 [RFC 5652] Housley, R., "Cryptographic Message Syntax (CMS)", 607 RFC 5652, September 2009. 609 [RFC 6376] Crocker, D., Hansen, T., Kucherawy, M., DomainKeys 610 Identified Mail (DKIM) Signatures", RFC 6376, 611 September 2011. 613 [X.680] ITU-T. Recommendation X.680 : Abstract Syntax 614 Notation One (ASN.1): Specification of basic 615 notation, November 2008. 617 9.2. Informative References 619 [RFC 2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 620 RFC 2595, June 1999. 622 [RFC 3183] Dean, T., Ottaway, W., "Domain security services 623 using S/MIME", RFC 3183, October 2001. 625 [RFC 3207] Hoffman, P., "SMTP Service Extension for secure 626 SMTP over Transport Layer Security", RFC 3207, 627 February 2002. 629 [RFC 3501] Crispin, M., "Internet Message Access Protocol, 630 version 4rev1", RFC 3501, March 2003. 632 [RFC 5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 633 5321, October 2008. 635 [RFC 5598] Crocker, D., "Internet Mail Architecture", RFC 636 5598, July 2009. 638 [RFC 5750] Ramsdell, B., Turner, S., "Secure/Multipurpose 639 Internet Mail Extensions (S/MIME) Version 3.2 640 Certificate Handling", RFC 5750, January 2010. 642 [RFC 5751] Ramsdell, B., Turner, S., "Secure/Multipurpose 643 Internet Mail Extensions (S/MIME) Version 3.2, 644 Message Specification", RFC 5751, January 2010. 646 Appendix A. Formal syntax of Secure Header 648 ASN.1 notation [X.680] of secure header structure is the 649 follow: 651 SecureHeaderFields ::= SET { 652 canonAlgorithm Algorithm, 653 secHeaderFields HeaderFields } 655 id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= 656 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs- 657 9(9) smime(16) id-aa(2) secure-headers (to be defined) } 659 Algorithm ::= ENUMERATED { 660 canonAlgorithmSimple(0), 661 canonAlgorithmRelaxed(1) } 663 HeaderFields ::= SET SIZE (1..max-header-fields) OF 664 HeaderField 666 max-header-fields INTEGER ::= MAX 668 HeaderField ::= SEQUENCE { 669 field-Name HeaderFieldName, 670 field-Value HeaderFieldValue, 671 field-Status HeaderFieldStatus DEFAULT duplicated } 673 HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":"))) 674 -- This description matches with the description of 675 -- field name in the chapters 2.2 and 3.6.8 of RFC 5322 677 HeaderFieldValue ::= IA5String (FROM (ALL EXCEPT ( 678 { 0, 0 }..{ 0, 9 } | { 0, 11 } | { 0, 12 } | 679 { 0, 14 }..{ 1, 15 } | { 7, 15 }))) 680 -- This description matches with the description of 681 -- field body in the chapter 2.2 of RFC 5322 683 HeaderFieldStatus ::= INTEGER { 684 duplicated(0), deleted(1), modified(2) } 686 Appendix B. Secure Header Fields example 688 In the following example, header fields subject, from, to and 689 x-ximf-primary-precedence are secured and integrated in a 690 SecureHeaders structure. 692 Extract of message header fields 694 From: John Doe 695 To: Mary Smith 696 Subject: This is a test 697 X-ximf-primary-precedence: priority 699 SecureHeaders structure extracted from signature: 701 2286 163: SEQUENCE { 702 2289 11: OBJECT IDENTIFIER 703 '1 2 840 113549 1 9 16 2 80' 704 2302 147: SET { 705 2305 144: SET { 706 2308 4: ENUMERATED 1 707 2314 135: SET { 708 2317 40: SEQUENCE { 709 2319 25: IA5String 'x-ximf-primary- 710 precedence' 711 2346 8: IA5String 'priority' 712 2356 1: INTEGER 0 713 : } 714 2359 25: SEQUENCE { 715 2361 2: IA5String 'to' 716 2365 16: IA5String 'mary@example.com' 717 2383 1: INTEGER 0 718 : } 719 2386 34: SEQUENCE { 720 2388 4: IA5String 'from' 721 2394 23: IA5String 'jdoe 722 ' 723 2419 1: INTEGER 0 724 : } 725 2422 28: SEQUENCE { 726 2424 7: IA5String 'subject' 727 2433 14: IA5String 'This is a test' 728 2449 1: INTEGER 0 729 : } 730 : } 731 : } 732 : } 733 : } 735 Example is displayed as an output of Peter Gutmann's 736 "dumpasn1" program. 738 OID used in this example is non-official. 740 Appendix C. Acknowledgements 742 The authors would like to thank Alexey Melnikov, Damien Roque, 743 Thibault Cassan, William Ottaway, and Sean Turner who kindly 744 provided reviews of the document and/or suggestions for 745 improvement. As always, all errors and omissions are the 746 responsibility of the authors. 748 Authors' Addresses 750 Laurent CAILLEUX 751 DGA MI 752 BP 7 753 35998 RENNES CEDEX 9 754 France 755 Email: laurent.cailleux@intradef.gouv.fr 757 Chris Bonatti 758 IECA, Inc. 759 3057 Nutley Street, Suite 106 760 Fairfax, VA 22031 761 USA 762 Email: bonatti252@ieca.com