From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5914.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc5914.txt (limited to 'doc/rfc/rfc5914.txt') diff --git a/doc/rfc/rfc5914.txt b/doc/rfc/rfc5914.txt new file mode 100644 index 0000000..d3ec852 --- /dev/null +++ b/doc/rfc/rfc5914.txt @@ -0,0 +1,787 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Housley +Request for Comments: 5914 Vigil Security, LLC +Category: Standards Track S. Ashmore +ISSN: 2070-1721 National Security Agency + C. Wallace + Cygnacom Solutions + June 2010 + + + Trust Anchor Format + +Abstract + + This document describes a structure for representing trust anchor + information. A trust anchor is an authoritative entity represented + by a public key and associated data. The public key is used to + verify digital signatures, and the associated data is used to + constrain the types of information or actions for which the trust + anchor is authoritative. The structures defined in this document are + intended to satisfy the format-related requirements defined in Trust + Anchor Management Requirements. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5914. + + + + + + + + + + + + + + + + +Housley, et al. Standards Track [Page 1] + +RFC 5914 TAF June 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Trust Anchor Information Syntax . . . . . . . . . . . . . . . 3 + 2.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Public Key . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.3. Key Identifier . . . . . . . . . . . . . . . . . . . . . . 4 + 2.4. Trust Anchor Title . . . . . . . . . . . . . . . . . . . . 4 + 2.5. Certification Path Controls . . . . . . . . . . . . . . . 4 + 2.6. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3. Trust Anchor List . . . . . . . . . . . . . . . . . . . . . . 8 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 + 5.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 11 + A.1. ASN.1 Module Using 2002 Syntax . . . . . . . . . . . . . . 11 + A.2. ASN.1 Module Using 1988 Syntax . . . . . . . . . . . . . . 12 + A.2.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 12 + + + + +Housley, et al. Standards Track [Page 2] + +RFC 5914 TAF June 2010 + + +1. Introduction + + Trust anchors are widely used to verify digital signatures and + validate certification paths [RFC5280][X.509]. They are required + when validating certification paths. Though widely used, there is no + standard format for representing trust anchor information. This + document describes the TrustAnchorInfo structure. This structure is + intended to satisfy the format-related requirements expressed in + Trust Anchor Management Requirements [TA-MGMT-REQS] and is expressed + using ASN.1 [X.680]. It can provide a more compact alternative to + X.509 certificates for exchanging trust anchor information and + provides a means of associating additional or alternative constraints + with certificates without breaking the signature on the certificate. + +1.1. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Trust Anchor Information Syntax + + This section describes the TrustAnchorInfo structure. + + TrustAnchorInfo ::= SEQUENCE { + version TrustAnchorInfoVersion DEFAULT v1, + pubKey SubjectPublicKeyInfo, + keyId KeyIdentifier, + taTitle TrustAnchorTitle OPTIONAL, + certPath CertPathControls OPTIONAL, + exts [1] EXPLICIT Extensions OPTIONAL, + taTitleLangTag [2] UTF8String OPTIONAL } + + TrustAnchorInfoVersion ::= INTEGER { v1(1) } + +2.1. Version + + version identifies the version of TrustAnchorInfo. Future updates to + this document may include changes to the TrustAnchorInfo structure, + in which case the version number should be incremented. However, the + default value, v1, cannot be changed. + +2.2. Public Key + + pubKey identifies the public key and algorithm associated with the + trust anchor using the SubjectPublicKeyInfo structure [RFC5280]. The + SubjectPublicKeyInfo structure contains the algorithm identifier + followed by the public key itself. The algorithm field is an + + + +Housley, et al. Standards Track [Page 3] + +RFC 5914 TAF June 2010 + + + AlgorithmIdentifier, which contains an object identifier and OPTIONAL + parameters. The object identifier names the public key algorithm and + indicates the syntax of the parameters, if present, as well as the + format of the public key. The public key is encoded as a BIT STRING. + +2.3. Key Identifier + + keyId contains the public key identifier of the trust anchor public + key. See Section 4.2.1.2 of [RFC5280] for a description of common + key identifier calculation methods. + +2.4. Trust Anchor Title + + TrustAnchorTitle ::= UTF8String (SIZE (1..64)) + + taTitle is OPTIONAL. When it is present, it provides a human- + readable name for the trust anchor. The text is encoded in UTF-8 + [RFC3629], which accommodates most of the world's writing systems. + The taTitleLangTag field identifies the language used to express the + taTitle. When taTitleLangTag is absent, English ("en" language tag) + is used. The value of the taTitleLangTag should be a language tag as + described in [RFC5646]. + +2.5. Certification Path Controls + + CertPathControls ::= SEQUENCE { + taName Name, + certificate [0] Certificate OPTIONAL, + policySet [1] CertificatePolicies OPTIONAL, + policyFlags [2] CertPolicyFlags OPTIONAL, + nameConstr [3] NameConstraints OPTIONAL, + pathLenConstraint[4] INTEGER (0..MAX) OPTIONAL} + + certPath is OPTIONAL. When it is present, it provides the controls + needed to initialize an X.509 certification path validation algorithm + implementation (see Section 6 of [RFC5280]). When absent, the trust + anchor cannot be used to validate the signature on an X.509 + certificate. + + taName provides the X.500 distinguished name associated with the + trust anchor, and this distinguished name is used to construct and + validate an X.509 certification path. The name MUST NOT be an empty + sequence. + + certificate provides an OPTIONAL X.509 certificate, which can be used + in some environments to represent the trust anchor in certification + path development and validation. If the certificate is present, the + subject name in the certificate MUST exactly match the X.500 + + + +Housley, et al. Standards Track [Page 4] + +RFC 5914 TAF June 2010 + + + distinguished name provided in the taName field, the public key MUST + exactly match the public key in the pubKey field, and the + subjectKeyIdentifier extension, if present, MUST exactly match the + key identifier in the keyId field. The complete description of the + syntax and semantics of the Certificate are provided in [RFC5280]. + Constraints defined in the policySet, policyFlags, nameConstr, + pathLenConstraint, and exts fields within TrustAnchorInfo replace + values contained in a certificate or provide values for extensions + not present in the certificate. Values defined in these + TrustAnchorInfo fields are always enforced. Extensions included in a + certificate are enforced only if there is no corresponding value in + the TrustAnchorInfo. Correspondence between extensions within + certificate and TrustAnchorInfo fields is defined as follows: + + o an id-ce-certificatePolicies certificate extension corresponds to + the CertPathControls.policySet field. + + o an id-ce-policyConstraints certificate extension corresponds to + the CertPolicyFlags.inhibitPolicyMapping and + CertPolicyFlags.requireExplicitPolicy fields. + + o an id-ce-inhibitAnyPolicy certificate extension corresponds to the + CertPolicyFlags.inhibitAnyPolicy field. + + o an id-ce-nameConstraints certificate extension corresponds to the + CertPathControls.nameConstr field. + + o the pathLenConstraint field of an id-ce-basicConstraints + certificate extension corresponds to the + CertPathControls.pathLenConstraint field (the presence of a + CertPathControls structure corresponds to a TRUE value in the cA + field of a BasicConstraints extension). + + o any other certificate extension corresponds to the same type of + extension in the TrustAnchorInfo.exts field. + + CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation + + PolicyInformation ::= SEQUENCE { + policyIdentifier CertPolicyId, + policyQualifiers SEQUENCE SIZE (1..MAX) OF + PolicyQualifierInfo OPTIONAL } + + CertPolicyId ::= OBJECT IDENTIFIER + + policySet is OPTIONAL. When present, it contains a sequence of + certificate policy identifiers to be provided as inputs to the + certification path validation algorithm. When absent, the special + + + +Housley, et al. Standards Track [Page 5] + +RFC 5914 TAF June 2010 + + + value any-policy is provided as the input to the certification path + validation algorithm. The complete description of the syntax and + semantics of the CertificatePolicies are provided in [RFC5280], + including the syntax for PolicyInformation. In this context, the + OPTIONAL policyQualifiers structure MUST NOT be included. + + CertPolicyFlags ::= BIT STRING { + inhibitPolicyMapping (0), + requireExplicitPolicy (1), + inhibitAnyPolicy (2) } + + policyFlags is OPTIONAL. When present, three Boolean values for + input to the certification path validation algorithm are provided in + a BIT STRING. When absent, the input to the certification path + validation algorithm is { FALSE, FALSE, FALSE }, which represents the + most liberal setting for these flags. The three bits are used as + follows: + + inhibitPolicyMapping indicates if policy mapping is allowed in the + certification path. When set to TRUE, policy mapping is not + permitted. This value represents the initial-policy-mapping- + inhibit input value to the certification path validation algorithm + described in Section 6.1.1 of [RFC5280]. + + requireExplicitPolicy indicates if the certification path MUST be + valid for at least one of the certificate policies in the + policySet. When set to TRUE, all certificates in the + certification path MUST contain an acceptable policy identifier in + the certificate policies extension. This value represents the + initial-explicit-policy input value to the certification path + validation algorithm described in Section 6.1.1 of [RFC5280]. An + acceptable policy identifier is a member of the policySet or the + identifier of a policy that is declared to be equivalent through + policy mapping. This bit MUST be set to FALSE if policySet is + absent. + + inhibitAnyPolicy indicates whether the special anyPolicy policy + identifier, with the value { 2 5 29 32 0 }, is considered an + explicit match for other certificate policies. This value + represents the initial-any-policy-inhibit input value to the + certification path validation algorithm described in Section 6.1.1 + of [RFC5280]. + + NameConstraints ::= SEQUENCE { + permittedSubtrees [0] GeneralSubtrees OPTIONAL, + excludedSubtrees [1] GeneralSubtrees OPTIONAL } + + GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree + + + +Housley, et al. Standards Track [Page 6] + +RFC 5914 TAF June 2010 + + + GeneralSubtree ::= SEQUENCE { + base GeneralName, + minimum [0] BaseDistance DEFAULT 0, + maximum [1] BaseDistance OPTIONAL } + + BaseDistance ::= INTEGER (0..MAX) + + nameConstr is OPTIONAL. It has the same syntax and semantics as the + Name Constraints certificate extension [RFC5280], which includes a + list of permitted names and a list of excluded names. The definition + of GeneralName can be found in [RFC5280]. When it is present, + constraints are provided on names (including alternative names) that + might appear in subsequent X.509 certificates in a certification + path. This field is used to set the initial-permitted-subtrees and + initial-excluded-subtrees input values to the certification path + validation algorithm described in Section 6.1.1 of [RFC5280]. When + this field is absent, the initial-permitted-subtrees variable is + unbounded and the initial-excluded-subtrees variable is empty. + + The pathLenConstraint field gives the maximum number of non-self- + issued intermediate certificates that may follow this certificate in + a valid certification path. (Note: The last certificate in the + certification path is not an intermediate certificate and is not + included in this limit. Usually, the last certificate is an end + entity certificate, but it can be a CA certificate.) A + pathLenConstraint of zero indicates that no non-self-issued + intermediate certification authority (CA) certificates may follow in + a valid certification path. Where it appears, the pathLenConstraint + field MUST be greater than or equal to zero. Where pathLenConstraint + does not appear, no limit is imposed. + + When the trust anchor is used to validate a certification path, + CertPathControls provides limitations on certification paths that + will successfully validate. An application that is validating a + certification path SHOULD NOT ignore these limitations, but the + application can impose additional limitations to ensure that the + validated certification path is appropriate for the intended + application context. As input to the certification path validation + algorithm, an application MAY: + + o Provide a subset of the certification policies provided in the + policySet; + + o Provide a TRUE value, if appropriate, for any of the flags in the + policyFlags; + + o Provide a subset of the permitted names provided in the + nameConstr; + + + +Housley, et al. Standards Track [Page 7] + +RFC 5914 TAF June 2010 + + + o Provide additional excluded names to the ones that are provided in + the nameConstr; + + o Provide a smaller value for pathLenConstraint. + +2.6. Extensions + + exts is OPTIONAL. When it is present, it can be used to associate + additional information with the trust anchor using the standard + Extensions structure. Extensions that are anticipated to be widely + used have been included in the CertPathControls structure to avoid + overhead associated with use of the Extensions structure. To avoid + duplication with the CertPathControls field, the following types of + extensions MUST NOT appear in the exts field and are ignored if they + do appear: id-ce-certificatePolicies, id-ce-policyConstraints, id-ce- + inhibitAnyPolicy, or id-ce-nameConstraints. + +3. Trust Anchor List + + TrustAnchorInfo allows for the representation of a single trust + anchor. In many cases, it is convenient to represent a collection of + trust anchors. The TrustAnchorList structure is defined for this + purpose. TrustAnchorList is defined as a sequence of one or more + TrustAnchorChoice objects. TrustAnchorChoice provides three options + for representing a trust anchor. The certificate option allows for + the use of a certificate with no additional associated constraints. + The tbsCert option allows for associating constraints by removing a + signature on a certificate and changing the extensions field. The + taInfo option allows for use of the TrustAnchorInfo structure defined + in this document. + + TrustAnchorList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorChoice + + TrustAnchorChoice ::= CHOICE { + certificate Certificate, + tbsCert [1] EXPLICIT TBSCertificate, + taInfo [2] EXPLICIT TrustAnchorInfo } + + trust-anchor-list PKCS7-CONTENT-TYPE ::= + { TrustAnchorList IDENTIFIED BY id-ct-trustAnchorList } + + The TrustAnchorList structure can be protected using the SignedData + structure defined in the Cryptographic Message Syntax (CMS) + [RFC5652]. The id-ct-trustAnchorList object identifier has been + defined to represent TrustAnchorList payloads with CMS structures. + + + + + + +Housley, et al. Standards Track [Page 8] + +RFC 5914 TAF June 2010 + + +4. Security Considerations + + Compromise of a trust anchor private key permits unauthorized parties + to masquerade as the trust anchor, with potentially severe + consequences. Where TA-based constraints are enforced, the + unauthorized holder of the trust anchor private key will be limited + by the certification path controls associated with the trust anchor, + as expressed in the certPath and exts fields. For example, name + constraints in the trust anchor will determine the name space that + will be accepted in certificates that are validated using the + compromised trust anchor. Reliance on an inappropriate or incorrect + trust anchor public key has similar potentially severe consequences. + + The compromise of a CA's private key leads to the same type of + problems as the compromise of a trust anchor private key. The + unauthorized holder of the CA private key will be limited by the + certification path controls associated with the trust anchor, as + expressed in the certPath field or as an extension. + + Usage of a certificate independent of the TrustAnchorInfo structure + that envelopes it must be carefully managed to avoid violating + constraints expressed in the TrustAnchorInfo. When enveloping a + certificate in a TrustAnchorInfo structure, values included in the + certificate should be evaluated to ensure there is no confusion or + conflict with values in the TrustAnchorInfo structure. + +5. References + +5.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", + RFC 5652, September 2009. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation + List (CRL) Profile", RFC 5280, May 2008. + + [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying + Languages", BCP 47, RFC 5646, September 2009. + + + + + +Housley, et al. Standards Track [Page 9] + +RFC 5914 TAF June 2010 + + + [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the + Public Key Infrastructure Using X.509 (PKIX)", + RFC 5912, June 2010. + + [X.680] "ITU-T Recommendation X.680: Information Technology - + Abstract Syntax Notation One", 2002. + +5.2. Informative References + + [TA-MGMT-REQS] Reddy, R. and C. Wallace, "Trust Anchor Management + Requirements", Work in Progress, March 2010. + + [X.509] "ITU-T Recommendation X.509 - The Directory - + Authentication Framework", 2000. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Housley, et al. Standards Track [Page 10] + +RFC 5914 TAF June 2010 + + +Appendix A. ASN.1 Modules + +A.1. ASN.1 Module Using 2002 Syntax + + Appendix A.1 provides the normative ASN.1 definitions for the + structures described in this specification using ASN.1 as defined in + [X.680]. It includes definitions imported from [RFC5280] and + [RFC5912]. + + TrustAnchorInfoModule + { joint-iso-ccitt(2) country(16) us(840) organization(1) + gov(101) dod(2) infosec(1) modules(0) 33 } + + DEFINITIONS IMPLICIT TAGS ::= + BEGIN + + IMPORTS + Certificate, Name, SubjectPublicKeyInfo, TBSCertificate + FROM PKIX1Explicit-2009 -- from [RFC5912] + {iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} + CertificatePolicies, KeyIdentifier, NameConstraints + FROM PKIX1Implicit-2009 -- from [RFC5912] + {iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} + Extensions{} + FROM PKIX-CommonTypes-2009 -- from [RFC5912] + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkixCommon-02(57) } ; + + TrustAnchorInfo ::= SEQUENCE { + version TrustAnchorInfoVersion DEFAULT v1, + pubKey SubjectPublicKeyInfo, + keyId KeyIdentifier, + taTitle TrustAnchorTitle OPTIONAL, + certPath CertPathControls OPTIONAL, + exts [1] EXPLICIT Extensions {{...}} OPTIONAL, + taTitleLangTag [2] UTF8String OPTIONAL } + + TrustAnchorInfoVersion ::= INTEGER { v1(1) } + + TrustAnchorTitle ::= UTF8String (SIZE (1..64)) + + CertPathControls ::= SEQUENCE { + taName Name, + certificate [0] Certificate OPTIONAL, + policySet [1] CertificatePolicies OPTIONAL, + + + +Housley, et al. Standards Track [Page 11] + +RFC 5914 TAF June 2010 + + + policyFlags [2] CertPolicyFlags OPTIONAL, + nameConstr [3] NameConstraints OPTIONAL, + pathLenConstraint[4] INTEGER (0..MAX) OPTIONAL} + + CertPolicyFlags ::= BIT STRING { + inhibitPolicyMapping (0), + requireExplicitPolicy (1), + inhibitAnyPolicy (2) } + + TrustAnchorList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorChoice + + TrustAnchorChoice ::= CHOICE { + certificate Certificate, + tbsCert [1] EXPLICIT TBSCertificate, + taInfo [2] EXPLICIT TrustAnchorInfo } + + id-ct-trustAnchorList OBJECT IDENTIFIER ::= { iso(1) + member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) + id-smime(16) id-ct(1) 34 } + + PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER + + trust-anchor-list PKCS7-CONTENT-TYPE ::= + { TrustAnchorList IDENTIFIED BY id-ct-trustAnchorList } + + END + +A.2. ASN.1 Module Using 1988 Syntax + + Appendix A.2 provides the normative ASN.1 definitions for the + structures described in this specification using ASN.1 as defined in + [X.680]. + +A.2.1. ASN.1 Module + + TrustAnchorInfoModule-88 + { joint-iso-ccitt(2) country(16) us(840) organization(1) + gov(101) dod(2) infosec(1) modules(0) 37 } + + DEFINITIONS IMPLICIT TAGS ::= + BEGIN + + IMPORTS + Certificate, Name, Extensions, + SubjectPublicKeyInfo, TBSCertificate + FROM PKIX1Explicit88 -- from [RFC5280] + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + + + +Housley, et al. Standards Track [Page 12] + +RFC 5914 TAF June 2010 + + + id-pkix1-explicit(18) } + CertificatePolicies, KeyIdentifier, NameConstraints + FROM PKIX1Implicit88 -- [RFC5280] + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-pkix1-implicit(19) } + ; + + TrustAnchorInfo ::= SEQUENCE { + version TrustAnchorInfoVersion DEFAULT v1, + pubKey SubjectPublicKeyInfo, + keyId KeyIdentifier, + taTitle TrustAnchorTitle OPTIONAL, + certPath CertPathControls OPTIONAL, + exts [1] EXPLICIT Extensions OPTIONAL, + taTitleLangTag [2] UTF8String OPTIONAL } + + TrustAnchorInfoVersion ::= INTEGER { v1(1) } + + TrustAnchorTitle ::= UTF8String (SIZE (1..64)) + + CertPathControls ::= SEQUENCE { + taName Name, + certificate [0] Certificate OPTIONAL, + policySet [1] CertificatePolicies OPTIONAL, + policyFlags [2] CertPolicyFlags OPTIONAL, + nameConstr [3] NameConstraints OPTIONAL, + pathLenConstraint[4] INTEGER (0..MAX) OPTIONAL} + + CertPolicyFlags ::= BIT STRING { + inhibitPolicyMapping (0), + requireExplicitPolicy (1), + inhibitAnyPolicy (2) } + + TrustAnchorList ::= SEQUENCE SIZE (1..MAX) OF TrustAnchorChoice + + TrustAnchorChoice ::= CHOICE { + certificate Certificate, + tbsCert [1] EXPLICIT TBSCertificate, + taInfo [2] EXPLICIT TrustAnchorInfo } + + id-ct-trustAnchorList OBJECT IDENTIFIER ::= { iso(1) + member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) + id-smime(16) id-ct(1) 34 } + + END + + + + + +Housley, et al. Standards Track [Page 13] + +RFC 5914 TAF June 2010 + + +Authors' Addresses + + Russ Housley + Vigil Security, LLC + 918 Spring Knoll Drive + Herndon, VA 20170 + + EMail: housley@vigilsec.com + + + Sam Ashmore + National Security Agency + Suite 6751 + 9800 Savage Road + Fort Meade, MD 20755 + + EMail: srashmo@radium.ncsc.mil + + + Carl Wallace + Cygnacom Solutions + Suite 5400 + 7925 Jones Branch Drive + McLean, VA 22102 + + EMail: cwallace@cygnacom.com + + + + + + + + + + + + + + + + + + + + + + + + + +Housley, et al. Standards Track [Page 14] + -- cgit v1.2.3