draft-ietf-lamps-rfc7030est-clarify-09.txt   draft-ietf-lamps-rfc7030est-clarify-10.txt 
LAMPS Working Group M. Richardson LAMPS Working Group M. Richardson
Internet-Draft Sandelman Software Works Internet-Draft Sandelman Software Works
Updates: 7030 (if approved) T. Werner Updates: 7030 (if approved) T. Werner
Intended status: Standards Track Siemens Intended status: Standards Track Siemens
Expires: January 13, 2021 W. Pan Expires: February 12, 2021 W. Pan
Huawei Technologies Huawei Technologies
July 12, 2020 August 11, 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-09 draft-ietf-lamps-rfc7030est-clarify-10
Abstract Abstract
This document updates RFC7030: Enrollment over Secure Transport (EST) This document updates RFC7030: Enrollment over Secure Transport (EST)
to resolve some errata that were reported, and which has proven to to resolve some errata that were reported, and which have proven to
cause interoperability issues when RFC7030 was extended. cause interoperability issues when RFC7030 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 EST endpoints. This document fixes some
syntactical errors in ASN.1 that were presented. 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2021. This Internet-Draft will expire on February 12, 2021.
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
skipping to change at page 2, line 46 skipping to change at page 2, line 46
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 end points 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 than
in terms of the HTTP protocol as defined in [RFC2616] and [RFC7230]. 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 [RFC7231] Appendix A.5 has 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 inline with HTTP processing risk
changing the on-wire protocol in a way that is not backwards 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
skipping to change at page 3, line 25 skipping to change at page 3, line 25
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 explicitely with [errata5107] and [errata5904] in This document deals with [errata5107] and [errata5904] in Section 3.
Section 3. [errata5108] is dealt with in section Section 5. [errata5108] is dealt with in Section 5. [errata4384] is closed by
correcting the ASN.1 Module in Section 4.
[errata4384] is closed by 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
skipping to change at page 4, line 26 skipping to change at page 4, line 26
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 Response,
as defined in [RFC5272], containing the certificates described in the as defined in [RFC5272], containing the certificates described in the
following paragraph. The HTTP content-type of 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: with: (RFCEDITOR: maybe artwork is the wrong choice here)
A successful response MUST be a certs-only CMC Simple PKI Response, A successful response MUST be a certs-only CMC Simple PKI Response,
as defined in [RFC5272], containing the certificates described in the as defined in [RFC5272], containing the certificates described in the
following paragraph. The HTTP content-type of 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-request",
as specified in [RFC5273]. The body of the message is the binary as specified in [RFC5273]. The body of the message is the binary
value of the encoding of the PKI Request with a 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-request",
as specified in [RFC5273]. The body of the message is encoded as specified in [RFC5273]. The body of the message is encoded
in base64 [RFC4648]. 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-encoded [X.690] part consists of the base64-encoded DER-encoded [X.690]
PrivateKeyInfo with a Content-Transfer-Encoding of "base64" PrivateKeyInfo with a Content-Transfer-Encoding of "base64"
[RFC4648]. [RFC4648].
with: with:
An "application/pkcs8" part consists of the base64-encoded An "application/pkcs8" part consists of the base64-encoded
DER-encoded [X.690] PrivateKeyInfo. DER-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 an
smime-type parameter of "server-generated-key" and a Content- 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 an smime-type parameter of "server-generated-key". It is with an smime-type parameter of "server-generated-key". It is
base64 encoded [RFC4648]. base64 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
skipping to change at page 6, line 21 skipping to change at page 6, line 21
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, e.g.,
incomplete CSR attributes in the request. 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"
[RFC2045] 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 ::= { ... }
skipping to change at page 8, line 39 skipping to change at page 8, line 39
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 "text/plain" content-type [RFC2046] Servers MAY use the "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 to either
active or passive observer would see with [RFC7030]. 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 mechanism.
All security considerations from [RFC7030] applies also for the All security considerations from [RFC7030] also apply for 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). This document requests that IANA register an OID
in the SMI Security for PKIX Arc in the Module identifiers subarc 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 (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 Decryption Key Identifier (1.2.840.113549.1.9.16.2.54) was previously
defined in [RFC7030]. defined in [RFC7030].
skipping to change at page 10, line 31 skipping to change at page 10, line 31
[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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
M., and D. Brungard, "Requirements for GMPLS-Based Multi- (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, <https://www.rfc-editor.org/info/rfc5272>.
DOI 10.17487/RFC5212, July 2008,
<https://www.rfc-editor.org/info/rfc5212>. [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC): Transport Protocols", RFC 5273,
DOI 10.17487/RFC5273, June 2008,
<https://www.rfc-editor.org/info/rfc5273>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>.
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
for the Cryptographic Message Syntax (CMS) and the Public for the Cryptographic Message Syntax (CMS) and the Public
Key Infrastructure Using X.509 (PKIX)", RFC 6268, Key Infrastructure Using X.509 (PKIX)", RFC 6268,
DOI 10.17487/RFC6268, July 2011, DOI 10.17487/RFC6268, July 2011,
<https://www.rfc-editor.org/info/rfc6268>. <https://www.rfc-editor.org/info/rfc6268>.
[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>.
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", BCP 79, RFC 8179,
DOI 10.17487/RFC8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
[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.", ISO/IEC 8824-1:2002, 2002.
[X.681] ITU-T, "Information technology - Abstract Syntax Notation [X.681] ITU-T, "Information technology - Abstract Syntax Notation
One: Information Object Specification.", ISO/ One: Information Object Specification.", ISO/
IEC 8824-2:2002, 2002. IEC 8824-2:2002, 2002.
[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: Constraint Specification.", ISO/IEC 8824-2:2002,
2002. 2002.
skipping to change at page 11, line 36 skipping to change at page 11, line 40
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).", ISO/IEC 8825-1:2002, 2002.
10.2. Informative References 10.2. Informative References
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M., Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-41 (work in progress), April 2020. keyinfra-43 (work in progress), August 2020.
[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 21 skipping to change at page 12, line 26
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 [RFC5212] 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 RFC 7030. 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(0)
id-mod-est-2019(TBD) } id-mod-est-2019(TBD) }
 End of changes. 24 change blocks. 
56 lines changed or deleted 58 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/