draft-ietf-lamps-rfc7030est-clarify-10.txt   rfc8951.txt 
LAMPS Working Group M. Richardson Internet Engineering Task Force (IETF) M. Richardson
Internet-Draft Sandelman Software Works Request for Comments: 8951 Sandelman Software Works
Updates: 7030 (if approved) T. Werner Updates: 7030 T. Werner
Intended status: Standards Track Siemens Category: Standards Track Siemens
Expires: February 12, 2021 W. Pan ISSN: 2070-1721 W. Pan
Huawei Technologies Huawei Technologies
August 11, 2020 November 2020
Clarification of Enrollment over Secure Transport (EST): transfer Clarification of Enrollment over Secure Transport (EST): Transfer
encodings and ASN.1 Encodings and ASN.1
draft-ietf-lamps-rfc7030est-clarify-10
Abstract Abstract
This document updates RFC7030: Enrollment over Secure Transport (EST) This document updates RFC 7030: Enrollment over Secure Transport to
to resolve some errata that were reported, and which have proven to resolve some errata that were reported and that have proven to cause
cause interoperability issues when RFC7030 was extended. interoperability issues when RFC 7030 was extended.
This document deprecates the specification of "Content-Transfer- This document deprecates the specification of "Content-Transfer-
Encoding" headers for EST endpoints. This document fixes some Encoding" headers for Enrollment over Secure Transport (EST)
syntactical errors in ASN.1 that were present. endpoints. This document fixes some syntactical errors in ASN.1 that
were present.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on February 12, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8951.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Changes to EST endpoint processing . . . . . . . . . . . . . 3 3. Changes to EST Endpoint Processing
3.1. Whitespace processing . . . . . . . . . . . . . . . . . . 4 3.1. White Space Processing
3.2. Changes sections 4 of RFC7030 . . . . . . . . . . . . . . 4 3.2. Changes to Section 4 of RFC 7030
3.2.1. Section 4.1.3 . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Section 4.1.3
3.2.2. Section 4.3.1 . . . . . . . . . . . . . . . . . . . . 4 3.2.2. Section 4.3.1
3.2.3. Section 4.3.2 . . . . . . . . . . . . . . . . . . . . 5 3.2.3. Section 4.3.2
3.2.4. Section 4.4.2 . . . . . . . . . . . . . . . . . . . . 5 3.2.4. Section 4.4.2
3.2.5. Section 4.5.2 . . . . . . . . . . . . . . . . . . . . 5 3.2.5. Section 4.5.2
4. Clarification of ASN.1 for Certificate Attribute set. . . . . 6 4. Clarification of ASN.1 for Certificate Attribute Set
5. Clarification of error messages for certificate enrollment 5. Clarification of Error Messages for Certificate Enrollment
operations . . . . . . . . . . . . . . . . . . . . . . . . . 8 Operations
5.1. Updating section 4.2.3: Simple Enroll and Re-enroll 5.1. Updating Section 4.2.3: Simple Enroll and Re-enroll
Response . . . . . . . . . . . . . . . . . . . . . . . . 8 Response
5.2. Updating section 4.4.2: Server-Side Key Generation 5.2. Updating Section 4.4.2: Server-Side Key Generation Response
Response . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Privacy Considerations
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. References
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 Appendix A. ASN.1 Module
10.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgements
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Enrollment over Secure Transport (EST) is defined in [RFC7030]. The Enrollment over Secure Transport (EST) is defined in [RFC7030]. The
EST specification defines a number of HTTP end points for certificate EST specification defines a number of HTTP endpoints for certificate
enrollment and management. The details of the transaction were enrollment and management. The details of the transaction were
defined in terms of MIME headers as defined in [RFC2045], rather than defined in terms of MIME headers, as defined in [RFC2045], rather
in terms of the HTTP protocol as defined in [RFC7230] and [RFC7231]. than in terms of the HTTP protocol, as defined in [RFC7230] and
[RFC7231].
[RFC2616] and later [RFC7231] Appendix A.5 has text specifically [RFC2616] and later Appendix A.5 of [RFC7231] have text specifically
deprecating Content-Transfer-Encoding. However, [RFC7030] deprecating Content-Transfer-Encoding. However, [RFC7030]
incorrectly uses this header. incorrectly uses this header.
Any updates to [RFC7030] to bring it inline with HTTP processing risk Any updates to [RFC7030] to bring it in line with HTTP processing
changing the on-wire protocol in a way that is not backwards risk changing the on-wire protocol in a way that is not backwards
compatible. However, reports from implementers suggest that many compatible. However, reports from implementers suggest that many
implementations do not send the Content-Transfer-Encoding, and many implementations do not send the Content-Transfer-Encoding, and many
of them ignore it. The consequence is that simply deprecating the of them ignore it. The consequence is that simply deprecating the
header would remain compatible with current implementations. header would remain compatible with current implementations.
[I-D.ietf-anima-bootstrapping-keyinfra] extends [RFC7030], adding new [BRSKI] extends [RFC7030], adding new functionality. Interop testing
functionality, and interop testing of the protocol has revealed that of the protocol has revealed that unusual processing called out in
unusual processing called out in [RFC7030] causes confusion. [RFC7030] causes confusion.
EST is currently specified as part of [IEC62351], and is widely used EST is currently specified as part of [IEC62351] and is widely used
in Government, Utilities and Financial markets today. in government, utilities, and financial markets today.
This document therefore revises [RFC7030] to reflect the field This document, therefore, revises [RFC7030] to reflect the field
reality, deprecating the extraneous field. reality, deprecating the extraneous field.
This document deals with errata numbers [errata4384], [errata5107], This document deals with errata numbers [errata4384], [errata5107],
[errata5108], and [errata5904]. [errata5108], and [errata5904].
This document deals with [errata5107] and [errata5904] in Section 3. This document deals with [errata5107] and [errata5904] in Section 3.
[errata5108] is dealt with in Section 5. [errata4384] is closed by [errata5108] is dealt with in Section 5. [errata4384] is closed by
correcting the ASN.1 Module in Section 4. correcting the ASN.1 Module in Section 4.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Changes to EST endpoint processing 3. Changes to EST Endpoint Processing
The [RFC7030] sections 4.1.3 (CA Certificates Response, /cacerts), Sections 4.1.3 (CA Certificates Response, /cacerts), 4.3.1 and 4.3.2
4.3.1/4.3.2 (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation, (Full CMC, /fullcmc), 4.4.2 (Server-Side Key Generation,
/serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) specify the use /serverkeygen), and 4.5.2 (CSR Attributes, /csrattrs) of [RFC7030]
of base64 encoding with a Content-Transfer-Encoding for requests and specify the use of base64 encoding with a Content-Transfer-Encoding
response. for requests and responses.
This document updates [RFC7030] to require the POST request and This document updates [RFC7030] to require the POST request and
payload response of all endpoints use Base64 encoding as specified in payload response of all endpoints using base64 encoding, as specified
Section 4 of [RFC4648]. In both cases, the Distinguished Encoding in Section 4 of [RFC4648]. In both cases, the Distinguished Encoding
Rules (DER) [X.690] are used to produce the input for the Base64 Rules (DER) [X.690] are used to produce the input for the base64
encoding routine. This format is to be used regardless of any encoding routine. This format is to be used regardless of any
Content-Transfer-Encoding header, and any value in such a header MUST Content-Transfer-Encoding header, and any value in such a header MUST
be ignored. be ignored.
3.1. Whitespace processing 3.1. White Space Processing
Note that "base64" as used in the HTTP [RFC2616] does not permit Note that "base64" as used in the HTTP [RFC2616] does not permit
CRLF, while the "base64" used in MIME [RFC2045] does. This CRLF, while the "base64" used in MIME [RFC2045] does. This
specification clarifies that despite [RFC2616], that white space specification clarifies that despite what [RFC2616] says, white space
including CR, LF, spaces (ASCII 32) and, tabs (ASCII 9) SHOULD be including CR, LF, spaces (ASCII 32), and tabs (ASCII 9) SHOULD be
tolerated by receivers. Senders are not required to insert any kind tolerated by receivers. Senders are not required to insert any kind
of white space. of white space.
3.2. Changes sections 4 of RFC7030 3.2. Changes to Section 4 of RFC 7030
3.2.1. Section 4.1.3 3.2.1. Section 4.1.3
Replace: Replace:
A successful response MUST be a certs-only CMC Simple PKI Response, | A successful response MUST be a certs-only CMC Simple PKI
as defined in [RFC5272], containing the certificates described in the | Response, as defined in [RFC5272], containing the certificates
following paragraph. The HTTP content-type of | described in the following paragraph. The HTTP content-type of
"application/pkcs7-mime" is used. The Simple PKI Response is sent | "application/pkcs7-mime" is used. The Simple PKI Response is sent
with a Content-Transfer-Encoding of "base64" [RFC2045]. | with a Content-Transfer-Encoding of "base64" [RFC2045].
with: (RFCEDITOR: maybe artwork is the wrong choice here) with:
A successful response MUST be a certs-only CMC Simple PKI Response, | A successful response MUST be a certs-only CMC Simple PKI
as defined in [RFC5272], containing the certificates described in the | Response, as defined in [RFC5272], containing the certificates
following paragraph. The HTTP content-type of | described in the following paragraph. The HTTP content-type of
"application/pkcs7-mime" is used. The CMC Simple PKI Response is | "application/pkcs7-mime" is used. The CMC Simple PKI Response is
encoded in base64 [RFC4648]. | encoded in base64 [RFC4648].
3.2.2. Section 4.3.1 3.2.2. Section 4.3.1
Replace: Replace:
If the HTTP POST to /fullcmc is not a valid Full PKI Request, the | 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 | server MUST reject the message. The HTTP content-type used is
"application/pkcs7-mime" with an smime-type parameter "CMC-request", | "application/pkcs7-mime" with an smime-type parameter "CMC-
as specified in [RFC5273]. The body of the message is the binary | request", as specified in [RFC5273]. The body of the message is
value of the encoding of the PKI Request with a | the binary value of the encoding of the PKI Request with a
Content-Transfer-Encoding of "base64" [RFC2045]. | Content-Transfer-Encoding of "base64" [RFC2045].
with: with:
If the HTTP POST to /fullcmc is not a valid Full PKI Request, the | 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 | server MUST reject the message. The HTTP content-type used is
"application/pkcs7-mime" with an smime-type parameter "CMC-request", | "application/pkcs7-mime" with an smime-type parameter "CMC-
as specified in [RFC5273]. The body of the message is encoded | request", as specified in [RFC5273]. The body of the message is
in base64 [RFC4648]. | encoded in base64 [RFC4648].
3.2.3. Section 4.3.2 3.2.3. Section 4.3.2
Replace: Replace:
The body of the message is the binary value of the encoding of the | The body of the message is the binary value of the encoding of the
PKI Response with a Content-Transfer-Encoding of "base64" [RFC2045]. | PKI Response with a Content-Transfer-Encoding of "base64"
| [RFC2045].
with: with:
The body of the message is the base64 [RFC4648] encoding of the | The body of the message is the base64 [RFC4648] encoding of the
PKI Response. | PKI Response.
3.2.4. Section 4.4.2 3.2.4. Section 4.4.2
Replace: Replace:
An "application/pkcs8" | An "application/pkcs8" part consists of the base64-encoded DER-
part consists of the base64-encoded DER-encoded [X.690] | encoded [X.690] PrivateKeyInfo with a Content-Transfer-Encoding of
PrivateKeyInfo with a Content-Transfer-Encoding of "base64" | "base64" [RFC2045].
[RFC4648].
with: with:
An "application/pkcs8" part consists of the base64-encoded | An "application/pkcs8" part consists of the base64-encoded, DER-
DER-encoded [X.690] PrivateKeyInfo. | encoded [X.690] PrivateKeyInfo.
Replace: Replace:
In all three additional encryption cases, the EnvelopedData is | In all three additional encryption cases, the EnvelopedData is
returned in the response as an "application/pkcs7-mime" part with an | returned in the response as an "application/pkcs7-mime" part with
smime-type parameter of "server-generated-key" and a Content- | an smime-type parameter of "server-generated-key" and a Content-
Transfer-Encoding of "base64". | Transfer-Encoding of "base64".
with: with:
In all three additional encryption cases, the EnvelopedData is | In all three additional encryption cases, the EnvelopedData is
returned in the response as an "application/pkcs7-mime" part | returned in the response as an "application/pkcs7-mime" part with
with an smime-type parameter of "server-generated-key". It is | an smime-type parameter of "server-generated-key". It is base64
base64 encoded [RFC4648]. | encoded [RFC4648].
3.2.5. Section 4.5.2 3.2.5. Section 4.5.2
This section is updated in its entirety in Section 4. This section is updated in its entirety in Section 4.
4. Clarification of ASN.1 for Certificate Attribute set. 4. Clarification of ASN.1 for Certificate Attribute Set
Section 4.5.2 of [RFC7030] is to be replaced with the following text: Section 4.5.2 of [RFC7030] is to be replaced with the following text:
4.5.2 CSR Attributes Response | 4.5.2 CSR Attributes Response
|
If locally configured policy for an authenticated EST client | If locally configured policy for an authenticated EST client
indicates a CSR Attributes Response is to be provided, the server | indicates a CSR Attributes Response is to be provided, the server
response MUST include an HTTP 200 response code. An HTTP response | response MUST include an HTTP 200 response code. An HTTP response
code of 204 or 404 indicates that a CSR Attributes Response is not | code of 204 or 404 indicates that a CSR Attributes Response is not
available. Regardless of the response code, the EST server and CA | available. Regardless of the response code, the EST server and CA
MAY reject any subsequent enrollment requests for any reason, e.g., | MAY reject any subsequent enrollment requests for any reason,
incomplete CSR attributes in the request. | e.g., incomplete CSR attributes in the request.
|
Responses to attribute request messages MUST be encoded as the | Responses to attribute request messages MUST be encoded as the
content-type of "application/csrattrs", and are to be "base64" | content-type of "application/csrattrs" and are to be "base64"
[RFC4648] encoded. The syntax for application/csrattrs body is as | [RFC4648] encoded. The syntax for application/csrattrs body is as
follows: | follows:
|
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID | CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
|
AttrOrOID ::= CHOICE { | AttrOrOID ::= CHOICE {
oid OBJECT IDENTIFIER, | oid OBJECT IDENTIFIER,
attribute Attribute {{AttrSet}} } | attribute Attribute {{AttrSet}} }
|
AttrSet ATTRIBUTE ::= { ... } | AttrSet ATTRIBUTE ::= { ... }
|
An EST server includes zero or more OIDs or attributes [RFC2986] that | An EST server includes zero or more OIDs or attributes [RFC2986]
it requests the client to use in the certification request. The | that it requests the client to use in the certification request.
client MUST ignore any OID or attribute it does not recognize. When | The client MUST ignore any OID or attribute it does not recognize.
the server encodes CSR Attributes as an empty SEQUENCE, it means that | When the server encodes CSR attributes as an empty SEQUENCE, it
the server has no specific additional information it desires in a | means that the server has no specific additional information it
client certification request (this is functionally equivalent to an | desires in a client certification request (this is functionally
HTTP response code of 204 or 404). | equivalent to an HTTP response code of 204 or 404).
|
If the CA requires a particular cryptographic algorithm or use of a | If the CA requires a particular cryptographic algorithm or use of
particular signature scheme (e.g., certification of a public key | a particular signature scheme (e.g., certification of a public key
based on a certain elliptic curve, or signing using a certain hash | based on a certain elliptic curve or signing using a certain hash
algorithm) it MUST provide that information in the CSR Attribute | algorithm), it MUST provide that information in the CSR Attribute
Response. If an EST server requires the linking of identity and POP | Response. If an EST server requires the linking of identity and
information (see Section 3.5), it MUST include the challengePassword | POP information (see Section 3.5), it MUST include the
OID in the CSR Attributes Response. | challengePassword OID in the CSR Attributes Response.
|
The structure of the CSR Attributes Response SHOULD, to the greatest | The structure of the CSR Attributes Response SHOULD, to the
extent possible, reflect the structure of the CSR it is requesting. | greatest extent possible, reflect the structure of the CSR it is
Requests to use a particular signature scheme (e.g. using a | requesting. Requests to use a particular signature scheme (e.g.,
particular hash function) are represented as an OID to be reflected | using a particular hash function) are represented as an OID to be
in the SignatureAlgorithm of the CSR. Requests to use a particular | reflected in the SignatureAlgorithm of the CSR. Requests to use a
cryptographic algorithm (e.g., certification of a public key based on | particular cryptographic algorithm (e.g., certification of a
a certain elliptic curve) are represented as an attribute, to be | public key based on a certain elliptic curve) are represented as
reflected as the AlgorithmIdentifier of the SubjectPublicKeyInfo, | an attribute, to be reflected as the AlgorithmIdentifier of the
with a type indicating the algorithm and the values indicating the | SubjectPublicKeyInfo, with a type indicating the algorithm and the
particular parameters specific to the algorithm. Requests for | values indicating the particular parameters specific to the
descriptive information from the client are made by an attribute, to | algorithm. Requests for descriptive information from the client
be represented as Attributes of the CSR, with a type indicating the | are made by an attribute, to be represented as Attributes of the
[RFC2985] extensionRequest and the values indicating the particular | CSR, with a type indicating the [RFC2985] extensionRequest and the
attributes desired to be included in the resulting certificate's | values indicating the particular attributes desired to be included
extensions. | in the resulting certificate's extensions.
|
The sequence is Distinguished Encoding Rules (DER) encoded [X.690] | The sequence is Distinguished Encoding Rules (DER) encoded [X.690]
and then base64 encoded (Section 4 of [RFC4648]). The resulting text | and then base64 encoded (Section 4 of [RFC4648]). The resulting
forms the application/csrattr body, without headers. | text forms the application/csrattr body, without headers.
|
For example, if a CA requests a client to submit a certification | For example, if a CA requests that a client a) submit a
request containing the challengePassword (indicating that linking of | certification request containing the challengePassword (indicating
identity and POP information is requested; see Section 3.5), an | that linking of identity and POP information is requested; see
extensionRequest with the Media Access Control (MAC) address | Section 3.5), b) submit an extensionRequest with the Media Access
([RFC2307]) of the client, and to use the secp384r1 elliptic curve | Control (MAC) address [RFC2307] of the client, and c) use the
and to sign with the SHA384 hash function. Then, it takes the | secp384r1 elliptic curve to sign using the SHA384 hash function,
following: | then it takes the following:
|
OID: challengePassword (1.2.840.113549.1.9.7) | OID: challengePassword (1.2.840.113549.1.9.7)
|
Attribute: type = extensionRequest (1.2.840.113549.1.9.14) | Attribute: type = extensionRequest (1.2.840.113549.1.9.14)
value = macAddress (1.3.6.1.1.1.1.22) | value = macAddress (1.3.6.1.1.1.1.22)
|
Attribute: type = id-ecPublicKey (1.2.840.10045.2.1) | Attribute: type = id-ecPublicKey (1.2.840.10045.2.1)
value = secp384r1 (1.3.132.0.34) | value = secp384r1 (1.3.132.0.34)
|
OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3) | OID: ecdsaWithSHA384 (1.2.840.10045.4.3.3)
|
and encodes them into an ASN.1 SEQUENCE to produce: | 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 | 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 | 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 | 09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03
03 | 03
|
and then base64 encodes the resulting ASN.1 SEQUENCE to produce: | and then base64 encodes the resulting ASN.1 SEQUENCE to produce:
|
MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ | MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
BgcrBgEBAQEWBggqhkjOPQQDAw== | BgcrBgEBAQEWBggqhkjOPQQDAw==
5. Clarification of error messages for certificate enrollment 5. Clarification of Error Messages for Certificate Enrollment
operations Operations
[errata5108] clarifies what format the error messages are to be in. [errata5108] clarifies what format the error messages are to be in.
Previously a client might be confused into believing that an error Previously, a client might be confused into believing that an error
returned with type text/plain was not intended to be an error. returned with type text/plain was not intended to be an error.
5.1. Updating section 4.2.3: Simple Enroll and Re-enroll Response 5.1. Updating Section 4.2.3: Simple Enroll and Re-enroll Response
Replace: Replace:
If the content-type is not set, the response data MUST be a | If the content-type is not set, the response data MUST be a
plaintext human-readable error message containing explanatory | plaintext human-readable error message containing explanatory
information describing why the request was rejected (for | information describing why the request was rejected (for example,
example, indicating that CSR attributes are incomplete). | indicating that CSR attributes are incomplete).
with: with:
If the content-type is not set, the response data MUST be a | If the content-type is not set, the response data MUST be a
plaintext human-readable error message containing explanatory | plaintext human-readable error message containing explanatory
information describing why the request was rejected (for | information describing why the request was rejected (for example,
example, indicating that CSR attributes are incomplete). | indicating that CSR attributes are incomplete). Servers MAY use
Servers MAY use the "text/plain" content-type [RFC2046] | the "text/plain" content-type [RFC2046] for human-readable errors.
for human-readable errors.
5.2. Updating section 4.4.2: Server-Side Key Generation Response 5.2. Updating Section 4.4.2: Server-Side Key Generation Response
Replace: Replace:
If the content-type is not set, the response data MUST be a | If the content-type is not set, the response data MUST be a
plaintext human-readable error message. | plaintext human-readable error message.
with: with:
If the content-type is not set, the response data MUST be a | If the content-type is not set, the response data MUST be a
plaintext human-readable error message. | plaintext human-readable error message. Servers MAY use the
Servers MAY use the "text/plain" content-type [RFC2046] | "text/plain" content-type [RFC2046] for human-readable errors.
for human-readable errors.
6. Privacy Considerations 6. Privacy Considerations
This document does not disclose any additional identities to either This document does not disclose any additional identities that either
active or passive observer would see with [RFC7030]. an active or passive observer would see with [RFC7030].
7. Security Considerations 7. Security Considerations
This document clarifies an existing security mechanism. It does not This document clarifies an existing security mechanism. It does not
create any new protocol mechanism. create any new protocol mechanisms.
All security considerations from [RFC7030] also apply for the All security considerations from [RFC7030] also apply to the
clarifications described in this document. clarifications described in this document.
8. IANA Considerations 8. IANA Considerations
The ASN.1 module in Appendix A of this document makes use of object The ASN.1 module in Appendix A of this document makes use of object
identifiers (OIDs). This document requests that IANA register an OID identifiers (OIDs).
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 [RFC7030].
IANA is requested to update the "Reference" column for the Asymmetric
Decryption Key Identifier attribute to also include a reference to
this document.
9. Acknowledgements
This work was supported by Huawei Technologies. 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 ASN.1 Module was assembled by Russ Housley and formatted by Sean The OID for the Asymmetric Decryption Key Identifier
Turner. Russ Housley provided editorial review. (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.
10. References 9. References
10.1. Normative References 9.1. Normative References
[errata4384] [errata4384]
"EST errata 4384: ASN.1 encoding error", n.d., RFC Errata, Erratum ID 4384, RFC 7030,
<https://www.rfc-editor.org/errata/eid4384>. <https://www.rfc-editor.org/errata/eid4384>.
[errata5107] [errata5107]
"EST errata 5107: use Content-Transfer-Encoding", n.d., RFC Errata, Erratum ID 5107, RFC 7030,
<https://www.rfc-editor.org/errata/eid5107>. <https://www.rfc-editor.org/errata/eid5107>.
[errata5108] [errata5108]
"EST errata 5108: use of Content-Type for error message", RFC Errata, Erratum ID 5108, RFC 7030,
n.d., <https://www.rfc-editor.org/errata/eid5108>. <https://www.rfc-editor.org/errata/eid5108>.
[errata5904] [errata5904]
"EST errata 5904: use Content-Transfer-Encoding", n.d., RFC Errata, Erratum ID 5904, RFC 7030,
<https://www.rfc-editor.org/errata/eid5904>. <https://www.rfc-editor.org/errata/eid5904>.
[IEC62351] [IEC62351] International Electrotechnical Commission, "Power systems
International Electrotechnical Commission, "Power systems
management and associated information exchange - Data and management and associated information exchange - Data and
communications security - Part 9: Cyber security key communications security - Part 9: Cyber security key
management for power system equipment", ISO/ management for power system equipment", ISO/
IEC 62351-9:2017, 2017. IEC 62351-9:2017, May 2017.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986, Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000, DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>. <https://www.rfc-editor.org/info/rfc2986>.
skipping to change at page 11, line 14 skipping to change at line 471
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>. <https://www.rfc-editor.org/info/rfc7030>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[X.680] ITU-T, "Information technology - Abstract Syntax Notation [X.680] ITU-T, "Information technology -- Abstract Syntax Notation
One.", ISO/IEC 8824-1:2002, 2002. One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2015, August 2015,
<https://www.itu.int/rec/T-REC-X.680-201508-I/en>.
[X.681] ITU-T, "Information technology - Abstract Syntax Notation [X.681] ITU-T, "Information Technology - Abstract Syntax Notation
One: Information Object Specification.", ISO/ One (ASN.1): Information object specification", ITU-T
IEC 8824-2:2002, 2002. Recommendation X.681, ISO/IEC 8824-2:2015, August 2015,
<https://www.itu.int/rec/T-REC-X.681>.
[X.682] ITU-T, "Information technology - Abstract Syntax Notation [X.682] ITU-T, "Information Technology - Abstract Syntax Notation
One: Constraint Specification.", ISO/IEC 8824-2:2002, One (ASN.1): Constraint specification", ITU-T
2002. Recommendation X.682, ISO/IEC 8824-3:2015, August 2015,
<https://www.itu.int/rec/T-REC-X.682>.
[X.683] ITU-T, "Information technology - Abstract Syntax Notation [X.683] ITU-T, "Information Technology - Abstract Syntax Notation
One: Parameterization of ASN.1 Specifications.", ISO/ One (ASN.1): Parameterization of ASN.1 specifications",
IEC 8824-2:2002, 2002. ITU-T Recommendation X.683, ISO/IEC 8824-4:2015, August
2015, <https://www.itu.int/rec/T-REC-X.683>.
[X.690] ITU-T, "Information technology - ASN.1 encoding Rules: [X.690] ITU-T, "Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER).", ISO/IEC 8825-1:2002, 2002. (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2015,
August 2015, <https://www.itu.int/rec/T-REC-X.690>.
10.2. Informative References 9.2. Informative References
[I-D.ietf-anima-bootstrapping-keyinfra] [BRSKI] Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M.
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., H., and K. Watsen, "Bootstrapping Remote Secure Key
and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Work in Progress, Internet-
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Draft, draft-ietf-anima-bootstrapping-keyinfra-45, 11
keyinfra-43 (work in progress), August 2020. November 2020, <https://tools.ietf.org/html/draft-ietf-
anima-bootstrapping-keyinfra-45>.
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network [RFC2307] Howard, L., "An Approach for Using LDAP as a Network
Information Service", RFC 2307, DOI 10.17487/RFC2307, Information Service", RFC 2307, DOI 10.17487/RFC2307,
March 1998, <https://www.rfc-editor.org/info/rfc2307>. March 1998, <https://www.rfc-editor.org/info/rfc2307>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>. <https://www.rfc-editor.org/info/rfc2616>.
skipping to change at page 12, line 24 skipping to change at line 535
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
This annex provides the normative ASN.1 definitions for the This annex provides the normative ASN.1 definitions for the
structures described in this specification using ASN.1 as defined in structures described in this specification using ASN.1 as defined in
[X.680], [X.681], [X.682] and [X.683]. [X.680], [X.681], [X.682], and [X.683].
The ASN.1 modules makes imports from the ASN.1 modules in [RFC5912] The ASN.1 modules makes imports from the ASN.1 modules in [RFC5912]
and [RFC6268]. and [RFC6268].
There is no ASN.1 Module in RFC 7030. This module has been created There is no ASN.1 Module in [RFC7030]. This module has been created
by combining the lines that are contained in the document body. by combining the lines that are contained in the document body.
PKIXEST-2019 PKIXEST-2019
{ iso(1) identified-organization(3) dod(6) { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) internet(1) security(5) mechanisms(5) pkix(7)
id-mod-est-2019(TBD) } id-mod(0) id-mod-est-2019(98) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS ALL -- -- EXPORTS ALL --
IMPORTS IMPORTS
Attribute Attribute
FROM CryptographicMessageSyntax-2010 -- [RFC6268] FROM CryptographicMessageSyntax-2010 -- [RFC6268]
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-2009(58) } id-mod-cms-2009(58) }
ATTRIBUTE ATTRIBUTE
FROM PKIX-CommonTypes-2009 -- [RFC5912] FROM PKIX-CommonTypes-2009 -- [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1) security(5) { iso(1) identified-organization(3) dod(6) internet(1)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } ; security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) } ;
-- CSR Attributes -- CSR Attributes
CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
AttrOrOID ::= CHOICE { AttrOrOID ::= CHOICE {
oid OBJECT IDENTIFIER, oid OBJECT IDENTIFIER,
attribute Attribute {{AttrSet}} } attribute Attribute {{AttrSet}} }
AttrSet ATTRIBUTE ::= { ... } AttrSet ATTRIBUTE ::= { ... }
-- Asymmetric Decrypt Key Identifier Attribute -- Asymmetric Decrypt Key Identifier Attribute
aa-asymmDecryptKeyID ATTRIBUTE ::= aa-asymmDecryptKeyID ATTRIBUTE ::=
{ TYPE AsymmetricDecryptKeyIdentifier { TYPE AsymmetricDecryptKeyIdentifier
IDENTIFIED BY id-aa-asymmDecryptKeyID } IDENTIFIED BY id-aa-asymmDecryptKeyID }
id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= { iso(1)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 54 } member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) aa(2) 54 }
AsymmetricDecryptKeyIdentifier ::= OCTET STRING AsymmetricDecryptKeyIdentifier ::= OCTET STRING
END END
Acknowledgements
Huawei Technologies supported the efforts of Wei Pan and Michael
Richardson.
The ASN.1 Module was assembled by Russ Housley and formatted by Sean
Turner. Russ Housley provided editorial review.
Authors' Addresses Authors' Addresses
Michael Richardson Michael Richardson
Sandelman Software Works Sandelman Software Works
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
Thomas Werner Thomas Werner
Siemens Siemens
 End of changes. 83 change blocks. 
307 lines changed or deleted 318 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/