summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5937.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5937.txt')
-rw-r--r--doc/rfc/rfc5937.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc5937.txt b/doc/rfc/rfc5937.txt
new file mode 100644
index 0000000..0cba090
--- /dev/null
+++ b/doc/rfc/rfc5937.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ashmore & Wallace Informational [Page 1]
+
+RFC 5937 Using Trust Anchor Constraints August 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
+ 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
+
+
+
+
+
+
+
+Ashmore & Wallace Informational [Page 2]
+
+RFC 5937 Using Trust Anchor Constraints August 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 [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
+
+
+
+Ashmore & Wallace Informational [Page 3]
+
+RFC 5937 Using Trust Anchor Constraints August 2010
+
+
+ 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
+
+
+
+
+
+Ashmore & Wallace Informational [Page 4]
+
+RFC 5937 Using Trust Anchor Constraints August 2010
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Ashmore & Wallace Informational [Page 5]
+
+RFC 5937 Using Trust Anchor Constraints August 2010
+
+
+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.
+
+
+
+
+
+
+Ashmore & Wallace Informational [Page 6]
+
+RFC 5937 Using Trust Anchor Constraints August 2010
+
+
+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.
+
+
+
+Ashmore & Wallace Informational [Page 7]
+
+RFC 5937 Using Trust Anchor Constraints August 2010
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ashmore & Wallace Informational [Page 8]
+