--- 1/draft-ietf-lamps-rfc7030est-clarify-09.txt 2020-08-11 11:13:15.452762982 -0700 +++ 2/draft-ietf-lamps-rfc7030est-clarify-10.txt 2020-08-11 11:13:15.488763893 -0700 @@ -1,49 +1,49 @@ LAMPS Working Group M. Richardson Internet-Draft Sandelman Software Works Updates: 7030 (if approved) T. Werner Intended status: Standards Track Siemens -Expires: January 13, 2021 W. Pan +Expires: February 12, 2021 W. Pan Huawei Technologies - July 12, 2020 + August 11, 2020 Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 - draft-ietf-lamps-rfc7030est-clarify-09 + draft-ietf-lamps-rfc7030est-clarify-10 Abstract 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. This document deprecates the specification of "Content-Transfer- 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 This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -81,21 +81,21 @@ 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Enrollment over Secure Transport (EST) is defined in [RFC7030]. 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 [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 deprecating Content-Transfer-Encoding. However, [RFC7030] incorrectly uses this header. Any updates to [RFC7030] 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 @@ -107,24 +107,23 @@ EST is currently specified as part of [IEC62351], and is widely used in Government, Utilities and Financial markets today. This document therefore revises [RFC7030] to reflect the field reality, deprecating the extraneous field. This document deals with errata numbers [errata4384], [errata5107], [errata5108], and [errata5904]. - This document deals explicitely with [errata5107] and [errata5904] in - Section 3. [errata5108] is dealt with in section Section 5. - - [errata4384] is closed by correcting the ASN.1 Module in Section 4. + This document deals with [errata5107] and [errata5904] in Section 3. + [errata5108] is dealt with in Section 5. [errata4384] is closed by + correcting the ASN.1 Module in Section 4. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Changes to EST endpoint processing @@ -157,21 +156,21 @@ 3.2.1. Section 4.1.3 Replace: A successful response MUST be a certs-only CMC Simple PKI Response, as defined in [RFC5272], 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" [RFC2045]. - with: + with: (RFCEDITOR: maybe artwork is the wrong choice here) A successful response MUST be a certs-only CMC Simple PKI Response, as defined in [RFC5272], 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 [RFC4648]. 3.2.2. Section 4.3.1 Replace: @@ -244,21 +243,21 @@ If 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" - [RFC2045] encoded. The syntax for application/csrattrs body is as + [RFC4648] 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 ::= { ... } @@ -355,36 +354,36 @@ 5.2. Updating section 4.4.2: Server-Side Key Generation Response Replace: 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 + 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 [RFC2046] for human-readable errors. 6. Privacy Considerations This document does not disclose any additional identities to either active or passive observer would see with [RFC7030]. 7. Security Considerations This document clarifies an existing security mechanism. It does not 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. 8. IANA Considerations 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 [RFC7030]. @@ -439,46 +438,49 @@ [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . - [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, - M., and D. Brungard, "Requirements for GMPLS-Based Multi- - Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, - DOI 10.17487/RFC5212, July 2008, - . + [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS + (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, + . + + [RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS + (CMC): Transport Protocols", RFC 5273, + DOI 10.17487/RFC5273, June 2008, + . + + [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, + . [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, . [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . - [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property - Rights in IETF Technology", BCP 79, RFC 8179, - DOI 10.17487/RFC8179, May 2017, - . - [X.680] ITU-T, "Information technology - Abstract Syntax Notation One.", ISO/IEC 8824-1:2002, 2002. [X.681] ITU-T, "Information technology - Abstract Syntax Notation One: Information Object Specification.", ISO/ IEC 8824-2:2002, 2002. [X.682] ITU-T, "Information technology - Abstract Syntax Notation One: Constraint Specification.", ISO/IEC 8824-2:2002, 2002. @@ -491,21 +493,21 @@ Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).", ISO/IEC 8825-1:2002, 2002. 10.2. Informative References [I-D.ietf-anima-bootstrapping-keyinfra] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., and K. Watsen, "Bootstrapping Remote Secure Key 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 Information Service", RFC 2307, DOI 10.17487/RFC2307, March 1998, . [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, . @@ -524,21 +526,21 @@ Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . Appendix A. ASN.1 Module This annex provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680], [X.681], [X.682] and [X.683]. - The ASN.1 modules makes imports from the ASN.1 modules in [RFC5212] + The ASN.1 modules makes imports from the ASN.1 modules in [RFC5912] and [RFC6268]. 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. PKIXEST-2019 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-est-2019(TBD) }