Network Working Group R. Housley Internet-Draft Vigil Security, LLC Intended status: Standards Track S. Ashmore Expires: April 9, 2009 National Security Agency C. Wallace Cygnacom Solutions October 6, 2008 Trust Anchor Format draft-ietf-pkix-ta-format-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 9, 2009. Housley, et al. Expires April 9, 2009 [Page 1] Internet-Draft TAF October 2008 Abstract This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented via 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 and for use within the context of the Trust Anchor Management Protocol (TAMP). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Trust Anchors . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1. Apex Trust Anchors . . . . . . . . . . . . . . . . . . 3 1.2.2. Management Trust Anchors . . . . . . . . . . . . . . . 4 1.2.3. Identity Trust Anchors . . . . . . . . . . . . . . . . 5 2. Trust Anchor Information Syntax . . . . . . . . . . . . . . . 6 2.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Public Key . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Key Identitifer . . . . . . . . . . . . . . . . . . . . . 6 2.4. Trust Anchor Type . . . . . . . . . . . . . . . . . . . . 7 2.5. Trust Anchor Title . . . . . . . . . . . . . . . . . . . . 10 2.6. Certification Path Controls . . . . . . . . . . . . . . . 11 2.7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Normative References . . . . . . . . . . . . . . . . . . . 20 5.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 21 A.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Housley, et al. Expires April 9, 2009 [Page 2] Internet-Draft TAF October 2008 1. Introduction Trust anchors are widely used to verify digital signatures and validate certification paths [RFC5280][X.509]. 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-requirements expressed in Trust Anchor Management Requirements [I-D.draft-ietf-pkix-ta-mgmt-reqs]. The structure is intended for use with the Trust Anchor Management Protocol (TAMP) [TAMP]. It is primarily intended to offer a more compact alternative to X.509 certificates for exchanging trust anchor information and to provide a means of associating 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]. 1.2. Trust Anchors As with TAMP, this specification recognizes three types of trust anchors: apex trust anchors, management trust anchors, and identity trust anchors. All trust anchors, regardless of their type, contain the following components: o A public key signature algorithm identifier and associated public key, which MAY include parameters o A public key identifier o An OPTIONAL human readable trust anchor title o OPTIONAL X.509 certification path controls o OPTIONAL extensions 1.2.1. Apex Trust Anchors Within the context of a single trust anchor store, one trust anchor is superior to all others. This trust anchor is referred to as the apex trust anchor. Typically, this trust anchor is installed during initialization of a trust anchor store, with its integrity confirmed using manual means. This trust anchor represents an authority that is unconstrained within the context of the trust anchor store. An apex trust anchor may delegate authority to other trust anchors. Housley, et al. Expires April 9, 2009 [Page 3] Internet-Draft TAF October 2008 The apex trust anchor private key is expected to be controlled by an entity with information assurance responsibility for the trust anchor store. The apex trust anchor is by definition unconstrained and therefore does not have explicit authorization information associated with it. In order to make processing of management messages as uniform as possible, the apex trust anchor has an implicit OID associated with it that represents the special anyContentType value. This OID will be used as input to processing algorithms to represent the apex trust anchor authorization. The apex trust anchor has a different structure than other trust anchors; it MAY include two public keys. Whenever the apex trust anchor is updated, both public keys are replaced. The first public key, called the operational public key, is used in the same manner as other trust anchors. The second public key, called the contingency public key, can only be used to update the apex trust anchor. The contingency private key SHOULD be used at only one point in time; it is used only to sign a message which results in its own replacement (as well as the replacement of the operational public key). The contingency public key is distributed in encrypted form. When the contingency public key is used, the symmetric key needed to decrypt the contingency public key must be provided, ideally as part of the message that is to be verified with the contingency public key. When an apex trust anchor that contains a contingency key is replaced with an apex trust anchor that does not contain a contingency key, the contingency key of the old apex trust anchor is deleted, or replaced with an empty object. 1.2.2. Management Trust Anchors Management trust anchors are used to verify and authorize selected digitally signed objects. Typically, these objects are protected using the Cryptographic Message Syntax (CMS) [RFC3852] and contain payloads used to manage some aspect of the device hosting the trust anchor store containing the management trust anchor. For example, TAMP messages are validated to a management trust anchor. Similarly, a signed firmware package as specified in [RFC4108] is validated to a management trust anchor. Authorization checking is required for management messages. These checks are based on the content type of the management message. Management trust anchors include a list of object identifiers (OIDs) that name authorized content types along with OPTIONAL constraints. The authorization mechanism used within the TrustAnchorInfo structure for management trust anchors is described in [CCC]. A management trust anchor may be used directly to verify and authorize a signed object, or may be used to validate a certification Housley, et al. Expires April 9, 2009 [Page 4] Internet-Draft TAF October 2008 path terminated by a certificate containing the public key used to verify a digitally signed object. 1.2.3. Identity Trust Anchors Identity trust anchors are used to validate certification paths, and they represent a trust anchor for a public key infrastructure. They are most often used in the validation of certificates associated with non-management applications. Housley, et al. Expires April 9, 2009 [Page 5] Internet-Draft TAF October 2008 2. Trust Anchor Information Syntax This section describes the TrustAnchorInfo structure. TrustAnchorInfo ::= SEQUENCE { version [0] TrustAnchorInfoVersion DEFAULT v2, pubKey PublicKeyInfo, keyId KeyIdentifier, taType TrustAnchorType, taTitle TrustAnchorTitle OPTIONAL, certPath CertPathControls OPTIONAL, exts [3] Extensions OPTIONAL } TrustAnchorInfoVersion ::= INTEGER { v1(1), v2(2), v3(3) } PublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, publicKey BIT STRING } KeyIdentifier ::= OCTET STRING 2.1. Version version identifies the version of TrustAnchorInfo. Where the exts field is present or the TrustAnchorType.apex option is used but the ApexTrustAnchorInfo.continPubKey is omitted, v3 MUST be used. In all other cases, v2 MAY be used. 2.2. Public Key pubKey identifies the public key and algorithm associated with the trust anchor using the PublicKeyInfo structure. The PublicKeyInfo structure contains the algorithm identifier followed by the public key itself. The algorithm field is an 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. For the apex trust anchor, this field contains the operational public key. 2.3. Key Identitifer keyId contains the public key identifier of the trust anchor public key. For the apex trust anchor, this field contains the public key identifier of the operational public key. Housley, et al. Expires April 9, 2009 [Page 6] Internet-Draft TAF October 2008 2.4. Trust Anchor Type TrustAnchorType ::= CHOICE { apex [0] ApexTrustAnchorInfo, mgmt [1] MgmtTrustAnchorInfo, ident [2] NULL } taType indicates the type of trust anchor, and it carries information specific to the type of trust anchor that is being represented. If an apex trust anchor is represented, then apex trust anchor information is carried using the ApexTrustAnchorInfo structure. If a management trust anchor is represented, then management trust anchor information is carried using the MgmtTrustAnchorInfo structure. If an identity trust anchor is represented, no additional information is carried. ApexTrustAnchorInfo ::= SEQUENCE { continPubKey ApexContingencyKey OPTIONAL, tampSeqNum SeqNumber OPTIONAL } ApexContingencyKey ::= SEQUENCE { wrapAlgorithm AlgorithmIdentifier, wrappedContinPubKey OCTET STRING } SeqNumber ::= INTEGER (0..9223372036854775807) The fields of ApexTrustAnchorInfo are used as follows: o continPubKey contains the optional encrypted apex trust anchor contingency public key using the ApexContingencyKey structure. o tampSeqNum is OPTIONAL. This field has been deprecated. TAMP [TAMP] provides sequence number propagation and processing details. The fields of ApexContingencyKey are used as follows: o wrapAlgorithm identifies the symmetric algorithm used to encrypt the apex trust anchor contingency public key. If this public key is ever needed, the symmetric key needed to decrypt it will be Housley, et al. Expires April 9, 2009 [Page 7] Internet-Draft TAF October 2008 provided in the message that is to be validated using it. The algorithm identifier is an AlgorithmIdentifier, which contains an object identifier and OPTIONAL parameters. The object identifier indicates the syntax of the parameters, if present. o wrappedContinPubKey is the encrypted apex trust anchor contingency public key. Once decrypted, it yields the PublicKeyInfo structure, which consists of the algorithm identifier followed by the public key itself. The algorithm identifier is an AlgorithmIdentifier that contains an object identifier and OPTIONAL parameters. The object identifier indicates the format of the public key and the syntax of the parameters, if present. The public key is encoded as a BIT STRING. MgmtTrustAnchorInfo ::= SEQUENCE { taUsage TrustAnchorUsage, tampSeqNum SeqNumber OPTIONAL } TrustAnchorUsage ::= CMSContentConstraints CMSContentConstraints ::= ContentTypeConstraintList ContentTypeConstraintList ::= SEQUENCE SIZE (1..MAX) OF ContentTypeConstraint ContentTypeConstraint ::= SEQUENCE { contentType ContentType, canSource BOOLEAN DEFAULT TRUE, attrConstraints AttrConstraintList OPTIONAL } ContentType ::= OBJECT IDENTIFIER AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint AttrConstraint ::= SEQUENCE { attrType AttributeType, attrValues SET SIZE (1..MAX) OF AttributeValue } The fields of MgmtTrustAnchorInfo are used as follows: o taUsage represents the authorized uses of the management trust anchor using the TrustAnchorUsage structure. Housley, et al. Expires April 9, 2009 [Page 8] Internet-Draft TAF October 2008 o tampSeqNum is OPTIONAL. This field has been deprecated. TAMP [TAMP] provides sequence number propagation and processing details. The TrustAnchorUsage is defined using the CMSContentConstraints type defined in [CCC], and repeated above. The CMSContentConstraints is a list of permitted content types and associated constraints. The management trust anchor can be used to validate digital signatures on the permitted content types, including TAMP message content types. The anyContentType object identifier can be used to indicate that the trust anchor is unconstrained. The apex trust anchor has an implicit CMSContentConstraints field with a single permitted content type of anyContentType. Where anyContentType is asserted or implied, canSource and attrConstraints MUST BE absent, indicating the trust anchor can serve as a source for any content type without any constraints. The fields of ContentTypeConstraint are used as follows: o contentType indicates the encapsulated content type identifier that can be validated using the management trust anchor. For example, it contains id-ct-firmwarePackage when the management trust anchor can be used to validate digital signatures on firmware packages [RFC4108]. A particular content type MUST NOT appear more than once in the list. The CMS-related content types need not be included in the list of permitted content types. These content types are always authorized to facilitate the use of CMS in the protection of content, and they MUST NOT appear in the contentType field. The always authorized content types are: * id-signedData, * id-envelopedData, * id-digestedData, * id-encryptedData, * id-ct-authEnvelopedData, * id-ct-authData, * id-ct-compressedData, * id-ct-contentCollection Housley, et al. Expires April 9, 2009 [Page 9] Internet-Draft TAF October 2008 * id-ct-contentWithAttrs. o canSource is a Boolean flag, and it applies to direct signatures or direct authentication for the specified content type. If the canSource flag is FALSE, then the management trust anchor cannot be used to directly sign or authenticate the specified content type. Regardless of the flag value, a management trust anchor can be used to sign or authenticate outer layers when multiple layers of CMS protected content type are present. o attrConstraints is an OPTIONAL field that contains a sequence of content type specific constraints. If the attrConstraints field is absent, then the management trust anchor can be used to verify the specified content type without any further checking. If the attrConstraints field is present, then the management trust anchor can only be used to verify the specified content type if all of the constraints for that content type are satisfied. Content type constraints are checked by matching the attribute values in the AttrConstraintList against the attribute value in the content. The constraints checking fails if the attribute is present and the attribute value is not one of the values provided in AttrConstraintList. The AttrConstraintList contains a sequence of attributes, which is defined in [CCC] and repeated above. The fields of AttrConstraint are used as follows: o attrType is the object identifier of the signed attribute carried in the SignerInfo of the content. For a signed content to satisfy the constraint, if the SignerInfo includes a signed attribute of the same type, then the signed attribute MUST contain one of the values supplied in the attrValues field. o attrValues provides one or more acceptable signed attribute values. It is a set of AttributeValue. For a signed content to satisfy the constraint, if the SignerInfo includes a signed attribute of the type identified in the attrType field, then the signed attribute MUST contain one of the values in the set. 2.5. Trust Anchor Title TrustAnchorTitle ::= UTF8String (SIZE (1..64)) taTitle is OPTIONAL. When it is present, it provides a human Housley, et al. Expires April 9, 2009 [Page 10] Internet-Draft TAF October 2008 readable name for the trust anchor. The text is encoded in UTF-8 [RFC3629], which accommodates most of the world's writing systems. 2.6. Certification Path Controls CertPathControls ::= SEQUENCE { taName Name, certificate [0] Certificate OPTIONAL, policySet [1] CertificatePolicies OPTIONAL, policyFlags [2] CertPolicyFlags OPTIONAL, clearanceConstr [3] AuthorityClearanceConstraints OPTIONAL, nameConstr [4] NameConstraints 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 in [RFC5280]). When absent, the trust anchor cannot be used to validate the signature on an X.509 certificate. For the apex trust anchor, this field contains the certification path controls associated with the operational public key. 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. An identity trust anchor is of little use without a distinguished name. Omission of the taName prevents the trust anchor from performing delegation using X.509 certificates. 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 distinguished name provided in the taName field. The complete description of the syntax and semantics of the Certificate are provided in [RFC5280]. Constraints defined in the taType, policySet, policyFlags, clearanceConstr, nameConstr and exts fields within TrustAnchorInfo augment or replace values contained in a certificate; values defined in these TrustAnchorInfo fields are always enforced. Extensions included in a certificate are enforced only if there is no value in the corresponding structure in the TrustAnchorInfo. Correspondence between extensions within a certificate and TrustAnchorInfo fields is defined as follows: Housley, et al. Expires April 9, 2009 [Page 11] Internet-Draft TAF October 2008 o id-pe-wrappedApexContinKey extensions correspond to the TrustAnchorType.apex field. o id-pe-cmsContentConstraints extensions correspond to the TrustAnchorType.mgmt field. o id-ce-certificatePolicies extensions correspond to the CertPathControls.policySet field. o id-ce-policyConstraints extensions correspond to the CertPolicyFlags.inhibitPolicyMapping and CertPolicyFlags.requireExplicitPolicy fields. o id-ce-inhibitAnyPolicy extensions correspond to the CertPolicyFlags.inhibitAnyPolicy field. o id-ce-authorityClearanceConstraints extensions correspond to the CertPathControls.clearanceConstr field. o id-ce-nameConstraints extensions correspond to the CertPathControls.nameConstr 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 sequence of certificate policy identifiers to be provided as inputs to the certification path validation algorithm. When absent, the special 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), Housley, et al. Expires April 9, 2009 [Page 12] Internet-Draft TAF October 2008 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. When set to TRUE, the special anyPolicy policy identifier is only considered a match for itself. This value represents the initial-any-policy-inhibit input value to the certification path validation algorithm described in section 6.1.1 of [RFC5280]. Housley, et al. Expires April 9, 2009 [Page 13] Internet-Draft TAF October 2008 AuthorityClearanceConstraints ::= SEQUENCE SIZE (1..MAX) OF Clearance Clearance ::= SEQUENCE { policyId [0] OBJECT IDENTIFIER, classList [1] ClassList DEFAULT {unclassified}, securityCategories [2] SET OF SecurityCategory OPTIONAL } ClassList ::= BIT STRING { unmarked (0), unclassified (1), restricted (2), confidential (3), secret (4), topSecret (5) } SecurityCategory ::= SEQUENCE { type [0] SECURITY-CATEGORY.&id({SecurityCategoriesTable}), value [1] EXPLICIT SECURITY-CATEGORY.&Type ({SecurityCategoriesTable}{@type}) } SECURITY-CATEGORY ::= TYPE-IDENTIFIER SecurityCategoriesTable SECURITY-CATEGORY ::= {...} clearanceConstr is OPTIONAL. It has the same syntax and semantics as the Authority Clearance Constraints certificate extension as specified in [ClearConstr]. When it is present, constraints are provided on the Authority Clearance Constraints certificate extension and Clearance certificate extension that might appear in subordinate X.509 certificates. For a subordinate certificate to be valid, it MUST conform to these constraints. When it is absent, no constraints are imposed on the Authority Clearance Constraints certificate extension and Clearance certificate extension that might appear in subordinate X.509 certificates. NameConstraints ::= SEQUENCE { permittedSubtrees [0] GeneralSubtrees OPTIONAL, excludedSubtrees [1] GeneralSubtrees OPTIONAL } GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree GeneralSubtree ::= SEQUENCE { base GeneralName, minimum [0] BaseDistance DEFAULT 0, Housley, et al. Expires April 9, 2009 [Page 14] Internet-Draft TAF October 2008 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 subordinate X.509 certificates. When applied to Certification Authority (CA) certificates, the CA can apply further constraints by including the Name Constraints certificate extension in subordinate certificates. For a subordinate certificate to be valid, it MUST conform to these constraints. When it is absent, no constraints are imposed on names that appear in subordinate X.509 certificates. 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 MUST 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 for any of the flags in the policyFlags; o Provide a subset of clearance values provided in the clearanceConstr; o Provide a subset of the permitted names provided in the nameConstr; o Provide additional excluded names to the ones that are provided in the nameConstr 2.7. 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 Housley, et al. Expires April 9, 2009 [Page 15] Internet-Draft TAF October 2008 duplication with the CertPathControls and TaType fields, the following types of extensions MUST NOT appear in the exts field and are ignored if they do appear: id-pe-apexTrustAnchorInfo, id-pe- cmsContentConstraints, id-ce-certificatePolicies, id-ce- policyConstraints, id-ce-inhibitAnyPolicy, id-ce- authorityClearanceConstraints or id-ce-nameConstraints. Housley, et al. Expires April 9, 2009 [Page 16] Internet-Draft TAF October 2008 3. Security Considerations Compromise of an identity trust anchor private key permits unauthorized parties to issue certificates that will be acceptable to all applications configured with the corresponding identity trust anchor. The unauthorized private key holder will be limited by the certification path controls associated with the identity trust anchor. For example, clearance constraints in the identity trust anchor will determine the clearances that will be accepted in certificates that are issued by the unauthorized private key holder. Compromise of a management trust anchor private key permits unauthorized parties to generate signed messages that will be acceptable to all applications that use a trust anchor store containing the corresponding management trust anchor. For example, if the management trust anchor is authorized to sign firmware packages, then the unauthorized private key holder can generate firmware that may be successfully installed and used by applications that trust the management trust anchor. Compromise of the Apex Trust Anchor operational private key permits unauthorized parties to generate signed messages that will be acceptable to all applications that use a trust anchor store containing the corresponding apex trust anchor. The unauthorized private key holder can generate signed messages of any content type that may be accepted and used by applications that trust the apex trust anchor. The contingency private key offers a potential way to recover from such a compromise. The compromise of a CA's private key leads to the same type of problems as the compromise of an identity or a management trust anchor private key. The unauthorized private key holder will be limited by the certification path controls associated with the trust anchor. If the CA is subordinate to a management trust anchor, the scope of potential damage caused by a private key compromise is also limited by the CMS content constraints certificate extension [CCC] in the CA certificate, the CMS content constraints on any superior CA certificates, and the CMS content constraints on the parent management trust anchor. The compromise of an end entity private key leads to the same type of problems as the compromise of an identity or a management trust anchor private key, except that the end entity is unable to issue any certificates. The unauthorized private key holder will be limited by the certification path controls associated with the trust anchor. If the certified public key is subordinate to a management trust anchor, the scope of potential damage caused by a private key compromise is also limited by the CMS content constraints certificate extension Housley, et al. Expires April 9, 2009 [Page 17] Internet-Draft TAF October 2008 [CCC] in the end entity certificate, the CMS content constraints on any superior CA certificates, and the CMS content constraints on the parent management trust anchor. Premature disclosure of the key-encryption key used to encrypt the apex trust anchor contingency public key may result in early exposure of the apex trust anchor contingency public key. 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. Housley, et al. Expires April 9, 2009 [Page 18] Internet-Draft TAF October 2008 4. IANA Considerations There are no IANA considerations. Please delete this section prior to RFC publication. Housley, et al. Expires April 9, 2009 [Page 19] Internet-Draft TAF October 2008 5. References 5.1. Normative References [CCC] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic Message Syntax (CMS) Content Constraints X.509 Certificate Extension", draft-ietf-pkix-cms-content-constraints-00 (work in progress). [ClearConstr] Turner, S. and S. Chokhani, "Clearance Attribute and Authority Clearance Constraints Certificate Extension", draft-turner-caclearanceconstraints-02.txt (work in progress), work in progress. [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. [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. [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. [X.680] "ITU-T Recommendation X.680: Information Technology - Abstract Syntax Notation One", 1997. 5.2. Informative References [I-D.draft-ietf-pkix-ta-mgmt-reqs] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", draft-ietf-pkix-ta-mgmt-reqs-01 (work in progress). [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005. [TAMP] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", draft-ietf-pkix-tamp-00 (work in progress). [X.509] "ITU-T Recommendation X.509 - The Directory - Authentication Framework", 2000. Housley, et al. Expires April 9, 2009 [Page 20] Internet-Draft TAF October 2008 Appendix A. ASN.1 Modules Appendix A.1 provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680]. A.1. ASN.1 Module TrustAnchorInfo { joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) modules(0) 33 } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS ContentType FROM CryptographicMessageSyntax2004 -- [RFC3852] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } AlgorithmIdentifier, Certificate, Name, Extensions FROM PKIX1Explicit88 -- from [RFC5280] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 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) } CMSContentConstraints FROM CMSContentConstraintsCertExtn-93 -- [CCC] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) cmsContentConstraints-93(42) } AuthorityClearanceConstraints FROM Clearance-AuthorityClearanceConstraints93 -- from [ClearConstr] { joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) modules(0) 32 } ; -- Trust Anchor Information TrustAnchorInfo ::= SEQUENCE { version [0] TrustAnchorInfoVersion DEFAULT v2, pubKey PublicKeyInfo, Housley, et al. Expires April 9, 2009 [Page 21] Internet-Draft TAF October 2008 keyId KeyIdentifier, taType TrustAnchorType, taTitle TrustAnchorTitle OPTIONAL, certPath CertPathControls OPTIONAL, exts [3] Extensions OPTIONAL } TrustAnchorInfoVersion ::= INTEGER { v1(1), v2(2), v3(3) } PublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, publicKey BIT STRING } KeyIdentifier ::= OCTET STRING TrustAnchorType ::= CHOICE { apex [0] ApexTrustAnchorInfo, mgmt [1] MgmtTrustAnchorInfo, ident [2] NULL } ApexTrustAnchorInfo ::= SEQUENCE { continPubKey ApexContingencyKey OPTIONAL, tampSeqNum SeqNumber OPTIONAL } ApexContingencyKey ::= SEQUENCE { wrapAlgorithm AlgorithmIdentifier, wrappedContinPubKey OCTET STRING } SeqNumber ::= INTEGER (0..9223372036854775807) MgmtTrustAnchorInfo ::= SEQUENCE { taUsage TrustAnchorUsage, tampSeqNum SeqNumber OPTIONAL } TrustAnchorUsage ::= CMSContentConstraints CMSContentConstraints ::= ContentTypeConstraintList ContentTypeConstraintList ::= SEQUENCE SIZE (1..MAX) OF ContentTypeConstraint ContentTypeConstraint ::= SEQUENCE { contentType ContentType, canSource BOOLEAN DEFAULT TRUE, attrConstraints AttrConstraintList OPTIONAL } AttrConstraintList ::= SEQUENCE SIZE (1..MAX) OF AttrConstraint AttrConstraint ::= SEQUENCE { Housley, et al. Expires April 9, 2009 [Page 22] Internet-Draft TAF October 2008 attrType AttributeType, attrValues SET SIZE (1..MAX) OF AttributeValue } ContentType ::= OBJECT IDENTIFIER TrustAnchorTitle ::= UTF8String (SIZE (1..64)) CertPathControls ::= SEQUENCE { taName Name, certificate [0] Certificate OPTIONAL, policySet [1] CertificatePolicies OPTIONAL, policyFlags [2] CertPolicyFlags OPTIONAL, clearanceConstr [3] AuthorityClearanceConstraints OPTIONAL, nameConstr [4] NameConstraints OPTIONAL } CertPolicyFlags ::= BIT STRING { inhibitPolicyMapping (0), requireExplicitPolicy (1), inhibitAnyPolicy (2) } END Housley, et al. Expires April 9, 2009 [Page 23] Internet-Draft TAF October 2008 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 5200 7925 Jones Branch Drive McLean, VA 22102 Email: cwallace@cygnacom.com Housley, et al. Expires April 9, 2009 [Page 24] Internet-Draft TAF October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Housley, et al. Expires April 9, 2009 [Page 25]