idnits 2.17.1 draft-ietf-lamps-rfc7030est-clarify-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 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 (January 03, 2020) is 1575 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 379, but not defined == Unused Reference: 'X681' is defined on line 302, but no explicit reference was found in the text == Unused Reference: 'X682' is defined on line 306, but no explicit reference was found in the text == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-32 ** 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: July 6, 2020 Siemens 6 W. Pan 7 Huawei Technologies 8 January 03, 2020 10 Clarification of Enrollment over Secure Transport (EST): transfer 11 encodings and ASN.1 12 draft-ietf-lamps-rfc7030est-clarify-00 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 July 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 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 11.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 [RFC7030] defines the Enrollment over Secure Transport, or EST 80 protocol. 82 This specification defines a number of HTTP end points for 83 certificate enrollment and management. The details of the 84 transaction were defined in terms of MIME headers as defined in 85 [RFC2045], rather than in terms of the HTTP protocol as defined in 86 [RFC2616] and [RFC7230]. 88 [RFC2616] and later [RFC7231] Appendix A.5 has text specifically 89 deprecating Content-Transfer-Encoding. 91 [RFC7030] calls it out this header incorrectly. 93 [I-D.ietf-anima-bootstrapping-keyinfra] extends [RFC7030], adding new 94 functionality, and interop testing of the protocol has revealed that 95 unusual processing called out in [RFC7030] causes confusion. 97 EST is currently specified as part of IEC 62351, and is widely used 98 in Government, Utilities and Financial markets today. 100 Changes to [RFC7030] to bring it inline with typical HTTP processing 101 would change the on-wire protocol in a way that is not backwards 102 compatible. Reports from the field suggest that many implementations 103 do not send the Content-Transfer-Encoding, and many of them ignore 104 it. 106 This document therefore revises [RFC7030] to reflect the field 107 reality, deprecating the extranous field. 109 This document deals with errata numbers [errata4384], [errata5107], 110 and [errata5108]. 112 2. Terminology 114 The abbreviation "CTE" is used to denote the Content-Transfer- 115 Encoding header, and the abbreviation "CTE-base64" is used to denote 116 a request or response whose Content-Transfer-Encoding header contains 117 the value "base64". 119 3. Requirements Language 121 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 122 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 123 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 124 [RFC2119] and indicate requirement levels for compliant STuPiD 125 implementations. 127 4. Changes to EST endpoint processing 129 The [RFC7030] sections 4.1.3 (CA Certificates Response, /cacerts), 130 4.3.1/4.3.2 (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation, 131 /serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) specify the use 132 of base64 encoding with a Content-Transfer-Encoding for requests and 133 response. 135 This document updates [RFC7030] to require the POST request and 136 payload response of all endpoints in to be [RFC4648] section 4 Base64 137 encoded DER. This format is to be used regardless of whether there 138 is any Content-Transfer-Encoding header, and any value in that header 139 is to be ignored. 141 5. Clarification of ASN.1 for Certificate Attribute set. 143 Section 4.5.2 of [RFC7030] is to be replaced with the following text: 145 5.1. CSR Attributes Response 147 If locally configured policy for an authenticated EST client 148 indicates a CSR Attributes Response is to be provided, the server 149 response MUST include an HTTP 200 response code. An HTTP response 150 code of 204 or 404 indicates that a CSR Attributes Response is not 151 available. Regardless of the response code, the EST server and CA 152 MAY reject any subsequent enrollment requests for any reason, e.g., 153 incomplete CSR attributes in the request. 155 Responses to attribute request messages MUST be encoded as the 156 content-type of "application/csrattrs", and are to be "base64" 157 [RFC2045] encoded. The syntax for application/csrattrs body is as 158 follows: 160 CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID 162 AttrOrOID ::= CHOICE { 163 oid OBJECT IDENTIFIER, 164 attribute Attribute {{AttrSet}} } 166 AttrSet ATTRIBUTE ::= { AttributesDefinedInRFC7030, ... } 168 An EST server includes zero or more OIDs or attributes [RFC2986] that 169 it requests the client to use in the certification request. The 170 client MUST ignore any OID or attribute it does not recognize. When 171 the server encodes CSR Attributes as an empty SEQUENCE, it means that 172 the server has no specific additional information it desires in a 173 client certification request (this is functionally equivalent to an 174 HTTP response code of 204 or 404). 176 If the CA requires a particular crypto system or use of a particular 177 signature scheme (e.g., certification of a public key based on a 178 certain elliptic curve, or signing using a certain hash algorithm) it 179 MUST provide that information in the CSR Attribute Response. If an 180 EST server requires the linking of identity and POP information (see 181 Section 3.5), it MUST include the challengePassword OID in the CSR 182 Attributes Response. 184 The structure of the CSR Attributes Response SHOULD, to the greatest 185 extent possible, reflect the structure of the CSR it is requesting. 186 Requests to use a particular signature scheme (e.g. using a 187 particular hash function) are represented as an OID to be reflected 188 in the SignatureAlgorithm of the CSR. Requests to use a particular 189 crypto system (e.g., certification of a public key based on a certain 190 elliptic curve) are represented as an attribute, to be reflected as 191 the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type 192 indicating the algorithm and the values indicating the particular 193 parameters specific to the algorithm. Requests for descriptive 194 information from the client are made by an attribute, to be 195 represented as Attributes of the CSR, with a type indicating the 196 [RFC2985] extensionRequest and the values indicating the particular 197 attributes desired to be included in the resulting certificate's 198 extensions. 200 The sequence is Distinguished Encoding Rules (DER) encoded [X690] and 201 then base64 encoded (Section 4 of [RFC4648]). The resulting text 202 forms the application/csrattr body, without headers. 204 For example, if a CA requests a client to submit a certification 205 request containing the challengePassword (indicating that linking of 206 identity and POP information is requested; see Section 3.5), an 207 extensionRequest with the Media Access Control (MAC) address 208 ([RFC2307]) of the client, and to use the secp384r1 elliptic curve 209 and to sign with the SHA384 hash function. Then, it takes the 210 following: 212 OID: challengePassword (1.2.840.113549.1.9.7) 214 Attribute: type = extensionRequest (1.2.840.113549.1.9.14) 215 value = macAddress (1.3.6.1.1.1.1.22) 217 Attribute: type = id-ecPublicKey (1.2.840.10045.2.1) 218 value = secp384r1 (1.3.132.0.34) 220 OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3) 222 and encodes them into an ASN.1 SEQUENCE to produce: ~~~ 30 41 06 09 223 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d 02 01 31 07 06 224 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01 09 0e 31 09 06 07 225 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03 03 ~~~ 227 and then base64 encodes the resulting ASN.1 SEQUENCE to produce: 229 MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ 230 BgcrBgEBAQEWBggqhkjOPQQDAw== 232 6. Clarification of error messages for certificate enrollment 233 operations 235 errata 5108. 237 7. Privacy Considerations 239 This document does not disclose any additional identifies to either 240 active or passive observer would see with [RFC7030]. 242 8. Security Considerations 244 This document clarifies an existing security mechanism. An option is 245 introduced to the security mechanism using an implicit negotiation. 247 9. IANA Considerations 249 The ASN.1 module in Appendix A of this doucment makes use of object 250 identifiers (OIDs). This document requests that IANA register an OID 251 in the SMI Security for PKIX Arc in the Module identifiers subarc 252 (1.3.6.1.5.5.7.0) for the ASN.1 module. The OID for the Asymmetric 253 Decryption Key Identifier (1.2.840.113549.1.9.16.2.54) was previously 254 defined in [RFC7030]. IANA is requested to update the "Reference" 255 column for the Asymmetric Decryption Key Identifier attribute to also 256 include a reference to this doducment. 258 10. Acknowledgements 260 This work was supported by the Huawei Technologies. 262 The ASN.1 Module was assembled by Russ Housley and formatted by Sean 263 Turner. 265 11. References 267 11.1. Normative References 269 [I-D.ietf-anima-bootstrapping-keyinfra] 270 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 271 and K. Watsen, "Bootstrapping Remote Secure Key 272 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 273 keyinfra-32 (work in progress), December 2019. 275 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 276 Extensions (MIME) Part One: Format of Internet Message 277 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 278 . 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, 282 DOI 10.17487/RFC2119, March 1997, 283 . 285 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 286 Request Syntax Specification Version 1.7", RFC 2986, 287 DOI 10.17487/RFC2986, November 2000, 288 . 290 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 291 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 292 . 294 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 295 "Enrollment over Secure Transport", RFC 7030, 296 DOI 10.17487/RFC7030, October 2013, 297 . 299 [X680] ITU-T, "Information technology - Abstract Syntax Notation 300 One.", ISO/IEC 8824-1:2002, 2002. 302 [X681] ITU-T, "Information technology - Abstract Syntax Notation 303 One: Information Object Specification.", ISO/ 304 IEC 8824-2:2002, 2002. 306 [X682] ITU-T, "Information technology - Abstract Syntax Notation 307 One: Constraint Specification.", ISO/IEC 8824-2:2002, 308 2002. 310 [X683] ITU-T, "Information technology - Abstract Syntax Notation 311 One: Parameterization of ASN.1 Specifications.", ISO/ 312 IEC 8824-2:2002, 2002. 314 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 315 Specification of Basic Encoding Rules (BER), Canonical 316 Encoding Rules (CER) and Distinguished Encoding Rules 317 (DER).", ISO/IEC 8825-1:2002, 2002. 319 11.2. Informative References 321 [errata4384] 322 "EST errata 4384: ASN.1 encoding error", n.d., 323 . 325 [errata5107] 326 "EST errata 5107: use Content-Transfer-Encoding", n.d., 327 . 329 [errata5108] 330 "EST errata 5108: use of Content-Type for error message", 331 n.d., . 333 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 334 Information Service", RFC 2307, DOI 10.17487/RFC2307, 335 March 1998, . 337 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 338 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 339 Transfer Protocol -- HTTP/1.1", RFC 2616, 340 DOI 10.17487/RFC2616, June 1999, 341 . 343 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 344 Classes and Attribute Types Version 2.0", RFC 2985, 345 DOI 10.17487/RFC2985, November 2000, 346 . 348 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 349 Protocol (HTTP/1.1): Message Syntax and Routing", 350 RFC 7230, DOI 10.17487/RFC7230, June 2014, 351 . 353 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 354 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 355 DOI 10.17487/RFC7231, June 2014, 356 . 358 Appendix A. ASN.1 Module 360 This annex provides the normative ASN.1 definitions for the 361 structures described in this specification using ASN.1 as defined in 362 [X680] through [X683]. 364 There is no ASN.1 Module in RFC 7030. This module has been created 365 by combining the lines that are contained in the document body. 367 PKIXEST-2019 368 { iso(1) identified-organization(3) dod(6) 369 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 370 id-mod-est-2019(TBD) } 372 DEFINITIONS IMPLICIT TAGS ::= 373 BEGIN 375 -- EXPORTS ALL -- 376 IMPORTS 378 Attribute 379 FROM CryptographicMessageSyntax-2010 -- [RFC6268] 380 { iso(1) member-body(2) us(840) rsadsi(113549) 381 pkcs(1) pkcs-9(9) smime(16) modules(0) 382 id-mod-cms-2009(58) } 384 ATTRIBUTE 385 FROM PKIX-CommonTypes-2009 386 { iso(1) identified-organization(3) dod(6) internet(1) security(5) 387 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; 389 -- CSR Attributes 391 CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID 393 AttrOrOID ::= CHOICE { 394 oid OBJECT IDENTIFIER, 395 attribute Attribute {{AttrSet}} } 397 AttrSet ATTRIBUTE ::= { AttributesDefinedInRFC7030, ... } 399 -- Asymmetric Decrypt Key Identifier Attribute 401 AttributesDefinedInRFC7030 ATTRIBUTE ::= { aa-asymmDecryptKeyID, ... } 403 aa-asymmDecryptKeyID ATTRIBUTE ::= 404 { TYPE AsymmetricDecryptKeyIdentifier 405 IDENTIFIED BY id-aa-asymmDecryptKeyID } 407 id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1) member-body(2) 408 us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) aa(2) 54 } 410 AsymmetricDecryptKeyIdentifier ::= OCTET STRING 412 END 414 Authors' Addresses 416 Michael Richardson 417 Sandelman Software Works 419 Email: mcr+ietf@sandelman.ca 420 Thomas Werner 421 Siemens 423 Email: thomas-werner@siemens.com 425 Wei Pan 426 Huawei Technologies 428 Email: william.panwei@huawei.com