idnits 2.17.1 draft-cailleux-secure-headers-08.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 (22 January 2015) is 3354 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC 3501' is defined on line 686, 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: 22 July 2015 IECA 6 22 January 2015 8 Securing Header Fields with S/MIME 9 draft-cailleux-secure-headers-08 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 22 July 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..............................10 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........................................16 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) OF HeaderField 332 HeaderField ::= SEQUENCE { 333 field-Name HeaderFieldName, 334 field-Value HeaderFieldValue, 335 field-Status HeaderFieldStatus DEFAULT duplicated } 337 HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":"))) 338 -- This description matches with the description of 339 -- field name in the chapters 2.2 and 3.6.8 of RFC 5322 341 HeaderFieldValue ::= UTF8String 342 -- This description matches with the description of 343 -- field body in the chapter 2.2 of RFC 5322 as 344 -- extended by chapter 3.1 of RFC 6532. 346 HeaderFieldStatus ::= INTEGER { 347 duplicated(0), deleted(1), modified(2) } 349 4.2. Secure header fields length and format 351 This specification requires MUA security capabilities in order 352 to process well formed headers, as specified in IMF. Notice 353 that it includes long header fields and folded header fields. 355 4.3. Canonization algorithm 357 During a message transfer through a messaging system, some 358 components might modify headers (i.e., space adding or 359 deletion, lowercase/uppercase rewriting...). This might lead 360 to header fields comparison mismatch. This emphasizes the need 361 of a conversion process in order to transform data to their 362 canonical form. This process is named canonization process. 364 Two canonization algorithms are considered here, according to 365 DKIM specification [RFC 6376], chapter 3.4. The simple 366 algorithm doesn't allow any modification whereas the relaxed 367 algorithm accepts slight modifications like spaces replacement 368 or line reformatting. Given the scope of this document, 369 canonization mechanisms only involve header fields. 371 Implementations SHOULD use the relaxed algorithm to promote 372 interoperability with non-conforming SMTP products. 374 4.4. Header fields statuses 376 Header fields statuses are necessary to provide a 377 confidentiality service toward message headers. In this 378 specification, the confidentiality of header fields is 379 provided by the DCA. This point is described in chapter 4. The 380 DCA performs the message encryption process and message 381 decryption process and these processes are described in 382 details in the chapters 4.6.1 and 4.6.2. Although header 383 fields statuses are embedded in the signature, the signature 384 processes (generation and verification) ignore them. The 385 header field status defaults to duplicated. If the header 386 field is confidential, the header field status MUST be either 387 deleted or modified. 389 4.5. Signature Process 391 4.5.1. Signature Generation Process 393 During the signature generation process, the sender's MUA MUST 394 embed the SecureHeaderFields structure in the signed 395 attributes, as described in CMS. SecureHeaderFields structure 396 MUST include a canonization algorithm. 398 The sender's MUA MUST have a list of header fields to secure, 399 statuses and a canonization algorithm, as defined by the 400 security policy. 402 Header fields (names and values) embedded in signed attributes 403 MUST be the same as the ones included in the initial message. 405 If different headers share the same name, all instances MUST 406 be included in the SecureHeaderFields structure. 408 If multiple signatures are used, as explained in CMS and 409 MULTISIGN [RFC 4853] specifications, SecureHeaderFields 410 structure MUST be the same in each SignerInfos object. 412 If a header field is present and its value is empty, 413 HeaderFieldValue MUST have a zero-length field-value. 415 Considering secure headers mechanisms, the signature 416 generation process MUST perform the following steps: 418 1) Select the relevant header fields to secure. This subset 419 of headers is defined according the security policy. 421 2) Apply the canonization algorithm for each selected header 422 field. 424 3) Complete the following fields in SecureHeaderFields 425 structure according to the initial message: HeaderFieldName, 426 HeaderFieldValue, HeaderFieldStatus. 428 4) Complete the algorithm field according to the 429 canonization algorithm configured. 431 5) Embed the SecureHeaderFields structure in the signed 432 attributes of the SignerInfos object. 434 6) Compute the signature generation process as described in 435 CMS, chapter 5.5 437 4.5.2. Signature verification process 439 During the signature verification process, the receiver's MUA 440 compares header fields embedded in the SecureHeaderFields 441 structure with those present in the message. For this purpose, 442 it uses the canonization algorithm identified in the signed 443 attributes. If a mismatch appears during the comparison 444 process, the receiver's MUA MUST invalidate the signature. The 445 MUA MUST display information on the validity of each header 446 field. It MUST also display the values embedded in the 447 signature. 449 The receiver's MUA MUST know the list of mandatory header 450 fields in order to verify their presence in the message. If a 451 header field defined in a message is in the secure header 452 list, it MUST be included in the SecureHeaderFields structure. 453 Otherwise, the receiver's MUA MUST warn the user that a non- 454 secure header is present. 456 Considering secure headers mechanisms, the signature 457 verification process MUST perform the following steps: 459 1) Execute the signature verification process as described 460 in CMS, chapter 5.6. If the signature appears to be invalid, 461 the process ends. Otherwise, the process continues. 463 2) Read the type of canonization algorithm specified in 464 SecureHeaderFields structure. 466 3) For each field present in the signature, find the 467 matching header in the message. If there is no matching 468 header, the verification process MUST warn the user, 469 specifying the missing header name. The signature is tagged 470 as invalid. Note that any headers fields encrypted as per 471 section 4.6 (i.e., status of "deleted" or "modified") have 472 been are already restored by the DCA when the signature 473 verification process is performed by the MUA. 475 4) Compute the canonization algorithm for each header field 476 value in the message. If the simple algorithm is used, the 477 steps described in DKIM, chapter 3.4.1, are performed. If 478 the relaxed algorithm is used, the steps described in DKIM, 479 chapter 3.4.2, are performed. 481 5) For each field, compare the value stored in the 482 SecureHeaderFields structure with the value returned by the 483 canonization algorithm. If values don't match, the 484 verification process MUST warn the user. This warning MUST 485 mention mismatching fields. The signature is tagged as 486 invalid. If all the comparisons succeed, the verification 487 process MUST also notify the user (i.e., using an 488 appropriate icon). 490 6) Verify that no secure header has been added to the 491 message header, given the initial fields. If an extra header 492 field has been added, the verification process MUST warn the 493 user. This warning MUST mention extra fields. The signature 494 is tagged as invalid. This step is only performed if the 495 sender and the recipient share the same security policy. 497 7) Verify that every mandatory headers in the security 498 policy and present in the message are also embedded in the 499 SecureHeaderFields structure. If such headers are missing, 500 the verification process MUST warn the user and indicate the 501 names of the missing headers. 503 The MUA MUST display features for each secure header field 504 (name, value and status) and canonization algorithm used. 506 4.6. Encryption and Decryption Processes 508 Encryption and decryption operations are not performed by 509 MUAs. This is mainly justified by limitations of existing 510 email delivery protocols, for example IMAP. The solution 511 developed here relies on concepts explained in Domain Security 512 specification, chapter 4. A fundamental component of the 513 architecture is the Domain Confidentiality Authority (DCA). 514 Its purpose is to encrypt and decrypt messages instead of 515 (respectively) senders and receivers. 517 4.6.1. Encryption Process 519 All the computations presented in this chapter MUST be 520 performed only if the following conditions are verified: 522 - The content to be encrypted MUST consist of a signed 523 message (application/pkcs7-mime with SignedData or 524 multipart/signed) as shown in S/MIME specification, chapter 525 3.4. 527 - A SecureHeaderFields structure MUST be included in the 528 signedAttrs field of the SignerInfo object of the signature. 530 All the mechanisms described below MUST start at the beginning 531 of the encryption process, as explained in CMS. They are 532 performed by the sender's DCA. The following steps MUST be 533 performed for each field included in the SecureHeaderFields 534 structure: 536 1. Extraction of the field status; 538 1.1 If the status is Duplicated, the field is left at its 539 existing value. 541 1.2 If the status is Deleted, the header field (name and 542 value) is removed from the message. Mandatory header fields 543 specified in [RFC 5322] MUST be kept. 545 1.3 If the status is Modified, the header value is replaced 546 by a new value, as configured in the DCA. 548 4.6.2. Decryption Process 550 All the computations presented in this chapter MUST be 551 performed only if the following conditions are verified: 553 - The decrypted content MUST consist of a signature object 554 or a multipart object, where one part is a detached 555 signature, as shown in S/MIME specification, chapter 3.4. 557 - A SecureHeaderFields structure MUST be included in the 558 SignerInfo object of the signature. 560 All the mechanisms described below MUST start at the end of 561 the decryption process, as explained in CMS. They are executed 562 by the receiver's DCA. The following steps MUST be performed 563 for each field included in the SecureHeaderFields structure: 565 1. If the status is Duplicated, the field is left at its 566 existing value. 568 2. If the status is Deleted, the DCA MUST write a header 569 field (name and value) in the message. This header MUST be 570 compliant with the information embedded in the signature. 572 3. If the status is Modified, the DCA MUST rewrite a header 573 field in the message. This header MUST be compliant with the 574 SecureHeaderFields structure. 576 5. Case of triple wrapping 578 Secure Headers mechanisms MAY be used with triple wrapping, as 579 described in ESS [RFC 2634]. In this case, a 580 SecureHeaderFields structure MAY be present in the inner 581 signature, in the outer signature, or both. In the last case, 582 the two structure SecureHeaderFields MAY differ. One MAY 583 consider the encapsulation of a header field in the inner 584 signature in order to satisfy confidentiality needs. On the 585 contrary, an outer signature encapsulation MAY help for 586 delivery purpose. Sender's MUA and receiver's MUA must have a 587 security policy for triple wrapping. This security policy 588 MUST be composed of two parts. One part dedicated for the 589 inner signature and one part dedicated for the outer 590 signature. 592 6. Security Gateways 594 Some security gateways sign or verify messages that pass 595 through them. Compliant gateways MUST apply the process 596 described in chapter 4.5. 598 For non-compliant gateways, the presence of SecureHeaderFields 599 structure do not change their behavior. 601 In some case, gateways MUST generate new signature or insert 602 signerInfos into the signedData block. The format of 603 signatures generated by gateways is outside the scope of this 604 document. 606 7. Security Considerations 608 This specification describes an extension of the S/MIME 609 standard. It provides message headers integrity, non- 610 repudiation and confidentiality. The signature and encryption 611 processes are complementary. However, according to the 612 security policy, only the signature mechanism is applicable. 613 In this case, the signature process is implemented between 614 MUAs. The encryption process requires signed messages with 615 Secure Headers extension. If required, the encryption process 616 is implemented by DCAs. 618 This specification doesn't address end-to-end confidentiality 619 for message header fields. Messages sent and received by MUAs 620 could be transmitted as plaintext. In order to avoid 621 interception, the use of TLS is recommended between MUAs and 622 DCAs (uplink and downlink). Another solution might be the use 623 of S/MIME between MUAs and DCAs in the same domain. 625 For the header field confidentiality mechanism to be effective 626 all DCAs supporting confidentiality must support SH 627 processing. Otherwise, there is a risk in the case where 628 headers are not obscured upon encryption, or not restored upon 629 decryption process. In the former case confidentiality of the 630 header fields is compromised. In the latter case the integrity 631 of the headers will appear to be compromised. 633 8. IANA Considerations 635 IANA must register a suitable Object Identifier (OID) value 636 for the identifier id-aa-secureHeaderFieldsIdentifier. This 637 value will be used to identify an authenticated attribute 638 carried within a CMS [RFC 5652] wrapper. This attribute OID 639 appears in Section 4.1, and again in the reference definition 640 in Appendix A. An appropriate registry arc is suggested in 641 those instances of the draft text. 643 9. References 645 9.1. Normative References 647 [RFC 2045] Borenstein, N., "Multipurpose Internet Mail 648 Extensions Part One", RFC 2045, November 1996. 650 [RFC 2119] Bradner, S., "Key words for use in RFCs to 651 indicate requirement levels", RFC 2119, March 652 1997. 654 [RFC 2634] Hoffman, P., "Enhanced Security Services for 655 S/MIME", RFC 2634, June 1999. 657 [RFC 4853] Housley, R., "Cryptographic Message Syntax (CMS), 658 Multiple Signer Clarification", RFC 4853, April 659 2007. 661 [RFC 5322] Resnick, P., "Internet Message Format", RFC 5322, 662 October 2008. 664 [RFC 5652] Housley, R., "Cryptographic Message Syntax (CMS)", 665 RFC 5652, September 2009. 667 [RFC 6376] Crocker, D., Hansen, T., Kucherawy, M., DomainKeys 668 Identified Mail (DKIM) Signatures", RFC 6376, 669 September 2011. 671 [ASN1-88] CCITT. Recommendation X.208: Specification of 672 Abstract Syntax Notation One (ASN.1), 1988. 674 9.2. Informative References 676 [RFC 2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 677 RFC 2595, June 1999. 679 [RFC 3183] Dean, T., Ottaway, W., "Domain security services 680 using S/MIME", RFC 3183, October 2001. 682 [RFC 3207] Hoffman, P., "SMTP Service Extension for secure 683 SMTP over Transport Layer Security", RFC 3207, 684 February 2002. 686 [RFC 3501] Crispin, M., "Internet Message Access Protocol, 687 version 4rev1", RFC 3501, March 2003. 689 [RFC 5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 690 5321, October 2008. 692 [RFC 5598] Crocker, D., "Internet Mail Architecture", RFC 693 5598, July 2009. 695 [RFC 5750] Ramsdell, B., Turner, S., "Secure/Multipurpose 696 Internet Mail Extensions (S/MIME) Version 3.2 697 Certificate Handling", RFC 5750, January 2010. 699 [RFC 5751] Ramsdell, B., Turner, S., "Secure/Multipurpose 700 Internet Mail Extensions (S/MIME) Version 3.2, 701 Message Specification", RFC 5751, January 2010. 703 Appendix A. Formal syntax of Secure Header 705 Note: The ASN.1 module contained herein uses the 1988 version 706 of ASN.1 notation [ASN1-88] for the purposes of alignment with 707 th existing S/MIME specifications. The secure header structure 708 is defined as follows: 710 SMimeSecureHeadersV1 711 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 712 pkcs-9(9) smime(16) modules(0) secure-headers-v1(to be 713 defined) } 715 DEFINITIONS IMPLICIT TAGS ::= 717 BEGIN 719 IMPORTS 721 id-aa 722 FROM SecureMimeMessageV3dot1 723 { iso(1) member-body(2) us(840) rsadsi(113549) 724 pkcs(1) pkcs-9(9) smime(16) modules(0) 725 msg-v3dot1(21) }; 727 -- id-aa is the arc with all new authenticated and 728 -- unauthenticated attributes produced by the S/MIME 729 -- Working Group 731 id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= { 732 id-aa secure-headers (to be defined) } 734 SecureHeaderFields ::= SET { 735 canonAlgorithm Algorithm, 736 secHeaderFields HeaderFields } 738 Algorithm ::= ENUMERATED { 739 canonAlgorithmSimple(0), 740 canonAlgorithmRelaxed(1) } 742 HeaderFields ::= SEQUENCE SIZE (1..MAX) OF HeaderField 744 HeaderField ::= SEQUENCE { 745 field-Name HeaderFieldName, 746 field-Value HeaderFieldValue, 747 field-Status HeaderFieldStatus DEFAULT duplicated } 749 HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":"))) 750 -- This description matches with the description of 751 -- field name in the chapters 2.2 and 3.6.8 of RFC 5322 753 HeaderFieldValue ::= UTF8String 754 -- This description matches with the description of 755 -- field body in the chapter 2.2 of RFC 5322 as 756 -- extended by chapter 3.1 of RFC 6532. 758 HeaderFieldStatus ::= INTEGER { 759 duplicated(0), deleted(1), modified(2) } 761 END 763 Appendix B. Secure Header Fields example 765 In the following example, header fields subject, x-ximf- 766 primary-precedence and x-ximf-correspondance-type are secured 767 and integrated in a SecureHeaders structure. This example 768 should produce a valid signature. 770 Extract of message header fields 772 From: John Doe 773 To: Mary Smith 774 subject: This is a test of Ext. 775 x-ximf-primary-precedence: priority 776 x-ximf-correspondance-type: official 778 SecureHeaders structure extracted from signature: 780 2286 150: SEQUENCE { 781 2289 11: OBJECT IDENTIFIER '1 2 840 113549 1 9 16 2 80' 782 2302 134: SET { 783 2305 131: SET { 784 2308 4: ENUMERATED 1 785 2314 123: SEQUENCE { 786 2316 40: SEQUENCE { 787 2318 25: VisibleString 'x-ximf-primary-precedence' 788 2345 8: UTF8String 'priority' 789 2355 1: INTEGER 0 790 : } 791 2358 41: SEQUENCE { 792 2360 26: VisibleString 'x-ximf-correspondance-type' 793 2388 8: UTF8String 'official' 794 2398 1: INTEGER 0 795 : } 796 2401 36: SEQUENCE { 797 2403 7: VisibleString 'subject' 798 2412 22: UTF8String 'This is a test of Ext.' 799 2436 1: INTEGER 0 800 : } 801 : } 802 : } 803 : } 804 : } 806 Example is displayed as an output of Peter Gutmann's 807 "dumpasn1" program. 809 OID used in this example is non-official. 811 Appendix C. Acknowledgements 813 The authors would like to thank Jim Schaad, Alexey Melnikov, 814 Damien Roque, Thibault Cassan, William Ottaway, and Sean 815 Turner who kindly provided reviews of the document and/or 816 suggestions for improvement. As always, all errors and 817 omissions are the responsibility of the authors. 819 Authors' Addresses 821 Laurent CAILLEUX 822 DGA MI 823 BP 7 824 35998 RENNES CEDEX 9 825 France 826 Email: laurent.cailleux@intradef.gouv.fr 828 Chris Bonatti 829 IECA, Inc. 830 3057 Nutley Street, Suite 106 831 Fairfax, VA 22031 832 USA 833 Email: bonatti252@ieca.com