idnits 2.17.00 (12 Aug 2021) /tmp/idnits61653/draft-housley-spasm-eku-constraints-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC5280, but the abstract doesn't seem to directly say this. It does mention RFC5280 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5280, updated by this document, for RFC5378 checks: 2005-04-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (25 May 2016) is 2187 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 334 -- Looks like a reference, but probably isn't: '1' on line 335 -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Housley 3 Intended Status: Standards Track Vigil Security 4 Updates: RFC 5280 (if approved) 5 Expires: 26 November 2016 25 May 2016 7 Extended Key Usage Constraints 8 draft-housley-spasm-eku-constraints-02 10 Abstract 12 This document specifies the extended key usage constraints 13 certificate extension, which is used to place restrictions on the key 14 purpose identifiers that are authorized to appear in the end-entity 15 certificate in a certification path. Restrictions apply to the 16 extended key usage certificate extension, which is described in 17 RFC 5280. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 1 Introduction 57 This document specifies the extended key usage constraints 58 certificate extension, which is used to place restrictions on the key 59 purpose identifiers that are authorized to appear in subsequent 60 certificates in a certification path. Restrictions apply to the 61 extended key usage certificate extension, which is described in 62 Section 4.2.1.12 of RFC 5280 [RFC5280]. 64 1.1 Terminology 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [RFC2119]. 70 1.2. ASN.1 72 Certificates are generated using ASN.1 [X680] and the Distinguished 73 Encoding Rules (DER) [X690]. 75 RFC 5280 [RFC5280] contains two ASN.1 modules that make use of an 76 older version of the syntax (the 1988 Syntax). RFC 5912 [RFC5912] 77 provides these same ASN.1 modules in the newer syntax. The appendix 78 of this document provides an ASN.1 module; it employs the newer 79 syntax. 81 2. Extended Key Usage Constraints Certificate Extension 83 The extended key usage (EKU) constraints certificate extension, which 84 MUST be used only in a CA certificate, indicates the extended key 85 usage values that are authorized to appear in subsequent certificates 86 in a certification path. Restrictions apply to the extended key 87 usage certificate extension, which is described in Section 4.2.1.12 88 of RFC 5280 [RFC5280]. 90 Restrictions are defined in terms of permitted or excluded key 91 purpose identifiers. 93 The permitted key purpose identifiers begins with the universal set. 94 Then, as each certificate in the certification path is processed, the 95 permitted key purpose identifiers are reduced to the intersection of 96 the previous set and the ones listed in the permittedKeyPurposeIds 97 field. Finally, each key purpose identifier in the extended key 98 usage extension of the end-entity certificate MUST appear in the 99 permitted key purpose identifiers set. 101 The excluded key purpose identifiers begins with the empty set. 102 Then, as each certificate in the certification path is processed, the 103 excluded key purpose identifiers are increased to the union of the 104 previous set and the ones listed in the excludedKeyPurposeIds field. 105 Finally, each key purpose identifier in the extended key usage 106 extension of the end-entity certificate MUST NOT appear in the 107 excluded key purpose identifiers set. 109 The special key purpose identifier anyExtendedKeyUsage is not treated 110 differently than any other key purpose identifier in processing the 111 constraints. If the anyExtendedKeyUsage key purpose identifier 112 appears in the extended key usage extension of the end-entity 113 certificate, then the anyExtendedKeyUsage key purpose identifier MUST 114 appear in the permitted key purpose identifiers set and the 115 anyExtendedKeyUsage key purpose identifier MUST NOT appear in the 116 excluded key purpose identifiers set. 118 This extension MAY, at the option of the certificate issuer, be 119 either critical or non-critical. 121 Conforming applications MUST be able to process this extension. If 122 any CA certificate in the certification path includes an extended key 123 usage constraints extension and the end-entity certificate includes 124 an extended key usage certificate extension, then the application 125 MUST either process the extended key usage extension constraint or 126 reject the certificate. 128 ext-ExtKeyUsageConstraints EXTENSION ::= { 129 SYNTAX EKUConstraints 130 IDENTIFIED BY id-ce-ekuConstraints } 132 id-ce-ekuConstraints OBJECT IDENTIFIER ::= { id-pe TBD } 134 EKUConstraints ::= CHOICE { 135 permittedKeyPurposeIds [0] KeyPurposeIds OPTIONAL, 136 excludedKeyPurposeIds [1] KeyPurposeIds OPTIONAL } 138 KeyPurposeIds ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 140 3. Basic Path Validation 142 Certification path validation is described in Section 6.1 of RFC 5280 143 [RFC5280]. Certification path processing verifies the binding 144 between the subject name and the subject public key. The binding is 145 limited by constraints that are specified in the certificates that 146 comprise the path and inputs that are specified by the relying party. 147 Certification path processing requires the name and public key for a 148 trust anchor. 150 This section extends certification path processing to include EKU 151 constraints. 153 The resulting certification path validation processing is compatible 154 with the trust anchor constrainsts processing described in RFC 5937 155 [RFC5937]. 157 3.1. Inputs 159 No additional inputs are needed. 161 3.2. Initialization 163 Two additional values are initialized. 165 (l) permitted_key_purpose_ids: a set of key purpose identifiers; 166 all of the key purpose identifiers in the end-entity certificate 167 MUST be included in this set. If the set is empty, then the 168 certification path will be considered invalid if the end-entity 169 certificate includes an extended key usage extension. The 170 initial value is the special value that represents the universal 171 set. 173 (m) excluded_key_purpose_ids: a set of key purpose identifiers; the 174 key purpose identifiers in the end-entity certificate MUST NOT 175 be included in this set. If the set is empty, then no key 176 purpose identifiers are excluded. The initial value is the 177 empty set. 179 3.3. Basic Certificate Processing 181 No additional processing steps are needed. 183 3.4. Preparation for Certificate i+1 185 One additional processing step is needed. 187 (p) If a EKU constraints extension is included in the certificate, 188 then modify the permitted_key_purpose_ids and 189 excluded_key_purpose_ids state variables as follows: 191 (1) If permittedKeyPurposeIds is present in the certificate, 192 set the permitted_key_purpose_ids state variable to the 193 intersection of its previous value and the value indicated 194 in the extension field. 196 (2) If excludedKeyPurposeIds is present in the certificate, set 197 the excluded_key_purpose_ids state variable to the union of 198 its previous value and the value indicated in the extension 199 field. 201 3.5. Wrap-Up Procedure 203 Two additional processing steps are needed. 205 (h) If the EKU extension is included in the end-entity certificate, 206 then confirm that the values meet the restrictions in the 207 permitted_key_purpose_ids and excluded_key_purpose_ids state 208 variables as follows: 210 (1) If permitted_key_purpose_ids state variable is empty, then 211 return a failure indication and an appropriate reason. 213 (2) If excluded_key_purpose_ids state variable is not empty, 214 then confirm that none of the key purpose identifiers in 215 the state variable are present in the end-entity 216 certificate. If any are present, then return a failure 217 indication and an appropriate reason. 219 (3) If permitted_key_purpose_ids state variable is not the 220 special value that represents the universal set, then 221 confirm that all of the key purpose identifiers in the end- 222 entity certificate are present in the state variable. If 223 any are missing, then return a failure indication and an 224 appropriate reason. 226 (i) If the EKU extension is not present in the end-entity 227 certificate, then confirm that the permitted_key_purpose_ids 228 state variable is the special value that represents the 229 universal set and the excluded_key_purpose_ids state variable is 230 the empty set. Otherwise, return a failure indication and an 231 appropriate reason. 233 3.6. Outputs 235 No additional output values are returned. 237 4. IANA Considerations 239 Please assign an object identifier for the certificate extension 240 specified in this document. 242 Please assign an object identifier for the ASN.1 module in the 243 Appendix. 245 5. Security Considerations 247 When a CA includes the extended key usage constraints certificate 248 extension marked as non-critical, a relying party that does not 249 understand this extension will ignore it. As a result, the relying 250 party might accept some key purpose identifiers in the end-entity 251 certificate that would have been unauthorized. If it would be 252 preferable for the certification path to be rejected, then the CA 253 SHOULD mark the extended key usage constraints certificate extension 254 as critical. 256 When a CA includes the extended key usage constraints certificate 257 extension for a subordinate CA, the OCSPSigning key purpose 258 identifier SHOULD be included in the permittedKeyPurposeIds field to 259 enable the issuance of delegated OCSP Responder certificates. 261 6. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, DOI 265 10.17487/RFC2119, March 1997, 266 . 268 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 269 Housley, R., and W. Polk, "Internet X.509 Public Key 270 Infrastructure Certificate and Certificate Revocation List 271 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 272 . 274 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 275 One (ASN.1): Specification of basic notation", ITU-T 276 Recommendation X.680, 2002. 278 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 279 Specification of Basic Encoding Rules (BER), Canonical 280 Encoding Rules (CER) and Distinguished Encoding Rules 281 (DER)", ITU-T Recommendation X.690, 2002. 283 7. Informative References 285 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 286 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 287 DOI 10.17487/RFC5912, June 2010, 288 . 290 [RFC5937] Ashmore, S. and C. Wallace, "Using Trust Anchor 291 Constraints during Certification Path Processing", 292 RFC 5937, DOI 10.17487/RFC5937, August 2010, 293 . 295 Appendix: ASN.1 Module 297 EKUConstraints2016 { iso(1) identified-organization(3) dod(6) 298 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 299 id-mod-ekuConstraints2016(TBD) } 301 DEFINITIONS IMPLICIT TAGS ::= BEGIN 303 -- EXPORTS ALL -- 305 IMPORTS 306 EXTENSION 307 FROM PKIX-CommonTypes-2009 308 { iso(1) identified-organization(3) dod(6) internet(1) 309 security(5) mechanisms(5) pkix(7) id-mod(0) 310 id-mod-pkixCommon-02(57) } 312 id-pe 313 FROM PKIX1Explicit-2009 314 { iso(1) identified-organization(3) dod(6) internet(1) 315 security(5) mechanisms(5) pkix(7) id-mod(0) 316 id-mod-pkix1-explicit-02(51) } 318 KeyPurposeId 319 FROM PKIX1Implicit-2009 320 { iso(1) identified-organization(3) dod(6) internet(1) 321 security(5) mechanisms(5) pkix(7) id-mod(0) 322 id-mod-pkix1-implicit-02(59) } ; 324 MoreCertExtensions EXTENSION ::= { 325 ext-ExtKeyUsageConstraints, ... } 327 ext-ExtKeyUsageConstraints EXTENSION ::= { 328 SYNTAX EKUConstraints 329 IDENTIFIED BY id-ce-ekuConstraints } 331 id-ce-ekuConstraints OBJECT IDENTIFIER ::= { id-pe TBD } 333 EKUConstraints ::= CHOICE { 334 permittedKeyPurposeIds [0] KeyPurposeIds OPTIONAL, 335 excludedKeyPurposeIds [1] KeyPurposeIds OPTIONAL } 337 KeyPurposeIds ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 339 END 341 Acknowledgements 343 Many thanks to review and insightful comments from Santosh Chokhani, 344 Stephen Farrell, Tom Gindin, Sean Leonard, Michael Richardson, Stefan 345 Santesson, Jim Schaad, and Mike St.Johns. 347 Author's Address 349 Russell Housley 350 Vigil Security, LLC 351 918 Spring Knoll Drive 352 Herndon, VA 20170 353 USA 354 EMail: housley@vigilsec.com