doc: Add RFC documents

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