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 GroupInternet-DraftThis document updates RFC7030: Enrollment over Secure Transport (EST) to resolve
some errata that was reported, and which has proven to cause interoperability
issues when RFC7030 was extended.This document deprecates the specification of “Content-Transfer-Encoding”
headers for EST endpoints.
This document fixes some syntactical errors in ASN.1 that was presented.Enrollment over Secure Transport (EST) is defined in .
The EST 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 . and later Appendix A.5 has text specifically
deprecating Content-Transfer-Encoding.
However, incorrectly uses this header.Any updates to to bring it inline 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, and 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 explicitely with and in
.
is dealt with in section . is closed by correcting the ASN.1 Module in .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.The 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-Transfer-Encoding for requests and response.This document updates to require the POST request and payload response of all endpoints use Base64 encoding as specified in Section 4 of .
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.Note that “base64” as used in the HTTP does not permit CRLF, while the “base64” used in MIME does.
This specification clarifies that despite , that 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:with:Replace:with:Replace:with:Replace:with:Replace:with:This section is updated in its entirety in .Section 4.5.2 of 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: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 (Section 4 of ). The resulting text
forms the application/csrattr body, without headers.For example, if a CA requests a client to submit a certification
request containing the challengePassword (indicating that linking of
identity and POP information is requested; see Section 3.5), an
extensionRequest with the Media Access Control (MAC) address
() of the client, and to use the secp384r1 elliptic curve
and to sign with the SHA384 hash function. Then, it takes the
following:and encodes them into an ASN.1 SEQUENCE to produce:and then base64 encodes the resulting ASN.1 SEQUENCE to produce: 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:with:Replace:with:This document does not disclose any additional identifies to either active or
passive observer would see with .This document clarifies an existing security mechanism.
It does not create any new protocol mechanism.The ASN.1 module in Appendix A of this document makes use of object
identifiers (OIDs). This document requests that IANA register an
OID in the SMI Security for PKIX Arc in the Module identifiers
subarc (1.3.6.1.5.5.7.0) 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 is requested to update the “Reference” column for the Asymmetric
Decryption Key Identifier
attribute to also include a reference to this document.This work was supported by Huawei Technologies.The ASN.1 Module was assembled by Russ Housley and formatted by Sean Turner.
Russ Housley provided editorial review.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.Intellectual Property Rights in IETF TechnologyThe IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879.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]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.Information technology - Abstract Syntax Notation One.ITU-TInformation technology - Abstract Syntax Notation One: Information Object Specification.ITU-TInformation technology - Abstract Syntax Notation One: Constraint Specification.ITU-TInformation technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications.ITU-TInformation technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).ITU-TPower systems management and associated information exchange - Data and communications security - Part 9: Cyber security key management for power system equipmentInternational Electrotechnical CommissionEST errata 4384: ASN.1 encoding errorEST errata 5107: use Content-Transfer-EncodingEST errata 5108: use of Content-Type for error messageEST errata 5904: use Content-Transfer-EncodingAmbiguity 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.Multipurpose 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]Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extending MPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies.In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN). This document defines a framework for GMPLS based multi-region / multi-layer networks and lists a set of functional requirements. This memo provides information for the Internet community.Bootstrapping Remote Secure Key Infrastructures (BRSKI)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.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]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.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.An 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.This 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 RFC 7030. This module has been created
by combining the lines that are contained in the document body.