< draft-richardson-lamps-rfc7030est-clarify-00.txt   draft-richardson-lamps-rfc7030est-clarify-01.txt >
LAMPS Working Group M. Richardson LAMPS Working Group M. Richardson
Internet-Draft Sandelman Software Works Internet-Draft Sandelman Software Works
Intended status: Standards Track T. Werner Intended status: Standards Track T. Werner
Expires: December 19, 2019 Siemens Expires: December 19, 2019 Siemens
June 17, 2019 June 17, 2019
Clarification of Enrollment over Secure Transport (EST): transfer Clarification of Enrollment over Secure Transport (EST): transfer
encodings and ASN.1 encodings and ASN.1
draft-richardson-lamps-rfc7030est-clarify-00 draft-richardson-lamps-rfc7030est-clarify-01
Abstract Abstract
This document updates RFC7030: Enrollment over Secure Transport (EST) This document updates RFC7030: Enrollment over Secure Transport (EST)
to resolve some errata that was reported, and which has proven to to resolve some errata that was reported, and which has proven to
have interoperability when RFC7030 has been extended. have interoperability when RFC7030 has been extended.
This document deprecates the specification of "Content-Transfer- This document deprecates the specification of "Content-Transfer-
Encoding" headers for EST endpoints, providing a way to do this in an Encoding" headers for EST endpoints, providing a way to do this in an
upward compatible way. This document additional defines a GRASP upward compatible way. This document additional defines a GRASP
skipping to change at page 2, line 21 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
4. Changes to EST endpoint processing . . . . . . . . . . . . . 3 4. Changes to EST endpoint processing . . . . . . . . . . . . . 3
4.1. Client configuration . . . . . . . . . . . . . . . . . . 4 5. Clarification of ASN.1 for Certificate Attribute set. . . . . 4
4.2. Retrieval of certificate attributes . . . . . . . . . . . 4
5. Clarification of ASN.1 for Certificate Attribute set. . . . . 5
6. Clarification of error messages for certificate enrollment 6. Clarification of error messages for certificate enrollment
operations . . . . . . . . . . . . . . . . . . . . . . . . . 5 operations . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Definition of GRASP discovery for updated EST servers . . . . 5 7. Definition of GRASP discovery for updated EST servers . . . . 4
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 4
9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. Security Considerations . . . . . . . . . . . . . . . . . . . 4
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
12.1. Normative References . . . . . . . . . . . . . . . . . . 5 12.1. Normative References . . . . . . . . . . . . . . . . . . 4
12.2. Informative References . . . . . . . . . . . . . . . . . 6 12.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
{[RFC7030}} defines the Enrollment over Secure Transport, or EST {[RFC7030}} defines the Enrollment over Secure Transport, or EST
protocol. protocol.
This specification defines a number of HTTP end points for This specification defines a number of HTTP end points for
certificate enrollment and management. The details of the certificate enrollment and management. The details of the
transaction were defined in terms of MIME headers as defined in transaction were defined in terms of MIME headers as defined in
[RFC2045], rather than in terms of the HTTP protocol as defined in [RFC2045], rather than in terms of the HTTP protocol as defined in
[RFC2616] and [RFC7230]. [RFC2616] and [RFC7230].
[RFC2616] has text specifically deprecating Content-Transfer- [RFC2616] has text specifically deprecating Content-Transfer-
Encoding. [RFC7030] calls it out this header incorrectly. Encoding. [RFC7030] calls it out this header incorrectly.
[I-D.ietf-anima-bootstrapping-keyinfra] extends [RFC7030], adding new [I-D.ietf-anima-bootstrapping-keyinfra] extends [RFC7030], adding new
functionality, and interop testing of the protocol has revealed that functionality, and interop testing of the protocol has revealed that
unusual processing called out in [RFC7030] causes confusion. unusual processing called out in [RFC7030] causes confusion.
EST is currently specified as part of IEC 62351, and is widely used
in Government, Utilities and Financial markets today.
Changes to [RFC7030] to bring it inline with typical HTTP processing Changes to [RFC7030] to bring it inline with typical HTTP processing
would change the on-wire protocol in a way that is not backwards would change the on-wire protocol in a way that is not backwards
compatible. This document provides a compromise that moves towards compatible. Reports from the field suggest that many implementations
the correct behaviour without breaking existing deployments. do not send the Content-Transfer-Encoding, and many of them ignore
it.
This document therefore revises [RFC7030] to reflect the field
reality, deprecating the extranous field.
This document deals with errata numbers [errata4384], [errata5107], This document deals with errata numbers [errata4384], [errata5107],
and [errata5108]. and [errata5108].
2. Terminology 2. Terminology
This document uses the term "amended server" to refer to an EST
server that complies with the changes in this document. The term
"legacy EST server" refers to servers that do not support the changes
in this document.
The term "BRSKI EST server" refers to an EST server that also
supports the mechanisms described in
[I-D.ietf-anima-bootstrapping-keyinfra].
The abbreviation "CTE" is used to denote the Content-Transfer- The abbreviation "CTE" is used to denote the Content-Transfer-
Encoding header, and the abbreviation "CTE-base64" is used to denote Encoding header, and the abbreviation "CTE-base64" is used to denote
a request or response whose Content-Transfer-Encoding header contains a request or response whose Content-Transfer-Encoding header contains
the value "base64". the value "base64".
3. Requirements Language 3. Requirements Language
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant STuPiD [RFC2119] and indicate requirement levels for compliant STuPiD
implementations. implementations.
4. Changes to EST endpoint processing 4. Changes to EST endpoint processing
[RFC7030] sections 4.1.3 (CA Certificates Response, /cacerts), The [RFC7030] sections 4.1.3 (CA Certificates Response, /cacerts),
4.3.1/4.3.2 (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation, 4.3.1/4.3.2 (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation,
/serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) specify the use /serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) specify the use
of base64 encoding with a Content-Transsfer-Encoding for requests and of base64 encoding with a Content-Transsfer-Encoding for requests and
response. response.
Both section 4.1.3 (CA certificate response), and Section 4.5.2, This document updates [RFC7030] to require the POST request and
/csrattrs is a GET operation, and will be dealt with below. payload response of all endpoints in to be [RFC4648] section 4 Base64
encoded DER. This format is to be used regardless of whether there
For the other three methods, when the client is aware that this is an is any Content-Transfer-Encoding header, and any value in that header
amended server then it SHOULD send the POST request in binary form is to be ignored.
(DER-encoded), and omit the Content-Transfer-Encoding header. How
the client knows what kind of server it is dealing with is
communicating with is detailed in the next section.
An amended server, when it receives a request that has no Content-
Transfer-Encoding header, or has a Content-Transfer-Encoding header
with the "binary" attribute, MUST respond in the same binary format.
When an amended server receives a request in CTE-base64 form, then it
MAY respond in kind. It is reasonable for a server to be configured
to ignore or fail requests of this form, either via run-time
configuration, or via a compile-time option. A main reason to do
this is to avoid a permutation that requires testing in the future
when no legacy EST clients are expected to connect.
4.1. Client configuration
[RFC7030] has some significant deployment. The protocol has no
version numbers or other ways to indicate that the format of the
operations has changed, and as the protocol is driven by a client
state machine, the client has to know whether it has to operate in
legacy EST server mode.
In certain market verticals it may be well known to client system
designers whether or not this is the case. In those cases, the out-
of-band configuration mechanism is appropriate.
Clients that start their process using
[I-D.ietf-anima-bootstrapping-keyinfra] SHOULD assume that the server
supports this amended specification.
Clients that discover an EST server in an ANIMA ACP via GRASP, using
the mechanism detailed in Section 7 SHOULD also assume that these
servers support this amended specification.
Other users or extensions for [RFC7030] should specify if clients are
to assume this amended specification or not.
4.2. Retrieval of certificate attributes
The 4.5.2 (CSR Attributes, /csrattrs) is a GET operation. It occurs
at the beginning of a transaction.
TBD how can the client indicate it is willing to accept an un-encoded
response?
The 4.1.3 (CA Certificates Response, /cacerts) is also a GET
operation, but it occurs after enrollment. The server SHOULD assume
that a client that wanted a binary response also wants a binary
response here.
5. Clarification of ASN.1 for Certificate Attribute set. 5. Clarification of ASN.1 for Certificate Attribute set.
errata 4384. errata 4384.
6. Clarification of error messages for certificate enrollment 6. Clarification of error messages for certificate enrollment
operations operations
errata 5108. errata 5108.
7. Definition of GRASP discovery for updated EST servers 7. Definition of GRASP discovery for updated EST servers
An ANIMA ACP device can discover the location of the nearest EST An ANIMA ACP device can discover the location of the nearest EST
server using a [I-D.ietf-anima-grasp-api] M_DISCOVERY mechanism. server using a [I-D.ietf-anima-grasp-api] M_DISCOVERY mechanism.
objective = ["AN_EST", F_DISC, 255 ] objective = ["AN_EST", F_DISC, 255 ]
EST servers discovered in this way MUST support the amended server
mechanism described in this document. The response will include a
hostname and port number for a nearby EST server that can be used to
renew an ACP credential.
8. Privacy Considerations 8. Privacy Considerations
This document does not disclose any additional identifies to either This document does not disclose any additional identifies to either
active or passive observer would see with [RFC7030]. active or passive observer would see with [RFC7030].
9. Security Considerations 9. Security Considerations
This document clarifies an existing security mechanism. An option is This document clarifies an existing security mechanism. An option is
introduced to the security mechanism using an implicit negotiation. introduced to the security mechanism using an implicit negotiation.
skipping to change at page 6, line 22 skipping to change at page 5, line 16
Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic
Autonomic Signaling Protocol Application Program Interface Autonomic Signaling Protocol Application Program Interface
(GRASP API)", draft-ietf-anima-grasp-api-03 (work in (GRASP API)", draft-ietf-anima-grasp-api-03 (work in
progress), January 2019. progress), January 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
12.2. Informative References 12.2. Informative References
[errata4384] [errata4384]
"EST errata 4384: ASN.1 encoding error", n.d., "EST errata 4384: ASN.1 encoding error", n.d.,
<https://www.rfc-editor.org/errata/eid4384>. <https://www.rfc-editor.org/errata/eid4384>.
 End of changes. 10 change blocks. 
86 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/