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]
