RPC, I think this reflects the author consensus. <!-- \[rfced\] We have updated the document title and short title that spans the header of the PDF file as follows. Please let us know any objections.
Original (Title): Clarification and enhancement of RFC7030 CSR Attributes definition Current: Clarification and Enhancement of the CSR Attributes Definition in RFC 7030 ... Original (Short Title): CSRAttr Current: CSR Attributes --> AUTHORS: I'm fine with this. 1. <!-- \[rfced\] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> SubjectAltName, SAN Certificate Extensions 1. <!-- \[rfced\] This document updates RFC 7030, which has multiple errata reports. Some of the errata reports seem relevant to the content of this document. Please review to ensure that these reports have been addressed if necessary. Specifically, Section 3.2 is about extending Section 4.5.2 of RFC 7030, which is the subject of this errata report: https://www.rfc-editor.org/errata/eid4384. Additionally, we note that the previous ASN.1 syntax from RFC 7030 appears in this document rather than the updated syntax. Are any updates needed here? Current: CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute } Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE { type ATTRIBUTE.&id({IOSet}), values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) } Perhaps: AttrOrOID ::= CHOICE { oid OBJECT IDENTIFIER, attribute Attribute{YouNeedToDefineOrReferenceAnObjectSet} } --> AUTHORS: The suggestion in the errata is not complete. We reference the original ASN.1 because that is what is being replaced. This errata is probably implemented by the changes. 1. <!--\[rfced\] May we combine these sentences as shown below to avoid the repetition of "This has resulted in" and "As a result"? Original: This has resulted in implementation challenges and implementor confusion. As a result, there was not universal understanding of what was specified. Perhaps: This has resulted in implementation challenges and implementor confusion because there was no universal understanding of what was specified. --> AUTHORS: okay. 1. <!--\[rfced\] We note that "CSR Attributes resource" is not present in Section 2.6 or any other sections in RFC 7030. Was "CSR Attributes Request" or "CSR Attributes Response" perhaps intended? Original: In \[RFC8994\], the ACP specification, the EST server is specified to make use of the CSR Attributes ("/csrattrs") resource (specified in \[RFC7030\], Section 2.6) to convey to the EST client that needs to go into its CSR and thus ultimately into its End Entity certificate. Perhaps: In \[RFC8994\], the ACP specification, the EST server is specified to make use of the CSR Attributes ("/csrattrs") Request (specified in \[RFC7030\], Section 2.6) to convey the actual subjectAltName to the EST client that needs to go into its CSR and thus ultimately into its End Entity (EE) certificate. --> AUTHORS: The word "resource" refers to an HTTP end-point, and that term was not common when RFC7030 was written. The fix is not wrong though. 1. <!-- \[rfced\] FYI - We have updated the sentence below. Please let us know any objections. Original: Replace the second paragraph with the following text: Current: This document replaces the second paragraph in Section 2.6 of RFC 7030 with the following text: --> AUTHORS: okay. 1. <!-- \[rfced\] May we rephrase the following sentence to limit the repetition of "such as"? Also, is "EC curve" referring to "elliptic curve (EC)" (option A) or "Elliptic Curve Cryptography (ECC)" (option B)? (Note that if it's the latter form, "ECC" will be expanded here rather than in Section 3.4.) Original: Otherwise, it MUST contain suitable parameters for the given key type, such as a singleton set containing the OID of an EC curve such as secp384r1 or containing an integer value for the RSA key size such as 4096. Perhaps A: Otherwise, it MUST contain suitable parameters for the given key type, such as a singleton set containing the OID of an elliptic curve (EC) (e.g., secp384r1) or containing an integer value for the RSA key size (e.g., 4096). or Perhaps B: Otherwise, it MUST contain suitable parameters for the given key type, such as a singleton set containing the OID of an Elliptic Curve Cryptography (ECC) (e.g., secp384r1) or containing an integer value for the RSA key size (e.g., 4096). --> MCR&David: option A. 1. <!-- \[rfced\] May we rephrase the sentence below as follows to clarify "transport"? Original: The updates to EST in this THISRFC equally apply when using CoAP as a transport as described in \[RFC9148\]. Perhaps: The updates to EST in this document equally apply when using CoAP as a transport mechanism as described in \[RFC9148\]. --> AUTHORS: yes. 1. <!-- \[rfced\] We will update the sentence below as follows if there are no objections. Original: EST over CoAP as specified in {{RFC9148}} applies unchanged to {{RFC7030}} updated by THISRFC. Hence, all references to {{RFC7030}} in {{RFC9148}} are assumed to indicate {{RFC7030}} updated by THISRFC. Perhaps: EST over CoAP as specified in \[RFC9148\] applies unchanged to \[RFC7030\], which is updated by RFC 9908. Hence, all references to \[RFC7030\] in \[RFC9148\] are assumed to indicate that \[RFC7030\] is updated by RFC 9908. --> AUTHORS: yes. 1. <!-- \[rfced\] We note that the following lines exceed the 72-character limit. Please let us know how the lines should be broken/wrapped. Section 3.4 (2 characters too long): EXTENSION.&ExtnType({ExtensionSet}{@extnID})) OPTIONAL Sections 5.3.2 and 5.6.2 (11 characters too long): 33 9: OBJECT IDENTIFIER friendlyName (for PKCS #12) (1 2 840 113549 1 9 20) Appendix A (3 characters too long): TYPE ExtensionReqTemplate IDENTIFIED BY id-aa-extensionReqTemplate } --> AUTHORS: section 3.4, seems hard to wrap sensibly. section 5.3.2 and 5.6.2, should be wrapped so that (1 2..) is together on a new line. Appendix A: TYPE ExtensionReqTemplate IDENTIFIED BY id-aa-extensionReqTemplate } 1. <!-- \[rfced\] May we rephrase the following sentence to avoid using RFC 2986 as an adjective? Also, we do not see "Full PKI Data content type" in RFC 5272. We do see "PKIData content type" and "Full PKI Request/Response". Should this be updated as "PKIData content type"? Original: In that approach, a pKCS7PDU attribute includes a Full PKI Data content type \[RFC5272\] and that in turn includes an \[RFC2986\] CSR or a Certificate Request Message Format (CRMF) formatted request (for details see \[RFC6268\] Sections 5 or 9, respectively). Perhaps: In that approach, a pKCS7PDU attribute includes a PKIData content type \[RFC5272\] and that, in turn, includes a CSR \[RFC2986\] or a Certificate Request Message Format (CRMF) formatted request (for details, see Sections 5 or 9 of \[RFC6268\], respectively). --> AUTHORS: Yes. 1. <!-- \[rfced\] Some author comments are present in the XML. Please confirm that no updates related to these comments are outstanding. Note that the comments will be deleted prior to publication. --> AUTHORS: delete them. 2. <!-- \[rfced\] Should "value" be plural here (option A), or is a definite article needed (option B)? Original: * the 'extKeyUsage' extension with value to be filled in by the EE. Perhaps A: * the 'extKeyUsage' extension with values to be filled in by the EE. or Perhaps B: the 'extKeyUsage' extension with the value to be filled in by the EE. --> MCR & David: option B. * <!-- \[rfced\] FYI: To avoid hyphenating an RFC number, we have updated this sentence as shown below. Please see style guidance at https://www.rfc-editor.org/styleguide/part2/#rfc_as_compound. Original: EST servers with legacy clients MAY continue to use the \[RFC7030\]- style unstructured list of attribute/value pairs, and MAY also include the template style described in Section 3.4 for newer clients. Current: EST servers with legacy clients MAY continue to use the unstructured list of attribute/value pairs as described in \[RFC7030\] and MAY also include the template style described in Section 3.4 for newer clients. --> AUTHORS: yes. <!-- \[rfced\] Informative reference RFC 9480 has been obsoleted by RFCs 9810 and 9811. We recommend replacing RFC 9480 with RFCs 9810 and 9811. However, if RFC 9480 must be referenced, we suggest mentioning RFCs 9810 and 9811 (e.g., RFC 9480 has been obsoleted by RFCs 9810 and 9811). See Section 4.8.6 in the RFC Style Guide (RFC 7322). --> AUTHORS: Yes, that's fine. 1. <!--\[rfced\] Does Appendix A provide the ASN.1 module for the Extension Request Template attribute? Or is it provided for the Certification Request Information Template attribute only? Original: This appendix provides an ASN.1 module \[X.680\] for the Certification Request Information Template attribute, and it follows the conventions established in \[RFC5911\], \[RFC5912\], and \[RFC6268\]. Perhaps: This appendix provides an ASN.1 module \[X.680\] for the Certification Request Information Template and Extension Request Template attributes, and it follows the conventions established in \[RFC5911\], \[RFC5912\], and \[RFC6268\]. --> AUTHORS: I think yes. NOT QUITE SURE. 1. <!-- \[rfced\] Please consider whether the "type" attribute of any sourcecode element should be set and/or has been set correctly. We note that "base64" was used as a sourcecode type; however, "base64" is not on the list of preferred values. Please review and let us know how we may update this. The current list of preferred values for "type" is available at https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. --> AUTHORS: I agree that base64 may not be descriptive enough. It's base64 encoded DER. I was about to write ASN.1, but it's not. It's DER. I don't see any thing that fits. I would suggest that base64 encoded DER get a name added to sourcecode-types. (It's actually... object code, kinda) We suggest either "DER" or "Base64-encoded-DER" (it's not PEM, because it has no BEGIN...) 1. <!-- \[rfced\] Regarding usage of <tt>, please review the occurrences and let us know if any updates are needed for consistency. In the HTML and PDF outputs, <tt> yields fixed-width font. In the text output, there is no change. <tt>algorithm</tt> <tt>attributes</tt> <tt>BIT STRING</tt> <tt>CertificationRequestInfo</tt> <tt>CertificationRequestInfoTemplate</tt> <tt>commonName</tt> <tt>critical</tt> <tt>CSRattrs</tt> <tt>CsrAttrs</tt> The single instance of CSRattrs -> CsrAttrs. <tt>directoryName</tt> AUTHORS: All of the rest look appropriate. 1. <!-- \[rfced\] Terminology a) We note that the following terms are used inconsistently. Please review the list below and let us know if any changes are needed. CSR Attribute(s) vs. CSR attribute(s) CsrAttrs vs. CSRattrs \[Note: Are these terms different or should one instance of "CSRattrs" be "CsrAttrs"?\] --> CSR Attribute(s) and CsrAttrs. 1. <!-- \[rfced\] Abbreviations a) FYI - We have added expansions for abbreviations upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. b) We note the following instances in the running text. If any changes are needed for consistency, please let us know. EC key (2 instances) ECC key (2 instances) ECC public key (1 instance) --> AUTHORS: ECC public key is most consistent/correct? 1. <!-- \[rfced\] Please review the "Inclusive Language" portion of the online Style Guide https://www.rfc-editor.org/styleguide/part2/#inclusive_language and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best a practice. --> AUTHORS: I see nothing. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
