idnits 2.17.1 draft-cailleux-secure-headers-06.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 (26 July 2014) is 3555 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC 3501' is defined on line 656, 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: 26 January 2015 IECA 6 26 July 2014 8 Securing Header Fields with S/MIME 9 draft-cailleux-secure-headers-06 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.................8 61 4.2. Secure header fields length and format...............9 62 4.3. Canonization algorithm..............................10 63 4.4. Header fields statuses..............................10 64 4.5. Signature Process...................................10 65 4.5.1. Signature Generation Process...................10 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..................................15 71 6. Security Gateways........................................16 72 7. Security Considerations..................................16 73 8. IANA Considerations......................................17 74 9. References...............................................17 75 9.1. Normative References................................17 76 9.2. Informative References..............................18 77 Appendix A. Formal syntax of Secure Header..................20 78 Appendix B. Secure Header Fields example....................21 79 Appendix C. Acknowledgements................................23 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 Secure Headers technology uses header fields statuses required 130 to provide a confidentiality service toward message headers. 131 The following three terms are used to describe the field 132 statuses: 134 - Duplicated (the default status). When this status is 135 present or if no status is specified, the signature process 136 embeds the header field value in the digital signature, but 137 the value is will also be present in the message header 138 fields. 140 - Deleted. When this status is present, the signature 141 process embeds the header field value in the digital 142 signature, and the encryption process deletes this field 143 from the message to preserve its confidentiality. 145 - Modified. When this status is present, the signature 146 process embeds the header field value in the digital 147 signature, and the encryption process modifies the value of 148 the header field in the message. This preserves 149 confidentiality and informs a receiver's non-compliant MUA 150 that secure headers are being used. New values for each 151 field might be configured by the sender (i.e., "This header 152 is secured, use a compliant client"). 154 3. Context 156 Over the Internet, email usage has grown and today represents 157 a fundamental service. Meanwhile, continually increasing 158 threat levels are motivating the implementation of security 159 services. 161 Historically, SMTP [RFC 5321] and IMF [RFC 5322] don't 162 provide, by default, security services. The S/MIME standard 163 [RFC 5751] was published in order to encompass these needs. 164 S/MIME defines a data encapsulation format for the provision 165 of end to end security services such as integrity, 166 authentication, non-repudiation and confidentiality. By 167 default, S/MIME secures message body parts, at the exclusion 168 of the message header fields. In order to protect message 169 header fields (for instance, the "Subject", "To", "From" or 170 customized fields), several solutions exist. 172 S/MIME defines an encapsulation mechanism, chapter 3.1: "The 173 sending client may wrap a full MIME message in a 174 message/rfc822 wrapper in order to apply S/MIME security 175 services to these header fields. It is up to the receiving 176 client to decide how to present this inner header along with 177 the unprotected outer header". However, some use cases are not 178 addressed, especially in the case of message encryption. What 179 happens when header fields are encrypted? How does the 180 receiving client display these header fields? How can a subset 181 of header fields be secured? S/MIME doesn't address these 182 issues. 184 An alternative solution is described in [RFC 5750]. "Receiving 185 agents MUST check that the address in the From or Sender 186 header of a mail message matches an Internet mail address, if 187 present, in the signer's certificate, if mail addresses are 188 present in the certificate". However, this solution only 189 provides a matching mechanism between email addresses, and 190 provides no protection to other header fields. 192 Other security standards (introduced below) exist such as 193 DKIM, STARTTLS and TLS with IMAP but meet other needs (signing 194 domain, secure channels...). 196 STARTTLS and TLS with IMAP provide secure channels between 197 components of email system (MUA, MSA, MTA...) but end to end 198 integrity cannot be guaranteed. 200 DKIM defines a domain-level authentication framework for email 201 to permit verification of the source and contents of messages. 202 It provides mechanisms to secure message header fields and 203 message body but it doesn't guarantee non-repudiation and 204 originator authentication. In addition, it doesn't provide 205 confidentiality. 207 An internet draft referred to as Protected Headers (PRHDRS) 208 has been proposed. Mechanisms described in this draft are the 209 following. "A digest value is computed over the canonicalized 210 version of some selected header fields. This technique 211 resembles header protection in DKIM. Then the digest value is 212 included in a signed attribute field of a CMS signature". This 213 specification doesn't address all conceivable requirements as 214 noted below. If the protected header field has been altered, 215 the original value cannot be determined by the recipient. In 216 addition, the encryption service cannot provide 217 confidentiality for fields that must remain present in the 218 message header during transport. 220 This document proposes a technology for securing message 221 header fields. It's referred to as Secure Headers. It is based 222 on S/MIME and CMS standards. It provides security services 223 such as data integrity, confidentiality and non-repudiation of 224 sender. Secure Headers is backward compatible with other 225 S/MIME clients. S/MIME clients who have not implemented Secure 226 Headers technology need merely ignore specific signed 227 attributes fields in a CMS signature (which is the default 228 behavior). 230 4. Mechanisms to secure message header fields 232 Secure Headers technology involves the description of a 233 security policy. This policy MUST describe a secure message 234 profile and list the header fields to secure. 236 Secure headers are based on the signed attributes field as 237 defined in CMS. The details are as follows. The message header 238 fields to be secured are integrated in a structure (secure 239 header structure) which is encapsulated in the signed 240 attributes structure of the SignerInfo object. See Appendix A 241 for an example. For each header field present in the secure 242 signature, a status can be set. Then, as described in chapter 243 5.4 of CMS, the message digest calculation process computes a 244 message digest on the content together with the signed 245 attributes. Details of the signature generation process are 246 described in chapter 4.5.1 of this document. 248 Verification of secure header fields is based on signature 249 verification process described in CMS. At the end of this 250 process, a comparison between the secure header fields and the 251 corresponding message header fields is performed. If they 252 match, the signature is valid. Otherwise, the signature is 253 invalid. Details of the signature verification process are 254 described in chapter 4.5.2 of this document. 256 Non-conforming S/MIME clients will ignore the signed attribute 257 containing the secure headers structure, and only perform the 258 verification process described in CMS. This guarantees 259 backward compatibility. 261 Secure headers provide security services such as data 262 integrity, non-repudiation and confidentiality. 264 For different reasons (e.g., usability, limits of IMAP [RFC 265 3501]), encryption and decryption processes are performed by a 266 third party. The third party that performs these processes is 267 referred to in Domain Security specification as a "Domain 268 Confidentiality Authority" (DCA). Details of the encryption 269 and decryption processes are described in chapters 4.6.1 and 270 4.6.2 of this document. 272 The architecture of Secure Headers is presented below. The MUA 273 performs the signature generation process (C) and signature 274 verification process (F). The DCA performs the message 275 encryption process (D) and message decryption process (E). The 276 encryption and decryption processes are optional. 278 A Domain B Domain 279 +----------------------+ +----------------------+ 281 +-----+ +-----+ +-----+ +-----+ 282 | MUA | -------> | DCA | ----------> | DCA |--------> | MUA | 283 | C | | D | | E | | F | 284 +-----+ +-----+ +-----+ +-----+ 285 SignedMsg EncryptedMsg SignedMsg 287 Figure 1: Architecture of Secure Headers 289 4.1. ASN.1 syntax of secure header fields 291 ASN.1 notation [X.680] of secure header structure is the 292 follow: 294 SecureHeaderFields ::= SET { 295 canonAlgorithm Algorithm, 296 secHeaderFields HeaderFields } 298 id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= 299 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 300 pkcs-9(9) smime(16) id-aa(2) secure-headers (to be 301 defined) } 303 Algorithm ::= ENUMERATED { 304 canonAlgorithmSimple(0), 305 canonAlgorithmRelaxed(1) } 307 HeaderFields ::= SET SIZE (1..max-header-fields) OF 308 HeaderField 310 max-header-fields INTEGER ::= MAX 312 HeaderField ::= SEQUENCE { 313 field-Name HeaderFieldName, 314 field-Value HeaderFieldValue, 315 field-Status HeaderFieldStatus DEFAULT duplicated } 317 HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":"))) 318 -- This description matches with the description of 319 -- field name in the chapters 2.2 and 3.6.8 of RFC 5322 321 HeaderFieldValue ::= IA5String (FROM (ALL EXCEPT ( 322 { 0, 0 }..{ 0, 9 } | { 0, 11 } | { 0, 12 } | 323 { 0, 14 }..{ 1, 15 } | { 7, 15 }))) 324 -- This description matches with the description of 325 -- field body in the chapter 2.2 of RFC 5322 327 HeaderFieldStatus ::= INTEGER { 328 duplicated(0), deleted(1), modified(2) } 330 4.2. Secure header fields length and format 332 This specification requires MUA security capabilities in order 333 to process well formed headers, as specified in IMF. Notice 334 that it includes long header fields and folded header fields. 336 4.3. Canonization algorithm 338 During a message transfer through a messaging system, some 339 components might modify headers (i.e., space adding or 340 deletion, lowercase/uppercase rewriting...). This might lead 341 to header fields comparison mismatch. This emphasizes the need 342 of a conversion process in order to transform data to their 343 canonical form. This process is named canonization process. 345 Two canonization algorithms are considered here, according to 346 DKIM specification [RFC 6376], chapter 3.4. The simple 347 algorithm doesn't allow any modification whereas the relaxed 348 algorithm accepts slight modifications like spaces replacement 349 or line reformatting. Given the scope of this document, 350 canonization mechanisms only involve header fields. 352 4.4. Header fields statuses 354 Header fields statuses are necessary to provide a 355 confidentiality service toward message headers. In this 356 specification, the confidentiality of header fields is 357 provided by the DCA. This point is described in chapter 4. The 358 DCA performs the message encryption process and message 359 decryption process and these processes are described in 360 details in the chapters 4.6.1 and 4.6.2. Although header 361 fields statuses are embedded in the signature, the signature 362 processes (generation and verification) ignore them. Since the 363 confidentiality service is OPTIONAL, the status field is also 364 OPTIONAL. 366 4.5. Signature Process 368 4.5.1. Signature Generation Process 370 During the signature generation process, the sender's MUA MUST 371 embed the SecureHeaderFields structure in the signed 372 attributes, as described in CMS. SecureHeaderFields structure 373 MUST include a canonization algorithm. 375 The sender's MUA MUST have a list of header fields to secure, 376 statuses and a canonization algorithm, as defined by the 377 security policy. 379 Header fields (names and values) embedded in signed attributes 380 MUST be the same as the ones included in the initial message. 382 If different headers share the same name, all instances MUST 383 be included in the SecureHeaderFields structure. 385 If multiple signatures are used, as explained in CMS and 386 MULTISIGN [RFC 4853] specifications, SecureHeaderFields 387 structure MUST be the same in each SignerInfos object. 389 If a header field is present and its value is empty, 390 HeaderFieldValue MUST have a zero-length field-value. 392 Considering secure headers mechanisms, the signature 393 generation process MUST perform the following steps: 395 1) Select the relevant header fields to secure. This subset 396 of headers is defined according the security policy. 398 2) Apply the canonization algorithm for each selected header 399 field. header field. 401 3) Complete the following fields in SecureHeaderFields 402 structure according to the initial message: HeaderFieldName, 403 HeaderFieldValue, HeaderFieldStatus (OPTIONAL). 405 4) Complete the algorithm field according to the 406 canonization algorithm configured. 408 5) Embed the SecureHeaderFields structure in the signed 409 attributes of the SignerInfos object. 411 6) Compute the signature generation process as described in 412 CMS, chapter 5.5 414 4.5.2. Signature verification process 416 During the signature verification process, the receiver's MUA 417 compares header fields embedded in the SecureHeaderFields 418 structure with those present in the message. For this purpose, 419 it uses the canonization algorithm identified in the signed 420 attributes. If a mismatch appears during the comparison 421 process, the receiver's MUA MUST invalidate the signature. The 422 MUA MUST display information on the validity of each header 423 field. It MUST also display the values embedded in the 424 signature. 426 The receiver's MUA MUST know the list of mandatory header 427 fields in order to verify their presence in the message. If a 428 header field defined in a message is in the secure header 429 list, it MUST be included in the SecureHeaderFields structure. 430 Otherwise, the receiver's MUA MUST warn the user that a non- 431 secure header is present. 433 Considering secure headers mechanisms, the signature 434 verification process MUST perform the following steps: 436 1) Execute the signature verification process as described 437 in CMS, chapter 5.6. If the signature appears to be invalid, 438 the process ends. Otherwise, the process continues. 440 2) Read the type of canonization algorithm specified in 441 SecureHeaderFields structure. 443 3) For each field present in the signature, find the 444 matching header in the message. If there is no matching 445 header, the verification process MUST warn the user, 446 specifying the missing header name. The signature is tagged 447 as invalid. 449 4) Compute the canonization algorithm for each header field 450 value in the message. If the simple algorithm is used, the 451 steps described in DKIM, chapter 3.4.1, are performed. If 452 the relaxed algorithm is used, the steps described in DKIM, 453 chapter 3.4.2, are performed. 455 5) For each field, compare the value stored in the 456 SecureHeaderFields structure with the value returned by the 457 canonization algorithm. If values don't match, the 458 verification process MUST warn the user. This warning MUST 459 mention mismatching fields. The signature is tagged as 460 invalid. If all the comparisons succeed, the verification 461 process MUST also notify the user (i.e., using an 462 appropriate icon). 464 6) Verify that no secure header has been added to the 465 message header, given the initial fields. If an extra header 466 field has been added, the verification process MUST warn the 467 user. This warning MUST mention extra fields. The signature 468 is tagged as invalid. 470 7) Verify that every mandatory headers in the security 471 policy and present in the message are also embedded in the 472 SecureHeaderFields structure. If such headers are missing, 473 the verification process MUST warn the user and indicate the 474 names of the missing headers. 476 The MUA MUST display features for each secure header field 477 (name, value and status) and canonization algorithm used. 479 4.6. Encryption and Decryption Processes 481 Encryption and decryption operations are not performed by 482 MUAs. This is mainly justified by IMAP limitations. The 483 solution developed here relies on concepts explained in Domain 484 Security specification, chapter 4. A fundamental component of 485 the architecture is the Domain Confidentiality Authority 486 (DCA). Its purpose is to encrypt and decrypt messages instead 487 of (respectively) senders and receivers. 489 4.6.1. Encryption Process 491 All the computations presented in this chapter MUST be 492 performed only if the following conditions are verified: 494 - The content to be encrypted MUST consist of a signature 495 object or a multipart object, where one part is a detached 496 signature, as shown in S/MIME specification, chapter 3.4. 498 - A SecureHeaderFields structure MUST be included in the 499 signedAttrs field of the SignerInfo object of the signature. 501 All the mechanisms described below MUST start at the beginning 502 of the encryption process, as explained in CMS. They are 503 performed by the sender's DCA. The following steps MUST be 504 performed for each field included in the SecureHeaderFields 505 structure: 507 1. Extraction of the field status; 509 1.1 If the status is Duplicated, the field is left at its 510 existing value. 512 1.2 If the status is Deleted, the header field (name and 513 value) is removed from the message. Mandatory header fields 514 specified in [RFC 5322] MUST be kept. 516 1.3 If the status is Modified, the header value is replaced 517 by a new value, as configured in the DCA. 519 4.6.2. Decryption Process 521 All the computations presented in this chapter MUST be 522 performed only if the following conditions are verified: 524 - The decrypted content MUST consist of a signature object 525 or a multipart object, where one part is a detached 526 signature, as shown in S/MIME specification, chapter 3.4. 528 - A SecureHeaderFields structure MUST be included in the 529 SignerInfo object of the signature. 531 All the mechanisms described below MUST start at the end of 532 the decryption process, as explained in CMS. They are executed 533 by the receiver's DCA. The following steps MUST be performed 534 for each field included in the SecureHeaderFields structure: 536 1. If the status is Duplicated, the field is left at its 537 existing value. 539 2. If the status is Deleted, the DCA MUST write a header 540 field (name and value) in the message. This header MUST be 541 compliant with the information embedded in the signature. 543 3. If the status is Modified, the DCA MUST rewrite a header 544 field in the message. This header MUST be compliant with the 545 SecureHeaderFields structure. 547 5. Case of triple wrapping 549 Secure Headers mechanisms MAY be used with triple wrapping, as 550 described in ESS [RFC 2634]. In this case, a 551 SecureHeaderFields structure MAY be present in the inner 552 signature, in the outer signature, or both. In the last case, 553 the two structure SecureHeaderFields MAY differ. One MAY 554 consider the encapsulation of a header field in the inner 555 signature in order to satisfy confidentiality needs. On the 556 contrary, an outer signature encapsulation MAY help for 557 delivery purpose. Header fields processing, given the 558 signature type (inner or outer), is out of the scope of this 559 document. 561 6. Security Gateways 563 Some security gateways sign or verify messages that pass 564 through them. Compliant gateways MUST apply the process 565 described in chapter 4.5. 567 For non-compliant gateways, the presence of SecureHeaderFields 568 structure do not change their behavior. 570 In some case, gateways MUST generate new signature or insert 571 signerInfos into the signedData block. The format of 572 signatures generated by gateways is outside the scope of this 573 document. 575 7. Security Considerations 577 This specification describes an extension of the S/MIME 578 standard. It provides message headers integrity, non- 579 repudiation and confidentiality. The signature and encryption 580 processes are complementary. However, according to the 581 security policy, only the signature mechanism MAY be 582 prescribed. In this case, the signature process is implemented 583 between MUAs. The encryption process requires signed messages 584 with Secure Headers extension. If required, the encryption 585 process is implemented by DCAs. 587 This specification doesn't address end-to-end confidentiality 588 for message header fields. Sent and received messages by MUAs 589 MAY appear in plaintext. In order to avoid interception, the 590 use of TLS is recommended between MUAs and DCAs (uplink and 591 downlink). Another solution might be the use of S/MIME between 592 MUAs and DCAs in the same domain. 594 For the header field confidentiality mechanism to be effective 595 all DCAs supporting confidentiality must support SH 596 processing. Otherwise, there is a risk in the case where 597 headers are not obscured upon encryption, or not restored upon 598 decryption process. In the former case confidentiality of the 599 header fields is compromised. In the latter case the integrity 600 of the headers will appear to be compromised. 602 8. IANA Considerations 604 IANA must register a suitable Object Identifier (OID) value 605 for the identifier id-aa-secureHeaderFieldsIdentifier. This 606 value will be used to identify an authenticated attribute 607 carried within a CMS [RFC 5652] wrapper. This attribute OID 608 appears in Section 4.1, and again in the reference definition 609 in Appendix A. An appropriate registry arc is suggested in 610 those instances of the draft text. 612 9. References 614 9.1. Normative References 616 [RFC 2045] Borenstein, N., "Multipurpose Internet Mail 617 Extensions Part One", RFC 2045, November 1996. 619 [RFC 2119] Bradner, S., "Key words for use in RFCs to 620 indicate requirement levels", RFC 2119, March 621 1997. 623 [RFC 2634] Hoffman, P., "Enhanced Security Services for 624 S/MIME", RFC 2634, June 1999. 626 [RFC 4853] Housley, R., "Cryptographic Message Syntax (CMS), 627 Multiple Signer Clarification", RFC 4853, April 628 2007. 630 [RFC 5322] Resnick, P., "Internet Message Format", RFC 5322, 631 October 2008. 633 [RFC 5652] Housley, R., "Cryptographic Message Syntax (CMS)", 634 RFC 5652, September 2009. 636 [RFC 6376] Crocker, D., Hansen, T., Kucherawy, M., DomainKeys 637 Identified Mail (DKIM) Signatures", RFC 6376, 638 September 2011. 640 [X.680] ITU-T. Recommendation X.680 : Abstract Syntax 641 Notation One (ASN.1): Specification of basic 642 notation, November 2008. 644 9.2. Informative References 646 [RFC 2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 647 RFC 2595, June 1999. 649 [RFC 3183] Dean, T., Ottaway, W., "Domain security services 650 using S/MIME", RFC 3183, October 2001. 652 [RFC 3207] Hoffman, P., "SMTP Service Extension for secure 653 SMTP over Transport Layer Security", RFC 3207, 654 February 2002. 656 [RFC 3501] Crispin, M., "Internet Message Access Protocol, 657 version 4rev1", RFC 3501, March 2003. 659 [RFC 5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 660 5321, October 2008. 662 [RFC 5598] Crocker, D., "Internet Mail Architecture", RFC 663 5598, July 2009. 665 [RFC 5750] Ramsdell, B., Turner, S., "Secure/Multipurpose 666 Internet Mail Extensions (S/MIME) Version 3.2 667 Certificate Handling", RFC 5750, January 2010. 669 [RFC 5751] Ramsdell, B., Turner, S., "Secure/Multipurpose 670 Internet Mail Extensions (S/MIME) Version 3.2, 671 Message Specification", RFC 5751, January 2010. 673 Appendix A. Formal syntax of Secure Header 675 ASN.1 notation [X.680] of secure header structure is the 676 follow: 678 SecureHeaderFields ::= SET { 679 canonAlgorithm Algorithm, 680 secHeaderFields HeaderFields } 682 id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= 683 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs- 684 9(9) smime(16) id-aa(2) secure-headers (to be defined) } 686 Algorithm ::= ENUMERATED { 687 canonAlgorithmSimple(0), 688 canonAlgorithmRelaxed(1) } 690 HeaderFields ::= SET SIZE (1..max-header-fields) OF 691 HeaderField 693 max-header-fields INTEGER ::= MAX 695 HeaderField ::= SEQUENCE { 696 field-Name HeaderFieldName, 697 field-Value HeaderFieldValue, 698 field-Status HeaderFieldStatus DEFAULT duplicated } 700 HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":"))) 701 -- This description matches with the description of 702 -- field name in the chapters 2.2 and 3.6.8 of RFC 5322 704 HeaderFieldValue ::= IA5String (FROM (ALL EXCEPT ( 705 { 0, 0 }..{ 0, 9 } | { 0, 11 } | { 0, 12 } | 706 { 0, 14 }..{ 1, 15 } | { 7, 15 }))) 707 -- This description matches with the description of 708 -- field body in the chapter 2.2 of RFC 5322 710 HeaderFieldStatus ::= INTEGER { 711 duplicated(0), deleted(1), modified(2) } 713 Appendix B. Secure Header Fields example 715 In the following example, header fields subject, from, to and 716 x-ximf-primary-precedence are secured and integrated in a 717 SecureHeaders structure. 719 Extract of message header fields 721 From: John Doe 722 To: Mary Smith 723 Subject: This is a test 724 X-ximf-primary-precedence: priority 726 SecureHeaders structure extracted from signature: 728 2286 163: SEQUENCE { 729 2289 11: OBJECT IDENTIFIER 730 '1 2 840 113549 1 9 16 2 80' 731 2302 147: SET { 732 2305 144: SET { 733 2308 4: ENUMERATED 1 734 2314 135: SET { 735 2317 40: SEQUENCE { 736 2319 25: IA5String 'x-ximf-primary- 737 precedence' 738 2346 8: IA5String 'priority' 739 2356 1: INTEGER 0 740 : } 741 2359 25: SEQUENCE { 742 2361 2: IA5String 'to' 743 2365 16: IA5String 'mary@example.com' 744 2383 1: INTEGER 0 745 : } 746 2386 34: SEQUENCE { 747 2388 4: IA5String 'from' 748 2394 23: IA5String 'jdoe 749 ' 750 2419 1: INTEGER 0 751 : } 752 2422 28: SEQUENCE { 753 2424 7: IA5String 'subject' 754 2433 14: IA5String 'This is a test' 755 2449 1: INTEGER 0 756 : } 757 : } 758 : } 759 : } 760 : } 762 Example is displayed as an output of Peter Gutmann's 763 "dumpasn1" program. 765 OID used in this example is non-official. 767 Appendix C. Acknowledgements 769 The authors would like to thank Alexey Melnikov, Damien Roque, 770 Thibault Cassan, William Ottaway, and Sean Turner who kindly 771 provided reviews of the document and/or suggestions for 772 improvement. As always, all errors and omissions are the 773 responsibility of the authors. 775 Authors' Addresses 777 Laurent CAILLEUX 778 DGA MI 779 BP 7 780 35998 RENNES CEDEX 9 781 France 782 Email: laurent.cailleux@intradef.gouv.fr 784 Chris Bonatti 785 IECA, Inc. 786 3057 Nutley Street, Suite 106 787 Fairfax, VA 22031 788 USA 789 Email: bonatti252@ieca.com