Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1

{[RFC7030}} defines the Enrollment over Secure Transport, or EST protocol. This specification defines a number of HTTP end points for certificate enrollment and management. The details of the transaction were defined in terms of MIME headers as defined in , rather than in terms of the HTTP protocol as defined in and . has text specifically deprecating Content-Transfer-Encoding. calls it out this header incorrectly. extends , adding new functionality, and interop testing of the protocol has revealed that unusual processing called out in causes confusion. Changes to to bring it inline with typical HTTP processing would change the on-wire protocol in a way that is not backwards compatible. This document provides a compromise that moves towards the correct behaviour without breaking existing deployments. This document deals with errata numbers , , and .

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 . The abbreviation "CTE" is used to denote the Content-Transfer-Encoding header, and the abbreviation "CTE-base64" is used to denote a request or response whose Content-Transfer-Encoding header contains the value "base64".

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and indicate requirement levels for compliant STuPiD implementations.

sections 4.1.3 (CA Certificates Response, /cacerts), 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 of base64 encoding with a Content-Transsfer-Encoding for requests and response. Both section 4.1.3 (CA certificate response), and Section 4.5.2, /csrattrs is a GET operation, and will be dealt with below. For the other three methods, when the client is aware that this is an amended server then it SHOULD send the POST request in binary form (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.

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 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 SHOULD also assume that these servers support this amended specification. Other users or extensions for should specify if clients are to assume this amended specification or not.

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.

errata 4384.

errata 5108.

An ANIMA ACP device can discover the location of the nearest EST server using a M_DISCOVERY mechanism. 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.

This document does not disclose any additional identifies to either active or passive observer would see with .

This document clarifies an existing security mechanism. An option is introduced to the security mechanism using an implicit negotiation.

Allocate the name AN_EST from the "GRASP Objective Names Table".

This work was supported by the Huawei Technologies.