idnits 2.17.1 draft-ietf-pkix-ta-format-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2009) is 5278 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) -- Looks like a reference, but probably isn't: '1' on line 584 -- Looks like a reference, but probably isn't: '2' on line 585 -- Looks like a reference, but probably isn't: '0' on line 569 -- Looks like a reference, but probably isn't: '3' on line 572 -- Looks like a reference, but probably isn't: '4' on line 573 == Outdated reference: A later version (-08) exists of draft-ietf-pkix-new-asn1-05 ** Downref: Normative reference to an Informational draft: draft-ietf-pkix-new-asn1 (ref. 'I-D.ietf-pkix-new-asn1') ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) == Outdated reference: A later version (-06) exists of draft-ietf-pkix-ta-mgmt-reqs-04 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley 3 Internet-Draft Vigil Security, LLC 4 Intended status: Standards Track S. Ashmore 5 Expires: April 18, 2010 National Security Agency 6 C. Wallace 7 Cygnacom Solutions 8 October 15, 2009 10 Trust Anchor Format 11 draft-ietf-pkix-ta-format-04 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 18, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document describes a structure for representing trust anchor 60 information. A trust anchor is an authoritative entity represented 61 by a public key and associated data. The public key is used to 62 verify digital signatures and the associated data is used to 63 constrain the types of information or actions for which the trust 64 anchor is authoritative. The structures defined in this document are 65 intended to satisfy the format-related requirements defined in Trust 66 Anchor Management Requirements. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Trust Anchor Information Syntax . . . . . . . . . . . . . . . 5 73 2.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.2. Public Key . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2.3. Key Identifier . . . . . . . . . . . . . . . . . . . . . . 5 76 2.4. Trust Anchor Title . . . . . . . . . . . . . . . . . . . . 5 77 2.5. Certification Path Controls . . . . . . . . . . . . . . . 6 78 2.6. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 10 79 3. Trust Anchor List . . . . . . . . . . . . . . . . . . . . . . 11 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 84 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 85 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 15 86 A.1. ASN.1 Module Using 1993 Syntax . . . . . . . . . . . . . . 15 87 A.2. ASN.1 Module Using 1988 Syntax . . . . . . . . . . . . . . 16 88 A.2.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 Trust anchors are widely used to verify digital signatures and 94 validate certification paths [RFC5280][X.509]. They are required 95 when validating certification paths. Though widely used, there is no 96 standard format for representing trust anchor information. This 97 document describes the TrustAnchorInfo structure. This structure is 98 intended to satisfy the format-related requirements expressed in 99 Trust Anchor Management Requirements 100 [I-D.draft-ietf-pkix-ta-mgmt-reqs] and is expressed using ASN.1 101 [X.680]. It can provide a more compact alternative to X.509 102 certificates for exchanging trust anchor information and provides a 103 means of associating additional or alternative constraints with 104 certificates without breaking the signature on the certificate. 106 1.1. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Trust Anchor Information Syntax 114 This section describes the TrustAnchorInfo structure. 116 TrustAnchorInfo ::= SEQUENCE { 117 version TrustAnchorInfoVersion DEFAULT v1, 118 pubKey SubjectPublicKeyInfo, 119 keyId KeyIdentifier, 120 taTitle TrustAnchorTitle OPTIONAL, 121 certPath CertPathControls OPTIONAL, 122 exts [1] EXPLICIT Extensions OPTIONAL, 123 taTitleLangTag [2] UTF8String OPTIONAL } 125 TrustAnchorInfoVersion ::= INTEGER { v1(1) } 127 2.1. Version 129 version identifies the version of TrustAnchorInfo. Future updates to 130 this document may include changes to the TrustAnchorInfo structure, 131 in which case the version number should be incremented. However, the 132 default value, v1, cannot be changed. 134 2.2. Public Key 136 pubKey identifies the public key and algorithm associated with the 137 trust anchor using the SubjectPublicKeyInfo structure [RFC5280]. The 138 SubjectPublicKeyInfo structure contains the algorithm identifier 139 followed by the public key itself. The algorithm field is an 140 AlgorithmIdentifier, which contains an object identifier and OPTIONAL 141 parameters. The object identifier names the public key algorithm and 142 indicates the syntax of the parameters, if present, as well as the 143 format of the public key. The public key is encoded as a BIT STRING. 145 2.3. Key Identifier 147 keyId contains the public key identifier of the trust anchor public 148 key. See section 4.2.1.2 of [RFC5280] for a description of common 149 key identifier calculation methods. 151 2.4. Trust Anchor Title 153 TrustAnchorTitle ::= UTF8String (SIZE (1..64)) 155 taTitle is OPTIONAL. When it is present, it provides a human 156 readable name for the trust anchor. The text is encoded in UTF-8 157 [RFC3629], which accommodates most of the world's writing systems. 158 The taTitleLangTag field identifies the language used to express the 159 taTitle. When taTitleLangTag is absent, English is used. The value 160 of the taTitleLangTag should be a language tag as described in 161 [RFC5646] 163 2.5. Certification Path Controls 165 CertPathControls ::= SEQUENCE { 166 taName Name, 167 certificate [0] Certificate OPTIONAL, 168 policySet [1] CertificatePolicies OPTIONAL, 169 policyFlags [2] CertPolicyFlags OPTIONAL, 170 nameConstr [3] NameConstraints OPTIONAL, 171 pathLenConstraint[4] INTEGER (0..MAX) OPTIONAL} 173 certPath is OPTIONAL. When it is present, it provides the controls 174 needed to initialize an X.509 certification path validation algorithm 175 implementation (see Section 6 in [RFC5280]). When absent, the trust 176 anchor cannot be used to validate the signature on an X.509 177 certificate. 179 taName provides the X.500 distinguished name associated with the 180 trust anchor, and this distinguished name is used to construct and 181 validate an X.509 certification path. The name MUST NOT be an empty 182 sequence. 184 certificate provides an OPTIONAL X.509 certificate, which can be used 185 in some environments to represent the trust anchor in certification 186 path development and validation. If the certificate is present, the 187 subject name in the certificate MUST exactly match the X.500 188 distinguished name provided in the taName field, the public key MUST 189 exactly match the public key in the pubKey field and the 190 subjectKeyIdentifier extension, if present, MUST exactly match the 191 key identifier in the keyId field. The complete description of the 192 syntax and semantics of the Certificate are provided in [RFC5280]. 193 Constraints defined in the policySet, policyFlags, nameConstr, 194 pathLenConstraint and exts fields within TrustAnchorInfo replace 195 values contained in a certificate or provide values for extensions 196 not present in the certificate. Values defined in these 197 TrustAnchorInfo fields are always enforced. Extensions included in a 198 certificate are enforced only if there is no corresponding value in 199 the TrustAnchorInfo. Correspondence between extensions within a 200 certificate and TrustAnchorInfo fields is defined as follows: 202 o an id-ce-certificatePolicies certificate extension corresponds to 203 the CertPathControls.policySet field. 205 o an id-ce-policyConstraints certificate extension corresponds to 206 the CertPolicyFlags.inhibitPolicyMapping and 207 CertPolicyFlags.requireExplicitPolicy fields. 209 o an id-ce-inhibitAnyPolicy certificate extension corresponds to the 210 CertPolicyFlags.inhibitAnyPolicy field. 212 o an id-ce-nameConstraints certificate extension corresponds to the 213 CertPathControls.nameConstr field. 215 o the pathLenConstraint field of an id-ce-basicConstraints 216 certificate extension corresponds to the 217 CertPathControls.pathLenConstraint field (the presence of a 218 CertPathControls structure corresponds to a TRUE value in the cA 219 field of a BasicConstraints extension). 221 o any other certificate extension corresponds to the same type of 222 extension in the TrustAnchorInfo.exts field. 224 CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 226 PolicyInformation ::= SEQUENCE { 227 policyIdentifier CertPolicyId, 228 policyQualifiers SEQUENCE SIZE (1..MAX) OF 229 PolicyQualifierInfo OPTIONAL } 231 CertPolicyId ::= OBJECT IDENTIFIER 233 policySet is OPTIONAL. When present, it contains sequence of 234 certificate policy identifiers to be provided as inputs to the 235 certification path validation algorithm. When absent, the special 236 value any-policy is provided as the input to the certification path 237 validation algorithm. The complete description of the syntax and 238 semantics of the CertificatePolicies are provided in [RFC5280], 239 including the syntax for PolicyInformation. In this context, the 240 OPTIONAL policyQualifiers structure MUST NOT be included. 242 CertPolicyFlags ::= BIT STRING { 243 inhibitPolicyMapping (0), 244 requireExplicitPolicy (1), 245 inhibitAnyPolicy (2) } 247 policyFlags is OPTIONAL. When present, three Boolean values for 248 input to the certification path validation algorithm are provided in 249 a BIT STRING. When absent, the input to the certification path 250 validation algorithm is { FALSE, FALSE, FALSE }, which represents the 251 most liberal setting for these flags. The three bits are used as 252 follows: 254 inhibitPolicyMapping indicates if policy mapping is allowed in the 255 certification path. When set to TRUE, policy mapping is not 256 permitted. This value represents the initial-policy-mapping- 257 inhibit input value to the certification path validation algorithm 258 described in section 6.1.1 of [RFC5280]. 260 requireExplicitPolicy indicates if the certification path MUST be 261 valid for at least one of the certificate policies in the 262 policySet. When set to TRUE, all certificates in the 263 certification path MUST contain an acceptable policy identifier in 264 the certificate policies extension. This value represents the 265 initial-explicit-policy input value to the certification path 266 validation algorithm described in section 6.1.1 of [RFC5280]. An 267 acceptable policy identifier is a member of the policySet or the 268 identifier of a policy that is declared to be equivalent through 269 policy mapping. This bit MUST be set to FALSE if policySet is 270 absent. 272 inhibitAnyPolicy indicates whether the special anyPolicy policy 273 identifier, with the value { 2 5 29 32 0 }, is considered an 274 explicit match for other certificate policies. This value 275 represents the initial-any-policy-inhibit input value to the 276 certification path validation algorithm described in section 6.1.1 277 of [RFC5280]. 279 NameConstraints ::= SEQUENCE { 280 permittedSubtrees [0] GeneralSubtrees OPTIONAL, 281 excludedSubtrees [1] GeneralSubtrees OPTIONAL } 283 GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree 285 GeneralSubtree ::= SEQUENCE { 286 base GeneralName, 287 minimum [0] BaseDistance DEFAULT 0, 288 maximum [1] BaseDistance OPTIONAL } 290 BaseDistance ::= INTEGER (0..MAX) 292 nameConstr is OPTIONAL. It has the same syntax and semantics as the 293 Name Constraints certificate extension [RFC5280], which includes a 294 list of permitted names and a list of excluded names. The definition 295 of GeneralName can be found in [RFC5280]. When it is present, 296 constraints are provided on names (including alternative names) that 297 might appear in subsequent X.509 certificates in a certification 298 path. This field is used to set the initial-permitted-subtrees and 299 initial-excluded-subtrees input values to the certification path 300 validation algorithm described in section 6.1.1 of [RFC5280]. When 301 this field is absent, the initial-permitted-subtrees variable is 302 unbounded and the initial-excluded-subtrees variable is empty. 304 The pathLenConstraint field gives the maximum number of non-self- 305 issued intermediate certificates that may follow this certificate in 306 a valid certification path. (Note: The last certificate in the 307 certification path is not an intermediate certificate, and is not 308 included in this limit. Usually, the last certificate is an end 309 entity certificate, but it can be a CA certificate.) A 310 pathLenConstraint of zero indicates that no non- self-issued 311 intermediate certification authority (CA) certificates may follow in 312 a valid certification path. Where it appears, the pathLenConstraint 313 field MUST be greater than or equal to zero. Where pathLenConstraint 314 does not appear, no limit is imposed. 316 When the trust anchor is used to validate a certification path, 317 CertPathControls provides limitations on certification paths that 318 will successfully validate. An application that is validating a 319 certification path SHOULD NOT ignore these limitations, but the 320 application can impose additional limitations to ensure that the 321 validated certification path is appropriate for the intended 322 application context. As input to the certification path validation 323 algorithm, an application MAY: 325 o Provide a subset of the certification policies provided in the 326 policySet; 328 o Provide a TRUE value, if appropriate, for any of the flags in the 329 policyFlags; 331 o Provide a subset of the permitted names provided in the 332 nameConstr; 334 o Provide additional excluded names to the ones that are provided in 335 the nameConstr; 337 o Provide a smaller value for pathLenConstraint 339 2.6. Extensions 341 exts is OPTIONAL. When it is present, it can be used to associate 342 additional information with the trust anchor using the standard 343 Extensions structure. Extensions that are anticipated to be widely 344 used have been included in the CertPathControls structure to avoid 345 overhead associated with use of the Extensions structure. To avoid 346 duplication with the CertPathControls field, the following types of 347 extensions MUST NOT appear in the exts field and are ignored if they 348 do appear: id-ce-certificatePolicies, id-ce-policyConstraints, id-ce- 349 inhibitAnyPolicy or id-ce-nameConstraints. 351 3. Trust Anchor List 353 TrustAnchorInfo allows for the representation of a single trust 354 anchor. In many cases, it is convenient to represent a collection of 355 trust anchors. The TrustAnchorList structure is defined for this 356 purpose. TrustAnchorList is defined as a sequence of one or more 357 TrustAnchorChoice objects. TrustAnchorChoice provides three options 358 for representing a trust anchor. The certificate option allows for 359 the use of a certificate with no additional associated constraints. 360 The tbsCert option allows for associating constraints by removing a 361 signature on a certificate and changing the extensions field. The 362 taInfo option allows for use of the TrustAnchorInfo structure defined 363 in this document. 365 TrustAnchorList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorChoice 367 TrustAnchorChoice ::= CHOICE { 368 certificate Certificate, 369 tbsCert [1] EXPLICIT TBSCertificate, 370 taInfo [2] EXPLICIT TrustAnchorInfo } 372 trust-anchor-list PKCS7-CONTENT-TYPE ::= 373 { TrustAnchorList IDENTIFIED BY id-ct-trustAnchorList } 375 The TrustAnchorList structure can be protected using the SignedData 376 structured defined in the Cryptographic Message Syntax(CMS) 377 [RFC3852]. The id-ct-trustAnchorList object identifier has been 378 defined to represent TrustAnchorList payloads with CMS structures. 380 4. Security Considerations 382 Compromise of a trust anchor private key permits unauthorized parties 383 to masquerade as the trust anchor, with potentially severe 384 consequences. Where TA-based constraints are enforced, the 385 unauthorized holder of the trust anchor private key will be limited 386 by the certification path controls associated with the trust anchor, 387 as expressed in the certPath and exts fields. For example, name 388 constraints in the trust anchor will determine the name space that 389 will be accepted in certificates that are validated using the 390 compromised trust anchor. Reliance on an inappropriate or incorrrect 391 trust anchor public key has similar potentially severe consequences. 393 The compromise of a CA's private key leads to the same type of 394 problems as the compromise of a trust anchor private key. The 395 unauthorized holder of the CA private key will be limited by the 396 certification path controls associated with the trust anchor, as 397 expressed in the certPath field or as an extension. 399 Usage of a certificate independent of the TrustAnchorInfo structure 400 that envelopes it must be carefully managed to avoid violating 401 constraints expressed in the TrustAnchorInfo. When enveloping a 402 certificate in a TrustAnchorInfo structure, values included in the 403 certificate should be evaluated to ensure there is no confusion or 404 conflict with values in the TrustAnchorInfo structure. 406 5. IANA Considerations 408 There are no IANA considerations. Please delete this section prior 409 to RFC publication. 411 6. References 413 6.1. Normative References 415 [I-D.ietf-pkix-new-asn1] 416 Hoffman, P. and J. Schaad, "New ASN.1 Modules for PKIX", 417 draft-ietf-pkix-new-asn1-05 (work in progress), 418 April 2009. 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, March 1997. 423 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 424 10646", STD 63, RFC 3629, November 2003. 426 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 427 RFC 3852, July 2004. 429 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 430 Housley, R., and W. Polk, "Internet X.509 Public Key 431 Infrastructure Certificate and Certificate Revocation List 432 (CRL) Profile", RFC 5280, May 2008. 434 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 435 Languages", BCP 47, RFC 5646, September 2009. 437 [X.680] "ITU-T Recommendation X.680: Information Technology - 438 Abstract Syntax Notation One", 1997. 440 6.2. Informative References 442 [I-D.draft-ietf-pkix-ta-mgmt-reqs] 443 Reddy, R. and C. Wallace, "Trust Anchor Management 444 Requirements", draft-ietf-pkix-ta-mgmt-reqs-04 (work in 445 progress). 447 [X.509] "ITU-T Recommendation X.509 - The Directory - 448 Authentication Framework", 2000. 450 Appendix A. ASN.1 Modules 452 Appendix A.1 provides the normative ASN.1 definitions for the 453 structures described in this specification using ASN.1 as defined in 454 [X.680]. It includes definitions imported from [RFC5280] and 455 [I-D.ietf-pkix-new-asn1]. 457 A.1. ASN.1 Module Using 1993 Syntax 459 TrustAnchorInfoModule 460 { joint-iso-ccitt(2) country(16) us(840) organization(1) 461 gov(101) dod(2) infosec(1) modules(0) 33 } 463 DEFINITIONS IMPLICIT TAGS ::= 464 BEGIN 466 IMPORTS 467 Certificate, Name, SubjectPublicKeyInfo, TBSCertificate 468 FROM PKIX1Explicit-2009 -- from [I-D.ietf-pkix-new-asn1] 469 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 470 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} 471 CertificatePolicies, KeyIdentifier, NameConstraints 472 FROM PKIX1Implicit-2009 -- from [I-D.ietf-pkix-new-asn1] 473 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 474 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 475 Extensions 476 FROM PKIX-CommonTypes-2009 -- from [I-D.ietf-pkix-new-asn1] 477 { iso(1) identified-organization(3) dod(6) internet(1) 478 security(5) mechanisms(5) pkix(7) id-mod(0) 479 id-mod-pkixCommon-02(57) } ; 481 TrustAnchorInfo ::= SEQUENCE { 482 version TrustAnchorInfoVersion DEFAULT v1, 483 pubKey SubjectPublicKeyInfo, 484 keyId KeyIdentifier, 485 taTitle TrustAnchorTitle OPTIONAL, 486 certPath CertPathControls OPTIONAL, 487 exts [1] EXPLICIT Extensions OPTIONAL, 488 taTitleLangTag [2] UTF8String OPTIONAL } 490 TrustAnchorInfoVersion ::= INTEGER { v1(1) } 492 TrustAnchorTitle ::= UTF8String (SIZE (1..64)) 494 CertPathControls ::= SEQUENCE { 495 taName Name, 496 certificate [0] Certificate OPTIONAL, 497 policySet [1] CertificatePolicies OPTIONAL, 498 policyFlags [2] CertPolicyFlags OPTIONAL, 499 nameConstr [3] NameConstraints OPTIONAL, 500 pathLenConstraint[4] INTEGER (0..MAX) OPTIONAL} 502 CertPolicyFlags ::= BIT STRING { 503 inhibitPolicyMapping (0), 504 requireExplicitPolicy (1), 505 inhibitAnyPolicy (2) } 507 TrustAnchorList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorChoice 509 TrustAnchorChoice ::= CHOICE { 510 certificate Certificate, 511 tbsCert [1] EXPLICIT TBSCertificate, 512 taInfo [2] EXPLICIT TrustAnchorInfo } 514 id-ct-trustAnchorList OBJECT IDENTIFIER ::= { iso(1) 515 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 516 id-smime(16) id-ct(1) 34 } 518 PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER 520 trust-anchor-list PKCS7-CONTENT-TYPE ::= 521 { TrustAnchorList IDENTIFIED BY id-ct-trustAnchorList } 523 END 525 A.2. ASN.1 Module Using 1988 Syntax 527 Appendix A.1 provides the normative ASN.1 definitions for the 528 structures described in this specification using ASN.1 as defined in 529 [X.680]. 531 A.2.1. ASN.1 Module 533 TrustAnchorInfoModule-88 534 { joint-iso-ccitt(2) country(16) us(840) organization(1) 535 gov(101) dod(2) infosec(1) modules(0) 37 } 537 DEFINITIONS IMPLICIT TAGS ::= 538 BEGIN 540 IMPORTS 541 Certificate, Name, Extensions, 542 SubjectPublicKeyInfo, TBSCertificate 543 FROM PKIX1Explicit88 -- from [RFC5280] 544 { iso(1) identified-organization(3) dod(6) internet(1) 545 security(5) mechanisms(5) pkix(7) id-mod(0) 546 id-pkix1-explicit(18) } 547 CertificatePolicies, KeyIdentifier, NameConstraints 548 FROM PKIX1Implicit88 -- [RFC5280] 549 { iso(1) identified-organization(3) dod(6) internet(1) 550 security(5) mechanisms(5) pkix(7) id-mod(0) 551 id-pkix1-implicit(19) } 552 ; 554 TrustAnchorInfo ::= SEQUENCE { 555 version TrustAnchorInfoVersion DEFAULT v1, 556 pubKey SubjectPublicKeyInfo, 557 keyId KeyIdentifier, 558 taTitle TrustAnchorTitle OPTIONAL, 559 certPath CertPathControls OPTIONAL, 560 exts [1] EXPLICIT Extensions OPTIONAL, 561 taTitleLangTag [2] UTF8String OPTIONAL } 563 TrustAnchorInfoVersion ::= INTEGER { v1(1) } 565 TrustAnchorTitle ::= UTF8String (SIZE (1..64)) 567 CertPathControls ::= SEQUENCE { 568 taName Name, 569 certificate [0] Certificate OPTIONAL, 570 policySet [1] CertificatePolicies OPTIONAL, 571 policyFlags [2] CertPolicyFlags OPTIONAL, 572 nameConstr [3] NameConstraints OPTIONAL, 573 pathLenConstraint[4] INTEGER (0..MAX) OPTIONAL} 575 CertPolicyFlags ::= BIT STRING { 576 inhibitPolicyMapping (0), 577 requireExplicitPolicy (1), 578 inhibitAnyPolicy (2) } 580 TrustAnchorList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorChoice 582 TrustAnchorChoice ::= CHOICE { 583 certificate Certificate, 584 tbsCert [1] EXPLICIT TBSCertificate, 585 taInfo [2] EXPLICIT TrustAnchorInfo } 587 id-ct-trustAnchorList OBJECT IDENTIFIER ::= { iso(1) 588 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 589 id-smime(16) id-ct(1) 34 } 591 END 593 Authors' Addresses 595 Russ Housley 596 Vigil Security, LLC 597 918 Spring Knoll Drive 598 Herndon, VA 20170 600 Email: housley@vigilsec.com 602 Sam Ashmore 603 National Security Agency 604 Suite 6751 605 9800 Savage Road 606 Fort Meade, MD 20755 608 Email: srashmo@radium.ncsc.mil 610 Carl Wallace 611 Cygnacom Solutions 612 Suite 5200 613 7925 Jones Branch Drive 614 McLean, VA 22102 616 Email: cwallace@cygnacom.com