idnits 2.17.1 draft-cailleux-secure-headers-07.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 (17 November 2014) is 3438 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC 3501' is defined on line 689, 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: 17 May 2015 IECA 6 17 November 2014 8 Securing Header Fields with S/MIME 9 draft-cailleux-secure-headers-07 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 26 January 2015. 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...................................................5 59 4. Mechanisms to secure message header fields................7 60 4.1. ASN.1 syntax of secure header fields.................9 61 4.2. Secure header fields length and format..............10 62 4.3. Canonization algorithm..............................10 63 4.4. Header fields statuses..............................11 64 4.5. Signature Process...................................11 65 4.5.1. Signature Generation Process...................11 66 4.5.2. Signature verification process.................12 67 4.6. Encryption and Decryption Processes.................14 68 4.6.1. Encryption Process.............................14 69 4.6.2. Decryption Process.............................15 70 5. Case of triple wrapping..................................16 71 6. Security Gateways........................................17 72 7. Security Considerations..................................17 73 8. IANA Considerations......................................18 74 9. References...............................................18 75 9.1. Normative References................................18 76 9.2. Informative References..............................19 77 Appendix A. Formal syntax of Secure Header..................20 78 Appendix B. Secure Header Fields example....................22 79 Appendix C. Acknowledgements................................24 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 provide any guidance regarding what subset of 94 message header fields to secure, procedures for clients to 95 reconcile the "inner" and "outer" headers, or procedures for 96 client interpretation or display of any failures. 98 Several other security standards supplement S/MIME features, 99 but fail to address the target requirement set of this draft. 100 Such other security standards include DKIM [RFC 6376], 101 STARTTLS [RFC 3207], TLS with IMAP [RFC 2595], and an internet 102 draft referred to as PROTECTED HEADERS. An explanation of 103 what these services accomplish and why they do not solve this 104 problem can be found in subsequent sections. 106 The goal of this document is to define end to end secure 107 header fields mechanisms compliant with S/MIME standard. This 108 technique is based on the signed attribute fields of a 109 Cryptographic Message Syntax (CMS) [RFC 5652] signature. 111 2. Terminology and conventions used in this document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 114 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described 116 in [RFC 2119]. 118 The terms Message User Agent (MUA), Message Submission Agent 119 (MSA) and Message Transfer Agent (MTA) terms are defined in 120 Email architecture document [RFC 5598]. 122 The term Domain Confidentiality Authority (DCA) is defined in 123 the S/MIME Domain Security specification [RFC 3183]. 125 End-to-end Internet Mail exchanges are performed between 126 message originators and recipients. 128 The term "message header fields" is described in [RFC 5322]. 129 A header field is composed of a name and a value. 131 Secure Headers technology uses header fields statuses required 132 to provide a confidentiality service toward message headers. 133 The following three terms are used to describe the field 134 statuses: 136 - Duplicated (the default status). When this status is 137 present or if no status is specified, the signature process 138 embeds the header field value in the digital signature, but 139 the value is will also be present in the message header 140 fields. 142 - Deleted. When this status is present, the signature 143 process embeds the header field value in the digital 144 signature, and the encryption process deletes this field 145 from the message to preserve its confidentiality. 147 - Modified. When this status is present, the signature 148 process embeds the header field value in the digital 149 signature, and the encryption process modifies the value of 150 the header field in the message. This preserves 151 confidentiality and informs a receiver's non-compliant MUA 152 that secure headers are being used. New values for each 153 field might be configured by the sender (i.e., "This header 154 is secured, use a compliant client"). 156 The term "non-repudiation" is used throughout this document in 157 deference to the usage in the S/MIME Message Specification 158 [RFC 5751]. It is recognized that this term carries with it 159 much baggage, and that there is some disagreement as to it's 160 proper meaning and usage. However, in the context of this 161 document the term merely refers to one of a set of possible 162 security services that a conforming implementation might be 163 able to provide. This document specifies no normative 164 requirements for non-repudiation. 166 3. Context 168 Over the Internet, email usage has grown and today represents 169 a fundamental service. Meanwhile, continually increasing 170 threat levels are motivating the implementation of security 171 services. 173 Historically, SMTP [RFC 5321] and IMF [RFC 5322] don't 174 provide, by default, security services. The S/MIME standard 175 [RFC 5751] was published in order to encompass these needs. 176 S/MIME defines a data encapsulation format for the provision 177 of end to end security services such as integrity, 178 authentication, non-repudiation and confidentiality. By 179 default, S/MIME secures message body parts, at the exclusion 180 of the message header fields. In order to protect message 181 header fields (for instance, the "Subject", "To", "From" or 182 customized fields), several solutions exist. 184 S/MIME defines an encapsulation mechanism, chapter 3.1: "The 185 sending client may wrap a full MIME message in a 186 message/rfc822 wrapper in order to apply S/MIME security 187 services to these header fields. It is up to the receiving 188 client to decide how to present this inner header along with 189 the unprotected outer header". However, some use cases are not 190 addressed, especially in the case of message encryption. What 191 happens when header fields are encrypted? How does the 192 receiving client display these header fields? How can a subset 193 of header fields be secured? S/MIME doesn't address these 194 issues. 196 Some partial header protection is provided by the S/MIME 197 Certificate Handling specification [RFC 5750]. "Receiving 198 agents MUST check that the address in the From or Sender 199 header of a mail message matches an Internet mail address, if 200 present, in the signer's certificate, if mail addresses are 201 present in the certificate". In some cases this may provide 202 assurance of the integrity of the From or Sender header 203 values. However, the RFC 5750 solution only provides a 204 matching mechanism between email addresses, and provides no 205 protection to other header fields. 207 Other security standards (introduced below) exist such as 208 DKIM, STARTTLS and TLS with IMAP but meet other needs (signing 209 domain, secure channels...). 211 STARTTLS and TLS with IMAP provide secure channels between 212 components of email system (MUA, MSA, MTA...) but end to end 213 integrity cannot be guaranteed. 215 DKIM defines a domain-level authentication framework for 216 email. While this permits integrity and origination checks on 217 message header fields and the message body, it does for a 218 domain actor (usually the SMTP service or equivalent) and not 219 for the entity that is sending, and thus signing the message. 220 (Extensions to DKIM might be able to solve this issue by 221 authenticating the sender and making a statement as part of 222 the signed message headers of this fact.) DKIM is also 223 deficient for our purposes as it does not provide a 224 confidentially service. 226 An internet draft referred to as Protected Headers (PRHDRS) 227 has been proposed. Mechanisms described in this draft are the 228 following. "A digest value is computed over the canonicalized 229 version of some selected header fields. This technique 230 resembles header protection in DKIM. Then the digest value is 231 included in a signed attribute field of a CMS signature". This 232 specification doesn't address all conceivable requirements as 233 noted below. If the protected header field has been altered, 234 the original value cannot be determined by the recipient. In 235 addition, the encryption service cannot provide 236 confidentiality for fields that must remain present in the 237 message header during transport. 239 This document proposes a technology for securing message 240 header fields. It's referred to as Secure Headers. It is based 241 on S/MIME and CMS standards. It provides security services 242 such as data integrity, confidentiality and non-repudiation of 243 sender. Secure Headers is backward compatible with other 244 S/MIME clients. S/MIME clients who have not implemented Secure 245 Headers technology need merely ignore specific signed 246 attributes fields in a CMS signature (which is the default 247 behavior). 249 4. Mechanisms to secure message header fields 251 Secure Headers technology involves the description of a 252 security policy. This policy MUST describe a secure message 253 profile and list the header fields to secure. How this 254 security policy is agreed or communicated is beyond the scope 255 of this document. 257 Secure headers are based on the signed attributes field as 258 defined in CMS. The details are as follows. The message header 259 fields to be secured are integrated in a structure (secure 260 header structure) which is encapsulated in the signed 261 attributes structure of the SignerInfo object. There is only 262 one value of HeaderFields encoded into a single 263 SignedAttribute in a signature. See Appendix A for an 264 example. For each header field present in the secure 265 signature, a status can be set. Then, as described in chapter 266 5.4 of CMS, the message digest calculation process computes a 267 message digest on the content together with the signed 268 attributes. Details of the signature generation process are 269 described in chapter 4.5.1 of this document. 271 Verification of secure header fields is based on signature 272 verification process described in CMS. At the end of this 273 process, a comparison between the secure header fields and the 274 corresponding message header fields is performed. If they 275 match, the signature is valid. Otherwise, the signature is 276 invalid. Details of the signature verification process are 277 described in chapter 4.5.2 of this document. 279 Non-conforming S/MIME clients will ignore the signed attribute 280 containing the secure headers structure, and only perform the 281 verification process described in CMS. This guarantees 282 backward compatibility. 284 Secure headers provide security services such as data 285 integrity, non-repudiation and confidentiality. 287 For different reasons (e.g., usability, limits of IMAP [RFC 288 3501]), encryption and decryption processes are performed by a 289 third party. The third party that performs these processes is 290 referred to in Domain Security specification as a "Domain 291 Confidentiality Authority" (DCA). Details of the encryption 292 and decryption processes are described in chapters 4.6.1 and 293 4.6.2 of this document. 295 The architecture of Secure Headers is presented below. The MUA 296 performs the signature generation process (C) and signature 297 verification process (F). The DCA performs the message 298 encryption process (D) and message decryption process (E). The 299 encryption and decryption processes are optional. 301 A Domain B Domain 302 +----------------------+ +----------------------+ 304 +-----+ +-----+ +-----+ +-----+ 305 | MUA | -------> | DCA | ----------> | DCA |--------> | MUA | 306 | C | | D | | E | | F | 307 +-----+ +-----+ +-----+ +-----+ 308 SignedMsg EncryptedMsg SignedMsg 310 Figure 1: Architecture of Secure Headers 312 4.1. ASN.1 syntax of secure header fields 314 ASN.1 notation [ASN1-88] of secure header structure is the 315 follow: 317 SecureHeaderFields ::= SET { 318 canonAlgorithm Algorithm, 319 secHeaderFields HeaderFields } 321 id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= 322 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 323 pkcs-9(9) smime(16) id-aa(2) secure-headers (to be 324 defined) } 326 Algorithm ::= ENUMERATED { 327 canonAlgorithmSimple(0), 328 canonAlgorithmRelaxed(1) } 330 HeaderFields ::= SEQUENCE SIZE (1..max-header-fields) OF 331 HeaderField 333 max-header-fields INTEGER ::= MAX 335 HeaderField ::= SEQUENCE { 336 field-Name HeaderFieldName, 337 field-Value HeaderFieldValue, 338 field-Status HeaderFieldStatus DEFAULT duplicated } 340 HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":"))) 341 -- This description matches with the description of 342 -- field name in the chapters 2.2 and 3.6.8 of RFC 5322 344 HeaderFieldValue ::= UTF8String 345 -- This description matches with the description of 346 -- field body in the chapter 2.2 of RFC 5322 as 347 -- extended by chapter 3.1 of RFC 6532. 349 HeaderFieldStatus ::= INTEGER { 350 duplicated(0), deleted(1), modified(2) } 352 4.2. Secure header fields length and format 354 This specification requires MUA security capabilities in order 355 to process well formed headers, as specified in IMF. Notice 356 that it includes long header fields and folded header fields. 358 4.3. Canonization algorithm 360 During a message transfer through a messaging system, some 361 components might modify headers (i.e., space adding or 362 deletion, lowercase/uppercase rewriting...). This might lead 363 to header fields comparison mismatch. This emphasizes the need 364 of a conversion process in order to transform data to their 365 canonical form. This process is named canonization process. 367 Two canonization algorithms are considered here, according to 368 DKIM specification [RFC 6376], chapter 3.4. The simple 369 algorithm doesn't allow any modification whereas the relaxed 370 algorithm accepts slight modifications like spaces replacement 371 or line reformatting. Given the scope of this document, 372 canonization mechanisms only involve header fields. 374 Implementations SHOULD use the relaxed algorithm to promote 375 interoperability with non-conforming SMTP products. 377 4.4. Header fields statuses 379 Header fields statuses are necessary to provide a 380 confidentiality service toward message headers. In this 381 specification, the confidentiality of header fields is 382 provided by the DCA. This point is described in chapter 4. The 383 DCA performs the message encryption process and message 384 decryption process and these processes are described in 385 details in the chapters 4.6.1 and 4.6.2. Although header 386 fields statuses are embedded in the signature, the signature 387 processes (generation and verification) ignore them. The 388 header field status defaults to duplicated. If the header 389 field is confidential, the header field status MUST be either 390 deleted or modified. 392 4.5. Signature Process 394 4.5.1. Signature Generation Process 396 During the signature generation process, the sender's MUA MUST 397 embed the SecureHeaderFields structure in the signed 398 attributes, as described in CMS. SecureHeaderFields structure 399 MUST include a canonization algorithm. 401 The sender's MUA MUST have a list of header fields to secure, 402 statuses and a canonization algorithm, as defined by the 403 security policy. 405 Header fields (names and values) embedded in signed attributes 406 MUST be the same as the ones included in the initial message. 408 If different headers share the same name, all instances MUST 409 be included in the SecureHeaderFields structure. 411 If multiple signatures are used, as explained in CMS and 412 MULTISIGN [RFC 4853] specifications, SecureHeaderFields 413 structure MUST be the same in each SignerInfos object. 415 If a header field is present and its value is empty, 416 HeaderFieldValue MUST have a zero-length field-value. 418 Considering secure headers mechanisms, the signature 419 generation process MUST perform the following steps: 421 1) Select the relevant header fields to secure. This subset 422 of headers is defined according the security policy. 424 2) Apply the canonization algorithm for each selected header 425 field. 427 3) Complete the following fields in SecureHeaderFields 428 structure according to the initial message: HeaderFieldName, 429 HeaderFieldValue, HeaderFieldStatus. 431 4) Complete the algorithm field according to the 432 canonization algorithm configured. 434 5) Embed the SecureHeaderFields structure in the signed 435 attributes of the SignerInfos object. 437 6) Compute the signature generation process as described in 438 CMS, chapter 5.5 440 4.5.2. Signature verification process 442 During the signature verification process, the receiver's MUA 443 compares header fields embedded in the SecureHeaderFields 444 structure with those present in the message. For this purpose, 445 it uses the canonization algorithm identified in the signed 446 attributes. If a mismatch appears during the comparison 447 process, the receiver's MUA MUST invalidate the signature. The 448 MUA MUST display information on the validity of each header 449 field. It MUST also display the values embedded in the 450 signature. 452 The receiver's MUA MUST know the list of mandatory header 453 fields in order to verify their presence in the message. If a 454 header field defined in a message is in the secure header 455 list, it MUST be included in the SecureHeaderFields structure. 456 Otherwise, the receiver's MUA MUST warn the user that a non- 457 secure header is present. 459 Considering secure headers mechanisms, the signature 460 verification process MUST perform the following steps: 462 1) Execute the signature verification process as described 463 in CMS, chapter 5.6. If the signature appears to be invalid, 464 the process ends. Otherwise, the process continues. 466 2) Read the type of canonization algorithm specified in 467 SecureHeaderFields structure. 469 3) For each field present in the signature, find the 470 matching header in the message. If there is no matching 471 header, the verification process MUST warn the user, 472 specifying the missing header name. The signature is tagged 473 as invalid. Note that any headers fields encrypted as per 474 section 4.6 (i.e., status of "deleted" or "modified") have 475 been are already restored by the DCA when the signature 476 verification process is performed by the MUA. 478 4) Compute the canonization algorithm for each header field 479 value in the message. If the simple algorithm is used, the 480 steps described in DKIM, chapter 3.4.1, are performed. If 481 the relaxed algorithm is used, the steps described in DKIM, 482 chapter 3.4.2, are performed. 484 5) For each field, compare the value stored in the 485 SecureHeaderFields structure with the value returned by the 486 canonization algorithm. If values don't match, the 487 verification process MUST warn the user. This warning MUST 488 mention mismatching fields. The signature is tagged as 489 invalid. If all the comparisons succeed, the verification 490 process MUST also notify the user (i.e., using an 491 appropriate icon). 493 6) Verify that no secure header has been added to the 494 message header, given the initial fields. If an extra header 495 field has been added, the verification process MUST warn the 496 user. This warning MUST mention extra fields. The signature 497 is tagged as invalid. This step is only performed if the 498 sender and the recipient share the same security policy. 500 7) Verify that every mandatory headers in the security 501 policy and present in the message are also embedded in the 502 SecureHeaderFields structure. If such headers are missing, 503 the verification process MUST warn the user and indicate the 504 names of the missing headers. 506 The MUA MUST display features for each secure header field 507 (name, value and status) and canonization algorithm used. 509 4.6. Encryption and Decryption Processes 511 Encryption and decryption operations are not performed by 512 MUAs. This is mainly justified by limitations of existing 513 email delivery protocols, for example IMAP. The solution 514 developed here relies on concepts explained in Domain Security 515 specification, chapter 4. A fundamental component of the 516 architecture is the Domain Confidentiality Authority (DCA). 517 Its purpose is to encrypt and decrypt messages instead of 518 (respectively) senders and receivers. 520 4.6.1. Encryption Process 522 All the computations presented in this chapter MUST be 523 performed only if the following conditions are verified: 525 - The content to be encrypted MUST consist of a signed 526 message (application/pkcs7-mime with SignedData or 527 multipart/signed) as shown in S/MIME specification, chapter 528 3.4. 530 - A SecureHeaderFields structure MUST be included in the 531 signedAttrs field of the SignerInfo object of the signature. 533 All the mechanisms described below MUST start at the beginning 534 of the encryption process, as explained in CMS. They are 535 performed by the sender's DCA. The following steps MUST be 536 performed for each field included in the SecureHeaderFields 537 structure: 539 1. Extraction of the field status; 541 1.1 If the status is Duplicated, the field is left at its 542 existing value. 544 1.2 If the status is Deleted, the header field (name and 545 value) is removed from the message. Mandatory header fields 546 specified in [RFC 5322] MUST be kept. 548 1.3 If the status is Modified, the header value is replaced 549 by a new value, as configured in the DCA. 551 4.6.2. Decryption Process 553 All the computations presented in this chapter MUST be 554 performed only if the following conditions are verified: 556 - The decrypted content MUST consist of a signature object 557 or a multipart object, where one part is a detached 558 signature, as shown in S/MIME specification, chapter 3.4. 560 - A SecureHeaderFields structure MUST be included in the 561 SignerInfo object of the signature. 563 All the mechanisms described below MUST start at the end of 564 the decryption process, as explained in CMS. They are executed 565 by the receiver's DCA. The following steps MUST be performed 566 for each field included in the SecureHeaderFields structure: 568 1. If the status is Duplicated, the field is left at its 569 existing value. 571 2. If the status is Deleted, the DCA MUST write a header 572 field (name and value) in the message. This header MUST be 573 compliant with the information embedded in the signature. 575 3. If the status is Modified, the DCA MUST rewrite a header 576 field in the message. This header MUST be compliant with the 577 SecureHeaderFields structure. 579 5. Case of triple wrapping 581 Secure Headers mechanisms MAY be used with triple wrapping, as 582 described in ESS [RFC 2634]. In this case, a 583 SecureHeaderFields structure MAY be present in the inner 584 signature, in the outer signature, or both. In the last case, 585 the two structure SecureHeaderFields MAY differ. One MAY 586 consider the encapsulation of a header field in the inner 587 signature in order to satisfy confidentiality needs. On the 588 contrary, an outer signature encapsulation MAY help for 589 delivery purpose. Sender's MUA and receiver's MUA must have a 590 security policy for triple wrapping. This security policy 591 MUST be composed of two parts. One part dedicated for the 592 inner signature and one part dedicated for the outer 593 signature. 595 6. Security Gateways 597 Some security gateways sign or verify messages that pass 598 through them. Compliant gateways MUST apply the process 599 described in chapter 4.5. 601 For non-compliant gateways, the presence of SecureHeaderFields 602 structure do not change their behavior. 604 In some case, gateways MUST generate new signature or insert 605 signerInfos into the signedData block. The format of 606 signatures generated by gateways is outside the scope of this 607 document. 609 7. Security Considerations 611 This specification describes an extension of the S/MIME 612 standard. It provides message headers integrity, non- 613 repudiation and confidentiality. The signature and encryption 614 processes are complementary. However, according to the 615 security policy, only the signature mechanism is applicable. 616 In this case, the signature process is implemented between 617 MUAs. The encryption process requires signed messages with 618 Secure Headers extension. If required, the encryption process 619 is implemented by DCAs. 621 This specification doesn't address end-to-end confidentiality 622 for message header fields. Messages sent and received by MUAs 623 could be transmitted as plaintext. In order to avoid 624 interception, the use of TLS is recommended between MUAs and 625 DCAs (uplink and downlink). Another solution might be the use 626 of S/MIME between MUAs and DCAs in the same domain. 628 For the header field confidentiality mechanism to be effective 629 all DCAs supporting confidentiality must support SH 630 processing. Otherwise, there is a risk in the case where 631 headers are not obscured upon encryption, or not restored upon 632 decryption process. In the former case confidentiality of the 633 header fields is compromised. In the latter case the integrity 634 of the headers will appear to be compromised. 636 8. IANA Considerations 638 IANA must register a suitable Object Identifier (OID) value 639 for the identifier id-aa-secureHeaderFieldsIdentifier. This 640 value will be used to identify an authenticated attribute 641 carried within a CMS [RFC 5652] wrapper. This attribute OID 642 appears in Section 4.1, and again in the reference definition 643 in Appendix A. An appropriate registry arc is suggested in 644 those instances of the draft text. 646 9. References 648 9.1. Normative References 650 [RFC 2045] Borenstein, N., "Multipurpose Internet Mail 651 Extensions Part One", RFC 2045, November 1996. 653 [RFC 2119] Bradner, S., "Key words for use in RFCs to 654 indicate requirement levels", RFC 2119, March 655 1997. 657 [RFC 2634] Hoffman, P., "Enhanced Security Services for 658 S/MIME", RFC 2634, June 1999. 660 [RFC 4853] Housley, R., "Cryptographic Message Syntax (CMS), 661 Multiple Signer Clarification", RFC 4853, April 662 2007. 664 [RFC 5322] Resnick, P., "Internet Message Format", RFC 5322, 665 October 2008. 667 [RFC 5652] Housley, R., "Cryptographic Message Syntax (CMS)", 668 RFC 5652, September 2009. 670 [RFC 6376] Crocker, D., Hansen, T., Kucherawy, M., DomainKeys 671 Identified Mail (DKIM) Signatures", RFC 6376, 672 September 2011. 674 [ASN1-88] CCITT. Recommendation X.208: Specification of 675 Abstract Syntax Notation One (ASN.1), 1988. 677 9.2. Informative References 679 [RFC 2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 680 RFC 2595, June 1999. 682 [RFC 3183] Dean, T., Ottaway, W., "Domain security services 683 using S/MIME", RFC 3183, October 2001. 685 [RFC 3207] Hoffman, P., "SMTP Service Extension for secure 686 SMTP over Transport Layer Security", RFC 3207, 687 February 2002. 689 [RFC 3501] Crispin, M., "Internet Message Access Protocol, 690 version 4rev1", RFC 3501, March 2003. 692 [RFC 5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 693 5321, October 2008. 695 [RFC 5598] Crocker, D., "Internet Mail Architecture", RFC 696 5598, July 2009. 698 [RFC 5750] Ramsdell, B., Turner, S., "Secure/Multipurpose 699 Internet Mail Extensions (S/MIME) Version 3.2 700 Certificate Handling", RFC 5750, January 2010. 702 [RFC 5751] Ramsdell, B., Turner, S., "Secure/Multipurpose 703 Internet Mail Extensions (S/MIME) Version 3.2, 704 Message Specification", RFC 5751, January 2010. 706 Appendix A. Formal syntax of Secure Header 708 Note: The ASN.1 module contained herein uses the 1988 version 709 of ASN.1 notation [ASN1-88] for the purposes of alignment with 710 th existing S/MIME specifications. The secure header structure 711 is defined as follows: 713 SMimeSecureHeadersV1 714 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 715 pkcs-9(9) smime(16) modules(0) secure-headers-v1(to be 716 defined) } 718 DEFINITIONS IMPLICIT TAGS ::= 720 BEGIN 722 IMPORTS 724 id-aa 725 FROM SecureMimeMessageV3dot1 726 { iso(1) member-body(2) us(840) rsadsi(113549) 727 pkcs(1) pkcs-9(9) smime(16) modules(0) 728 msg-v3dot1(21) }; 730 -- id-aa is the arc with all new authenticated and 731 -- unauthenticated attributes produced by the S/MIME 732 -- Working Group 734 id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= id-aa 735 secure-headers (to be defined) } 737 SecureHeaderFields ::= SET { 738 canonAlgorithm Algorithm, 739 secHeaderFields HeaderFields } 741 Algorithm ::= ENUMERATED { 742 canonAlgorithmSimple(0), 743 canonAlgorithmRelaxed(1) } 745 HeaderFields ::= SEQUENCE SIZE (1..max-header-fields) OF 746 HeaderField 748 max-header-fields INTEGER ::= MAX 750 HeaderField ::= SEQUENCE { 751 field-Name HeaderFieldName, 752 field-Value HeaderFieldValue, 753 field-Status HeaderFieldStatus DEFAULT duplicated } 755 HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":"))) 756 -- This description matches with the description of 757 -- field name in the chapters 2.2 and 3.6.8 of RFC 5322 759 HeaderFieldValue ::= UTF8String 760 -- This description matches with the description of 761 -- field body in the chapter 2.2 of RFC 5322 as 762 -- extended by chapter 3.1 of RFC 6532. 764 HeaderFieldStatus ::= INTEGER { 765 duplicated(0), deleted(1), modified(2) } 767 END 769 Appendix B. Secure Header Fields example 771 In the following example, header fields subject, x-ximf- 772 primary-precedence and x-ximf-correspondance-type are secured 773 and integrated in a SecureHeaders structure. This example 774 should produce a valid signature. 776 Extract of message header fields 778 From: John Doe 779 To: Mary Smith 780 subject: This is a test of Ext. 781 x-ximf-primary-precedence: priority 782 x-ximf-correspondance-type: official 784 SecureHeaders structure extracted from signature: 786 2286 150: SEQUENCE { 787 2289 11: OBJECT IDENTIFIER '1 2 840 113549 1 9 16 2 80' 788 2302 134: SET { 789 2305 131: SET { 790 2308 4: ENUMERATED 1 791 2314 123: SEQUENCE { 792 2316 40: SEQUENCE { 793 2318 25: VisibleString 'x-ximf-primary-precedence' 794 2345 8: UTF8String 'priority' 795 2355 1: INTEGER 0 796 : } 797 2358 41: SEQUENCE { 798 2360 26: VisibleString 'x-ximf-correspondance-type' 799 2388 8: UTF8String 'official' 800 2398 1: INTEGER 0 801 : } 802 2401 36: SEQUENCE { 803 2403 7: VisibleString 'subject' 804 2412 22: UTF8String 'This is a test of Ext.' 805 2436 1: INTEGER 0 806 : } 807 : } 808 : } 809 : } 810 : } 812 Example is displayed as an output of Peter Gutmann's 813 "dumpasn1" program. 815 OID used in this example is non-official. 817 Appendix C. Acknowledgements 819 The authors would like to thank Jim Schaad, Alexey Melnikov, 820 Damien Roque, Thibault Cassan, William Ottaway, and Sean 821 Turner who kindly provided reviews of the document and/or 822 suggestions for improvement. As always, all errors and 823 omissions are the responsibility of the authors. 825 Authors' Addresses 827 Laurent CAILLEUX 828 DGA MI 829 BP 7 830 35998 RENNES CEDEX 9 831 France 832 Email: laurent.cailleux@intradef.gouv.fr 834 Chris Bonatti 835 IECA, Inc. 836 3057 Nutley Street, Suite 106 837 Fairfax, VA 22031 838 USA 839 Email: bonatti252@ieca.com