Subject: Document Action: 'Using Trust Anchor Constraints During Certification Path Processing' to Informational RFC

From: The IESG <[email-masked]>
Date: Mon, 26 Apr 2010 12:16:07 -0700 (PDT)

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).