idnits 2.17.1 draft-cailleux-secure-headers-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 191 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (16 October 2011) is 4575 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 3850 (Obsoleted by RFC 5750) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 3 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: 16 April 2012 IECA 6 16 October 2011 8 Securing Header Fields with S/MIME 9 draft-cailleux-secure-headers-00 11 Abstract 13 This document describes how the S/MIME protocol can be extended in 14 order to secure message header fields. This technology provides 15 security services such as data integrity, non-repudiation and 16 confidentiality. This extension is referred to as 'Secure Headers'. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 16 April 2012. 35 Draft Version 0.26 (20110728) 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document MUST 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction...................................................2 55 2. Terminology and conventions used in this document..............3 56 3. Context........................................................3 57 4. Mechanisms to secure message header fields.....................5 58 4.1. ASN.1 syntax of secure header fields......................6 59 4.2. Secure header fields length and format....................7 60 4.3. Canonization algorithm....................................7 61 4.4. Header fields statuses....................................8 62 4.5. Signature Process.........................................8 63 4.5.1. Signature Generation Process.........................8 64 4.5.2. Signature verification process.......................9 65 4.6. Encryption and Decryption Processes......................11 66 4.6.1. Encryption Process..................................11 67 4.6.2. Decryption Process..................................12 68 5. Case of triple wrapping.......................................13 69 6. Security Considerations.......................................13 70 7. References....................................................13 71 7.1. Normative References.....................................13 72 7.2. Informative References...................................14 73 Appendix A. Formal syntax of Secure Header.......................15 74 Appendix B. Secure Header Fields example.........................16 75 Appendix C. Acknowledgements.....................................18 77 1. Introduction 79 S/MIME [RFC5751] standard defines a data encapsulation format for the 80 achievement of end to end security services such as integrity, 81 authentication, non-repudiation and confidentiality. By default, 82 S/MIME secures message body parts, at the exclusion of the message 83 header fields. 85 S/MIME provides an alternative solution to secure header fields. "The 86 sending client MAY wrap a full MIME [RFC2045] message in a 87 message/rfc822 wrapper in order to apply S/MIME security services to 88 header fields". However, the S/MIME solution doesn't allow selection 89 of a subset of message header fields to secure. In addition, 90 confidentiality service can not be implemented for message header 91 fields. The solution described herein overcomes those limitations. 93 Several security standards exist such as DKIM [RFC4871], STARTTLS 94 [RFC3207] and TLS with IMAP [RFC2595] but meet other needs (signing 95 domain, secure channels). An internet draft referred to as PROTECTED 96 HEADERS has been proposed, but doesn't address all the requirements. 97 These different solutions are explained in the next chapters. 99 The goal of this document is to define end to end secure header 100 fields mechanisms compliant with S/MIME standard. This technique is 101 based on signed attribute fields of a CMS [RFC5652] signature. 103 2. Terminology and conventions used in this document 105 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 106 and "MAY" in this document are to be interpreted as described in "Key 107 words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 109 MUA, MSA and MTA terms are defined in Email architecture document 110 [RFC5598]. 112 DCA term is defined in Domain Security specification [RFC3183]. 114 End-to-end Internet Mail exchanges are performed between message 115 originators and recipients. 117 Description of message header fields are described in [RFC5322]. A 118 header field is composed of a name and a value. 120 3. Context 122 Over the Internet, email usage has grown and today represents a 123 fundamental service. Meanwhile, continually increasing threat levels 124 are motivating the implementation of security services. 126 Historically, SMTP [RFC5321] and IMF [RFC5322] don't provide, by 127 default, security services. The S/MIME standard [RFC5751] was 128 published in order to encompass these needs. S/MIME defines a data 129 encapsulation format for the provision of end to end security 130 services such as integrity, authentication, non-repudiation and 131 confidentiality. By default, S/MIME secures message body parts, at 132 the exclusion of the message header fields. In order to protect 133 message header fields (for instance, the "Subject", "To", "From" or 134 customized fields), several solutions exist. 136 S/MIME defines an encapsulation mechanism, chapter 3.1: "The sending 137 client may wrap a full MIME message in a message/rfc822 wrapper in 138 order to apply S/MIME security services to these header fields. It is 139 up to the receiving client to decide how to present this inner header 140 along with the unprotected outer header". However, some use cases are 141 not addressed, especially in the case of message encryption. What 142 happens when header fields are encrypted? How does receiving client 143 display these header fields? How can a subset of header fields be 144 secured? S/MIME doesn't address these issues. 146 An alternative solution is described in [RFC3850]. "Receiving agents 147 MUST check that the address in the From or Sender header of a mail 148 message matches an Internet mail address, if present, in the signer's 149 certificate, if mail addresses are present in the certificate". 150 However, this solution only provides a matching mechanism between 151 email addresses, and provides no protection to other header fields. 153 Other security standards (introduced below) exist such as DKIM, 154 STARTTLS and TLS with IMAP but meet other needs (signing domain, 155 secure channels...). 157 STARTTLS and TLS with IMAP provide secure channels between components 158 of email system (MUA, MSA, MTA...) but end to end integrity cannot be 159 guaranteed. 161 DKIM defines a domain-level authentication framework for email to 162 permit verification of the source and contents of messages. It 163 provides mechanisms to secure message header fields and message body 164 but it doesn't guarantee non-repudiation and originator 165 authentication. In addition, it doesn't provide confidentiality 166 service. 168 An internet draft referred to as Protected Headers (PRHDRS) has been 169 proposed. Mechanisms described in this draft are the following. "A 170 digest value is computed over the canonicalized version of some 171 selected header fields. This technique resembles header protection in 172 DKIM. Then the digest value is included in a signed attribute field 173 of a CMS signature". This specification doesn't address all the 174 requirements. If protected header field has been altered, the 175 original value cannot be determined by the recipient. In addition, 176 encryption service cannot be applied on protected header fields. 178 This document proposes a technology for securing message header 179 fields. It's referred to as Secure Headers. It is based on S/MIME and 180 CMS standards. It provides security services such as data integrity, 181 confidentiality and non-repudiation of sender. Secure Headers is 182 backward compatible with other S/MIME clients. S/MIME clients who 183 have not implemented Secure Headers technology need merely ignore 184 specific signed attributes fields in a CMS signature (which is the 185 default behavior). 187 4. Mechanisms to secure message header fields 189 Secure Headers technology involves the description of a security 190 policy. This policy MUST describe a secure message profile and list 191 the header fields to secure. 193 Secure headers are based on signed attributes field as defined in 194 CMS. The details are as follows. The message header fields to be 195 secured are integrated in a structure (secure header structure) which 196 is encapsulated in signed attributes structure of SignerInfo object. 197 See Appendix A for an example. For each header field present in the 198 secure signature, a status can be set. Then, as described in chapter 199 5.4 of CMS, the message digest calculation process computes a message 200 digest on the content together with the signed attributes. Details of 201 the signature generation process are described in chapter 4.5.1 of 202 this document. 204 Verification of secure header fields is based on signature 205 verification process described in CMS. At the end of this process, a 206 comparison between secure header fields (in signature) and message 207 header fields is performed. If they match, the signature is valid. 208 Otherwise, the signature is invalid. Details of the signature 209 verification process are described in chapter 4.5.2 of this document. 211 Non-conforming S/MIME clients will ignore the signed attribute 212 contains a secure headers structure, and only perform the 213 verification process described in CMS. This guarantees backward 214 compatibility. 216 Secure headers provide security services such as data integrity, non- 217 repudiation and confidentiality. 219 For different reasons (e.g., usability, limits of IMAP [RFC3501]), 220 encryption and decryption processes are performed by a third party. 221 The third party that performs these processes is referred to in 222 Domain Security specification as a "Domain Confidentiality Authority" 223 (DCA). Details of the encryption and decryption processes are 224 described in chapters 4.6.1 and 4.6.2 of this document. 226 The architecture of Secure Headers is presented below. The MUA 227 performs the signature generation process (C) and signature 228 verification process (F). The DCA performs the message encryption 229 process (D) and message decryption process (E). The encryption and 230 decryption processes are optional. 232 A Domain B Domain 233 +------------------------+ +------------------------+ 235 +-----+ +-----+ +-----+ +-----+ 236 | MUA | ---------> | DCA | ------------> | DCA |----------> | MUA | 237 | C | SignedMsg | D | EncryptedMsg | E | SignedMsg | F | 238 +-----+ +-----+ +-----+ +-----+ 240 Figure 1: Architecture of Secure Headers 242 4.1. ASN.1 syntax of secure header fields 244 ASN.1 notation [X.680] of secure header structure is the follow: 246 SecureHeaderFields ::= SET { 247 canonAlgorithm Algorithm, 248 secHeaderFields HeaderFields} 250 id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= {iso(1) 251 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id- 252 aa(2) secure-headers (to be defined)} 254 Algorithm ::= ENUMERATED { 255 canonAlgorithmSimple(0), 256 canonAlgorithmRelaxed(1)} 258 HeaderFields ::= SET SIZE (1..max-header-fields) OF HeaderField 259 max-header-fields INTEGER ::= MAX 261 HeaderField ::= SEQUENCE { 262 field-Name HeaderFieldName, 263 field-Value HeaderFieldValue, 264 field-Status HeaderFieldStatus OPTIONAL 265 } 267 HeaderFieldName ::= IA5String 268 HeaderFieldValue ::= IA5String 270 HeaderFieldStatus ::= INTEGER 271 { 272 duplicated(0), deleted(1), modified(2) 273 } 275 4.2. Secure header fields length and format 277 This specification requires MUA security capabilities in order to 278 process well formed headers, as specified in IMF. Notice that it 279 includes long header fields and folded header fields. 281 4.3. Canonization algorithm 283 During a message transfer through a messaging system, some components 284 might modify headers (i.e., space adding or deletion, 285 lowercase/uppercase rewriting...). This might leads to header fields 286 comparison mismatch. This emphasizes the need of a conversion process 287 in order to transform data to their canonical form. This process is 288 named canonization process. 290 Two canonization algorithms are considered here, according to DKIM 291 specification, chapter 3.4. The simple algorithm doesn't allow any 292 modification whereas the relaxed algorithm accepts slight 293 modifications like spaces replacement or line reformatting. Given the 294 scope of this document, canonization mechanisms only involve header 295 fields. 297 4.4. Header fields statuses 299 Header fields statuses are required to provide a confidentiality 300 service toward message headers. Since this mechanism is OPTIONAL, the 301 status field is also OPTIONAL. The three following statuses MUST be 302 used: 304 - Duplicated (default). When this status is present or if no status 305 is specified, the signature process MUST embed the header field in 306 the signature. 308 - Deleted. When this status is present, the signature process MUST 309 embed the header field in the signature. Then, the encryption 310 process MUST delete this field from the message. This guarantees 311 header confidentiality during the message transfer. Mandatory 312 header fields, as specified in IMF MUST be kept in the message. 314 - Modified. When this status is present, the signature process MUST 315 embed the header field in the signature. Then, the encryption 316 process MUST modify the value of the header field in the message. 317 This guarantees header confidentiality during the message transfer. 318 Furthermore, modified values MAY inform a receiver's non-compliant 319 MUA that secure headers are being used. The new value for each 320 field is configured by the sender (i.e., this header is secured, 321 use a compliant client). Mandatory header fields, as specified in 322 IMF MUST be kept well formed after the modification process. For 323 example, Date field MUST be compliant with the IMF specification. 325 4.5. Signature Process 327 4.5.1. Signature Generation Process 329 During the signature generation process, the sender's MUA MUST embed 330 the SecureHeaderFields structure in the signed attributes, as 331 described in CMS. SecureHeaderFields structure MUST include a 332 canonization algorithm. 334 The sender's MUA MUST have a list of header fields to secure, 335 statuses and a canonization algorithm, as defined by the security 336 policy. 338 Header fields (names and values) embedded in signed attributes MUST 339 be the same as the ones included in the initial message. 341 If different headers share the same name, all instances MUST be 342 included in the SecureHeaderFields structure. 344 If multiple signatures are used, as explained in CMS and MULTISIGN 345 [RFC4853] specifications, SecureHeaderFields structure MUST be the 346 same in each SignerInfos object. 348 If a header field is present and its value is empty, HeaderFieldValue 349 MUST have a zero-length field-value. 351 Considering secure headers mechanisms, the signature generation 352 process MUST perform the following steps: 354 1) Select the relevant header fields to secure. This subset of 355 headers is defined according the security policy. 357 2) Apply the canonization algorithm for each selected header 358 field. 360 3) Complete the following fields in SecureHeaderFields structure 361 according to the initial message: HeaderFieldName, HeaderFieldValue, 362 HeaderFieldStatus (OPTIONAL). 364 4) Complete the algorithm field according to the canonization 365 algorithm configured. 367 5) Embed the SecureHeaderFields structure in the signed attributes 368 of the SignerInfos object. 370 6) Compute the signature generation process as described in CMS, 371 chapter 5.5 373 4.5.2. Signature verification process 375 During the signature verification process, the receiver's MUA 376 compares header fields embedded in the SecureHeaderFields structure 377 with those present in the message. For this purpose, it uses the 378 canonization algorithm identified in the signed attributes. If a 379 mismatch appears during the comparison process, the receiver's MUA 380 MUST invalidate the signature. The MUA MUST display information on 381 the validity of each header field. It MUST also display the values 382 embedded in the signature. 384 The receiver's MUA MUST know the list of mandatory header fields in 385 order to verify their presence in the message. If a header field 386 defined in a message is in the secure header list, it MUST be 387 included in the SecureHeaderFields structure. Otherwise, the 388 receiver's MUA MUST warn the user that a non-secure header is 389 present. 391 Considering secure headers mechanisms, the signature verification 392 process MUST perform the following steps: 394 1) Execute the signature verification process as described in CMS, 395 chapter 5.6. If the signature appears to be invalid, the process 396 ends. Otherwise, the process continues. 398 2) Read the type of canonization algorithm specified in 399 SecureHeaderFields structure. 401 3) For each field present in the signature, find the matching 402 header in the message. If there is no matching header, the 403 verification process MUST warn the user, specifying the missing 404 header name. The signature is tagged as invalid. 406 4) Compute the canonization algorithm for each header field value 407 in the message. If the simple algorithm is used, the steps described 408 in DKIM, chapter 3.4.1, are performed. If the relaxed algorithm is 409 used, the steps described in DKIM, chapter 3.4.2, are performed. 411 5) For each field, compare the value stored in the 412 SecureHeaderFields structure with the value returned by the 413 canonization algorithm. If values don't match, the verification 414 process MUST warn the user. This warning MUST mention mismatching 415 fields. The signature is tagged as invalid. If all the comparisons 416 succeed, the verification process MUST also notify the user (i.e., 417 using an appropriate icon). 419 6) Verify that no secure header has been added to the message 420 header, given the initial fields. If an extra header field has been 421 added, the verification process MUST warn the user. This warning MUST 422 mention extra fields. The signature is tagged as invalid. 424 7) Verify that every mandatory headers in the security policy and 425 present in the message are also embedded in the SecureHeaderField 426 structure. If such headers are missing, the verification process MUST 427 warn the user and indicate the names of the missing headers. 429 The MUA MUST display features for each secure header field (name, 430 value and status) and canonization algorithm used. 432 4.6. Encryption and Decryption Processes 434 Encryption and decryption operations are not performed by MUAs. This 435 is mainly justified by IMAP limitations. The solution developed here 436 relies on concepts explained in Domain Security specification, 437 chapter 4. A fundamental component of the architecture is the Domain 438 Confidentiality Authority (DCA). Its purpose is to encrypt and 439 decrypt messages instead of - respectively - senders and receivers. 441 4.6.1. Encryption Process 443 All the computations presented in this chapter MUST be performed only 444 if the following conditions are verified: 446 - The content to be encrypted MUST consist of a signature object 447 or a multipart object, where one part is a detached signature, as 448 shown in S/MIME specification, chapter 3.4. 450 - A SecureHeaderFields structure MUST be included in the 451 signedAttrs field of the SignerInfo object of the signature. 453 All the mechanisms described below MUST start at the beginning of the 454 encryption process, as explained in CMS. They are performed by the 455 sender's DCA. The following steps MUST be performed for each field 456 included in the SecureHeaderFields structure: 458 1. Extraction of the field status; 459 1.1 If the status is Duplicated, the field is left at its existing 460 value. 462 1.2 If the status is Deleted, the header field (name and value) is 463 removed from the message. Mandatory header fields specified in 464 [RFC5322] MUST be kept. 466 1.3 If the status is Modified, the header value is replaced by a 467 new value, as configured in the DCA. 469 4.6.2. Decryption Process 471 All the computations presented in this chapter MUST be performed only 472 if the following conditions are verified: 474 - The decrypted content MUST consist of a signature object or a 475 multipart object, where one part is a detached signature, as shown in 476 S/MIME specification, chapter 3.4. 478 - A SecureHeaderFileds structure MUST be included in the 479 SignerInfo object of the signature. 481 All the mechanisms described below MUST start at the end of the 482 decryption process, as explained in CMS. They are executed by the 483 receiver's DCA. The following steps MUST be performed for each field 484 included in the SecureHeaderFields structure: 486 1. If the status is Duplicated, the field is left at its existing 487 value. 489 2. If the status is Deleted, the DCA MUST write a header field 490 (name and value) in the message. This header MUST be compliant with 491 the information embedded in the signature. 493 3. If the status is Modified, the DCA MUST rewrite a header field 494 in the message. This header MUST be compliant with the 495 SecureHeaderFields structure. 497 5. Case of triple wrapping 499 Secure Headers mechanisms MAY be used with triple wrapping, as 500 described in ESS [RFC2634]. In this case, a SecureHeaderFields 501 structure MAY be present in the inner signature, in the outer 502 signature, or both. In the last case, the two structure 503 SecureHeaderFields MAY differ. One MAY consider the encapsulation of 504 a header field in the inner signature in order to satisfy 505 confidentiality needs. On the contrary, an outer signature 506 encapsulation MAY help for delivery purpose. Header fields 507 processing, given the signature type (inner or outer), is out of the 508 scope of this document. 510 6. Security Considerations 512 This specification describes an extension of the S/MIME standard. It 513 provides message headers integrity, non-repudiation and 514 confidentiality. The signature and encryption processes are 515 complementary. However, according to the security policy, only the 516 signature mechanism MAY be prescribed. In this case, the signature 517 process is implemented between MUAs. The encryption process requires 518 signed messages with Secure Headers extension. If required, the 519 encryption process is implemented by DCAs. 521 This specification doesn't address end-to-end confidentiality for 522 message header fields. Sent and received messages by MUAs MAY appear 523 in plaintext. In order to avoid interception, the use of TLS is 524 recommended between MUAs and DCAs (uplink and downlink). Another 525 solution might be the use of S/MIME between MUAs and DCAs in the same 526 domain. 528 7. References 530 7.1. Normative References 532 [RFC2045] Borenstein, N., "Multipurpose Internet Mail Extensions Part 533 One", RFC 2045, November 1996. 535 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 536 requirement levels", RFC 2119, March 1997. 538 [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 539 2634, June 1999. 541 [RFC4853] Housley, R., "Cryptographic Message Syntax (CMS), Multiple 542 Signer Clarification", RFC 4853, April 2007. 544 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J. 545 and Thomas, M., "DomainKeys Identified Mail (DKIM) 546 Signatures", RFC 4871, May 2007. 548 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, October 549 2008. 551 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 552 5652, September 2009. 554 [X.680] ITU-T. Recommendation X.680 : Abstract Syntax Notation One 555 (ASN.1): Specification of basic notation, November 2008. 557 7.2. Informative References 559 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 560 June 1999. 562 [RFC3183] Dean, T., Ottaway, W., "Domain security services using 563 S/MIME", RFC 3183, October 2001. 565 [RFC3207] Hoffman, P., "SMTP Service Extension for secure SMTP over 566 Transport Layer Security", RFC 3207, February 2002. 568 [RFC3501] Crispin, M., "Internet Message Access Protocol, version 569 4rev1", RFC 3501, March 2003. 571 [RFC3850] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 572 (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 573 2004. 575 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 576 October 2008. 578 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 579 2009. 581 [RFC5751] Ramsdell, B., Turner, S., "Secure/Multipurpose Internet 582 Mail Extensions (S/MIME) Version 3.2, Message 583 Specification", RFC 5751, January 2010. 585 Appendix A. Formal syntax of Secure Header 587 ASN.1 notation [X.680] of secure header structure is the follow: 589 SecureHeaderFields ::= SET { 590 canonAlgorithm Algorithm, 591 secHeaderFields HeaderFields} 593 id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= {iso(1) 594 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id- 595 aa(2) secure-headers (to be defined)} 597 Algorithm ::= ENUMERATED { 598 canonAlgorithmSimple(0), 599 canonAlgorithmRelaxed(1)} 601 HeaderFields ::= SET SIZE (1..max-header-fields) OF HeaderField 602 max-header-fields INTEGER ::= MAX 604 HeaderField ::= SEQUENCE { 605 field-Name HeaderFieldName, 606 field-Value HeaderFieldValue, 607 field-Status HeaderFieldStatus OPTIONAL 608 } 610 HeaderFieldName ::= IA5String 611 HeaderFieldValue ::= IA5String 613 HeaderFieldStatus ::= INTEGER 614 { 615 duplicated(0), deleted(1), modified(2) 616 } 618 Appendix B. Secure Header Fields example 620 In the following example, header fields subject, from, to and x-ximf- 621 primary-precedence are secured and integrated in a SecureHeaders 622 structure. 624 Extract of message header fields 626 From: John Doe 627 To: Mary Smith 628 Subject: This is a test 629 X-ximf-primary-precedence: priority 631 SecureHeaders structure extracted from signature: 633 2286 163: SEQUENCE { 634 2289 11: OBJECT IDENTIFIER '1 2 840 113549 1 9 16 2 80' 635 2302 147: SET { 636 2305 144: SET { 637 2308 4: ENUMERATED 1 638 2314 135: SET { 639 2317 40: SEQUENCE { 640 2319 25: IA5String 'x-ximf-primary-precedence' 641 2346 8: IA5String 'priority' 642 2356 1: INTEGER 0 643 : } 644 2359 25: SEQUENCE { 645 2361 2: IA5String 'to' 646 2365 16: IA5String 'mary@example.com' 647 2383 1: INTEGER 0 648 : } 649 2386 34: SEQUENCE { 650 2388 4: IA5String 'from' 651 2394 23: IA5String 'jdoe ' 652 2419 1: INTEGER 0 653 : } 654 2422 28: SEQUENCE { 655 2424 7: IA5String 'subject' 656 2433 14: IA5String 'This is a test' 657 2449 1: INTEGER 0 658 : } 659 : } 660 : } 661 : } 662 : } 664 Example is displayed as an output of Peter Gutmann's "dumpasn1" 665 program. 667 OID used in this example is non official. 669 Appendix C. Acknowledgements 671 The author would like to thank Damien Roque and Thibault Cassan 672 kindly provided reviews of the document and/or suggestions for 673 improvement. As always, all errors and omissions are the 674 responsibility of the authors. 676 Author's addresses 678 Laurent CAILLEUX 679 DGA Maitrise de l'information 680 BP 7 681 35998 Rennes Armees 682 France 683 Email: laurent.cailleux@dga.defense.gouv.fr 685 Chris Bonatti 686 IECA, Inc. 687 3057 Nutley Street, Suite 106 688 Fairfax, VA 22031 689 USA 690 Email: bonattic@ieca.com