idnits 2.17.00 (12 Aug 2021) /tmp/idnits61893/draft-housley-spasm-eku-constraints-01.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 (17 May 2016) is 2195 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 308 -- Looks like a reference, but probably isn't: '1' on line 309 -- 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: 18 November 2016 17 May 2016 7 Extended Key Usage Constraints 8 draft-housley-spasm-eku-constraints-01 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 Conforming CAs MUST mark this extension as critical, and conforming 119 CAs MUST NOT issue certificates where this extension is an empty 120 sequence. That is, at least one of the permittedKeyPurposeIds field 121 or the excludedKeyPurposeIds field MUST be present. 123 Conforming applications MUST be able to process this extension. If 124 any CA certificate in the certification path includes an extended key 125 usage constraints extension and the end-entity certificate includes 126 an extended key usage certificate extension, then the application 127 MUST either process the extended key usage extension constraint or 128 reject the certificate. 130 ext-ExtKeyUsageConstraints EXTENSION ::= { 131 SYNTAX EKUConstraints 132 IDENTIFIED BY id-ce-ekuConstraints } 134 id-ce-ekuConstraints OBJECT IDENTIFIER ::= { id-pe TBD } 136 EKUConstraints ::= SEQUENCE { 137 permittedKeyPurposeIds [0] KeyPurposeIds OPTIONAL, 138 excludedKeyPurposeIds [1] KeyPurposeIds OPTIONAL } 139 ( WITH COMPONENTS { ..., permittedKeyPurposeIds PRESENT } | 140 WITH COMPONENTS { ..., excludedKeyPurposeIds PRESENT } ) 142 KeyPurposeIds ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 144 3. Basic Path Validation 146 Certification path validation is described in Section 6.1 of RFC 5280 147 [RFC5280]. Certification path processing verifies the binding 148 between the subject name and the subject public key. The binding is 149 limited by constraints that are specified in the certificates that 150 comprise the path and inputs that are specified by the relying party. 152 This section extends to path processing to include EKU constraints. 154 3.1. Inputs 156 No additional inputs are needed. 158 3.2. Initialization 160 Two additional values are initialized. 162 (l) permitted_key_purpose_ids: a set of key purpose identifiers; 163 all of the key purpose identifiers in the end-entity certificate 164 MUST be included in this set. If the set is empty, then the 165 certification path will be considered invalid if the end-entity 166 certificate includes an extended key usage extension. The 167 initial value is a special value that represents the universal 168 set. 170 (m) excluded_key_purpose_ids: a set of key purpose identifiers; the 171 key purpose identifiers in the end-entity certificate MUST NOT 172 be included in this set. If the set is empty, then no key 173 purpose identifiers are excluded. The initial value is the 174 empty set. 176 3.3. Basic Certificate Processing 178 No additional processing steps are needed. 180 3.4. Preparation for Certificate i+1 182 One additional processing step is needed. 184 (p) If a EKU constraints extension is included in the certificate, 185 then modify the permitted_key_purpose_ids and 186 excluded_key_purpose_ids state variables as follows: 188 (1) If permittedKeyPurposeIds is present in the certificate, 189 set the permitted_key_purpose_ids state variable to the 190 intersection of its previous value and the value indicated 191 in the extension field. 193 (2) If excludedKeyPurposeIds is present in the certificate, set 194 the excluded_key_purpose_ids state variable to the union of 195 its previous value and the value indicated in the extension 196 field. 198 3.5. Wrap-Up Procedure 200 One additional processing step is needed. 202 (h) If the EKU extension is included in the end-entity certificate, 203 then confirm that the values meet the restrictions in the 204 permitted_key_purpose_ids and excluded_key_purpose_ids state 205 variables as follows: 207 (1) If permitted_key_purpose_ids state variable is empty, then 208 return a failure indication and an appropriate reason. 210 (2) If excluded_key_purpose_ids state variable is not empty, 211 then confirm that none of the key purpose identifiers in 212 the state variable are present in the end-entity 213 certificate. If any are present, then return a failure 214 indication and an appropriate reason. 216 (3) If permitted_key_purpose_ids state variable is not the 217 special value that represents the universal set, then 218 confirm that all of the key purpose identifiers in the end- 219 entity certificate are present in the state variable. If 220 any are missing, then return a failure indication and an 221 appropriate reason. 223 3.6. Outputs 225 No additional output values are returned. 227 4. IANA Considerations 229 Please assign an object identifier for the certificate extension 230 specified in this document. Once the ASN.1 module is added, then an 231 object identifier for that will be needed too. 233 5. Security Considerations 235 When a CA includes the extended key usage constraints certificate 236 extension for a subordinate CA, the OCSPSigning key purpose 237 identifier SHOULD be included in the permittedKeyPurposeIds field to 238 enable the issuance of delegated OCSP Responder certificates. 240 6. Normative References 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, DOI 244 10.17487/RFC2119, March 1997, . 247 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 248 Housley, R., and W. Polk, "Internet X.509 Public Key 249 Infrastructure Certificate and Certificate Revocation List 250 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 251 . 253 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 254 One (ASN.1): Specification of basic notation", ITU-T 255 Recommendation X.680, 2002. 257 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 258 Specification of Basic Encoding Rules (BER), Canonical 259 Encoding Rules (CER) and Distinguished Encoding Rules 260 (DER)", ITU-T Recommendation X.690, 2002. 262 7. Informative References 264 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 265 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 266 DOI 10.17487/RFC5912, June 2010, . 269 Appendix: ASN.1 Module 271 EKUConstraints2016 { iso(1) identified-organization(3) dod(6) 272 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 273 id-mod-ekuConstraints2016(TBD) } 275 DEFINITIONS IMPLICIT TAGS ::= BEGIN 277 -- EXPORTS ALL -- 279 IMPORTS 280 EXTENSION 281 FROM PKIX-CommonTypes-2009 282 { iso(1) identified-organization(3) dod(6) internet(1) 283 security(5) mechanisms(5) pkix(7) id-mod(0) 284 id-mod-pkixCommon-02(57) } 286 id-pe 287 FROM PKIX1Explicit-2009 288 { iso(1) identified-organization(3) dod(6) internet(1) 289 security(5) mechanisms(5) pkix(7) id-mod(0) 290 id-mod-pkix1-explicit-02(51) } 292 KeyPurposeId 293 FROM PKIX1Implicit-2009 294 { iso(1) identified-organization(3) dod(6) internet(1) 295 security(5) mechanisms(5) pkix(7) id-mod(0) 296 id-mod-pkix1-implicit-02(59) } ; 298 MoreCertExtensions EXTENSION ::= { 299 ext-ExtKeyUsageConstraints, ... } 301 ext-ExtKeyUsageConstraints EXTENSION ::= { 302 SYNTAX EKUConstraints 303 IDENTIFIED BY id-ce-ekuConstraints } 305 id-ce-ekuConstraints OBJECT IDENTIFIER ::= { id-pe TBD } 307 EKUConstraints ::= SEQUENCE { 308 permittedKeyPurposeIds [0] KeyPurposeIds OPTIONAL, 309 excludedKeyPurposeIds [1] KeyPurposeIds OPTIONAL } 310 ( WITH COMPONENTS { ..., permittedKeyPurposeIds PRESENT } | 311 WITH COMPONENTS { ..., excludedKeyPurposeIds PRESENT } ) 313 KeyPurposeIds ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 315 END 317 Acknowledgements 319 Many thanks to review and insightful comments from Santosh Chokhani, 320 Stephen Farrell, Tom Gindin, Sean Leonard, Michael Richardson, Jim 321 Schaad, and Mike St.Johns. 323 Author's Address 325 Russell Housley 326 Vigil Security, LLC 327 918 Spring Knoll Drive 328 Herndon, VA 20170 329 USA 330 EMail: housley@vigilsec.com