idnits 2.17.00 (12 Aug 2021) /tmp/idnits62121/draft-housley-spasm-eku-constraints-00.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 (13 May 2016) is 2199 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) == Missing Reference: 'X680' is mentioned on line 72, but not defined == Missing Reference: 'X690' is mentioned on line 74, but not defined -- Looks like a reference, but probably isn't: '0' on line 108 -- Looks like a reference, but probably isn't: '1' on line 109 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 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: 14 November 2016 13 May 2016 7 Extended Key Usage Constraints 8 draft-housley-spasm-eku-constraints-00 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 subsequent 15 certificates in a certification path. Restrictions apply to the 16 extended key usage certificate extension, which is described in RFC 17 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 27 Internet-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], which uses the Basic 73 Encoding Rules (BER) and the Distinguished Encoding Rules (DER) 74 [X690]. 76 2. Extended Key Usage Constraints Certificate Extension 78 The extended key usage (EKU) constraints certificate extension, which 79 MUST be used only in a CA certificate, indicates the extended key 80 usage values that are authorized to appear in subsequent certificates 81 in a certification path. Restrictions apply to the extended key 82 usage certificate extension, which is described in Section 4.2.1.12 83 of RFC 5280 [RFC5280]. 85 Restrictions are defined in terms of permitted or excluded key 86 purpose identifiers. Any key purpose identifier matching an entry in 87 the excludedKeyPurposeIds field is invalid regardless of information 88 appearing in the permittedKeyPurposeIds. 90 Conforming CAs MUST mark this extension as critical, and conforming 91 CAs MUST NOT issue certificates where this extension is an empty 92 sequence. That is, either the permittedKeyPurposeIds field or the 93 excludedKeyPurposeIds field MUST be present. 95 Conforming applications MUST be able to process this extension. If 96 any CA certificate in the certification path includes an EKU 97 constraints extension that is marked as critical, and the end-entity 98 certificate includes an extended key usage certificate extension, 99 then the application MUST either process the EKU constraint or reject 100 the certificate. 102 ekuConstraints EXTENSION ::= { SYNTAX EKUConstraints 103 IDENTIFIED BY id-ce-ekuConstraints } 105 id-ce-ekuConstraints OBJECT IDENTIFIER ::= { id-ce TBD } 107 EKUConstraints ::= SEQUENCE { 108 permittedKeyPurposeIds [0] KeyPurposeIds OPTIONAL, 109 excludedKeyPurposeIds [1] KeyPurposeIds OPTIONAL } 111 KeyPurposeIds ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 113 3. Basic Path Validation 115 Certification path validation is described in Section 6.1 of RFC 5280 116 [RFC5280]. Certification path processing verifies the binding 117 between the subject name and the subject public key. The binding is 118 limited by constraints that are specified in the certificates that 119 comprise the path and inputs that are specified by the relying party. 121 This section extends to path processing to include EKU constraints. 123 3.1. Inputs 125 No additional inputs are needed. 127 3.2. Initialization 129 Two additional values are initialized. 131 (l) permitted_key_purpose_ids: a set of key purpose identifiers; 132 all of the key purpose identifiers in the end-entity certificate 133 MUST be included in this set. If the set is empty, then the 134 certification path will be considered invalid if the end-entity 135 certificate includes an extended key usage extension. The 136 initial value is a special value that represents the universal 137 set. 139 (m) excluded_key_purpose_ids: a set of key purpose identifiers; the 140 key purpose identifiers in the end-entity certificate MUST NOT 141 be included in this set. If the set is empty, then no key 142 purpose identifiers are excluded. The initial value is a is the 143 empty set. 145 3.3. Basic Certificate Processing 147 No additional processing steps are needed. 149 3.4. Preparation for Certificate i+1 151 One additional processing step is needed. 153 (p) If a EKU constraints extension is included in the certificate, 154 then modify the permitted_key_purpose_ids and 155 excluded_key_purpose_ids state variables as follows: 157 (1) If permittedKeyPurposeIds is present in the certificate, 158 set the permitted_key_purpose_ids state variable to the 159 intersection of its previous value and the value indicated 160 in the extension field. 162 (2) If excludedKeyPurposeIds is present in the certificate, set 163 the excluded_key_purpose_ids state variable to the union of 164 its previous value and the value indicated in the extension 165 field. 167 3.5. Wrap-Up Procedure 169 One additional processing step is needed. 171 (h) If the EKU extension is included in the end-entity certificate, 172 then confirm that the values meet the restrictions in the 173 permitted_key_purpose_ids and excluded_key_purpose_ids state 174 variables as follows: 176 (1) If permitted_key_purpose_ids state variable is not special 177 value that represents the universal set, then confirm that 178 all of the key purpose identifiers are present in the set. 179 If any are missing, then returning a failure indication and 180 an appropriate reason. 182 (2) If excluded_key_purpose_ids state variable is not empty, 183 then confirm that none of the key purpose identifiers are 184 present in the set. If any are present, then returning a 185 failure indication and an appropriate reason. 187 3.6. Outputs 189 No additional output values are returned. 191 4. IANA Considerations 193 Please assign an object identifier for the certificate extension 194 specified in this document. Once the ASN.1 module is added, then an 195 object identifier for that will be needed too. 197 5. Security Considerations 199 TBD 201 6. Normative References 203 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 204 Requirement Levels", BCP 14, RFC 2119, DOI 205 10.17487/RFC2119, March 1997, . 208 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 209 Housley, R., and W. Polk, "Internet X.509 Public Key 210 Infrastructure Certificate and Certificate Revocation List 211 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 212 . 214 Appendix: ASN.1 Module 216 TBD 218 Author's Address 220 Russell Housley 221 Vigil Security, LLC 222 918 Spring Knoll Drive 223 Herndon, VA 20170 224 USA 225 EMail: housley@vigilsec.com