idnits 2.17.1 draft-ietf-smime-escertid-03.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 609. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 633. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 a Security Considerations section. ** 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 155 has weird spacing: '... certs conta...' == Line 178 has weird spacing: '...olicies conta...' == Line 252 has weird spacing: '...hashAlg conta...' == Line 255 has weird spacing: '...ertHash is co...' == Line 258 has weird spacing: '...rSerial holds...' == (2 more instances...) -- 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 (December 21, 2006) is 6328 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'UNIVERSAL 12' is mentioned on line 388, but not defined == Missing Reference: 'UTF8' is mentioned on line 389, but not defined -- Looks like a reference, but probably isn't: '0' on line 537 -- Looks like a reference, but probably isn't: '1' on line 538 -- Looks like a reference, but probably isn't: '2' on line 539 ** Obsolete normative reference: RFC 3280 (ref. 'PKIXCERT') (Obsoleted by RFC 5280) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 10 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 Intended status: Informational December 21, 2006 5 Expires: June 24, 2007 7 ESS Update: Adding CertID Algorithm Agility 8 draft-ietf-smime-escertid-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 24, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 In the original Enhanced Security Services for S/MIME draft, a 42 structure for cryptographically linking the certificate to be used in 43 validation with the signature was introduced, this structure was 44 hardwired to use SHA-1. This document allows for the structure to 45 have algorithm agility and defines new attributes to deal with the 46 updating. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Replace Section 5.4 'Signing Certificate Attribute 53 Definitions' . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Insert new section 5.4.1 'Signing Certificate Attribute 55 Definition Version 2' . . . . . . . . . . . . . . . . . . . . 5 56 4. Insert new section 5.4.1.1 'Certificate Identification 57 Version 2' . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Insert new section 5.4.2 ' Signing Certificate Attribute 59 Defintion Version 1 . . . . . . . . . . . . . . . . . . . . . 9 60 6. Renumber Section 5.4.1 Certificate Identification Version 1 . 11 61 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 62 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 13 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 64 Intellectual Property and Copyright Statements . . . . . . . . . . 19 66 1. Introduction 68 In the original Enhanced Security Services (ESS) for S/MIME draft 69 [ESS], a structure for cryptographically linking the certificate to 70 be used in validation with the signature was defined. This 71 structure, called ESSCertID was hardwired to use a SHA-1 hash value. 72 The recent attacks on SHA-1 require that we change define a new 73 attribute which allows for the use of a different algorithm. This 74 document performs that task. 76 This document defines the structure ESSCertIDv2 along with a new 77 attribute SigningCertificateV2 which uses the updated structure. 78 This document allows for the structure to have algorithm agility and 79 defines new attributes to deal with the updating. 81 1.1. Notation 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Replace Section 5.4 'Signing Certificate Attribute Definitions' 89 The signing certificate attribute is designed to prevent simple 90 substitution and re-issue attacks, and to allow for a restricted set 91 of authorization certificates to be used in verifying a signature. 93 Two different attributes exist for this due to a flaw in the original 94 design. The only substantial difference between the two attributes 95 is that SigningCertificateV2 allows for hash algorithm agility, while 96 SigningCertificate forces the use of the SHA-1 hash algorithm. With 97 the recent advances in the ability to create hash collisions for 98 SHA-1 it is deemed wise to move forward sooner rather than later. 100 When the SHA-1 hash function is used, the SigningCertificate 101 attribute MUST be used. The SigningCertificateV2 attribute MUST be 102 used if any algorithm other than SHA-1 is used and SHOULD NOT be used 103 for SHA-1. Applications SHOULD recognize both attributes as long as 104 they consider SHA-1 able to distinguish between two different 105 certificates. (I.e. the possibility of a collision is sufficently 106 low.) 108 Four cases exist which need to be taken into account when using this 109 attribute for correct processing: 111 1. Signature Validates and the hashes match: This is the success 112 case. 114 2. Signature Validates and the hashes do not match: In this case the 115 certificate contained the correct public key, the certificate 116 containing the public key is not the one that the signer intended 117 to be used. In this case the application should attempt a search 118 for a different certificate with the same public key and for 119 which the hashes match. If no such certificate can be found, 120 this is a failure case. 122 3. Signature Fails Validation and the hashes match: In this case it 123 can be assumed that the signature has been modified in some 124 fashion. This is a failure case. 126 4. Signature Fails Validation and the Hashes do not match: In this 127 case it can be either that the signature has been modified, or 128 that the wrong certificate has been used. Applications should 129 attempt a search for a different certificate which matches the 130 hash value in the attribute and use the new certificate to retry 131 the signature validation. 133 3. Insert new section 5.4.1 'Signing Certificate Attribute Definition 134 Version 2' 136 5.4.1 Signing Certificate Attribute Definition Version 2 138 The signing certificate attribute is designed to prevent the simple 139 substitution and re-issue attacks, and to allow for a restricted set 140 of authorization certificates to be used in verifying a signature. 142 SigningCertificateV2 is identified by the OID: 144 id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) 145 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 146 smime(16) id-aa(2) 47 } 148 The attribute has the ASN.1 definition: 150 SigningCertificateV2 ::= SEQUENCE { 151 certs SEQUENCE OF ESSCertIDv2, 152 policies SEQUENCE OF PolicyInformation OPTIONAL 153 } 155 certs contains the list of certificates that are to be used in 156 validating the message. The first certificate identified in the 157 sequence of certificate identifiers MUST be the certificate used 158 to verify the signature. The encoding of the ESSCertIDv2 for this 159 certificate SHOULD include the issuerSerial field. If other 160 constraints ensure that issuerAndSerialNumber will be present in 161 the SignerInfo, the issuerSerial field MAY be omitted. The 162 certificate identified is used during the signature verification 163 process. If the hash of the certificate does not match the 164 certificate used to verify the signature, the signature MUST be 165 considered invalid. 167 If more than one certificate is present, subsequent certificates 168 limit the set of authorization certificates that are used during 169 signature validation. Authorization certificates can be either 170 attribute certificates or normal certificates. The issuerSerial 171 field (in the ESSCertIDv2 structure) SHOULD be present for these 172 certificates, unless the client who is validating the signature is 173 expected to have easy access to all the certificates required for 174 validation. If only the signing certificate is present in the 175 sequence, there are no restrictions on the set of authorization 176 certificates used in validating the signature. 178 policies contains a sequence of policy information terms that 179 identify those certificate policies that the signer asserts apply 180 to the certificate, and under which the certificate should be 181 relied upon. This value suggests a policy value to be used in the 182 relying party's certification path validation. The definition of 183 PolicyInformation can be found in [PKIXCERT]. 185 If present, the SigningCertificateV2 attribute MUST be a signed 186 attribute; it MUST NOT be an unsigned attribute. CMS defines 187 SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT 188 include multiple instances of the SigningCertificate attribute. CMS 189 defines the ASN.1 syntax for the signed attributes to include 190 attrValues SET OF AttributeValue. A SigningCertificate attribute 191 MUST include only a single instance of AttributeValue. There MUST 192 NOT be zero or multiple instances of AttributeValue present in the 193 attrValues SET OF AttributeValue. 195 4. Insert new section 5.4.1.1 'Certificate Identification Version 2' 197 Insert the following text as a new section 199 5.4.1.1 Certificate Identification Version 2 201 The best way to identify certificates is an often-discussed issue. 202 The ESSCertIDV2 structure supplies two different fields that are used 203 for this purpose. 205 The hash of the entire certificate allows for a verifier to check 206 that the certificate used in the verification process was the same 207 certificate the signer intended. Hashes are convenient in that they 208 are frequently used by certificate stores as a method of indexing and 209 retrieving certificates as well. The use of the hash is required by 210 this structure since the detection of substituted certificates is 211 based on the fact they would map to different hash values. 213 The issuer/serial number pair is the method of identification of 214 certificates used in [PKIXCERT]. That document imposes a restriction 215 for certificates that the issuer distinguished name must be present. 216 The issuer/serial number pair would therefore normally be sufficient 217 to identify the correct signing certificate. (This assumes the same 218 issuer name is not re-used from the set of trust anchors.) The 219 issuer/serial number pair can be stored in the sid field of the 220 SignerInfo object. However the sid field is not covered by the 221 signature. In the cases where the issuer/serial number pair is not 222 used in the sid or the issuer/serial number pair needs to be signed, 223 it SHOULD be placed in the issuerSerial field of the ESSCertIDv2 224 structure. 226 Attribute certificates and additional public key certificates 227 containing authorization information do not have an issuer/serial 228 number pair represented anywhere in a SignerInfo object. When an 229 attribute certificate or an additional public key certificate is not 230 included in the SignedData object, it becomes much more difficult to 231 get the correct set of certificates based only on a hash of the 232 certificate. For this reason, these certificates SHOULD be 233 identified by the IssuerSerial object. 235 This document defines a certificate identifier as: 237 ESSCertIDv2 ::= SEQUENCE { 238 hashAlg AlgorithmIdentifier DEFAULT {id-sha256} 239 certHash Hash, 240 issuerSerial IssuerSerial OPTIONAL 241 } 243 Hash ::= OCTET STRING 245 IssuerSerial ::= SEQUENCE { 246 issuer GeneralNames, 247 serialNumber CertificateSerialNumber 248 } 250 The fields of ESSCertIDv2 are defined as follows: 252 hashAlg contains the identifier of the algorithm used in computing 253 certHash. 255 certHash is computed over the entire DER encoded certificate 256 including the signature. 258 issuerSerial holds the identification of the certificate. The 259 issuerSerial would normally be present unless the value can be 260 inferred from other information (e.g. the sid field of the 261 SignerInfo object). 263 The fields of IssuerSerial are defined as follows: 265 issuer contains the issuer name of the certificate. For non- 266 attribute certificates, the issuer MUST contain only the issuer 267 name from the certificate encoded in the directoryName choice of 268 GeneralNames. For attribute certificates, the issuer MUST contain 269 the issuer name field from the attribute certificate. 271 serialNumber holds the serial number that uniquely identifies the 272 certificate for the issuer CA. 274 5. Insert new section 5.4.2 ' Signing Certificate Attribute Defintion 275 Version 1 277 5.4.2 Signing Certificate Attribute Definition Version 1 279 The signing certificate attribute is designed to prevent the simple 280 substitution and re-issue attacks, and to allow for a restricted set 281 of authorization certificates to be used in verifying a signature. 283 The definition of SigningCertificate is 285 SigningCertificate ::= SEQUENCE { 286 certs SEQUENCE OF ESSCertID, 287 policies SEQUENCE OF PolicyInformation OPTIONAL 288 } 290 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 291 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 292 smime(16) id-aa(2) 12 } 294 The first certificate identified in the sequence of certificate 295 identifiers MUST be the certificate used to verify the signature. 296 The encoding of the ESSCertID for this certificate SHOULD include the 297 issuerSerial field. If other constraints ensure that 298 issuerAndSerialNumber will be present in the SignerInfo, the 299 issuerSerial field MAY be omitted. The certificate identified is 300 used during the signature verification process. If the hash of the 301 certificate does not match the certificate used to verify the 302 signature, the signature MUST be considered invalid. 304 If more than one certificate is present in the sequence of 305 ESSCertIDs, the certificates after the first one limit the set of 306 authorization certificates that are used during signature validation. 307 Authorization certificates can be either attribute certificates or 308 normal certificates. The issuerSerial field (in the ESSCertID 309 structure) SHOULD be present for these certificates, unless the 310 client who is validating the signature is expected to have easy 311 access to all the certificates required for validation. If only the 312 signing certificate is present in the sequence, there are no 313 restrictions on the set of authorization certificates used in 314 validating the signature. 316 The sequence of policy information terms identifies those certificate 317 policies that the signer asserts apply to the certificate, and under 318 which the certificate should be relied upon. This value suggests a 319 policy value to be used in the relying party's certification path 320 validation. 322 If present, the SigningCertificate attribute MUST be a signed 323 attribute; it MUST NOT be an unsigned attribute. CMS defines 324 SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT 325 include multiple instances of the SigningCertificate attribute. CMS 326 defines the ASN.1 syntax for the signed attributes to include 327 attrValues SET OF AttributeValue. A SigningCertificate attribute 328 MUST include only a single instance of AttributeValue. There MUST 329 NOT be zero or multiple instances of AttributeValue present in the 330 attrValues SET OF AttributeValue. 332 6. Renumber Section 5.4.1 Certificate Identification Version 1 334 Change the number on this section from 5.4.1 to 5.4.2.1 336 Change the title on this section to "Certificate Identification 337 Version 1". 339 7. Normative References 341 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 342 RFC 2634, June 1999. 344 [PKIXCERT] 345 Housley, R., Ford, W., Polk, W., and D. Solo, "Internet 346 X.509 Public Key Infrastructure Certificate and 347 Certificate Revocation List (CRL) Profile", RFC 3280, 348 April 2002. 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", RFC 2119, BCP 14, March 1997. 353 Appendix A. ASN.1 Module 355 Replace the ASN.1 module with this one. 357 ExtendedSecurityServices-2006 358 { iso(1) member-body(2) us(840) rsadsi(113549) 359 pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) } 361 DEFINITIONS IMPLICIT TAGS ::= 362 BEGIN 364 IMPORTS 366 -- Cryptographic Message Syntax (CMS) 367 ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier, 368 AlgorithmIdentifier 369 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) 370 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} 372 -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, 373 -- 1988 Syntax 374 PolicyInformation, CertificateSerialNumber, GeneralNames FROM 375 PKIX1Implicit88 {iso(1) 376 identified-organization(3) dod(6) internet(1) security(5) 377 mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit(19)}; 379 -- Extended Security Services 381 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 382 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or 383 -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to 384 -- have at least one entry. MAX indicates the upper bound is unspecified. 385 -- Implementations are free to choose an upper bound that suits their 386 -- environment. 388 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 389 -- The contents are formatted as described in [UTF8] 391 -- Section 2.7 393 ReceiptRequest ::= SEQUENCE { 394 signedContentIdentifier ContentIdentifier, 395 receiptsFrom ReceiptsFrom, 396 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames } 398 ub-receiptsTo INTEGER ::= 16 400 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 401 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1} 403 ContentIdentifier ::= OCTET STRING 405 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2) 406 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7} 408 ReceiptsFrom ::= CHOICE { 409 allOrFirstTier [0] AllOrFirstTier, 410 -- formerly "allOrNone [0]AllOrNone" 411 receiptList [1] SEQUENCE OF GeneralNames } 413 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone 414 allReceipts (0), 415 firstTierRecipients (1) } 417 -- Section 2.8 419 Receipt ::= SEQUENCE { 420 version ESSVersion, 421 contentType ContentType, 422 signedContentIdentifier ContentIdentifier, 423 originatorSignatureValue OCTET STRING } 425 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 426 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} 428 ESSVersion ::= INTEGER { v1(1) } 430 -- Section 2.9 432 ContentHints ::= SEQUENCE { 433 contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL, 434 contentType ContentType } 436 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 437 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} 439 -- Section 2.10 441 MsgSigDigest ::= OCTET STRING 443 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 444 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} 446 -- Section 2.11 448 ContentReference ::= SEQUENCE { 449 contentType ContentType, 450 signedContentIdentifier ContentIdentifier, 451 originatorSignatureValue OCTET STRING } 453 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2) 454 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 } 456 -- Section 3.2 458 ESSSecurityLabel ::= SET { 459 security-policy-identifier SecurityPolicyIdentifier, 460 security-classification SecurityClassification OPTIONAL, 461 privacy-mark ESSPrivacyMark OPTIONAL, 462 security-categories SecurityCategories OPTIONAL } 464 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) 465 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} 467 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER 469 SecurityClassification ::= INTEGER { 470 unmarked (0), 471 unclassified (1), 472 restricted (2), 473 confidential (3), 474 secret (4), 475 top-secret (5) } (0..ub-integer-options) 477 ub-integer-options INTEGER ::= 256 479 ESSPrivacyMark ::= CHOICE { 480 pString PrintableString (SIZE (1..ub-privacy-mark-length)), 481 utf8String UTF8String (SIZE (1..MAX)) 482 } 484 ub-privacy-mark-length INTEGER ::= 128 486 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 487 SecurityCategory 489 ub-security-categories INTEGER ::= 64 491 SecurityCategory ::= SEQUENCE { 492 type [0] OBJECT IDENTIFIER, 493 value [1] ANY DEFINED BY type -- defined by type 494 } 496 --Note: The aforementioned SecurityCategory syntax produces identical 497 --hex encodings as the following SecurityCategory syntax that is 498 --documented in the X.411 specification: 499 -- 500 --SecurityCategory ::= SEQUENCE { 501 -- type [0] SECURITY-CATEGORY, 502 -- value [1] ANY DEFINED BY type } 503 -- 504 --SECURITY-CATEGORY MACRO ::= 505 --BEGIN 506 --TYPE NOTATION ::= type | empty 507 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 508 --END 510 -- Section 3.4 512 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel 514 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2) 515 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9} 517 -- Section 4.4 519 MLExpansionHistory ::= SEQUENCE 520 SIZE (1..ub-ml-expansion-history) OF MLData 522 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) 523 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} 525 ub-ml-expansion-history INTEGER ::= 64 527 MLData ::= SEQUENCE { 528 mailListIdentifier EntityIdentifier, 529 expansionTime GeneralizedTime, 530 mlReceiptPolicy MLReceiptPolicy OPTIONAL } 532 EntityIdentifier ::= CHOICE { 533 issuerAndSerialNumber IssuerAndSerialNumber, 534 subjectKeyIdentifier SubjectKeyIdentifier } 536 MLReceiptPolicy ::= CHOICE { 537 none [0] NULL, 538 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, 539 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } 541 -- Section 5.4 543 SigningCertificate ::= SEQUENCE { 544 certs SEQUENCE OF ESSCertID, 545 policies SEQUENCE OF PolicyInformation OPTIONAL 546 } 548 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 549 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 550 smime(16) id-aa(2) 12 } 552 SigningCertificateV2 ::= SEQUENCE { 553 certs SEQUENCE OF ESSCertIDv2, 554 policies SEQUENCE OF PolicyInformation OPTIONAL 555 } 557 id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) 558 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 559 smime(16) id-aa(2) 47 } 561 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 562 country(16) us(840) organization(1) gov(101) 563 csor(3) nistalgorithm(4) hashalgs(2) 1 } 565 ESSCertIDv2 ::= SEQUENCE { 566 hashAlgorithm AlgorithmIdentifier DEFAULT {algorithm 567 id-sha256 parameters NULL} 568 certHash Hash, 569 issuerSerial IssuerSerial OPTIONAL 570 } 572 ESSCertID ::= SEQUENCE { 573 certHash Hash, 574 issuerSerial IssuerSerial OPTIONAL 575 } 577 Hash ::= OCTET STRING -- SHA1 hash of entire certificate 579 IssuerSerial ::= SEQUENCE { 580 issuer GeneralNames, 581 serialNumber CertificateSerialNumber 582 } 584 END -- of ExtendedSecurityServices-2006 585 Author's Address 587 Jim Schaad 588 Soaring Hawk Consulting 589 PO Box 675 590 Gold Bar, WA 98251 592 Phone: (425) 785-1031 593 Email: jimsch@exmsft.com 595 Full Copyright Statement 597 Copyright (C) The Internet Society (2006). 599 This document is subject to the rights, licenses and restrictions 600 contained in BCP 78, and except as set forth therein, the authors 601 retain all their rights. 603 This document and the information contained herein are provided on an 604 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 605 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 606 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 607 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 608 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 609 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 611 Intellectual Property 613 The IETF takes no position regarding the validity or scope of any 614 Intellectual Property Rights or other rights that might be claimed to 615 pertain to the implementation or use of the technology described in 616 this document or the extent to which any license under such rights 617 might or might not be available; nor does it represent that it has 618 made any independent effort to identify any such rights. Information 619 on the procedures with respect to rights in RFC documents can be 620 found in BCP 78 and BCP 79. 622 Copies of IPR disclosures made to the IETF Secretariat and any 623 assurances of licenses to be made available, or the result of an 624 attempt made to obtain a general license or permission for the use of 625 such proprietary rights by implementers or users of this 626 specification can be obtained from the IETF on-line IPR repository at 627 http://www.ietf.org/ipr. 629 The IETF invites any interested party to bring to its attention any 630 copyrights, patents or patent applications, or other proprietary 631 rights that may cover technology that may be required to implement 632 this standard. Please address the information to the IETF at 633 ietf-ipr@ietf.org. 635 Acknowledgment 637 Funding for the RFC Editor function is provided by the IETF 638 Administrative Support Activity (IASA).