Technical Summary
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.
Working Group Summary
This document is an individual submission. It describes the usage of
constraints represented using the Trust Anchor Format (TAF).
Document Quality
The document is well-written and clear. It has been implemented as part
of an open source library (though not all components have been released at
this time).
Personnel
Geoff Beier is the Document Shepherd for this document. Tim Polk
is the Responsible Area Director.
RFC Editor Note
In Section 1, Introduction, please make the following substitution:
OLD
[RFC5280]
describes how to validate a certification path, including the usage
of a trust anchor name and public key. This document describes how
to use other trust anchor information during certification path
processing.
NEW
[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 in RFC 5280).
This document defines a mechanism to identify constraints that should
be enforced and the supplementary processing rule. 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.
In Section 5, Security Considerations, please make the following
substitution:
OLD
Implementations that enforce trust anchor constraints may reject some
certification paths accepted by implementations that do not enforce
trust anchor constraints.
Trust anchor information must be securely stored. Changes to trust
anchor information can cause acceptance of certificates that should
be rejected.
NEW
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.
[I-D.draft-ietf-pkix-ta-format] and [I-D.draft-ietf-pkix-tamp]
provide additional security considerations regarding the preparation,
storage and usage of trust anchors. [RFC5280] provides additional
security considerations regarding the usage of name constraints.
In Section 7, please make the following reference normative. That is,
please move it from 7.2 Informational References to 7.1 Normative
Reference.
[I-D.draft-ietf-pkix-ta-format]
Housley, R., Wallace, C., and S. Ashmore, "Trust Anchor
Format", draft-ietf-pkix-ta-format (work in progress).