The IESG has approved the following document: - 'Using Trust Anchor Constraints During Certification Path Processing ' <draft-wallace-using-ta-constraints-02.txt> as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wallace-using-ta-constraints-02.txt 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). _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
