Using Trust Anchor Constraints during Certification Path Processing
draft-wallace-using-ta-constraints-02

Network Working Group                                         S. Ashmore
Internet-Draft                                  National Security Agency
Intended status: Informational                                C. Wallace
Expires: September 4, 2010                            Cygnacom Solutions
                                                           March 3, 2010

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

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

   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 September 4, 2010.

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

Ashmore & Wallace       Expires September 4, 2010               [Page 1]
Internet-Draft       Using Trust Anchor Constraints           March 2010

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

Ashmore & Wallace       Expires September 4, 2010               [Page 2]
Internet-Draft       Using Trust Anchor Constraints           March 2010

Table of Contents

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

Ashmore & Wallace       Expires September 4, 2010               [Page 3]
Internet-Draft       Using Trust Anchor Constraints           March 2010

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 [I-D.draft-ietf-pkix-ta-format] defines means for
   limiting the scope in which a trust anchor may be used.  [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.

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

Ashmore & Wallace       Expires September 4, 2010               [Page 4]
Internet-Draft       Using Trust Anchor Constraints           March 2010

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

Ashmore & Wallace       Expires September 4, 2010               [Page 5]
Internet-Draft       Using Trust Anchor Constraints           March 2010

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:

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

Ashmore & Wallace       Expires September 4, 2010               [Page 6]
Internet-Draft       Using Trust Anchor Constraints           March 2010

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

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.

Ashmore & Wallace       Expires September 4, 2010               [Page 7]
Internet-Draft       Using Trust Anchor Constraints           March 2010

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.

Ashmore & Wallace       Expires September 4, 2010               [Page 8]
Internet-Draft       Using Trust Anchor Constraints           March 2010

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.

Ashmore & Wallace       Expires September 4, 2010               [Page 9]
Internet-Draft       Using Trust Anchor Constraints           March 2010

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.

Ashmore & Wallace       Expires September 4, 2010              [Page 10]
Internet-Draft       Using Trust Anchor Constraints           March 2010

6.  IANA Considerations

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

Ashmore & Wallace       Expires September 4, 2010              [Page 11]
Internet-Draft       Using Trust Anchor Constraints           March 2010

7.  References

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

7.2.  Informative References

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

   [X.509]    "ITU-T Recommendation X.509 - The Directory -
              Authentication Framework", 2000.

Ashmore & Wallace       Expires September 4, 2010              [Page 12]
Internet-Draft       Using Trust Anchor Constraints           March 2010

Authors' Addresses

   Sam Ashmore
   National Security Agency
   Suite 6751
   9800 Savage Road
   Fort Meade, MD  20755

   Email: srashmo@radium.ncsc.mil

   Carl Wallace
   Cygnacom Solutions
   Suite 5200
   7925 Jones Branch Drive
   McLean, VA  22102

   Email: cwallace@cygnacom.com

Ashmore & Wallace       Expires September 4, 2010              [Page 13]