Using Trust Anchor Constraints During Certification Path Processing
draft-wallace-using-ta-constraints-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on October 5, 2009.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

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.

Table of Contents

1.  Introduction
    1.1.  Terminology
2.  Identifying trust anchor constraints
3.  Using trust anchor constraints during certification path processing
    3.1.  Inputs
    3.2.  Initialization
    3.3.  Basic Certificate Processing
    3.4.  Preparation for Certificate i+1
    3.5.  Wrap-up procedure
4.  Relationship to RFC 5280
5.  Security Considerations
6.  IANA Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses

1.  Introduction

Trust anchors are widely used to verify digital signatures and validate certification paths [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,” May 2008.)[X.509] (, “ITU-T Recommendation X.509 - The Directory - Authentication Framework,” 2000.). They are required when validating certification paths. The Trust Anchor Format (TAF) specification [I‑D.draft‑ietf‑pkix‑ta‑format] (Housley, R., Wallace, C., and S. Ashmore, “Trust Anchor Format,” .) defines means for limiting the scope in which a trust anchor may used. [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,” May 2008.) 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.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Identifying trust anchor constraints

TAF supports three formats for representating 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 and name 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 a 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 the nine inputs defined in RFC 5280 are provided to the path processing logic plus one additional variable:

• 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 intialization steps described below. These steps (or equivalent) MUST be performed prior to initialization steps described in RFC 5280.

• 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.
• 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.
• 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.
• 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.
• 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 to true.
• 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 to true.
• 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 to true.
• 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 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 basic certificate processing steps described in 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 basic certificate processing steps described in 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 can not be implemented using pre-preprocessing. 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-preprocessing or post-processing to enforce trust anchor constraints.

5.  Security Considerations

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.

6.  IANA Considerations

There are no IANA considerations. Please delete this section prior to RFC publication.

7.  References

7.1. Normative References

7.2. Informative References

Authors' Addresses