Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1
updates
- rfc-7030 — Enrollment over Secure Transport
Extracted elements (24)
Errata 5108 addressed client confusion: without explicit permission to use 'text/plain', a client might not recognize that an error response with text/plain content-type was actually an error. The clarification allows servers to explicitly signal errors via content-type.
RFC 7030 incorrectly specified EST endpoints using MIME Content-Transfer-Encoding headers (RFC 2045) rather than HTTP transfer semantics, even though RFC 2616 and RFC 7231 Appendix A.5 had already deprecated that header. Field reality—most implementations neither send nor check the header—made simple deprecation backward-compatible.
This document resolves RFC 7030 errata 4384 (ASN.1 module errors), 5107 and 5904 (Content-Transfer-Encoding misuse in endpoint descriptions), and 5108 (ambiguous error message content-type handling). The fixes update normative text and introduce a corrected ASN.1 module.
BRSKI (draft-ietf-anima-bootstrapping-keyinfra), which extends RFC 7030, encountered interoperability problems during testing caused by the unusual Content-Transfer-Encoding processing required by RFC 7030, motivating this clarification.
Many EST implementations do not send the Content-Transfer-Encoding header and many receivers ignore it. This field reality meant that deprecating the header would remain compatible with deployed implementations without changing the on-wire protocol.
All EST endpoints that use base64 encoding MUST format their POST request bodies and payload responses as base64 per RFC 4648, with input produced via DER (X.690). This format applies regardless of any Content-Transfer-Encoding header; any value in such a header MUST be ignored.
Although RFC 2616 base64 does not permit CRLF, EST receivers SHOULD tolerate white space including CR, LF, spaces (ASCII 32), and tabs (ASCII 9) in base64-encoded bodies. Senders are not required to insert any white space.
For Server-Side Key Generation error responses where content-type is not set, the response data MUST be a plaintext human-readable error message; servers MAY use the 'text/plain' content-type (RFC 2046) for human-readable errors.
For Simple Enroll and Re-enroll error responses where content-type is not set, the response data MUST be a plaintext human-readable error message; servers MAY additionally use the 'text/plain' content-type (RFC 2046) for such errors.
If locally configured policy indicates a CSR Attributes Response is to be provided, the server response MUST include an HTTP 200 response code. An HTTP 204 or 404 indicates no CSR Attributes Response is available.
If the CA requires a particular cryptographic algorithm or signature scheme, it MUST provide that information in the CSR Attributes Response. If an EST server requires linking of identity and POP information, it MUST include the challengePassword OID (1.2.840.113549.1.9.7) in the CSR Attributes Response.
Responses to CSR attribute request messages MUST be encoded as content-type application/csrattrs and base64 encoded per RFC 4648. The ASN.1 structure is CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID.
The CSR Attributes Response structure SHOULD, to the greatest extent possible, reflect the structure of the CSR it is requesting, so that signature scheme requests appear as OIDs in SignatureAlgorithm and algorithm parameter requests appear as attributes in SubjectPublicKeyInfo.
The EST client MUST ignore any OID or attribute in a CSR Attributes Response that it does not recognize.
RFC 8951 does not disclose any additional identities that either an active or passive observer would see beyond what is already exposed by RFC 7030. The clarifications are encoding-level only and do not alter the identities exchanged.
For /serverkeygen, an application/pkcs8 part contains base64-encoded DER-encoded PrivateKeyInfo, and encrypted variants return EnvelopedData as application/pkcs7-mime with smime-type 'server-generated-key', both base64 encoded per RFC 4648, without Content-Transfer-Encoding headers.
The /cacerts (CA Certificates) response MUST be a certs-only CMC Simple PKI Response (RFC 5272) with content-type application/pkcs7-mime, encoded in base64 per RFC 4648. The previous requirement to use a Content-Transfer-Encoding of 'base64' is removed.
The /fullcmc POST request body MUST use content-type application/pkcs7-mime with smime-type parameter 'CMC-request' (RFC 5273), with the body encoded in base64 per RFC 4648, replacing the prior Content-Transfer-Encoding specification.
The /fullcmc response body (PKI Response) is encoded in base64 per RFC 4648, replacing the prior Content-Transfer-Encoding of 'base64' (RFC 2045) requirement.
IANA registered OID 1.3.6.1.5.5.7.0.98 (id-mod-est-2019) in the 'SMI Security for PKIX Module Identifier' registry for the ASN.1 module defined in Appendix A of this document.
The IANA 'SMI Security for S/MIME Attributes' registry entry for the Asymmetric Decryption Key Identifier attribute (OID 1.2.840.113549.1.9.16.2.54), previously defined in RFC 7030, has been updated to also reference RFC 8951.
RFC 8951 clarifies an existing security mechanism and does not create any new protocol mechanisms. All security considerations from RFC 7030 continue to apply without change.
AsymmetricDecryptKeyIdentifier is defined as OCTET STRING, identified by OID id-aa-asymmDecryptKeyID (1.2.840.113549.1.9.16.2.54), carried as the aa-asymmDecryptKeyID attribute in the ASN.1 module PKIXEST-2019.
CsrAttrs is an ASN.1 SEQUENCE of AttrOrOID elements; AttrOrOID is a CHOICE between an OBJECT IDENTIFIER (oid) and an Attribute constrained by AttrSet. The sequence is DER-encoded (X.690) then base64-encoded to form the application/csrattrs body.