| RFC 8951 | Clarification of EST | November 2020 |
| Richardson, et al. | Standards Track | [Page] |
This document updates RFC 7030: Enrollment over Secure Transport to resolve some errata that were reported and that have proven to cause interoperability issues when RFC 7030 was extended.¶
This document deprecates the specification of "Content-Transfer-Encoding" headers for Enrollment over Secure Transport (EST) endpoints. This document fixes some syntactical errors in ASN.1 that were present.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc8951.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Enrollment over Secure Transport (EST) is defined in[RFC7030]. The EST specification defines a number of HTTP endpoints for certificate enrollment and management. The details of the transaction were defined in terms of MIME headers, as defined in[RFC2045], rather than in terms of the HTTP protocol, as defined in[RFC7230] and[RFC7231].¶
[RFC2616] and laterAppendix A.5 of [RFC7231] have text specifically deprecating Content-Transfer-Encoding. However,[RFC7030] incorrectly uses this header.¶
Any updates to[RFC7030] to bring it in line with HTTP processing risk changing the on-wire protocol in a way that is not backwards compatible. However, reports from implementers suggest that many implementations do not send the Content-Transfer-Encoding, and many of them ignore it. The consequence is that simply deprecating the header would remain compatible with current implementations.¶
[BRSKI] extends[RFC7030], adding new functionality. Interop testing of the protocol has revealed that unusual processing called out in[RFC7030] causes confusion.¶
EST is currently specified as part of[IEC62351] and is widely used in government, utilities, and financial markets today.¶
This document, therefore, revises[RFC7030] to reflect the field reality, deprecating the extraneous field.¶
This document deals with errata numbers[errata4384],[errata5107],[errata5108], and[errata5904].¶
This document deals with[errata5107] and[errata5904] inSection 3.[errata5108] is dealt with inSection 5.[errata4384] is closed by correcting the ASN.1 Module inSection 4.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Sections4.1.3 (CA Certificates Response, /cacerts),4.3.1 and4.3.2 (Full CMC, /fullcmc),4.4.2 (Server-Side Key Generation, /serverkeygen), and4.5.2 (CSR Attributes, /csrattrs) of[RFC7030] specify the use of base64 encoding with a Content-Transfer-Encoding for requests and responses.¶
This document updates[RFC7030] to require the POST request and payload response of all endpoints using base64 encoding, as specified inSection 4 of [RFC4648]. In both cases, the Distinguished Encoding Rules (DER)[X.690] are used to produce the input for the base64 encoding routine. This format is to be used regardless of any Content-Transfer-Encoding header, and any value in such a headerMUST be ignored.¶
Note that "base64" as used in the HTTP[RFC2616] does not permit CRLF, while the "base64" used in MIME[RFC2045] does. This specification clarifies that despite what[RFC2616] says, white space including CR, LF, spaces (ASCII 32), and tabs (ASCII 9)SHOULD be tolerated by receivers. Senders are not required to insert any kind of white space.¶
Replace:¶
A successful responseMUST be a certs-only CMC Simple PKI Response,as defined in[RFC5272], containing the certificates described in thefollowing paragraph. The HTTP content-type of"application/pkcs7-mime" is used. The Simple PKI Response is sentwith a Content-Transfer-Encoding of "base64"[RFC2045].¶
with:¶
A successful responseMUST be a certs-only CMC Simple PKI Response,as defined in[RFC5272], containing the certificates described in thefollowing paragraph. The HTTP content-type of"application/pkcs7-mime" is used. The CMC Simple PKI Response isencoded in base64[RFC4648].¶
Replace:¶
If the HTTP POST to /fullcmc is not a valid Full PKI Request, theserverMUST reject the message. The HTTP content-type used is"application/pkcs7-mime" with an smime-type parameter "CMC-request",as specified in[RFC5273]. The body of the message is the binaryvalue of the encoding of the PKI Request with aContent-Transfer-Encoding of "base64"[RFC2045].¶
with:¶
If the HTTP POST to /fullcmc is not a valid Full PKI Request, theserverMUST reject the message. The HTTP content-type used is"application/pkcs7-mime" with an smime-type parameter "CMC-request",as specified in[RFC5273]. The body of the message is encodedin base64[RFC4648].¶
Replace:¶
The body of the message is the binary value of the encoding of thePKI Response with a Content-Transfer-Encoding of "base64"[RFC2045].¶
with:¶
The body of the message is the base64[RFC4648] encoding of thePKI Response.¶
Replace:¶
An "application/pkcs8"part consists of the base64-encoded DER-encoded[X.690]PrivateKeyInfo with a Content-Transfer-Encoding of "base64"[RFC2045].¶
with:¶
An "application/pkcs8" part consists of the base64-encoded,DER-encoded[X.690] PrivateKeyInfo.¶
Replace:¶
In all three additional encryption cases, the EnvelopedData isreturned in the response as an "application/pkcs7-mime" part with ansmime-type parameter of "server-generated-key" and a Content-Transfer-Encoding of "base64".¶
with:¶
In all three additional encryption cases, the EnvelopedData isreturned in the response as an "application/pkcs7-mime" partwith an smime-type parameter of "server-generated-key". It isbase64 encoded[RFC4648].¶
Section 4.5.2 of [RFC7030] is to be replaced with the following text:¶
4.5.2 CSR Attributes Response¶
If locally configured policy for an authenticated EST client indicatesa CSR Attributes Response is to be provided, the server responseMUSTinclude an HTTP 200 response code. An HTTP response code of 204 or 404indicates that a CSR Attributes Response is not available. Regardlessof the response code, the EST server and CAMAY reject any subsequentenrollment requests for any reason, e.g., incomplete CSR attributes inthe request.¶
Responses to attribute request messagesMUST be encoded as thecontent-type of "application/csrattrs" and are to be "base64"[RFC4648]encoded. The syntax for application/csrattrs body is as follows:¶
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOIDAttrOrOID ::= CHOICE { oid OBJECT IDENTIFIER, attribute Attribute {{AttrSet}} }AttrSet ATTRIBUTE ::= { ... }¶An EST server includes zero or more OIDs or attributes[RFC2986] that it requests the client to use in the certification request. The clientMUST ignore any OID or attribute it does not recognize. When the server encodes CSR attributes as an empty SEQUENCE, it means that the server has no specific additional information it desires in a client certification request (this is functionally equivalent to an HTTP response code of 204 or 404).¶
If the CA requires a particular cryptographic algorithm or use of a particularsignature scheme (e.g., certification of a public key based on acertain elliptic curve or signing using a certain hash algorithm), itMUST provide that information in the CSR Attribute Response. If anEST server requires the linking of identity and POP information (seeSection 3.5), itMUST include the challengePassword OID in the CSRAttributes Response.¶
The structure of the CSR Attributes ResponseSHOULD, to the greatestextent possible, reflect the structure of the CSR it is requesting.Requests to use a particular signature scheme (e.g., using aparticular hash function) are represented as an OID to be reflectedin the SignatureAlgorithm of the CSR. Requests to use a particularcryptographic algorithm (e.g., certification of a public key based on a certainelliptic curve) are represented as an attribute, to be reflected asthe AlgorithmIdentifier of the SubjectPublicKeyInfo, with a typeindicating the algorithm and the values indicating the particularparameters specific to the algorithm. Requests for descriptiveinformation from the client are made by an attribute, to berepresented as Attributes of the CSR, with a type indicating the[RFC2985] extensionRequest and the values indicating the particularattributes desired to be included in the resulting certificate'sextensions.¶
The sequence is Distinguished Encoding Rules (DER) encoded[X.690] and then base64 encoded (Section 4 of [RFC4648]). The resulting text forms the application/csrattr body, without headers.¶
For example, if a CA requests that a client a) submit a certification request containing the challengePassword (indicating that linking of identity and POP information is requested; see Section3.5), b) submit an extensionRequest with the Media Access Control (MAC) address[RFC2307] of the client, and c) use the secp384r1 elliptic curve to sign using the SHA384 hash function, then it takes the following:¶
OID: challengePassword (1.2.840.113549.1.9.7) Attribute: type = extensionRequest (1.2.840.113549.1.9.14) value = macAddress (1.3.6.1.1.1.1.22) Attribute: type = id-ecPublicKey (1.2.840.10045.2.1) value = secp384r1 (1.3.132.0.34) OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3)¶and encodes them into an ASN.1 SEQUENCE to produce:¶
30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d 02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01 09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03 03¶and then base64 encodes the resulting ASN.1 SEQUENCE to produce:¶
MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ BgcrBgEBAQEWBggqhkjOPQQDAw==¶
[errata5108] clarifies what format the error messages are to be in. Previously, a client might be confused into believing that an error returned with type text/plain was not intended to be an error.¶
Replace:¶
If the content-type is not set, the response dataMUST be a plaintext human-readable error message containing explanatory information describing why the request was rejected (for example, indicating that CSR attributes are incomplete).¶
with:¶
If the content-type is not set, the response dataMUST be a plaintext human-readable error message containing explanatory information describing why the request was rejected (for example, indicating that CSR attributes are incomplete). ServersMAY use the "text/plain" content-type[RFC2046] for human-readable errors.¶
Replace:¶
If the content-type is not set, the response dataMUST be a plaintext human-readable error message.¶
with:¶
If the content-type is not set, the response dataMUST be a plaintext human-readable error message. ServersMAY use the "text/plain" content-type[RFC2046] for human-readable errors.¶
This document does not disclose any additional identities that either an active or passive observer would see with[RFC7030].¶
This document clarifies an existing security mechanism.It does not create any new protocol mechanisms.¶
All security considerations from[RFC7030] also apply to the clarifications described in this document.¶
The ASN.1 module inAppendix A of this document makes use of object identifiers (OIDs).¶
IANA has registered an OID for id-mod-est-2019 (1.3.6.1.5.5.7.0.98) in the "SMI Security for PKIX Module Identifier" registry for the ASN.1 module.¶
The OID for the Asymmetric Decryption Key Identifier (1.2.840.113549.1.9.16.2.54) was previously defined in[RFC7030]. IANA has updated the Reference column for the Asymmetric Decryption Key Identifier attribute to also include a reference to this document.¶
This annex provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in[X.680],[X.681],[X.682], and[X.683].¶
The ASN.1 modules makes imports from the ASN.1 modules in[RFC5912] and[RFC6268].¶
There is no ASN.1 Module in[RFC7030]. This module has been created by combining the lines that are contained in the document body.¶
PKIXEST-2019 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-est-2019(98) }DEFINITIONS IMPLICIT TAGS ::=BEGIN-- EXPORTS ALL --IMPORTSAttributeFROM CryptographicMessageSyntax-2010 -- [RFC6268] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }ATTRIBUTEFROM PKIX-CommonTypes-2009 -- [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ;-- CSR AttributesCsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOIDAttrOrOID ::= CHOICE { oid OBJECT IDENTIFIER, attribute Attribute {{AttrSet}} }AttrSet ATTRIBUTE ::= { ... }-- Asymmetric Decrypt Key Identifier Attributeaa-asymmDecryptKeyID ATTRIBUTE ::= { TYPE AsymmetricDecryptKeyIdentifier IDENTIFIED BY id-aa-asymmDecryptKeyID }id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 54 }AsymmetricDecryptKeyIdentifier ::= OCTET STRINGEND¶Huawei Technologies supported the efforts ofWei Pan andMichael Richardson.¶
The ASN.1 Module was assembled byRuss Housley and formatted bySean Turner.Russ Housley provided editorial review.¶