idnits 2.17.1 draft-richardson-lamps-rfc7030est-clarify-04.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 abstract seems to indicate that this document updates RFC7030, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 24, 2019) is 1645 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: 'RFC6268' is mentioned on line 383, but not defined == Unused Reference: 'X681' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'X682' is defined on line 310, but no explicit reference was found in the text == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-28 ** Downref: Normative reference to an Informational RFC: RFC 2986 -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X681' -- Possible downref: Non-RFC (?) normative reference: ref. 'X682' -- Possible downref: Non-RFC (?) normative reference: ref. 'X683' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track T. Werner 5 Expires: April 26, 2020 Siemens 6 W. Pan 7 Huawei Technologies 8 S. Turner 9 sn3rd 10 October 24, 2019 12 Clarification of Enrollment over Secure Transport (EST): transfer 13 encodings and ASN.1 14 draft-richardson-lamps-rfc7030est-clarify-04 16 Abstract 18 This document updates RFC7030: Enrollment over Secure Transport (EST) 19 to resolve some errata that was reported, and which has proven to 20 have interoperability when RFC7030 has been extended. 22 This document deprecates the specification of "Content-Transfer- 23 Encoding" headers for EST endpoints, providing a way to do this in an 24 upward compatible way. This document additional defines a GRASP 25 discovery mechanism for EST endpoints, and specifies requirements for 26 them. 28 Finally, this document fixes some syntactical errors in ASN.1 that 29 was presented. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 26, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 68 4. Changes to EST endpoint processing . . . . . . . . . . . . . 3 69 5. Clarification of ASN.1 for Certificate Attribute set. . . . . 4 70 5.1. CSR Attributes Response . . . . . . . . . . . . . . . . . 4 71 6. Clarification of error messages for certificate enrollment 72 operations . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 79 11.2. Informative References . . . . . . . . . . . . . . . . . 7 80 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 [RFC7030] defines the Enrollment over Secure Transport, or EST 86 protocol. 88 This specification defines a number of HTTP end points for 89 certificate enrollment and management. The details of the 90 transaction were defined in terms of MIME headers as defined in 91 [RFC2045], rather than in terms of the HTTP protocol as defined in 92 [RFC2616] and [RFC7230]. 94 [RFC2616] and later [RFC7231] Appendix A.5 has text specifically 95 deprecating Content-Transfer-Encoding. 97 [RFC7030] calls it out this header incorrectly. 99 [I-D.ietf-anima-bootstrapping-keyinfra] extends [RFC7030], adding new 100 functionality, and interop testing of the protocol has revealed that 101 unusual processing called out in [RFC7030] causes confusion. 103 EST is currently specified as part of IEC 62351, and is widely used 104 in Government, Utilities and Financial markets today. 106 Changes to [RFC7030] to bring it inline with typical HTTP processing 107 would change the on-wire protocol in a way that is not backwards 108 compatible. Reports from the field suggest that many implementations 109 do not send the Content-Transfer-Encoding, and many of them ignore 110 it. 112 This document therefore revises [RFC7030] to reflect the field 113 reality, deprecating the extranous field. 115 This document deals with errata numbers [errata4384], [errata5107], 116 and [errata5108]. 118 2. Terminology 120 The abbreviation "CTE" is used to denote the Content-Transfer- 121 Encoding header, and the abbreviation "CTE-base64" is used to denote 122 a request or response whose Content-Transfer-Encoding header contains 123 the value "base64". 125 3. Requirements Language 127 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 128 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 129 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 130 [RFC2119] and indicate requirement levels for compliant STuPiD 131 implementations. 133 4. Changes to EST endpoint processing 135 The [RFC7030] sections 4.1.3 (CA Certificates Response, /cacerts), 136 4.3.1/4.3.2 (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation, 137 /serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) specify the use 138 of base64 encoding with a Content-Transfer-Encoding for requests and 139 response. 141 This document updates [RFC7030] to require the POST request and 142 payload response of all endpoints in to be [RFC4648] section 4 Base64 143 encoded DER. This format is to be used regardless of whether there 144 is any Content-Transfer-Encoding header, and any value in that header 145 is to be ignored. 147 5. Clarification of ASN.1 for Certificate Attribute set. 149 Section 4.5.2 of [RFC7030] is to be replaced with the following text: 151 5.1. CSR Attributes Response 153 If locally configured policy for an authenticated EST client 154 indicates a CSR Attributes Response is to be provided, the server 155 response MUST include an HTTP 200 response code. An HTTP response 156 code of 204 or 404 indicates that a CSR Attributes Response is not 157 available. Regardless of the response code, the EST server and CA 158 MAY reject any subsequent enrollment requests for any reason, e.g., 159 incomplete CSR attributes in the request. 161 Responses to attribute request messages MUST be encoded as the 162 content-type of "application/csrattrs", and are to be "base64" 163 [RFC2045] encoded. The syntax for application/csrattrs body is as 164 follows: 166 CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID 168 AttrOrOID ::= CHOICE { 169 oid OBJECT IDENTIFIER, 170 attribute Attribute {{AttrSet}} } 172 AttrSet ATTRIBUTE ::= { AttributesDefinedInRFC7030, ... } 174 An EST server includes zero or more OIDs or attributes [RFC2986] that 175 it requests the client to use in the certification request. The 176 client MUST ignore any OID or attribute it does not recognize. When 177 the server encodes CSR Attributes as an empty SEQUENCE, it means that 178 the server has no specific additional information it desires in a 179 client certification request (this is functionally equivalent to an 180 HTTP response code of 204 or 404). 182 If the CA requires a particular crypto system or use of a particular 183 signature scheme (e.g., certification of a public key based on a 184 certain elliptic curve, or signing using a certain hash algorithm) it 185 MUST provide that information in the CSR Attribute Response. If an 186 EST server requires the linking of identity and POP information (see 187 Section 3.5), it MUST include the challengePassword OID in the CSR 188 Attributes Response. 190 The structure of the CSR Attributes Response SHOULD, to the greatest 191 extent possible, reflect the structure of the CSR it is requesting. 193 Requests to use a particular signature scheme (e.g. using a 194 particular hash function) are represented as an OID to be reflected 195 in the SignatureAlgorithm of the CSR. Requests to use a particular 196 crypto system (e.g., certification of a public key based on a certain 197 elliptic curve) are represented as an attribute, to be reflected as 198 the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type 199 indicating the algorithm and the values indicating the particular 200 parameters specific to the algorithm. Requests for descriptive 201 information from the client are made by an attribute, to be 202 represented as Attributes of the CSR, with a type indicating the 203 [RFC2985] extensionRequest and the values indicating the particular 204 attributes desired to be included in the resulting certificate's 205 extensions. 207 The sequence is Distinguished Encoding Rules (DER) encoded [X690] and 208 then base64 encoded (Section 4 of [RFC4648]). The resulting text 209 forms the application/csrattr body, without headers. 211 For example, if a CA requests a client to submit a certification 212 request containing the challengePassword (indicating that linking of 213 identity and POP information is requested; see Section 3.5), an 214 extensionRequest with the Media Access Control (MAC) address 215 ([RFC2307]) of the client, and to use the secp384r1 elliptic curve 216 and to sign with the SHA384 hash function. Then, it takes the 217 following: 219 OID: challengePassword (1.2.840.113549.1.9.7) 221 Attribute: type = extensionRequest (1.2.840.113549.1.9.14) 222 value = macAddress (1.3.6.1.1.1.1.22) 224 Attribute: type = id-ecPublicKey (1.2.840.10045.2.1) 225 value = secp384r1 (1.3.132.0.34) 227 OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3) 229 and encodes them into an ASN.1 SEQUENCE to produce: ~~~ 30 41 06 09 230 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d 02 01 31 07 06 231 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01 09 0e 31 09 06 07 232 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03 03 ~~~ 234 and then base64 encodes the resulting ASN.1 SEQUENCE to produce: 236 MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ 237 BgcrBgEBAQEWBggqhkjOPQQDAw== 239 6. Clarification of error messages for certificate enrollment 240 operations 242 errata 5108. 244 7. Privacy Considerations 246 This document does not disclose any additional identifies to either 247 active or passive observer would see with [RFC7030]. 249 8. Security Considerations 251 This document clarifies an existing security mechanism. An option is 252 introduced to the security mechanism using an implicit negotiation. 254 9. IANA Considerations 256 The ASN.1 module in Appendix A of this doucment makes use of object 257 identifiers (OIDs). This document requests that IANA register an OID 258 in the SMI Security for PKIX Arc in the Module identifiers subarc 259 (1.3.6.1.5.5.7.0) for the ASN.1 module. The OID for the Asymmetric 260 Decryption Key Identifier (1.2.840.113549.1.9.16.2.54) was previously 261 defined in [RFC7030]. IANA is requested to update the "Reference" 262 column for the Asymmetric Decryption Key Identifier attribute to also 263 include a reference to this doducment. 265 10. Acknowledgements 267 This work was supported by the Huawei Technologies. 269 11. References 271 11.1. Normative References 273 [I-D.ietf-anima-bootstrapping-keyinfra] 274 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 275 and K. Watsen, "Bootstrapping Remote Secure Key 276 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 277 keyinfra-28 (work in progress), September 2019. 279 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 280 Extensions (MIME) Part One: Format of Internet Message 281 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 282 . 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, 286 DOI 10.17487/RFC2119, March 1997, 287 . 289 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 290 Request Syntax Specification Version 1.7", RFC 2986, 291 DOI 10.17487/RFC2986, November 2000, 292 . 294 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 295 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 296 . 298 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 299 "Enrollment over Secure Transport", RFC 7030, 300 DOI 10.17487/RFC7030, October 2013, 301 . 303 [X680] ITU-T, "Information technology - Abstract Syntax Notation 304 One.", ISO/IEC 8824-1:2002, 2002. 306 [X681] ITU-T, "Information technology - Abstract Syntax Notation 307 One: Information Object Specification.", ISO/ 308 IEC 8824-2:2002, 2002. 310 [X682] ITU-T, "Information technology - Abstract Syntax Notation 311 One: Constraint Specification.", ISO/IEC 8824-2:2002, 312 2002. 314 [X683] ITU-T, "Information technology - Abstract Syntax Notation 315 One: Parameterization of ASN.1 Specifications.", ISO/ 316 IEC 8824-2:2002, 2002. 318 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 319 Specification of Basic Encoding Rules (BER), Canonical 320 Encoding Rules (CER) and Distinguished Encoding Rules 321 (DER).", ISO/IEC 8825-1:2002, 2002. 323 11.2. Informative References 325 [errata4384] 326 "EST errata 4384: ASN.1 encoding error", n.d., 327 . 329 [errata5107] 330 "EST errata 5107: use Content-Transfer-Encoding", n.d., 331 . 333 [errata5108] 334 "EST errata 5108: use of Content-Type for error message", 335 n.d., . 337 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 338 Information Service", RFC 2307, DOI 10.17487/RFC2307, 339 March 1998, . 341 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 342 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 343 Transfer Protocol -- HTTP/1.1", RFC 2616, 344 DOI 10.17487/RFC2616, June 1999, 345 . 347 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 348 Classes and Attribute Types Version 2.0", RFC 2985, 349 DOI 10.17487/RFC2985, November 2000, 350 . 352 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 353 Protocol (HTTP/1.1): Message Syntax and Routing", 354 RFC 7230, DOI 10.17487/RFC7230, June 2014, 355 . 357 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 358 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 359 DOI 10.17487/RFC7231, June 2014, 360 . 362 Appendix A. ASN.1 Module 364 This annex provides the normative ASN.1 definitions for the 365 structures described in this specification using ASN.1 as defined in 366 [X680] through [X683]. 368 There is no ASN.1 Module in RFC 7030. This module has been created 369 by combining the lines that are contained in the document body. 371 PKIXEST-2019 372 { iso(1) identified-organization(3) dod(6) 373 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 374 id-mod-est-2019(TBD) } 376 DEFINITIONS IMPLICIT TAGS ::= 377 BEGIN 379 -- EXPORTS ALL -- 380 IMPORTS 382 Attribute 383 FROM CryptographicMessageSyntax-2010 -- [RFC6268] 384 { iso(1) member-body(2) us(840) rsadsi(113549) 385 pkcs(1) pkcs-9(9) smime(16) modules(0) 386 id-mod-cms-2009(58) } 388 ATTRIBUTE 389 FROM PKIX-CommonTypes-2009 390 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 391 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; 393 -- CSR Attributes 395 CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID 397 AttrOrOID ::= CHOICE { 398 oid OBJECT IDENTIFIER, 399 attribute Attribute {{AttrSet}} } 401 AttrSet ATTRIBUTE ::= { AttributesDefinedInRFC7030, ... } 403 -- Asymmetric Decrypt Key Identifier Attribute 405 AttributesDefinedInRFC7030 ATTRIBUTE ::= { aa-asymmDecryptKeyID, ... } 407 aa-asymmDecryptKeyID ATTRIBUTE ::= 408 { TYPE AsymmetricDecryptKeyIdentifier 409 IDENTIFIED BY id-aa-asymmDecryptKeyID } 411 id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1) member-body(2) 412 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 54 } 414 AsymmetricDecryptKeyIdentifier ::= OCTET STRING 416 END 418 Authors' Addresses 420 Michael Richardson 421 Sandelman Software Works 423 Email: mcr+ietf@sandelman.ca 424 Thomas Werner 425 Siemens 427 Email: thomas-werner@siemens.com 429 Wei Pan 430 Huawei Technologies 432 Email: william.panwei@huawei.com 434 Sean Turner 435 sn3rd 437 Email: sean@sn3rd.com