idnits 2.17.1 draft-housley-spasm-eku-constraints-03.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 (26 May 2016) is 2892 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 336 -- Looks like a reference, but probably isn't: '1' on line 337 -- 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: 27 November 2016 26 May 2016 7 Extended Key Usage Constraints 8 draft-housley-spasm-eku-constraints-03 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. The permittedKeyPurposeIds 100 field MUST NOT be an empty sequence. 102 The excluded key purpose identifiers begins with the empty set. 103 Then, as each certificate in the certification path is processed, the 104 excluded key purpose identifiers are increased to the union of the 105 previous set and the ones listed in the excludedKeyPurposeIds field. 106 Finally, each key purpose identifier in the extended key usage 107 extension of the end-entity certificate MUST NOT appear in the 108 excluded key purpose identifiers set. The excludedKeyPurposeIds 109 field MUST NOT be an empty sequence. 111 The special key purpose identifier anyExtendedKeyUsage is not treated 112 differently than any other key purpose identifier in processing the 113 constraints. If the anyExtendedKeyUsage key purpose identifier 114 appears in the extended key usage extension of the end-entity 115 certificate, then the anyExtendedKeyUsage key purpose identifier MUST 116 appear in the permitted key purpose identifiers set and the 117 anyExtendedKeyUsage key purpose identifier MUST NOT appear in the 118 excluded key purpose identifiers set. 120 This extension MAY, at the option of the certificate issuer, be 121 either critical or non-critical. 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 ::= CHOICE { 137 permittedKeyPurposeIds [0] KeyPurposeIds, 138 excludedKeyPurposeIds [1] KeyPurposeIds } 140 KeyPurposeIds ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 142 3. Basic Path Validation 144 Certification path validation is described in Section 6.1 of RFC 5280 145 [RFC5280]. Certification path processing verifies the binding 146 between the subject name and the subject public key. The binding is 147 limited by constraints that are specified in the certificates that 148 comprise the path and inputs that are specified by the relying party. 149 Certification path processing requires the name and public key for a 150 trust anchor. 152 This section extends certification path processing to include EKU 153 constraints. 155 The resulting certification path validation processing is compatible 156 with the trust anchor constrainsts processing described in RFC 5937 157 [RFC5937]. 159 3.1. Inputs 161 No additional inputs are needed. 163 3.2. Initialization 165 Two additional values are initialized. 167 (l) permitted_key_purpose_ids: a set of key purpose identifiers; 168 all of the key purpose identifiers in the end-entity certificate 169 MUST be included in this set. If the set is empty, then the 170 certification path will be considered invalid if the end-entity 171 certificate includes an extended key usage extension. The 172 initial value is the special value that represents the universal 173 set. 175 (m) excluded_key_purpose_ids: a set of key purpose identifiers; the 176 key purpose identifiers in the end-entity certificate MUST NOT 177 be included in this set. If the set is empty, then no key 178 purpose identifiers are excluded. The initial value is the 179 empty set. 181 3.3. Basic Certificate Processing 183 No additional processing steps are needed. 185 3.4. Preparation for Certificate i+1 187 One additional processing step is needed. 189 (p) If a EKU constraints extension is included in the certificate, 190 then modify the permitted_key_purpose_ids and 191 excluded_key_purpose_ids state variables as follows: 193 (1) If permittedKeyPurposeIds is present in the certificate, 194 set the permitted_key_purpose_ids state variable to the 195 intersection of its previous value and the value indicated 196 in the extension field. 198 (2) If excludedKeyPurposeIds is present in the certificate, set 199 the excluded_key_purpose_ids state variable to the union of 200 its previous value and the value indicated in the extension 201 field. 203 3.5. Wrap-Up Procedure 205 Two additional processing steps are needed. 207 (h) If the EKU extension is included in the end-entity certificate, 208 then confirm that the values meet the restrictions in the 209 permitted_key_purpose_ids and excluded_key_purpose_ids state 210 variables as follows: 212 (1) If permitted_key_purpose_ids state variable is empty, then 213 return a failure indication and an appropriate reason. 215 (2) If excluded_key_purpose_ids state variable is not empty, 216 then confirm that none of the key purpose identifiers in 217 the state variable are present in the end-entity 218 certificate. If any are present, then return a failure 219 indication and an appropriate reason. 221 (3) If permitted_key_purpose_ids state variable is not the 222 special value that represents the universal set, then 223 confirm that all of the key purpose identifiers in the end- 224 entity certificate are present in the state variable. If 225 any are missing, then return a failure indication and an 226 appropriate reason. 228 (i) If the EKU extension is not present in the end-entity 229 certificate, then confirm that the permitted_key_purpose_ids 230 state variable is the special value that represents the 231 universal set and the excluded_key_purpose_ids state variable is 232 the empty set. Otherwise, return a failure indication and an 233 appropriate reason. 235 3.6. Outputs 237 No additional output values are returned. 239 4. IANA Considerations 241 Please assign an object identifier for the certificate extension 242 specified in this document. 244 Please assign an object identifier for the ASN.1 module in the 245 Appendix. 247 5. Security Considerations 249 When a CA includes the extended key usage constraints certificate 250 extension marked as non-critical, a relying party that does not 251 understand this extension will ignore it. As a result, the relying 252 party might accept some key purpose identifiers in the end-entity 253 certificate that would have been unauthorized. If it would be 254 preferable for the certification path to be rejected, then the CA 255 SHOULD mark the extended key usage constraints certificate extension 256 as critical. 258 When a CA includes the extended key usage constraints certificate 259 extension for a subordinate CA, the OCSPSigning key purpose 260 identifier SHOULD be included in the permittedKeyPurposeIds field to 261 enable the issuance of delegated OCSP Responder certificates. 263 6. Normative References 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, DOI 267 10.17487/RFC2119, March 1997, 268 . 270 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 271 Housley, R., and W. Polk, "Internet X.509 Public Key 272 Infrastructure Certificate and Certificate Revocation List 273 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 274 . 276 [X680] ITU-T, "Information technology -- Abstract Syntax Notation 277 One (ASN.1): Specification of basic notation", ITU-T 278 Recommendation X.680, 2002. 280 [X690] ITU-T, "Information technology -- ASN.1 encoding rules: 281 Specification of Basic Encoding Rules (BER), Canonical 282 Encoding Rules (CER) and Distinguished Encoding Rules 283 (DER)", ITU-T Recommendation X.690, 2002. 285 7. Informative References 287 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 288 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 289 DOI 10.17487/RFC5912, June 2010, 290 . 292 [RFC5937] Ashmore, S. and C. Wallace, "Using Trust Anchor 293 Constraints during Certification Path Processing", 294 RFC 5937, DOI 10.17487/RFC5937, August 2010, 295 . 297 Appendix: ASN.1 Module 299 EKUConstraints2016 { iso(1) identified-organization(3) dod(6) 300 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 301 id-mod-ekuConstraints2016(TBD) } 303 DEFINITIONS IMPLICIT TAGS ::= BEGIN 305 -- EXPORTS ALL -- 307 IMPORTS 308 EXTENSION 309 FROM PKIX-CommonTypes-2009 310 { iso(1) identified-organization(3) dod(6) internet(1) 311 security(5) mechanisms(5) pkix(7) id-mod(0) 312 id-mod-pkixCommon-02(57) } 314 id-pe 315 FROM PKIX1Explicit-2009 316 { iso(1) identified-organization(3) dod(6) internet(1) 317 security(5) mechanisms(5) pkix(7) id-mod(0) 318 id-mod-pkix1-explicit-02(51) } 320 KeyPurposeId 321 FROM PKIX1Implicit-2009 322 { iso(1) identified-organization(3) dod(6) internet(1) 323 security(5) mechanisms(5) pkix(7) id-mod(0) 324 id-mod-pkix1-implicit-02(59) } ; 326 MoreCertExtensions EXTENSION ::= { 327 ext-ExtKeyUsageConstraints, ... } 329 ext-ExtKeyUsageConstraints EXTENSION ::= { 330 SYNTAX EKUConstraints 331 IDENTIFIED BY id-ce-ekuConstraints } 333 id-ce-ekuConstraints OBJECT IDENTIFIER ::= { id-pe TBD } 335 EKUConstraints ::= CHOICE { 336 permittedKeyPurposeIds [0] KeyPurposeIds, 337 excludedKeyPurposeIds [1] KeyPurposeIds } 339 KeyPurposeIds ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 341 END 343 Acknowledgements 345 Many thanks to review and insightful comments from Santosh Chokhani, 346 Stephen Farrell, Tom Gindin, Sean Leonard, Michael Richardson, Stefan 347 Santesson, Jim Schaad, and Mike St.Johns. 349 Author's Address 351 Russell Housley 352 Vigil Security, LLC 353 918 Spring Knoll Drive 354 Herndon, VA 20170 355 USA 356 EMail: housley@vigilsec.com