idnits 2.17.1 draft-ietf-smime-escertid-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 704. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 715. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 722. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 728. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 14) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages 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 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC2634, but the abstract doesn't seem to directly say this. It does mention RFC2634 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 184 has weird spacing: '... certs conta...' == Line 208 has weird spacing: '...olicies conta...' == Line 283 has weird spacing: '...gorithm conta...' == Line 286 has weird spacing: '...ertHash is co...' == Line 289 has weird spacing: '...rSerial holds...' == (4 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2634, updated by this document, for RFC5378 checks: 1997-11-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 24, 2007) is 6202 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3852' is mentioned on line 447, but not defined ** Obsolete undefined reference: RFC 3852 (Obsoleted by RFC 5652) == Missing Reference: 'RFC 3280' is mentioned on line 461, but not defined ** Obsolete undefined reference: RFC 3280 (Obsoleted by RFC 5280) == Missing Reference: 'UNIVERSAL 12' is mentioned on line 476, but not defined == Missing Reference: 'UTF8' is mentioned on line 478, but not defined -- Looks like a reference, but probably isn't: '0' on line 632 -- Looks like a reference, but probably isn't: '1' on line 633 -- Looks like a reference, but probably isn't: '2' on line 634 == Unused Reference: 'RFC3852' is defined on line 434, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) Summary: 7 errors (**), 0 flaws (~~), 16 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Updates: 2634 (if approved) April 24, 2007 5 Intended status: Standards Track 6 Expires: October 26, 2007 8 ESS Update: Adding CertID Algorithm Agility 9 draft-ietf-smime-escertid-06.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 26, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 In the original Enhanced Security Services for S/MIME document (RFC 43 2634), a structure for cryptographically linking the certificate to 44 be used in validation with the signature was introduced, this 45 structure was hardwired to use SHA-1. This document allows for the 46 structure to have algorithm agility and defines a new attribute for 47 this purpose. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Updates to RFC 2634 . . . . . . . . . . . . . . . . . . . 3 54 2. Replace Section 5.4 'Signing Certificate Attribute 55 Definitions' . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Insert new section 5.4.1 'Signing Certificate Attribute 57 Definition Version 2' . . . . . . . . . . . . . . . . . . . . 5 58 4. Insert new section 5.4.1.1 'Certificate Identification 59 Version 2' . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Insert new section 5.4.2 ' Signing Certificate Attribute 61 Defintion Version 1 . . . . . . . . . . . . . . . . . . . . . 9 62 6. Insert new section 5.4.2.1 Certificate Identification 63 Version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 66 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 14 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 68 Intellectual Property and Copyright Statements . . . . . . . . . . 20 70 1. Introduction 72 In the original Enhanced Security Services (ESS) for S/MIME 73 document[ESS], a structure for cryptographically linking the 74 certificate to be used in validation with the signature was defined. 75 This structure, called ESSCertID, identifies a certificate by its 76 hash. The structure is hardwired to use a SHA-1 hash value. The 77 recent attacks on SHA-1 require that we define a new attribute which 78 allows for the use of different algorithms. This document performs 79 that task. 81 This document defines the structure ESSCertIDv2 along with a new 82 attribute SigningCertificateV2 which uses the updated structure. 83 This document allows for the structure to have algorithm agility by 84 including an algorithm identifier and defines a new signed attribute 85 to use the new structure.. 87 This document specifies the continued use of ESSCertID to ensure 88 compatiblity when SHA-1 is used to for certificate disamiguation. 90 1.1. Notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in[RFC2119]. 96 1.2. Updates to RFC 2634 98 This document updates section 5.4 of RFC 2634. Once the updates are 99 applied, the revised section will have the following structure: 101 5.4 Signing Certificate Attribute Definitions 103 5.4.1 Signing Certificate Attribute Definition Version 2 105 5.4.1.1 Certificate Identification Version 2 107 5.4.2 Signing Certificate Attribute Definition Version 1 109 5.4.2.1 Certificate Identification Version 1 111 In addition, the ASN.1 module in Appendix A is replaced. 113 2. Replace Section 5.4 'Signing Certificate Attribute Definitions' 115 5.4 Signing Certificate Attribute Definitions 117 The signing certificate attribute is designed to prevent simple 118 substitution and re-issue attacks, and to allow for a restricted set 119 of certificates to be used in verifying a signature. 121 Two different attributes exist for this due to a flaw in the original 122 design. The only substantial difference between the two attributes 123 is that SigningCertificateV2 allows for hash algorithm agility, while 124 SigningCertificate forces the use of the SHA-1 hash algorithm. With 125 the recent advances in the ability to create hash collisions for 126 SHA-1 it is wise to move forward sooner rather than later. 128 When the SHA-1 hash function is used, the SigningCertificate 129 attribute MUST be used. The SigningCertificateV2 attribute MUST be 130 used if any algorithm other than SHA-1 is used and SHOULD NOT be used 131 for SHA-1. Applications SHOULD recognize both attributes as long as 132 they consider SHA-1 able to distinguish between two different 133 certificates. (I.e. the possibility of a collision is sufficiently 134 low.) If both attributes exist in a single message they are 135 independently evaluated. 137 Four cases exist which need to be taken into account when using this 138 attribute for correct processing: 140 1. Signature Validates and the hashes match: This is the success 141 case. 143 2. Signature Validates and the hashes do not match: In this case the 144 certificate contained the correct public key, but the certificate 145 containing the public key is not the one that the signer intended 146 to be used. In this case the application should attempt a search 147 for a different certificate with the same public key and for 148 which the hashes match. If no such certificate can be found, 149 this is a failure case. 151 3. Signature Fails Validation and the hashes match: In this case it 152 can be assumed that the signature has been modified in some 153 fashion. This is a failure case. 155 4. Signature Fails Validation and the Hashes do not match: In this 156 case it can be either that the signature has been modified, or 157 that the wrong certificate has been used. Applications should 158 attempt a search for a different certificate which matches the 159 hash value in the attribute and use the new certificate to retry 160 the signature validation. 162 3. Insert new section 5.4.1 'Signing Certificate Attribute Definition 163 Version 2' 165 5.4.1 Signing Certificate Attribute Definition Version 2 167 The signing certificate attribute is designed to prevent the simple 168 substitution and re-issue attacks, and to allow for a restricted set 169 of certificates to be used in verifying a signature. 171 SigningCertificateV2 is identified by the OID: 173 id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) 174 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 175 smime(16) id-aa(2) 47 } 177 The attribute has the ASN.1 definition: 179 SigningCertificateV2 ::= SEQUENCE { 180 certs SEQUENCE OF ESSCertIDv2, 181 policies SEQUENCE OF PolicyInformation OPTIONAL 182 } 184 certs contains the list of certificates that are to be used in 185 validating the message. The first certificate identified in the 186 sequence of certificate identifiers MUST be the certificate used 187 to verify the signature. The encoding of the ESSCertIDv2 for this 188 certificate SHOULD include the issuerSerial field. If other 189 constraints ensure that issuerAndSerialNumber will be present in 190 the SignerInfo, the issuerSerial field MAY be omitted. The 191 certificate identified is used during the signature verification 192 process. If the hash of the certificate does not match the 193 certificate used to verify the signature, the signature MUST be 194 considered invalid. 196 If more than one certificate is present, subsequent certificates 197 limit the set of certificates that are used during validation. 198 Certificates can be either attribute certificates (limiting 199 authorizations) or public key certificates (limiting path 200 validation). The issuerSerial field (in the ESSCertIDv2 201 structure) SHOULD be present for these certificates, unless the 202 client who is validating the signature is expected to have easy 203 access to all the certificates required for validation. If only 204 the signing certificate is present in the sequence, there are no 205 restrictions on the set of certificates used in validating the 206 signature. 208 policies contains a sequence of policy information terms that 209 identify those certificate policies that the signer asserts apply 210 to the certificate, and under which the certificate should be 211 relied upon. This value suggests a policy value to be used in the 212 relying party's certification path validation. The definition of 213 PolicyInformation can be found in[RFC3280]. 215 If present, the SigningCertificateV2 attribute MUST be a signed 216 attribute; it MUST NOT be an unsigned attribute. CMS defines 217 SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT 218 include multiple instances of the SigningCertificateV2 attribute. 219 CMS defines the ASN.1 syntax for the signed attributes to include 220 attrValues SET OF AttributeValue. A SigningCertificateV2 attribute 221 MUST include only a single instance of AttributeValue. There MUST 222 NOT be zero or multiple instances of AttributeValue present in the 223 attrValues SET OF AttributeValue. 225 4. Insert new section 5.4.1.1 'Certificate Identification Version 2' 227 Insert the following text as a new section. 229 5.4.1.1 Certificate Identification Version 2 231 The best way to identify certificates is an often-discussed issue. 232 The ESSCertIDv2 structure supplies two different fields that are used 233 for this purpose. 235 The hash of the entire certificate allows for a verifier to check 236 that the certificate used in the verification process was the same 237 certificate the signer intended. Hashes are convenient in that they 238 are frequently used by certificate stores as a method of indexing and 239 retrieving certificates as well. The use of the hash is required by 240 this structure since the detection of substituted certificates is 241 based on the fact they would map to different hash values. 243 The issuer/serial number pair is the method of identification of 244 certificates used in[RFC3280]. That document imposes a restriction 245 for certificates that the issuer distinguished name must be present. 246 The issuer/serial number pair would therefore normally be sufficient 247 to identify the correct signing certificate. (This assumes the same 248 issuer name is not re-used from the set of trust anchors.) The 249 issuer/serial number pair can be stored in the sid field of the 250 SignerInfo object. However the sid field is not covered by the 251 signature. In the cases where the issuer/serial number pair is not 252 used in the sid or the issuer/serial number pair needs to be signed, 253 it SHOULD be placed in the issuerSerial field of the ESSCertIDv2 254 structure. 256 Attribute certificates and additional public key certificates 257 containing information do not have an issuer/serial number pair 258 represented anywhere in a SignerInfo object. When an attribute 259 certificate or an additional public key certificate is not included 260 in the SignedData object, it becomes much more difficult to get the 261 correct set of certificates based only on a hash of the certificate. 262 For this reason, these certificates SHOULD be identified by the 263 IssuerSerial object. 265 This document defines a certificate identifier as: 267 ESSCertIDv2 ::= SEQUENCE { 268 hashAlgorithm AlgorithmIdentifier 269 DEFAULT {algorithm id-sha256 parameters NULL}, 270 certHash Hash, 271 issuerSerial IssuerSerial OPTIONAL 272 } 274 Hash ::= OCTET STRING 276 IssuerSerial ::= SEQUENCE { 277 issuer GeneralNames, 278 serialNumber CertificateSerialNumber 279 } 281 The fields of ESSCertIDv2 are defined as follows: 283 hashAlgorithm contains the identifier of the algorithm used in 284 computing certHash. 286 certHash is computed over the entire DER encoded certificate 287 including the signature. 289 issuerSerial holds the identification of the certificate. The 290 issuerSerial would normally be present unless the value can be 291 inferred from other information (e.g. the sid field of the 292 SignerInfo object). 294 The fields of IssuerSerial are defined as follows: 296 issuer contains the issuer name of the certificate. For non- 297 attribute certificates, the issuer MUST contain only the issuer 298 name from the certificate encoded in the directoryName choice of 299 GeneralNames. For attribute certificates, the issuer MUST contain 300 the issuer name field from the attribute certificate. 302 serialNumber holds the serial number that uniquely identifies the 303 certificate for the issuer. 305 5. Insert new section 5.4.2 ' Signing Certificate Attribute Defintion 306 Version 1 308 (Note: This section does not present new material. This section 309 contains the original contents of Section 5.4 in [ESS], which are 310 retained with minor changes in this specification to achive backwards 311 compatibility.) 313 Insert the following text as a new section. 315 5.4.2 Signing Certificate Attribute Definition Version 1 317 The signing certificate attribute is designed to prevent the simple 318 substitution and re-issue attacks, and to allow for a restricted set 319 of certificates to be used in verifying a signature. 321 The definition of SigningCertificate is 323 SigningCertificate ::= SEQUENCE { 324 certs SEQUENCE OF ESSCertID, 325 policies SEQUENCE OF PolicyInformation OPTIONAL 326 } 328 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 329 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 330 smime(16) id-aa(2) 12 } 332 The first certificate identified in the sequence of certificate 333 identifiers MUST be the certificate used to verify the signature. 334 The encoding of the ESSCertID for this certificate SHOULD include the 335 issuerSerial field. If other constraints ensure that 336 issuerAndSerialNumber will be present in the SignerInfo, the 337 issuerSerial field MAY be omitted. The certificate identified is 338 used during the signature verification process. If the hash of the 339 certificate does not match the certificate used to verify the 340 signature, the signature MUST be considered invalid. 342 If more than one certificate is present in the sequence of 343 ESSCertIDs, the certificates after the first one limit the set of 344 certificates that are used during validation. Certificates can be 345 either attribute certificates (limiting authorizations) or public key 346 certificates (limiting path validation). The issuerSerial field (in 347 the ESSCertID structure) SHOULD be present for these certificates, 348 unless the client who is validating the signature is expected to have 349 easy access to all the certificates required for validation. If only 350 the signing certificate is present in the sequence, there are no 351 restrictions on the set of certificates used in validating the 352 signature. 354 The sequence of policy information terms identifies those certificate 355 policies that the signer asserts apply to the certificate, and under 356 which the certificate should be relied upon. This value suggests a 357 policy value to be used in the relying party's certification path 358 validation. 360 If present, the SigningCertificate attribute MUST be a signed 361 attribute; it MUST NOT be an unsigned attribute. CMS defines 362 SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT 363 include multiple instances of the SigningCertificate attribute. CMS 364 defines the ASN.1 syntax for the signed attributes to include 365 attrValues SET OF AttributeValue. A SigningCertificate attribute 366 MUST include only a single instance of AttributeValue. There MUST 367 NOT be zero or multiple instances of AttributeValue present in the 368 attrValues SET OF AttributeValue. 370 6. Insert new section 5.4.2.1 Certificate Identification Version 1 372 (Note: This section does not present new material. This section 373 contains the original contents of Section 5.4 in [ESS], which are 374 retained with minor changes in this specification to achive backwards 375 compatibility.) 377 Delete old section 5.4.1 379 Insert the following as new text 381 5.4.2.1 Certificate Identification Version 1 383 Certificates are uniquely identified using the information in the 384 ESSCertID structure. Discussion can be found in section 5.4.1.1. 386 This document defines a certificate identifier as: 388 ESSCertID ::= SEQUENCE { 389 certHash Hash, 390 issuerSerial IssuerSerial OPTIONAL 391 } 393 The fields of ESSCertID are defined as follows: 395 certHash is computed over the entire DER encoded certificate 396 (including the signature). 398 issuerSerial holds the identification of the certificate. This 399 field would normally be present unless the value can be inferred 400 from other information (e.g. the sid field of the SignerInfo 401 object). 403 The fields of IssuerSerial are discussed in section 5.4.1.1 405 7. Security Considerations 407 This document is designed to address the security issue of a 408 substituted certificate used by the validator. If a different 409 certificate is used by the validator than the signer the validator 410 may not get the correct result. An example of this would be that the 411 original certificate was revoked and a new certificate with the same 412 public key was issued for a different individual. Since the issuer/ 413 serial number field is not protected the attacker could replace this 414 and point to the new certificate and validation would be successful. 416 The attributes defined in this document are to be placed in locations 417 that are protected by the signature. This attribute does not provide 418 any additional security if placed in an un-signed or un-authenticated 419 location. 421 8. Normative References 423 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 424 RFC 2634, June 1999. 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", RFC 2119, BCP 14, March 1997. 429 [RFC3280] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet 430 X.509 Public Key Infrastructure Certificate and 431 Certificate Revocation List (CRL) Profile", RFC 3280, 432 April 2002. 434 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 435 RFC 3852, July 2004. 437 Appendix A. ASN.1 Module 439 Replace the ASN.1 module in RFC 2634 with this one. 441 ExtendedSecurityServices-2006 442 { iso(1) member-body(2) us(840) rsadsi(113549) 443 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) } 444 DEFINITIONS IMPLICIT TAGS ::= 445 BEGIN 446 IMPORTS 447 -- Cryptographic Message Syntax (CMS) [RFC 3852] 448 ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier 449 FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) 450 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) 451 cms-2004(24)} 452 -- PKIX Certificate and CRL Profile, Section A.1 Explicity Tagged Module 453 -- 1988 Syntax [RFC 3280] 454 AlgorithmIdentifier, CertificateSerialNumber 455 FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) 456 internet(1) 457 security(5) mechanisms(5) pkix(7) id-mod(0) 458 pkix1-explicit(18) } 460 -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, 461 -- 1988 Syntax [RFC 3280] 462 PolicyInformation, CertificateSerialNumber, GeneralNames 463 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 464 internet(1) 465 security(5) mechanisms(5) pkix(7)id-mod(0) 466 id-pkix1-implicit(19)}; 468 -- Extended Security Services 469 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 470 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or 471 -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to 472 -- have at least one entry. MAX indicates the upper bound is unspecified. 473 -- Implementations are free to choose an upper bound that suits their 474 -- environment. 476 -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 478 -- The contents are formatted as described in [UTF8] 479 -- Section 2.7 481 ReceiptRequest ::= SEQUENCE { 482 signedContentIdentifier ContentIdentifier, 483 receiptsFrom ReceiptsFrom, 484 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames 485 } 487 ub-receiptsTo INTEGER ::= 16 489 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 490 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1} 492 ContentIdentifier ::= OCTET STRING 494 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2) 495 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7} 497 ReceiptsFrom ::= CHOICE { 498 allOrFirstTier [0] AllOrFirstTier, -- formerly "allOrNone [0]AllOrNone" 499 receiptList [1] SEQUENCE OF GeneralNames 500 } 502 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone 503 allReceipts (0), 504 firstTierRecipients (1) 505 } 507 -- Section 2.8 509 Receipt ::= SEQUENCE { 510 version ESSVersion, 511 contentType ContentType, 512 signedContentIdentifier ContentIdentifier, 513 originatorSignatureValue OCTET STRING 514 } 516 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 517 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} 519 ESSVersion ::= INTEGER { v1(1) } 521 -- Section 2.9 523 ContentHints ::= SEQUENCE { 524 contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL, 525 contentType ContentType 526 } 528 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 529 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} 531 -- Section 2.10 533 MsgSigDigest ::= OCTET STRING 535 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 536 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} 538 -- Section 2.11 540 ContentReference ::= SEQUENCE { 541 contentType ContentType, 542 signedContentIdentifier ContentIdentifier, 543 originatorSignatureValue OCTET STRING 544 } 546 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2) 547 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 } 549 -- Section 3.2 551 ESSSecurityLabel ::= SET { 552 security-policy-identifier SecurityPolicyIdentifier, 553 security-classification SecurityClassification OPTIONAL, 554 privacy-mark ESSPrivacyMark OPTIONAL, 555 security-categories SecurityCategories OPTIONAL 556 } 558 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) 559 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} 560 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER 562 SecurityClassification ::= INTEGER { 563 unmarked (0), 564 unclassified (1), 565 restricted (2), 566 confidential (3), 567 secret (4), 568 top-secret (5) 569 }(0..ub-integer-options) 571 ub-integer-options INTEGER ::= 256 573 ESSPrivacyMark ::= CHOICE { 574 pString PrintableString (SIZE (1..ub-privacy-mark-length)), 575 utf8String UTF8String (SIZE (1..MAX)) 576 } 578 ub-privacy-mark-length INTEGER ::= 128 580 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 581 SecurityCategory 583 ub-security-categories INTEGER ::= 64 585 SecurityCategory ::= SEQUENCE { 586 type [0] OBJECT IDENTIFIER, 587 value [1] ANY DEFINED BY type 588 } 590 --Note: The aforementioned SecurityCategory syntax produces identical 591 --hex encodings as the following SecurityCategory syntax that is 592 --documented in the X.411 specification: 593 -- 594 --SecurityCategory ::= SEQUENCE { 596 -- type [0] SECURITY-CATEGORY, 597 -- value [1] ANY DEFINED BY type } 598 -- 599 --SECURITY-CATEGORY MACRO ::= 600 --BEGIN 601 --TYPE NOTATION ::= type | empty 602 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 603 --END 605 -- Section 3.4 607 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel 609 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2) 610 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9} 612 -- Section 4.4 614 MLExpansionHistory ::= SEQUENCE 615 SIZE (1..ub-ml-expansion-history) OF MLData 617 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) 618 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3 } 620 ub-ml-expansion-history INTEGER ::= 64 MLData ::= SEQUENCE { 621 mailListIdentifier EntityIdentifier, 622 expansionTime GeneralizedTime, 623 mlReceiptPolicy MLReceiptPolicy OPTIONAL 624 } 626 EntityIdentifier ::= CHOICE { 627 issuerAndSerialNumber IssuerAndSerialNumber, 628 subjectKeyIdentifier SubjectKeyIdentifier 629 } 631 MLReceiptPolicy ::= CHOICE { 632 none [0] NULL, 633 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, 634 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames 635 } 637 -- Section 5.4 639 SigningCertificate ::= SEQUENCE { 640 certs SEQUENCE OF ESSCertID, 641 policies SEQUENCE OF PolicyInformation OPTIONAL 642 } 644 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 645 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 646 smime(16) id-aa(2) 12 } 648 SigningCertificateV2 ::= SEQUENCE { 649 certs SEQUENCE OF ESSCertIDv2, 650 policies SEQUENCE OF PolicyInformation OPTIONAL 651 } 653 id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) 654 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 655 smime(16) id-aa(2) 47 } 657 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 658 country(16) us(840) organization(1) gov(101) 659 csor(3) nistalgorithm(4) hashalgs(2) 1 } 661 ESSCertIDv2 ::= SEQUENCE { 662 hashAlgorithm AlgorithmIdentifier 663 DEFAULT {algorithm id-sha256 parameters NULL}, 664 certHash Hash, 665 issuerSerial IssuerSerial OPTIONAL 666 } 668 ESSCertID ::= SEQUENCE { 669 certHash Hash, 670 issuerSerial IssuerSerial OPTIONAL 671 } 673 Hash ::= OCTET STRING IssuerSerial ::= SEQUENCE { 674 issuer GeneralNames, 675 serialNumber CertificateSerialNumber 676 } 678 END 679 -- of ExtendedSecurityServices-2006 681 Author's Address 683 Jim Schaad 684 Soaring Hawk Consulting 685 PO Box 675 686 Gold Bar, WA 98251 688 Email: jimsch@exmsft.com 690 Full Copyright Statement 692 Copyright (C) The IETF Trust (2007). 694 This document is subject to the rights, licenses and restrictions 695 contained in BCP 78, and except as set forth therein, the authors 696 retain all their rights. 698 This document and the information contained herein are provided on an 699 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 700 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 701 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 702 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 703 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 704 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 706 Intellectual Property 708 The IETF takes no position regarding the validity or scope of any 709 Intellectual Property Rights or other rights that might be claimed to 710 pertain to the implementation or use of the technology described in 711 this document or the extent to which any license under such rights 712 might or might not be available; nor does it represent that it has 713 made any independent effort to identify any such rights. Information 714 on the procedures with respect to rights in RFC documents can be 715 found in BCP 78 and BCP 79. 717 Copies of IPR disclosures made to the IETF Secretariat and any 718 assurances of licenses to be made available, or the result of an 719 attempt made to obtain a general license or permission for the use of 720 such proprietary rights by implementers or users of this 721 specification can be obtained from the IETF on-line IPR repository at 722 http://www.ietf.org/ipr. 724 The IETF invites any interested party to bring to its attention any 725 copyrights, patents or patent applications, or other proprietary 726 rights that may cover technology that may be required to implement 727 this standard. Please address the information to the IETF at 728 ietf-ipr@ietf.org. 730 Acknowledgment 732 Funding for the RFC Editor function is provided by the IETF 733 Administrative Support Activity (IASA).