idnits 2.17.1 draft-ietf-lamps-rfc7030est-clarify-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 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 (March 05, 2020) is 1512 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: 'RFC2046' is mentioned on line 272, but not defined == Missing Reference: 'RFC6268' is mentioned on line 420, but not defined == Unused Reference: 'X681' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'X682' is defined on line 346, but no explicit reference was found in the text == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-37 ** 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 (~~), 7 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: September 6, 2020 Siemens 6 W. Pan 7 Huawei Technologies 8 March 05, 2020 10 Clarification of Enrollment over Secure Transport (EST): transfer 11 encodings and ASN.1 12 draft-ietf-lamps-rfc7030est-clarify-02 14 Abstract 16 This document updates RFC7030: Enrollment over Secure Transport (EST) 17 to resolve some errata that was reported, and which has proven to 18 have interoperability when RFC7030 has been extended. 20 This document deprecates the specification of "Content-Transfer- 21 Encoding" headers for EST endpoints, providing a way to do this in an 22 upward compatible way. This document fixes some syntactical errors 23 in ASN.1 that was presented. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 6, 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 62 4. Changes to EST endpoint processing . . . . . . . . . . . . . 3 63 5. Clarification of ASN.1 for Certificate Attribute set. . . . . 4 64 5.1. CSR Attributes Response . . . . . . . . . . . . . . . . . 4 65 6. Clarification of error messages for certificate enrollment 66 operations . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6.1. Updating section 4.2.3: Simple Enroll and Re-enroll 68 Response . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6.2. Updating section 4.4.2: Server-Side Key Generation 70 Response . . . . . . . . . . . . . . . . . . . . . . . . 6 71 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 11.2. Informative References . . . . . . . . . . . . . . . . . 8 78 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 [RFC7030] defines the Enrollment over Secure Transport, or EST 84 protocol. 86 This specification defines a number of HTTP end points for 87 certificate enrollment and management. The details of the 88 transaction were defined in terms of MIME headers as defined in 89 [RFC2045], rather than in terms of the HTTP protocol as defined in 90 [RFC2616] and [RFC7230]. 92 [RFC2616] and later [RFC7231] Appendix A.5 has text specifically 93 deprecating Content-Transfer-Encoding. 95 [RFC7030] calls it out this header incorrectly. 97 [I-D.ietf-anima-bootstrapping-keyinfra] extends [RFC7030], adding new 98 functionality, and interop testing of the protocol has revealed that 99 unusual processing called out in [RFC7030] causes confusion. 101 EST is currently specified as part of IEC 62351, and is widely used 102 in Government, Utilities and Financial markets today. 104 Changes to [RFC7030] to bring it inline with typical HTTP processing 105 would change the on-wire protocol in a way that is not backwards 106 compatible. Reports from the field suggest that many implementations 107 do not send the Content-Transfer-Encoding, and many of them ignore 108 it. 110 This document therefore revises [RFC7030] to reflect the field 111 reality, deprecating the extranous field. 113 This document deals with errata numbers [errata4384], [errata5107], 114 and [errata5108]. 116 2. Terminology 118 The abbreviation "CTE" is used to denote the Content-Transfer- 119 Encoding header, and the abbreviation "CTE-base64" is used to denote 120 a request or response whose Content-Transfer-Encoding header contains 121 the value "base64". 123 3. Requirements Language 125 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 126 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 127 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 128 [RFC2119] and indicate requirement levels for compliant STuPiD 129 implementations. 131 4. Changes to EST endpoint processing 133 The [RFC7030] sections 4.1.3 (CA Certificates Response, /cacerts), 134 4.3.1/4.3.2 (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation, 135 /serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) specify the use 136 of base64 encoding with a Content-Transfer-Encoding for requests and 137 response. 139 This document updates [RFC7030] to require the POST request and 140 payload response of all endpoints in to be [RFC4648] section 4 Base64 141 encoded DER. This format is to be used regardless of whether there 142 is any Content-Transfer-Encoding header, and any value in that header 143 is to be ignored. 145 5. Clarification of ASN.1 for Certificate Attribute set. 147 Section 4.5.2 of [RFC7030] is to be replaced with the following text: 149 5.1. CSR Attributes Response 151 If locally configured policy for an authenticated EST client 152 indicates a CSR Attributes Response is to be provided, the server 153 response MUST include an HTTP 200 response code. An HTTP response 154 code of 204 or 404 indicates that a CSR Attributes Response is not 155 available. Regardless of the response code, the EST server and CA 156 MAY reject any subsequent enrollment requests for any reason, e.g., 157 incomplete CSR attributes in the request. 159 Responses to attribute request messages MUST be encoded as the 160 content-type of "application/csrattrs", and are to be "base64" 161 [RFC2045] encoded. The syntax for application/csrattrs body is as 162 follows: 164 CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID 166 AttrOrOID ::= CHOICE { 167 oid OBJECT IDENTIFIER, 168 attribute Attribute {{AttrSet}} } 170 AttrSet ATTRIBUTE ::= { AttributesDefinedInRFC7030, ... } 172 An EST server includes zero or more OIDs or attributes [RFC2986] that 173 it requests the client to use in the certification request. The 174 client MUST ignore any OID or attribute it does not recognize. When 175 the server encodes CSR Attributes as an empty SEQUENCE, it means that 176 the server has no specific additional information it desires in a 177 client certification request (this is functionally equivalent to an 178 HTTP response code of 204 or 404). 180 If the CA requires a particular crypto system or use of a particular 181 signature scheme (e.g., certification of a public key based on a 182 certain elliptic curve, or signing using a certain hash algorithm) it 183 MUST provide that information in the CSR Attribute Response. If an 184 EST server requires the linking of identity and POP information (see 185 Section 3.5), it MUST include the challengePassword OID in the CSR 186 Attributes Response. 188 The structure of the CSR Attributes Response SHOULD, to the greatest 189 extent possible, reflect the structure of the CSR it is requesting. 190 Requests to use a particular signature scheme (e.g. using a 191 particular hash function) are represented as an OID to be reflected 192 in the SignatureAlgorithm of the CSR. Requests to use a particular 193 crypto system (e.g., certification of a public key based on a certain 194 elliptic curve) are represented as an attribute, to be reflected as 195 the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type 196 indicating the algorithm and the values indicating the particular 197 parameters specific to the algorithm. Requests for descriptive 198 information from the client are made by an attribute, to be 199 represented as Attributes of the CSR, with a type indicating the 200 [RFC2985] extensionRequest and the values indicating the particular 201 attributes desired to be included in the resulting certificate's 202 extensions. 204 The sequence is Distinguished Encoding Rules (DER) encoded [X690] and 205 then base64 encoded (Section 4 of [RFC4648]). The resulting text 206 forms the application/csrattr body, without headers. 208 For example, if a CA requests a client to submit a certification 209 request containing the challengePassword (indicating that linking of 210 identity and POP information is requested; see Section 3.5), an 211 extensionRequest with the Media Access Control (MAC) address 212 ([RFC2307]) of the client, and to use the secp384r1 elliptic curve 213 and to sign with the SHA384 hash function. Then, it takes the 214 following: 216 OID: challengePassword (1.2.840.113549.1.9.7) 218 Attribute: type = extensionRequest (1.2.840.113549.1.9.14) 219 value = macAddress (1.3.6.1.1.1.1.22) 221 Attribute: type = id-ecPublicKey (1.2.840.10045.2.1) 222 value = secp384r1 (1.3.132.0.34) 224 OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3) 226 and encodes them into an ASN.1 SEQUENCE to produce: ~~~ 30 41 06 09 227 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d 02 01 31 07 06 228 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01 09 0e 31 09 06 07 229 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03 03 ~~~ 231 and then base64 encodes the resulting ASN.1 SEQUENCE to produce: 233 MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ 234 BgcrBgEBAQEWBggqhkjOPQQDAw== 236 6. Clarification of error messages for certificate enrollment 237 operations 239 [errata5108] clarifies what format the error messages are to be in. 240 Previously a client might be confused into believing that an error 241 returned with type text/plain was not intended to be an error. 243 6.1. Updating section 4.2.3: Simple Enroll and Re-enroll Response 245 Replace: 247 If the content-type is not set, the response data MUST be a 248 plaintext human-readable error message containing explanatory 249 information describing why the request was rejected (for 250 example, indicating that CSR attributes are incomplete). 252 with: 254 If the content-type is not set, the response data must be a 255 plaintext human-readable error message containing explanatory 256 information describing why the request was rejected (for 257 example, indicating that CSR attributes are incomplete). 258 Servers MAY use the "text/plain" content-type [RFC2046] 259 for human-readable errors. 261 6.2. Updating section 4.4.2: Server-Side Key Generation Response 263 Replace: 265 If the content-type is not set, the response data MUST be a 266 plaintext human-readable error message. 268 with: 270 If the content-type is not set, the response data must be a 271 plaintext human-readable error message. 272 Servers MAY use the "text/plain" content-type [RFC2046] 273 for human-readable errors. 275 7. Privacy Considerations 277 This document does not disclose any additional identifies to either 278 active or passive observer would see with [RFC7030]. 280 8. Security Considerations 282 This document clarifies an existing security mechanism. It does not 283 create any new protocol mechanism. 285 9. IANA Considerations 287 The ASN.1 module in Appendix A of this doucment makes use of object 288 identifiers (OIDs). This document requests that IANA register an OID 289 in the SMI Security for PKIX Arc in the Module identifiers subarc 290 (1.3.6.1.5.5.7.0) for the ASN.1 module. The OID for the Asymmetric 291 Decryption Key Identifier (1.2.840.113549.1.9.16.2.54) was previously 292 defined in [RFC7030]. 294 IANA is requested to update the "Reference" column for the Asymmetric 295 Decryption Key Identifier attribute to also include a reference to 296 this doducment. 298 10. Acknowledgements 300 This work was supported by the Huawei Technologies. 302 The ASN.1 Module was assembled by Russ Housley and formatted by Sean 303 Turner. 305 11. References 307 11.1. Normative References 309 [I-D.ietf-anima-bootstrapping-keyinfra] 310 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 311 and K. Watsen, "Bootstrapping Remote Secure Key 312 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 313 keyinfra-37 (work in progress), February 2020. 315 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 316 Extensions (MIME) Part One: Format of Internet Message 317 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 318 . 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, 322 DOI 10.17487/RFC2119, March 1997, 323 . 325 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 326 Request Syntax Specification Version 1.7", RFC 2986, 327 DOI 10.17487/RFC2986, November 2000, 328 . 330 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 331 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 332 . 334 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 335 "Enrollment over Secure Transport", RFC 7030, 336 DOI 10.17487/RFC7030, October 2013, 337 . 339 [X680] ITU-T, "Information technology - Abstract Syntax Notation 340 One.", ISO/IEC 8824-1:2002, 2002. 342 [X681] ITU-T, "Information technology - Abstract Syntax Notation 343 One: Information Object Specification.", ISO/ 344 IEC 8824-2:2002, 2002. 346 [X682] ITU-T, "Information technology - Abstract Syntax Notation 347 One: Constraint Specification.", ISO/IEC 8824-2:2002, 348 2002. 350 [X683] ITU-T, "Information technology - Abstract Syntax Notation 351 One: Parameterization of ASN.1 Specifications.", ISO/ 352 IEC 8824-2:2002, 2002. 354 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 355 Specification of Basic Encoding Rules (BER), Canonical 356 Encoding Rules (CER) and Distinguished Encoding Rules 357 (DER).", ISO/IEC 8825-1:2002, 2002. 359 11.2. Informative References 361 [errata4384] 362 "EST errata 4384: ASN.1 encoding error", n.d., 363 . 365 [errata5107] 366 "EST errata 5107: use Content-Transfer-Encoding", n.d., 367 . 369 [errata5108] 370 "EST errata 5108: use of Content-Type for error message", 371 n.d., . 373 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 374 Information Service", RFC 2307, DOI 10.17487/RFC2307, 375 March 1998, . 377 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 378 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 379 Transfer Protocol -- HTTP/1.1", RFC 2616, 380 DOI 10.17487/RFC2616, June 1999, 381 . 383 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 384 Classes and Attribute Types Version 2.0", RFC 2985, 385 DOI 10.17487/RFC2985, November 2000, 386 . 388 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 389 Protocol (HTTP/1.1): Message Syntax and Routing", 390 RFC 7230, DOI 10.17487/RFC7230, June 2014, 391 . 393 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 394 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 395 DOI 10.17487/RFC7231, June 2014, 396 . 398 Appendix A. ASN.1 Module 400 This annex provides the normative ASN.1 definitions for the 401 structures described in this specification using ASN.1 as defined in 402 [X680] through [X683]. 404 There is no ASN.1 Module in RFC 7030. This module has been created 405 by combining the lines that are contained in the document body. 407 PKIXEST-2019 408 { iso(1) identified-organization(3) dod(6) 409 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 410 id-mod-est-2019(TBD) } 412 DEFINITIONS IMPLICIT TAGS ::= 413 BEGIN 415 -- EXPORTS ALL -- 417 IMPORTS 419 Attribute 420 FROM CryptographicMessageSyntax-2010 -- [RFC6268] 421 { iso(1) member-body(2) us(840) rsadsi(113549) 422 pkcs(1) pkcs-9(9) smime(16) modules(0) 423 id-mod-cms-2009(58) } 425 ATTRIBUTE 426 FROM PKIX-CommonTypes-2009 427 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 428 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; 430 -- CSR Attributes 432 CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID 434 AttrOrOID ::= CHOICE { 435 oid OBJECT IDENTIFIER, 436 attribute Attribute {{AttrSet}} } 438 AttrSet ATTRIBUTE ::= { AttributesDefinedInRFC7030, ... } 440 -- Asymmetric Decrypt Key Identifier Attribute 442 AttributesDefinedInRFC7030 ATTRIBUTE ::= { aa-asymmDecryptKeyID, ... } 444 aa-asymmDecryptKeyID ATTRIBUTE ::= 445 { TYPE AsymmetricDecryptKeyIdentifier 446 IDENTIFIED BY id-aa-asymmDecryptKeyID } 448 id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1) member-body(2) 449 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 54 } 451 AsymmetricDecryptKeyIdentifier ::= OCTET STRING 453 END 455 Authors' Addresses 457 Michael Richardson 458 Sandelman Software Works 460 Email: mcr+ietf@sandelman.ca 462 Thomas Werner 463 Siemens 465 Email: thomas-werner@siemens.com 466 Wei Pan 467 Huawei Technologies 469 Email: william.panwei@huawei.com