idnits 2.17.1 draft-richardson-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 (June 17, 2019) is 1772 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) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-21 == Outdated reference: A later version (-10) exists of draft-ietf-anima-grasp-api-03 ** Downref: Normative reference to an Informational draft: draft-ietf-anima-grasp-api (ref. 'I-D.ietf-anima-grasp-api') -- 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) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 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: December 19, 2019 Siemens 6 June 17, 2019 8 Clarification of Enrollment over Secure Transport (EST): transfer 9 encodings and ASN.1 10 draft-richardson-lamps-rfc7030est-clarify-00 12 Abstract 14 This document updates RFC7030: Enrollment over Secure Transport (EST) 15 to resolve some errata that was reported, and which has proven to 16 have interoperability when RFC7030 has been extended. 18 This document deprecates the specification of "Content-Transfer- 19 Encoding" headers for EST endpoints, providing a way to do this in an 20 upward compatible way. This document additional defines a GRASP 21 discovery mechanism for EST endpoints, and specifies requirements for 22 them. 24 Finally, this document fixes some syntactical errors in ASN.1 that 25 was presented. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 19, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 4. Changes to EST endpoint processing . . . . . . . . . . . . . 3 65 4.1. Client configuration . . . . . . . . . . . . . . . . . . 4 66 4.2. Retrieval of certificate attributes . . . . . . . . . . . 4 67 5. Clarification of ASN.1 for Certificate Attribute set. . . . . 5 68 6. Clarification of error messages for certificate enrollment 69 operations . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 7. Definition of GRASP discovery for updated EST servers . . . . 5 71 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 12.1. Normative References . . . . . . . . . . . . . . . . . . 5 77 12.2. Informative References . . . . . . . . . . . . . . . . . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 {[RFC7030}} defines the Enrollment over Secure Transport, or EST 83 protocol. 85 This specification defines a number of HTTP end points for 86 certificate enrollment and management. The details of the 87 transaction were defined in terms of MIME headers as defined in 88 [RFC2045], rather than in terms of the HTTP protocol as defined in 89 [RFC2616] and [RFC7230]. 91 [RFC2616] has text specifically deprecating Content-Transfer- 92 Encoding. [RFC7030] calls it out this header incorrectly. 94 [I-D.ietf-anima-bootstrapping-keyinfra] extends [RFC7030], adding new 95 functionality, and interop testing of the protocol has revealed that 96 unusual processing called out in [RFC7030] causes confusion. 98 Changes to [RFC7030] to bring it inline with typical HTTP processing 99 would change the on-wire protocol in a way that is not backwards 100 compatible. This document provides a compromise that moves towards 101 the correct behaviour without breaking existing deployments. 103 This document deals with errata numbers [errata4384], [errata5107], 104 and [errata5108]. 106 2. Terminology 108 This document uses the term "amended server" to refer to an EST 109 server that complies with the changes in this document. The term 110 "legacy EST server" refers to servers that do not support the changes 111 in this document. 113 The term "BRSKI EST server" refers to an EST server that also 114 supports the mechanisms described in 115 [I-D.ietf-anima-bootstrapping-keyinfra]. 117 The abbreviation "CTE" is used to denote the Content-Transfer- 118 Encoding header, and the abbreviation "CTE-base64" is used to denote 119 a request or response whose Content-Transfer-Encoding header contains 120 the value "base64". 122 3. Requirements Language 124 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 125 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 126 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 127 [RFC2119] and indicate requirement levels for compliant STuPiD 128 implementations. 130 4. Changes to EST endpoint processing 132 [RFC7030] sections 4.1.3 (CA Certificates Response, /cacerts), 133 4.3.1/4.3.2 (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation, 134 /serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) specify the use 135 of base64 encoding with a Content-Transsfer-Encoding for requests and 136 response. 138 Both section 4.1.3 (CA certificate response), and Section 4.5.2, 139 /csrattrs is a GET operation, and will be dealt with below. 141 For the other three methods, when the client is aware that this is an 142 amended server then it SHOULD send the POST request in binary form 143 (DER-encoded), and omit the Content-Transfer-Encoding header. How 144 the client knows what kind of server it is dealing with is 145 communicating with is detailed in the next section. 147 An amended server, when it receives a request that has no Content- 148 Transfer-Encoding header, or has a Content-Transfer-Encoding header 149 with the "binary" attribute, MUST respond in the same binary format. 151 When an amended server receives a request in CTE-base64 form, then it 152 MAY respond in kind. It is reasonable for a server to be configured 153 to ignore or fail requests of this form, either via run-time 154 configuration, or via a compile-time option. A main reason to do 155 this is to avoid a permutation that requires testing in the future 156 when no legacy EST clients are expected to connect. 158 4.1. Client configuration 160 [RFC7030] has some significant deployment. The protocol has no 161 version numbers or other ways to indicate that the format of the 162 operations has changed, and as the protocol is driven by a client 163 state machine, the client has to know whether it has to operate in 164 legacy EST server mode. 166 In certain market verticals it may be well known to client system 167 designers whether or not this is the case. In those cases, the out- 168 of-band configuration mechanism is appropriate. 170 Clients that start their process using 171 [I-D.ietf-anima-bootstrapping-keyinfra] SHOULD assume that the server 172 supports this amended specification. 174 Clients that discover an EST server in an ANIMA ACP via GRASP, using 175 the mechanism detailed in Section 7 SHOULD also assume that these 176 servers support this amended specification. 178 Other users or extensions for [RFC7030] should specify if clients are 179 to assume this amended specification or not. 181 4.2. Retrieval of certificate attributes 183 The 4.5.2 (CSR Attributes, /csrattrs) is a GET operation. It occurs 184 at the beginning of a transaction. 186 TBD how can the client indicate it is willing to accept an un-encoded 187 response? 189 The 4.1.3 (CA Certificates Response, /cacerts) is also a GET 190 operation, but it occurs after enrollment. The server SHOULD assume 191 that a client that wanted a binary response also wants a binary 192 response here. 194 5. Clarification of ASN.1 for Certificate Attribute set. 196 errata 4384. 198 6. Clarification of error messages for certificate enrollment 199 operations 201 errata 5108. 203 7. Definition of GRASP discovery for updated EST servers 205 An ANIMA ACP device can discover the location of the nearest EST 206 server using a [I-D.ietf-anima-grasp-api] M_DISCOVERY mechanism. 208 objective = ["AN_EST", F_DISC, 255 ] 210 EST servers discovered in this way MUST support the amended server 211 mechanism described in this document. The response will include a 212 hostname and port number for a nearby EST server that can be used to 213 renew an ACP credential. 215 8. Privacy Considerations 217 This document does not disclose any additional identifies to either 218 active or passive observer would see with [RFC7030]. 220 9. Security Considerations 222 This document clarifies an existing security mechanism. An option is 223 introduced to the security mechanism using an implicit negotiation. 225 10. IANA Considerations 227 Allocate the name AN_EST from the [I-D.ietf-anima-grasp-api] "GRASP 228 Objective Names Table". 230 11. Acknowledgements 232 This work was supported by the Huawei Technologies. 234 12. References 236 12.1. Normative References 238 [I-D.ietf-anima-bootstrapping-keyinfra] 239 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 240 S., and K. Watsen, "Bootstrapping Remote Secure Key 241 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 242 keyinfra-21 (work in progress), June 2019. 244 [I-D.ietf-anima-grasp-api] 245 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 246 Autonomic Signaling Protocol Application Program Interface 247 (GRASP API)", draft-ietf-anima-grasp-api-03 (work in 248 progress), January 2019. 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, 252 DOI 10.17487/RFC2119, March 1997, 253 . 255 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 256 "Enrollment over Secure Transport", RFC 7030, 257 DOI 10.17487/RFC7030, October 2013, 258 . 260 12.2. Informative References 262 [errata4384] 263 "EST errata 4384: ASN.1 encoding error", n.d., 264 . 266 [errata5107] 267 "EST errata 5107: use Content-Transfer-Encoding", n.d., 268 . 270 [errata5108] 271 "EST errata 5108: use of Content-Type for error message", 272 n.d., . 274 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 275 Extensions (MIME) Part One: Format of Internet Message 276 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 277 . 279 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 280 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 281 Transfer Protocol -- HTTP/1.1", RFC 2616, 282 DOI 10.17487/RFC2616, June 1999, 283 . 285 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 286 Protocol (HTTP/1.1): Message Syntax and Routing", 287 RFC 7230, DOI 10.17487/RFC7230, June 2014, 288 . 290 Authors' Addresses 292 Michael Richardson 293 Sandelman Software Works 295 Email: mcr+ietf@sandelman.ca 297 Thomas Werner 298 Siemens 300 Email: thomas.werner@siemens.com