Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1Sandelman Software Worksmcr+ietf@sandelman.caSiemensthomas-werner@siemens.comHuawei Technologieswilliam.panwei@huawei.com
Internet
LAMPS Working GroupThis 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.Status of This Memo
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 at
.
Copyright Notice
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
() 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.
Table of Contents
. Introduction
. Terminology
. Changes to EST Endpoint Processing
. White Space Processing
. Changes to Section 4 of RFC 7030
. Section 4.1.3
. Section 4.3.1
. Section 4.3.2
. Section 4.4.2
. Section 4.5.2
. Clarification of ASN.1 for Certificate Attribute Set
. Clarification of Error Messages for Certificate Enrollment Operations
. Updating Section 4.2.3: Simple Enroll and Re-enroll Response
IntroductionEnrollment over Secure Transport (EST) is defined in . 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 , rather than in
terms of the HTTP protocol, as defined in and . and later have text
specifically deprecating Content-Transfer-Encoding. However, incorrectly uses this header.Any updates to 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. extends ,
adding new functionality. Interop testing of the protocol has
revealed that unusual processing called out in causes confusion.EST is currently specified as part of and is widely used in government, utilities, and
financial markets today.This document, therefore, revises to reflect the field reality, deprecating the
extraneous field.This document deals with errata numbers , , , and .This document deals with
and in . is dealt with in . is
closed by correcting the ASN.1 Module in .Terminology
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
when, and only when, they appear in all capitals, as shown here.
Changes to EST Endpoint ProcessingSections (CA Certificates Response, /cacerts), and (Full CMC,
/fullcmc),
(Server-Side Key Generation, /serverkeygen), and (CSR Attributes, /csrattrs) of
specify the use of base64 encoding with a Content-Transfer-Encoding for
requests and responses.This document updates to
require the POST request and payload response of all endpoints using
base64 encoding, as specified in . In both cases, the Distinguished
Encoding Rules (DER) 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 header MUST be ignored.White Space ProcessingNote that "base64" as used in the HTTP does not permit CRLF, while the "base64" used in
MIME does. This
specification clarifies that despite what 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.Changes to Section 4 of RFC 7030Section 4.1.3Replace:
A successful response MUST be a certs-only CMC Simple PKI Response,
as defined in , containing the certificates described in the
following paragraph. The HTTP content-type of
"application/pkcs7-mime" is used. The Simple PKI Response is sent
with a Content-Transfer-Encoding of "base64" .
with:
A successful response MUST be a certs-only CMC Simple PKI Response,
as defined in , containing the certificates described in the
following paragraph. The HTTP content-type of
"application/pkcs7-mime" is used. The CMC Simple PKI Response is
encoded in base64 .
Section 4.3.1Replace:
If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
server MUST reject the message. The HTTP content-type used is
"application/pkcs7-mime" with an smime-type parameter "CMC-request",
as specified in . The body of the message is the binary
value of the encoding of the PKI Request with a
Content-Transfer-Encoding of "base64" .
with:
If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
server MUST reject the message. The HTTP content-type used is
"application/pkcs7-mime" with an smime-type parameter "CMC-request",
as specified in . The body of the message is encoded
in base64 .
Section 4.3.2Replace:
The body of the message is the binary value of the encoding of the
PKI Response with a Content-Transfer-Encoding of "base64" .
with:
The body of the message is the base64 encoding of the
PKI Response.
Section 4.4.2Replace:
An "application/pkcs8"
part consists of the base64-encoded DER-encoded
PrivateKeyInfo with a Content-Transfer-Encoding of "base64"
.
with:
An "application/pkcs8" part consists of the base64-encoded,
DER-encoded PrivateKeyInfo.
Replace:
In all three additional encryption cases, the EnvelopedData is
returned in the response as an "application/pkcs7-mime" part with an
smime-type parameter of "server-generated-key" and a Content-
Transfer-Encoding of "base64".
with:
In all three additional encryption cases, the EnvelopedData is
returned in the response as an "application/pkcs7-mime" part
with an smime-type parameter of "server-generated-key". It is
base64 encoded .
Section 4.5.2This section is updated in its entirety in .Clarification of ASN.1 for Certificate Attribute Set is to be
replaced with the following text:
4.5.2 CSR Attributes ResponseIf locally configured policy for an authenticated EST client indicates
a CSR Attributes Response is to be provided, the server response MUST
include an HTTP 200 response code. An HTTP response code of 204 or 404
indicates that a CSR Attributes Response is not available. Regardless
of the response code, the EST server and CA MAY reject any subsequent
enrollment requests for any reason, e.g., incomplete CSR attributes in
the request.Responses to attribute request messages MUST be encoded as the
content-type of "application/csrattrs" and are to be "base64"
encoded. The syntax for application/csrattrs body is as follows:
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
AttrOrOID ::= CHOICE {
oid OBJECT IDENTIFIER,
attribute Attribute {{AttrSet}} }
AttrSet ATTRIBUTE ::= { ... }
An EST server includes zero or more OIDs or attributes that it requests the client to use
in the certification request. The client MUST 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 particular
signature scheme (e.g., certification of a public key based on a
certain elliptic curve or signing using a certain hash algorithm), it
MUST provide that information in the CSR Attribute Response. If an
EST server requires the linking of identity and POP information (see
Section 3.5), it MUST include the challengePassword OID in the CSR
Attributes Response.The structure of the CSR Attributes Response SHOULD, to the greatest
extent possible, reflect the structure of the CSR it is requesting.
Requests to use a particular signature scheme (e.g., using a
particular hash function) are represented as an OID to be reflected
in the SignatureAlgorithm of the CSR. Requests to use a particular
cryptographic algorithm (e.g., certification of a public key based on a certain
elliptic curve) are represented as an attribute, to be reflected as
the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type
indicating the algorithm and the values indicating the particular
parameters specific to the algorithm. Requests for descriptive
information from the client are made by an attribute, to be
represented as Attributes of the CSR, with a type indicating the
extensionRequest and the values indicating the particular
attributes desired to be included in the resulting certificate's
extensions.The sequence is Distinguished Encoding Rules (DER) encoded and then base64 encoded (). 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 Section ), b) submit an
extensionRequest with the Media Access Control (MAC) address
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==
Clarification of Error Messages for Certificate Enrollment Operations 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.Updating Section 4.2.3: Simple Enroll and Re-enroll ResponseReplace:
If the content-type is not set, the response data MUST 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 data MUST be a
plaintext human-readable error message containing explanatory
information describing why the request was rejected (for
example, indicating that CSR attributes are incomplete).
Servers MAY use the "text/plain" content-type
for human-readable errors.
If the content-type is not set, the response data MUST be a
plaintext human-readable error message.
with:
If the content-type is not set, the response data MUST be a
plaintext human-readable error message.
Servers MAY use the "text/plain" content-type
for human-readable errors.
Privacy ConsiderationsThis document does not disclose any additional identities that either
an active or passive observer would see with .Security ConsiderationsThis document clarifies an existing security mechanism.
It does not create any new protocol mechanisms.All security considerations from also apply to the clarifications described in this document.IANA ConsiderationsThe ASN.1 module in 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 .
IANA has updated the Reference column for the Asymmetric
Decryption Key Identifier attribute to also include a reference to this document.ReferencesNormative ReferencesErratum ID 4384RFC ErrataRFC 7030Erratum ID 5107RFC ErrataRFC 7030Erratum ID 5108RFC ErrataRFC 7030Erratum ID 5904RFC ErrataRFC 7030Power systems management and associated information exchange - Data and communications security - Part 9: Cyber security key management for power system equipmentInternational Electrotechnical CommissionMultipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message BodiesThis initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK]Multipurpose Internet Mail Extensions (MIME) Part Two: Media TypesThis second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.PKCS #10: Certification Request Syntax Specification Version 1.7This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community.The Base16, Base32, and Base64 Data EncodingsThis document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]Certificate Management over CMS (CMC)This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community:1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-TRACK]Certificate Management over CMS (CMC): Transport ProtocolsThis document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic Message Syntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. [STANDARDS-TRACK]New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.Enrollment over Secure TransportThis document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notationITU-TInformation Technology - Abstract Syntax Notation One (ASN.1): Information object specificationITU-TInformation Technology - Abstract Syntax Notation One (ASN.1): Constraint specificationITU-TInformation Technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specificationsITU-TInformation Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)ITU-TInformative ReferencesBootstrapping Remote Secure Key Infrastructures (BRSKI)CiscoSandelman Software WorksFuturewei Technologies Inc. USAWatsen Networks This document specifies automated bootstrapping of an Autonomic
Control Plane. To do this a Secure Key Infrastructure is
bootstrapped. This is done using manufacturer-installed X.509
certificates, in combination with a manufacturer's authorizing
service, both online and offline. We call this process the
Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.
Bootstrapping a new device can occur using a routable address and a
cloud service, or using only link-local connectivity, or on limited/
disconnected networks. Support for deployment models with less
stringent security requirements is included. Bootstrapping is
complete when the cryptographic identity of the new key
infrastructure is successfully deployed to the device. The
established secure connection can be used to deploy a locally issued
certificate to the device as well.
Work in ProgressAn Approach for Using LDAP as a Network Information ServiceThis document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC2251]. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.Hypertext Transfer Protocol -- HTTP/1.1HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068. [STANDARDS-TRACK]PKCS #9: Selected Object Classes and Attribute Types Version 2.0This memo represents a republication of PKCS #9 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification. This memo provides information for the Internet community.Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and RoutingThe Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentThe Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.ASN.1 ModuleThis annex provides the normative ASN.1 definitions for the
structures described in this specification using ASN.1 as defined in
, , , and .The ASN.1 modules makes imports from the ASN.1 modules in and .There is no ASN.1 Module in . 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 --
IMPORTS
Attribute
FROM 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) }
ATTRIBUTE
FROM 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 Attributes
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
AttrOrOID ::= CHOICE {
oid OBJECT IDENTIFIER,
attribute Attribute {{AttrSet}} }
AttrSet ATTRIBUTE ::= { ... }
-- Asymmetric Decrypt Key Identifier Attribute
aa-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 STRING
END
AcknowledgementsHuawei Technologies supported the efforts of and .The ASN.1 Module was assembled by
and formatted by . provided editorial review.Authors' AddressesSandelman Software Worksmcr+ietf@sandelman.caSiemensthomas-werner@siemens.comHuawei Technologieswilliam.panwei@huawei.com