Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5937

Using Trust Anchor Constraints during Certification Path Processing

Pages: 8
Informational

Top   ToC   RFC5937 - Page 1
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.
Top   ToC   RFC5937 - Page 2
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
Top   ToC   RFC5937 - Page 3

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
Top   ToC   RFC5937 - Page 4
   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
Top   ToC   RFC5937 - Page 5
      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.
Top   ToC   RFC5937 - Page 6

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.
Top   ToC   RFC5937 - Page 7

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.
Top   ToC   RFC5937 - Page 8

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