idnits 2.17.1 draft-ietf-lamps-rfc7030est-clarify-05.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 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 date (May 06, 2020) is 1451 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 278, but not defined == Unused Reference: 'RFC8179' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'X681' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'X682' is defined on line 389, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IEC62351' ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Downref: Normative reference to an Informational RFC: RFC 5912 ** Downref: Normative reference to an Informational RFC: RFC 6268 -- 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' == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-41 -- 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: 3 errors (**), 0 flaws (~~), 7 warnings (==), 11 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 Updates: RFC7030 (if approved) T. Werner 5 Intended status: Standards Track Siemens 6 Expires: November 7, 2020 W. Pan 7 Huawei Technologies 8 May 06, 2020 10 Clarification of Enrollment over Secure Transport (EST): transfer 11 encodings and ASN.1 12 draft-ietf-lamps-rfc7030est-clarify-05 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 cause interoperability issues when RFC7030 was extended. 20 This document deprecates the specification of "Content-Transfer- 21 Encoding" headers for EST endpoints. This document fixes some 22 syntactical errors in ASN.1 that was presented. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 7, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Changes to EST endpoint processing . . . . . . . . . . . . . 3 61 3.1. Whitespace processing . . . . . . . . . . . . . . . . . . 4 62 4. Clarification of ASN.1 for Certificate Attribute set. . . . . 4 63 4.1. CSR Attributes Response . . . . . . . . . . . . . . . . . 4 64 5. Clarification of error messages for certificate enrollment 65 operations . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. Updating section 4.2.3: Simple Enroll and Re-enroll 67 Response . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5.2. Updating section 4.4.2: Server-Side Key Generation 69 Response . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 10.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 10 78 Appendix B. FAKE REFERENCES . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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. However, [RFC7030] 94 incorrectly uses this header. 96 Changes to [RFC7030] to bring it inline with typical HTTP processing 97 risk changes the on-wire protocol in a way that is not backwards 98 compatible. However, reports from the implementers suggest that many 99 implementations do not send the Content-Transfer-Encoding, and many 100 of them ignore it. The consequence is that simply deprecating the 101 header would remain compatible with current implementations. 103 [I-D.ietf-anima-bootstrapping-keyinfra] extends [RFC7030], adding new 104 functionality, and interop testing of the protocol has revealed that 105 unusual processing called out in [RFC7030] causes confusion. 107 EST is currently specified as part of [IEC62351], and is widely used 108 in Government, Utilities and Financial markets today. 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 [errata5108], and [errata5904]. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in 121 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 3. Changes to EST endpoint processing 126 The [RFC7030] sections 4.1.3 (CA Certificates Response, /cacerts), 127 4.3.1/4.3.2 (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation, 128 /serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) specify the use 129 of base64 encoding with a Content-Transfer-Encoding for requests and 130 response. 132 This document updates [RFC7030] to require the POST request and 133 payload response of all endpoints use Base64 encoding as specified in 134 Section 4 of [RFC4648]. In both cases, the Distinguished Encoding 135 Rules (DER) [X690] are used to produce the input for the Base64 136 encoding routine. This format is to be used regardless of any 137 Content-Transfer-Encoding header, and any value in such a header MUST 138 be ignored. 140 3.1. Whitespace processing 142 Note that "base64" as used in the HTTP [RFC2616] does not permit 143 CRLF, while the "base64" used in MIME [RFC2045] does. This 144 specification clarifies that despite [RFC2616], that white space 145 including CR, LF, spaces (ASCII 32) and, tabs (ASCII 9) should be 146 tolerated by receivers. Senders are not required to insert any kind 147 of white space. 149 4. Clarification of ASN.1 for Certificate Attribute set. 151 Section 4.5.2 of [RFC7030] is to be replaced with the following text: 153 4.1. CSR Attributes Response 155 If locally configured policy for an authenticated EST client 156 indicates a CSR Attributes Response is to be provided, the server 157 response MUST include an HTTP 200 response code. An HTTP response 158 code of 204 or 404 indicates that a CSR Attributes Response is not 159 available. Regardless of the response code, the EST server and CA 160 MAY reject any subsequent enrollment requests for any reason, e.g., 161 incomplete CSR attributes in the request. 163 Responses to attribute request messages MUST be encoded as the 164 content-type of "application/csrattrs", and are to be "base64" 165 [RFC2045] encoded. The syntax for application/csrattrs body is as 166 follows: 168 CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID 170 AttrOrOID ::= CHOICE { 171 oid OBJECT IDENTIFIER, 172 attribute Attribute {{AttrSet}} } 174 AttrSet ATTRIBUTE ::= { aa-asymmDecryptKeyID, ... } 176 An EST server includes zero or more OIDs or attributes [RFC2986] that 177 it requests the client to use in the certification request. The 178 client MUST ignore any OID or attribute it does not recognize. When 179 the server encodes CSR Attributes as an empty SEQUENCE, it means that 180 the server has no specific additional information it desires in a 181 client certification request (this is functionally equivalent to an 182 HTTP response code of 204 or 404). 184 If the CA requires a particular cryptographic algorithm or use of a 185 particular signature scheme (e.g., certification of a public key 186 based on a certain elliptic curve, or signing using a certain hash 187 algorithm) it MUST provide that information in the CSR Attribute 188 Response. If an EST server requires the linking of identity and POP 189 information (see Section 3.5), it MUST include the challengePassword 190 OID in the CSR Attributes Response. 192 The structure of the CSR Attributes Response SHOULD, to the greatest 193 extent possible, reflect the structure of the CSR it is requesting. 194 Requests to use a particular signature scheme (e.g. using a 195 particular hash function) are represented as an OID to be reflected 196 in the SignatureAlgorithm of the CSR. Requests to use a particular 197 cryptographic algorithm (e.g., certification of a public key based on 198 a certain elliptic curve) are represented as an attribute, to be 199 reflected as the AlgorithmIdentifier of the SubjectPublicKeyInfo, 200 with a type indicating the algorithm and the values indicating the 201 particular parameters specific to the algorithm. Requests for 202 descriptive information from the client are made by an attribute, to 203 be represented as Attributes of the CSR, with a type indicating the 204 [RFC2985] extensionRequest and the values indicating the particular 205 attributes desired to be included in the resulting certificate's 206 extensions. 208 The sequence is Distinguished Encoding Rules (DER) encoded [X690] and 209 then base64 encoded (Section 4 of [RFC4648]). The resulting text 210 forms the application/csrattr body, without headers. 212 For example, if a CA requests a client to submit a certification 213 request containing the challengePassword (indicating that linking of 214 identity and POP information is requested; see Section 3.5), an 215 extensionRequest with the Media Access Control (MAC) address 216 ([RFC2307]) of the client, and to use the secp384r1 elliptic curve 217 and to sign with the SHA384 hash function. Then, it takes the 218 following: 220 OID: challengePassword (1.2.840.113549.1.9.7) 222 Attribute: type = extensionRequest (1.2.840.113549.1.9.14) 223 value = macAddress (1.3.6.1.1.1.1.22) 225 Attribute: type = id-ecPublicKey (1.2.840.10045.2.1) 226 value = secp384r1 (1.3.132.0.34) 228 OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3) 230 and encodes them into an ASN.1 SEQUENCE to produce: 232 30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d 233 02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01 234 09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03 235 03 237 and then base64 encodes the resulting ASN.1 SEQUENCE to produce: 239 MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ 240 BgcrBgEBAQEWBggqhkjOPQQDAw== 242 5. Clarification of error messages for certificate enrollment 243 operations 245 [errata5108] clarifies what format the error messages are to be in. 246 Previously a client might be confused into believing that an error 247 returned with type text/plain was not intended to be an error. 249 5.1. Updating section 4.2.3: Simple Enroll and Re-enroll Response 251 Replace: 253 If the content-type is not set, the response data MUST be a 254 plaintext human-readable error message containing explanatory 255 information describing why the request was rejected (for 256 example, indicating that CSR attributes are incomplete). 258 with: 260 If the content-type is not set, the response data must be a 261 plaintext human-readable error message containing explanatory 262 information describing why the request was rejected (for 263 example, indicating that CSR attributes are incomplete). 264 Servers MAY use the "text/plain" content-type [RFC2046] 265 for human-readable errors. 267 5.2. Updating section 4.4.2: Server-Side Key Generation Response 269 Replace: 271 If the content-type is not set, the response data MUST be a 272 plaintext human-readable error message. 274 with: 276 If the content-type is not set, the response data must be a 277 plaintext human-readable error message. 278 Servers MAY use the "text/plain" content-type [RFC2046] 279 for human-readable errors. 281 6. Privacy Considerations 283 This document does not disclose any additional identifies to either 284 active or passive observer would see with [RFC7030]. 286 7. Security Considerations 288 This document clarifies an existing security mechanism. It does not 289 create any new protocol mechanism. 291 8. IANA Considerations 293 The ASN.1 module in Appendix A of this doucment makes use of object 294 identifiers (OIDs). This document requests that IANA register an OID 295 in the SMI Security for PKIX Arc in the Module identifiers subarc 296 (1.3.6.1.5.5.7.0) for the ASN.1 module. The OID for the Asymmetric 297 Decryption Key Identifier (1.2.840.113549.1.9.16.2.54) was previously 298 defined in [RFC7030]. 300 IANA is requested to update the "Reference" column for the Asymmetric 301 Decryption Key Identifier attribute to also include a reference to 302 this doducment. 304 9. Acknowledgements 306 This work was supported by Huawei Technologies. 308 The ASN.1 Module was assembled by Russ Housley and formatted by Sean 309 Turner. Russ Housley provided editorial review. 311 10. References 313 10.1. Normative References 315 [errata4384] 316 "EST errata 4384: ASN.1 encoding error", n.d., 317 . 319 [errata5107] 320 "EST errata 5107: use Content-Transfer-Encoding", n.d., 321 . 323 [errata5108] 324 "EST errata 5108: use of Content-Type for error message", 325 n.d., . 327 [errata5904] 328 "EST errata 5904: use Content-Transfer-Encoding", n.d., 329 . 331 [IEC62351] 332 International Electrotechnical Commission, "Power systems 333 management and associated information exchange - Data and 334 communications security - Part 9: Cyber security key 335 management for power system equipment", ISO/ 336 IEC 62351-9:2017, 2017. 338 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 339 Extensions (MIME) Part One: Format of Internet Message 340 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 341 . 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, 345 DOI 10.17487/RFC2119, March 1997, 346 . 348 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 349 Request Syntax Specification Version 1.7", RFC 2986, 350 DOI 10.17487/RFC2986, November 2000, 351 . 353 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 354 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 355 . 357 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 358 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 359 DOI 10.17487/RFC5912, June 2010, 360 . 362 [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules 363 for the Cryptographic Message Syntax (CMS) and the Public 364 Key Infrastructure Using X.509 (PKIX)", RFC 6268, 365 DOI 10.17487/RFC6268, July 2011, 366 . 368 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 369 "Enrollment over Secure Transport", RFC 7030, 370 DOI 10.17487/RFC7030, October 2013, 371 . 373 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 374 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 375 May 2017, . 377 [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property 378 Rights in IETF Technology", BCP 79, RFC 8179, 379 DOI 10.17487/RFC8179, May 2017, 380 . 382 [X680] ITU-T, "Information technology - Abstract Syntax Notation 383 One.", ISO/IEC 8824-1:2002, 2002. 385 [X681] ITU-T, "Information technology - Abstract Syntax Notation 386 One: Information Object Specification.", ISO/ 387 IEC 8824-2:2002, 2002. 389 [X682] ITU-T, "Information technology - Abstract Syntax Notation 390 One: Constraint Specification.", ISO/IEC 8824-2:2002, 391 2002. 393 [X683] ITU-T, "Information technology - Abstract Syntax Notation 394 One: Parameterization of ASN.1 Specifications.", ISO/ 395 IEC 8824-2:2002, 2002. 397 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 398 Specification of Basic Encoding Rules (BER), Canonical 399 Encoding Rules (CER) and Distinguished Encoding Rules 400 (DER).", ISO/IEC 8825-1:2002, 2002. 402 10.2. Informative References 404 [I-D.ietf-anima-bootstrapping-keyinfra] 405 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 406 and K. Watsen, "Bootstrapping Remote Secure Key 407 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 408 keyinfra-41 (work in progress), April 2020. 410 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 411 Information Service", RFC 2307, DOI 10.17487/RFC2307, 412 March 1998, . 414 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 415 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 416 Transfer Protocol -- HTTP/1.1", RFC 2616, 417 DOI 10.17487/RFC2616, June 1999, 418 . 420 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 421 Classes and Attribute Types Version 2.0", RFC 2985, 422 DOI 10.17487/RFC2985, November 2000, 423 . 425 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 426 Protocol (HTTP/1.1): Message Syntax and Routing", 427 RFC 7230, DOI 10.17487/RFC7230, June 2014, 428 . 430 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 431 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 432 DOI 10.17487/RFC7231, June 2014, 433 . 435 Appendix A. ASN.1 Module 437 This annex provides the normative ASN.1 definitions for the 438 structures described in this specification using ASN.1 as defined in 439 [X680] through [X683]. 441 There is no ASN.1 Module in RFC 7030. This module has been created 442 by combining the lines that are contained in the document body. 444 PKIXEST-2019 445 { iso(1) identified-organization(3) dod(6) 446 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 447 id-mod-est-2019(TBD) } 449 DEFINITIONS IMPLICIT TAGS ::= 450 BEGIN 452 -- EXPORTS ALL -- 454 IMPORTS 456 Attribute 457 FROM CryptographicMessageSyntax-2010 -- [RFC6268] 458 { iso(1) member-body(2) us(840) rsadsi(113549) 459 pkcs(1) pkcs-9(9) smime(16) modules(0) 460 id-mod-cms-2009(58) } 462 ATTRIBUTE 463 FROM PKIX-CommonTypes-2009 -- [RFC5912] 464 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 465 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; 467 -- CSR Attributes 469 CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID 471 AttrOrOID ::= CHOICE { 472 oid OBJECT IDENTIFIER, 473 attribute Attribute {{AttrSet}} } 475 AttrSet ATTRIBUTE ::= { aa-asymmDecrytKeyID, ... } 477 -- Asymmetric Decrypt Key Identifier Attribute 479 aa-asymmDecryptKeyID ATTRIBUTE ::= 480 { TYPE AsymmetricDecryptKeyIdentifier 481 IDENTIFIED BY id-aa-asymmDecryptKeyID } 483 id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1) member-body(2) 484 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 54 } 486 AsymmetricDecryptKeyIdentifier ::= OCTET STRING 488 END 490 Appendix B. FAKE REFERENCES 492 RFC-EDITOR: please remove this section. It exists just to reference 493 [RFC6268] and [RFC5912]. 495 Authors' Addresses 497 Michael Richardson 498 Sandelman Software Works 500 Email: mcr+ietf@sandelman.ca 502 Thomas Werner 503 Siemens 505 Email: thomas-werner@siemens.com 507 Wei Pan 508 Huawei Technologies 510 Email: william.panwei@huawei.com