idnits 2.17.1 draft-wallace-using-ta-constraints-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2010) is 5166 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Ashmore 3 Internet-Draft National Security Agency 4 Intended status: Informational C. Wallace 5 Expires: September 4, 2010 Cygnacom Solutions 6 March 3, 2010 8 Using Trust Anchor Constraints During Certification Path Processing 9 draft-wallace-using-ta-constraints-02 11 Abstract 13 This document describes how to use information associated with a 14 trust anchor public key when validating certification paths. This 15 information can be used to constrain the usage of a trust anchor. 16 Typically, constraints are used to limit the certificate policies and 17 names that can appear in certification paths validated using a trust 18 anchor. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 4, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Identifying trust anchor constraints . . . . . . . . . . . . . 5 75 3. Using trust anchor constraints during certification path 76 processing . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 3.2. Initialization . . . . . . . . . . . . . . . . . . . . . . 6 79 3.3. Basic Certificate Processing . . . . . . . . . . . . . . . 7 80 3.4. Preparation for Certificate i+1 . . . . . . . . . . . . . 7 81 3.5. Wrap-up procedure . . . . . . . . . . . . . . . . . . . . 8 82 4. Relationship to RFC 5280 . . . . . . . . . . . . . . . . . . . 9 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 87 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 Trust anchors are widely used to verify digital signatures and 93 validate certification paths [RFC5280][X.509]. They are required 94 when validating certification paths. The Trust Anchor Format (TAF) 95 specification [I-D.draft-ietf-pkix-ta-format] defines means for 96 limiting the scope in which a trust anchor may be used. [RFC5280] 97 describes how to validate a certification path, including the usage 98 of a trust anchor name and public key. This document describes how 99 to use other trust anchor information during certification path 100 processing. 102 1.1. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. Identifying trust anchor constraints 110 TAF supports three formats for representating trust anchor 111 information: TrustAnchorInfo, Certificate and TBSCertificate. In all 112 three cases, trust anchor constraints may be represented as 113 extensions. In the TrustAnchorInfo structure, certificate policies, 114 policy constraints, name constraints, inhibit any policy and basic 115 constraints do not appear as extensions and instead appear as part of 116 the CertPathControls field. 118 Extensions may be marked critical or not critical. When trust anchor 119 constraints are enforced, clients MUST reject certification paths 120 containing a trust anchor with unrecognized critical extensions. 121 When trust anchor constraints are not enforced, clients MAY accept 122 certification paths containing a trust anchor with unrecognized 123 critical extensions. Information appearing in the CertPathControls 124 field of a TrustAnchorInfo object MUST be processed, ensuring 125 enforcement of the constraints indicated by this field in all cases. 127 For some types of trust anchor constraints there is a type mismatch 128 between the input parameters for the certification path validation 129 algorithm and the extension that contains the constraint. The 130 certification path validation algorithm essentially defines the 131 initial-any-policy-inhibit, initial-policy-mapping-inhibit and 132 initial-explicit-policy as boolean values. The inhibitAnyPolicy and 133 policyConstraints extensions that correspond to these inputs are 134 expressed as integer values. In the steps described below, presence 135 of an inhibitAnyPolicy extension results in the initial-any-policy- 136 inhibit value being set to true. If a policyConstraints extension is 137 present and contains a requireExplicitPolicy field, the initial- 138 explicit-policy value is set to true. If a policyConstraints 139 extension is present and contains a inhibitPolicyMapping field, the 140 initial-policy-mapping-inhibit value is set to true. 142 3. Using trust anchor constraints during certification path processing 144 3.1. Inputs 146 This algorithm assumes the nine inputs defined in RFC 5280 are 147 provided to the path processing logic plus one additional variable: 149 o enforceTrustAnchorConstraints: indicates if trust anchor 150 constraints should be enforced 152 Conforming implementations are not required to support the setting of 153 the enforceTrustAnchorConstraints input. If a conforming 154 implementation does not support the setting of this flag, it MUST 155 validate all certification paths using a value of TRUE for 156 enforceTrustAnchorConstraints. 158 3.2. Initialization 160 If enforceTrustAnchorConstraints is false, no additional 161 initialization steps are required. 163 If enforceTrustAnchorConstraints is true, perform the following 164 intialization steps described below. These steps (or equivalent) 165 MUST be performed prior to initialization steps described in RFC 166 5280. 168 o If no subject distinguished name is associated with the trust 169 anchor, path validation fails. The name may appear in the subject 170 field of a Certificate or TBSCertificate structure or in the 171 taName field of CertPathControls in a TrustAnchorInfo structure. 173 o If name constraints are associated with the trust anchor, set the 174 initial-permitted-subtrees variable equal to the intersection of 175 the permitted subtrees from the trust anchor and the user provided 176 initial-permitted-subtrees. If one of these two inputs is not 177 provided, the initial-permitted-subtrees variable is set to the 178 value that is available. If neither is provided, the initial- 179 permitted-subtrees variable is set to an infinite set. 181 o If name constraints are associated with the trust anchor, set the 182 initial-excluded-subtrees variable equal to the union of the 183 excluded subtrees from the trust anchor and the user provided 184 initial-excluded-subtrees. If one of these two inputs is not 185 provided, the initial-excluded-subtrees variable is set to the 186 value that is available. If neither is provided, the initial- 187 excluded-subtrees variable is set to an empty set. 189 o If certificate policies are associated with the trust anchor, set 190 the user-initial-policy-set variable equal to the intersection of 191 the certificate policies associated with the trust anchor and the 192 user provided user-initial-policy-set. If one of these two inputs 193 is not provided, the user-initial-policy-set variable is set to 194 the value that is available. If neither is provided, the user- 195 initial-policy-set variable is set to any-policy. 197 o If an inhibit any policy value of true is associated with the 198 trust anchor (either in a CertPathControls or in an 199 InhibitAnyPolicy extension) and the initial-any-policy-inhibit 200 value is false, set the initial-any-policy-inhibit to true. 202 o If a require explicit policy value of true is associated with the 203 trust anchor (either in a CertPathControls or in a 204 PolicyConstraints extension) and the initial-explicit-policy value 205 is false, set the initial-explicit-policy to true. 207 o If an inhibit policy mapping value of true is associated with the 208 trust anchor (either in a CertPathControls or in a 209 PolicyConstraints extension) and the initial-policy-mapping- 210 inhibit value is false, set the initial-policy-mapping-inhibit to 211 true. 213 o If a basic constraints extension is associated with the trust 214 anchor and contains a pathLenConstraint value, set the 215 max_path_length state variable equal to the pathLenConstraint 216 value from the basic constraints extension. 218 3.3. Basic Certificate Processing 220 This document does not require any augmentation of the basic 221 certificate processing steps described in RFC 5280. However, some 222 types of trust anchor constraints may have defined additional steps, 223 for example, CMS Content Constraints or Authority Clearance 224 Constraints. 226 3.4. Preparation for Certificate i+1 228 This document does not require any augmentation of the basic 229 certificate processing steps described in RFC 5280. However, some 230 types of trust anchor constraints may have defined additional steps, 231 for example, CMS Content Constraints or Authority Clearance 232 Constraints. 234 3.5. Wrap-up procedure 236 This document does not require any augmentation of the basic 237 certificate processing steps described in RFC 5280. However, some 238 types of trust anchor constraints may have defined additional steps, 239 for example, CMS Content Constraints or Authority Clearance 240 Constraints. 242 4. Relationship to RFC 5280 244 The processing described above can be incorporated into an RFC 5280 245 implementation or be implemented as pre-processing of RFC 5280 inputs 246 and post-processing of RFC 5280 outputs, i.e., as a wrapper around an 247 RFC 5280 compliant implementation. 249 For name constraints and policy-related constraints, pre-processing 250 can be used, provided the RFC 5280 implementation allows 251 configuration of the user-initial-policy-set, initial-policy-mapping- 252 inhibit, initial-explicit-policy, initial-any-policy-inhibit, 253 initial-permitted-subtrees and initial-excluded-subtrees input 254 values. RFC 5280 does not define an input for path length 255 constraints, so basic constraints can not be implemented using pre- 256 preprocessing. It can be implemented as post-processing, provided 257 the RFC 5280 implementation returns the certification path to enable 258 the post-processor to perform the length check. 260 Some types of trust anchor constraints may impose additional 261 requirements on an RFC 5280 implementation to support pre- 262 preprocessing or post-processing to enforce trust anchor constraints. 264 5. Security Considerations 266 Implementations that enforce trust anchor constraints may reject some 267 certification paths accepted by implementations that do not enforce 268 trust anchor constraints. 270 Trust anchor information must be securely stored. Changes to trust 271 anchor information can cause acceptance of certificates that should 272 be rejected. 274 6. IANA Considerations 276 There are no IANA considerations. Please delete this section prior 277 to RFC publication. 279 7. References 281 7.1. Normative References 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, March 1997. 286 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 287 Housley, R., and W. Polk, "Internet X.509 Public Key 288 Infrastructure Certificate and Certificate Revocation List 289 (CRL) Profile", RFC 5280, May 2008. 291 7.2. Informative References 293 [I-D.draft-ietf-pkix-ta-format] 294 Housley, R., Wallace, C., and S. Ashmore, "Trust Anchor 295 Format", draft-ietf-pkix-ta-format (work in progress). 297 [X.509] "ITU-T Recommendation X.509 - The Directory - 298 Authentication Framework", 2000. 300 Authors' Addresses 302 Sam Ashmore 303 National Security Agency 304 Suite 6751 305 9800 Savage Road 306 Fort Meade, MD 20755 308 Email: srashmo@radium.ncsc.mil 310 Carl Wallace 311 Cygnacom Solutions 312 Suite 5200 313 7925 Jones Branch Drive 314 McLean, VA 22102 316 Email: cwallace@cygnacom.com