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