Using Trust Anchor Constraints during Certification Path Processing
How to enforce limits on what a trusted certificate signer can certify
Ashmore, S. and C. Wallace, "Using Trust Anchor Constraints during Certification Path Processing", RFC 5937, DOI 10.17487/RFC5937, August 2010, <https://www.rfc-editor.org/info/rfc5937>.
@misc{rfc5937,
series = {Request for Comments},
number = 5937,
howpublished = {RFC 5937},
publisher = {RFC Editor},
doi = {10.17487/RFC5937},
url = {https://www.rfc-editor.org/info/rfc5937},
author = {S. Ashmore and C. Wallace},
title = {{Using Trust Anchor Constraints during Certification Path Processing}},
pagetotal = 8,
year = 2010,
month = aug,
} RFC text
Contents
Internet Engineering Task Force (IETF) S. Ashmore
Request for Comments: 5937 National Security Agency
Category: Informational C. Wallace
ISSN: 2070-1721 Cygnacom Solutions
August 2010
Using Trust Anchor Constraints during Certification Path Processing
Abstract
This document describes how to use information associated with a
trust anchor public key when validating certification paths. This
information can be used to constrain the usage of a trust anchor.
Typically, constraints are used to limit the certificate policies and
names that can appear in certification paths validated using a trust
anchor.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
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). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see 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/rfc5937.
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. Identifying Trust Anchor Constraints ............................3
3. Using Trust Anchor Constraints during Certification Path
Processing ......................................................4
3.1. Inputs .....................................................4
3.2. Initialization .............................................4
3.3. Basic Certificate Processing ...............................6
3.4. Preparation for Certificate i+1 ............................6
3.5. Wrap-Up Procedure ..........................................6
4. Relationship to RFC 5280 ........................................6
5. Security Considerations .........................................7
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
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. The Trust Anchor Format (TAF)
specification [RFC5914] defines a means for limiting the scope in
which a trust anchor may be used. [RFC5280] describes how to
validate a certification path. The algorithm requires processing the
name and key from a trust anchor. Usage of other information,
including enforcement of constraints, is permitted but not required,
and the processing rules are not specified (see Section 6.2 of
RFC 5280).
This document defines a mechanism to identify constraints that should
be enforced and the supplementary processing rules. The
supplementary rules specify an additional input and extend the
initialization procedures in the [RFC5280] path validation algorithm.
Post-initialization processing steps are not affected.
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. Identifying Trust Anchor Constraints
TAF supports three formats for representing trust anchor information:
TrustAnchorInfo, Certificate, and TBSCertificate. In all three
cases, trust anchor constraints may be represented as extensions. In
the TrustAnchorInfo structure, certificate policies, policy
constraints, name constraints, inhibit any policy, and basic
constraints do not appear as extensions and instead appear as part of
the CertPathControls field.
Extensions may be marked critical or not critical. When trust anchor
constraints are enforced, clients MUST reject certification paths
containing a trust anchor with unrecognized critical extensions.
When trust anchor constraints are not enforced, clients MAY accept
certification paths containing a trust anchor with unrecognized
critical extensions. Information appearing in the CertPathControls
field of a TrustAnchorInfo object MUST be processed, ensuring
enforcement of the constraints indicated by this field in all cases.
For some types of trust anchor constraints, there is a type mismatch
between the input parameters for the certification path validation
algorithm and the extension that contains the constraint. The
certification path validation algorithm essentially defines the
initial-any-policy-inhibit, initial-policy-mapping-inhibit, and
initial-explicit-policy as Boolean values. The inhibitAnyPolicy and
policyConstraints extensions that correspond to these inputs are
expressed as integer values. In the steps described below, presence
of an inhibitAnyPolicy extension results in the initial-any-policy-
inhibit value being set to true. If a policyConstraints extension is
present and contains a requireExplicitPolicy field, the initial-
explicit-policy value is set to true. If a policyConstraints
extension is present and contains an inhibitPolicyMapping field, the
initial-policy-mapping-inhibit value is set to true.
3. Using Trust Anchor Constraints during Certification Path Processing
3.1. Inputs
This algorithm assumes that the nine inputs defined in Section 6.1.1
of RFC 5280 are provided to the path processing logic, plus one
additional variable:
o enforceTrustAnchorConstraints: indicates if trust anchor
constraints should be enforced
Conforming implementations are not required to support the setting of
the enforceTrustAnchorConstraints input. If a conforming
implementation does not support the setting of this flag, it MUST
validate all certification paths using a value of TRUE for
enforceTrustAnchorConstraints.
3.2. Initialization
If enforceTrustAnchorConstraints is false, no additional
initialization steps are required.
If enforceTrustAnchorConstraints is true, perform the following
initialization steps described below. These steps (or equivalent)
MUST be performed prior to initialization steps described in
RFC 5280.
o If no subject distinguished name is associated with the trust
anchor, path validation fails. The name may appear in the subject
field of a Certificate or TBSCertificate structure or in the
taName field of CertPathControls in a TrustAnchorInfo structure.
o If name constraints are associated with the trust anchor, set the
initial-permitted-subtrees variable equal to the intersection of
the permitted subtrees from the trust anchor and the user-provided
initial-permitted-subtrees. If one of these two inputs is not
provided, the initial-permitted-subtrees variable is set to the
value that is available. If neither is provided, the initial-
permitted-subtrees variable is set to an infinite set.
o If name constraints are associated with the trust anchor, set the
initial-excluded-subtrees variable equal to the union of the
excluded subtrees from the trust anchor and the user-provided
initial-excluded-subtrees. If one of these two inputs is not
provided, the initial-excluded-subtrees variable is set to the
value that is available. If neither is provided, the initial-
excluded-subtrees variable is set to an empty set.
o If certificate policies are associated with the trust anchor, set
the user-initial-policy-set variable equal to the intersection of
the certificate policies associated with the trust anchor and the
user-provided user-initial-policy-set. If one of these two inputs
is not provided, the user-initial-policy-set variable is set to
the value that is available. If neither is provided, the
user-initial-policy-set variable is set to any-policy.
o If an inhibit any policy value of true is associated with the
trust anchor (either in a CertPathControls or in an
inhibitAnyPolicy extension) and the initial-any-policy-inhibit
value is false, set the initial-any-policy-inhibit value to true.
o If a require explicit policy value of true is associated with the
trust anchor (either in a CertPathControls or in a
PolicyConstraints extension) and the initial-explicit-policy value
is false, set the initial-explicit-policy value to true.
o If an inhibit policy mapping value of true is associated with the
trust anchor (either in a CertPathControls or in a
PolicyConstraints extension) and the initial-policy-mapping-
inhibit value is false, set the initial-policy-mapping-inhibit
value to true.
o If a basic constraints extension is associated with the trust
anchor and contains a pathLenConstraint value, set the
max_path_length state variable equal to the pathLenConstraint
value from the basic constraints extension.
3.3. Basic Certificate Processing
This document does not require any augmentation of the basic
certificate processing steps described in Section 6.1.3 of RFC 5280.
However, some types of trust anchor constraints may have defined
additional steps, for example, CMS Content Constraints or Authority
Clearance Constraints.
3.4. Preparation for Certificate i+1
This document does not require any augmentation of the steps to
prepare for processing of certificate i+1 described in Section 6.1.4
of RFC 5280. However, some types of trust anchor constraints may
have defined additional steps, for example, CMS Content Constraints
or Authority Clearance Constraints.
3.5. Wrap-Up Procedure
This document does not require any augmentation of the wrap-up
procedure steps described in Section 6.1.5 of RFC 5280. However,
some types of trust anchor constraints may have defined additional
steps, for example, CMS Content Constraints or Authority Clearance
Constraints.
4. Relationship to RFC 5280
The processing described above can be incorporated into an RFC 5280
implementation or be implemented as pre-processing of RFC 5280 inputs
and post-processing of RFC 5280 outputs, i.e., as a wrapper around an
RFC 5280 compliant implementation.
For name constraints and policy-related constraints, pre-processing
can be used, provided the RFC 5280 implementation allows
configuration of the user-initial-policy-set, initial-policy-mapping-
inhibit, initial-explicit-policy, initial-any-policy-inhibit,
initial-permitted-subtrees, and initial-excluded-subtrees input
values. RFC 5280 does not define an input for path length
constraints, so basic constraints cannot be implemented using
pre-processing. It can be implemented as post-processing, provided
the RFC 5280 implementation returns the certification path to enable
the post-processor to perform the length check.
Some types of trust anchor constraints may impose additional
requirements on an RFC 5280 implementation to support pre-processing
or post-processing to enforce trust anchor constraints.
5. Security Considerations
Implementations that do not enforce trust anchor constraints may
accept some certification paths rejected by implementations that do
enforce trust anchor constraints. For example, an application that
does not enforce a certificate policy constraint included in a trust
anchor may accept certificates issued under a certificate policy that
provides a lower-than-required-level of assurance.
Trust anchor information must be securely stored. Changes to trust
anchor information can cause acceptance of certificates that should
be rejected. For example, if a trust anchor definition is altered to
remove a name constraint, applications may accept certificates
containing names that should only be trusted in certificates that
validate to a different trust anchor. Similarly, addition of
inappropriate trust anchors to a trust anchor store can result in
validation of certificates to a different trust anchor and with
different constraints than intended.
[RFC5914] and [RFC5934] provide additional security considerations
regarding the preparation, storage, and usage of trust anchors.
[RFC5280] provides additional security considerations regarding the
usage of name constraints.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
Format", RFC 5914, June 2010.
6.2. Informative References
[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
Management Protocol (TAMP)", RFC 5934, August 2010.
[X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005,
Information technology - Open Systems Interconnection -
The Directory: Public-key and attribute certificate
frameworks.
Authors' Addresses
Sam Ashmore
National Security Agency
Suite 6751
9800 Savage Road
Fort Meade, MD 20755
USA
EMail: srashmo@radium.ncsc.mil
Carl Wallace
Cygnacom Solutions
Suite 5400
7925 Jones Branch Drive
McLean, VA 22102
USA
EMail: cwallace@cygnacom.com
AI ELI5
On this page
§1Introduction to Trust Anchor Constraints
Trust anchors are the root certificates that applications use to verify certification paths. RFC 5280 defines how to validate a chain of certificates but permits (but does not require) implementations to enforce constraints attached to a trust anchor. This document specifies exactly how to do that enforcement.
A trust anchor constraint limits what certificates the trust anchor can issue or endorse. For example, a trust anchor might be allowed to certify only certain names or only certificates under specific policies. Without consistent rules, different applications may enforce constraints differently, creating security risks or interoperability problems.
A trusted person can be trusted for some things but not others. This explains the clear rules for what a trusted signer is allowed to do.
§2Identifying Trust Anchor Constraints
The Trust Anchor Format (RFC 5914) can represent trust anchors in three ways: as a TrustAnchorInfo structure, as a complete certificate, or as just the certificate data (TBSCertificate). All three can carry constraints using standard X.509 certificate extensions.
Constraints appear as extensions like certificate policies, policy constraints, name constraints, and basic constraints. In the TrustAnchorInfo structure, some constraints (such as certificate policies and name constraints) appear in a special CertPathControls field instead of as extensions. When processing a trust anchor, implementations MUST enforce any constraints marked critical and MAY accept those marked non-critical if recognized.
The limits are stored in special data fields attached to the trusted signer. Some limits are marked as very important and must never be ignored.
§3Using Constraints During Path Validation
RFC 5280 defines a path validation algorithm with inputs like initial permitted names, certificate policies, and other values. This RFC specifies how to initialize those inputs from the trust anchor's constraints.
If a trust anchor has name constraints, the permitted and excluded name ranges from the anchor are intersected or unioned with any user-provided ranges. If the trust anchor specifies allowed certificate policies, those are intersected with the user-supplied policies. Boolean flags like inhibit-any-policy are activated if present in the trust anchor. A path length constraint from the trust anchor sets the maximum depth of the certified chain.
These initialization steps must occur before the main RFC 5280 validation algorithm runs. After initialization, the standard algorithm proceeds without modification.
Before checking a chain of certificates, the algorithm starts with the limits from the trusted signer, then applies the normal checking rules.
§4Implementation Approaches
The constraint initialization can be done in two ways. One approach is to integrate it directly into an RFC 5280 implementation, modifying the initialization steps. The other is to implement it as a preprocessing wrapper that adjusts the inputs to an existing RFC 5280 implementation.
For constraints on names and policies, preprocessing is straightforward because RFC 5280 accepts configurable initial values. However, the basic constraints path-length limit cannot be preprocessed since RFC 5280 does not expose a corresponding input parameter. It must instead be validated as post-processing by checking the returned path length.
Some constraint types (such as CMS Content Constraints) may require additional implementation work beyond what this document specifies.
The limits can be checked before or after the main algorithm, as long as the final result respects all the limits.
§5Security Considerations
Applications that do not enforce trust anchor constraints may accept certificates rejected by implementations that do enforce them. For example, an application ignoring a certificate-policy constraint on a trust anchor might accept a certificate under a lower-assurance policy than intended. This is a security weakness that undermines the purpose of the constraints.
Trust anchor information must be securely stored. Modifying a trust anchor to remove constraints could cause the application to accept certificates that should be rejected. Adding unauthorized trust anchors could cause unexpected validation results. The Trust Anchor Format specification (RFC 5914) and the Trust Anchor Management Protocol (RFC 5934) provide additional guidance on secure management of trust anchors.
If you ignore the limits on a trusted signer, you might accidentally trust something you shouldn't. Keeping the trust information safe is very important.