Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [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 --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!-- [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} } --> 4) <!--[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. --> 5) <!--[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. --> 6) <!-- [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: --> 7) <!-- [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). --> 8) <!-- [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]. --> 9) <!-- [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. --> 10) <!-- [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 } --> 11) <!-- [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). --> 12) <!-- [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. --> 13) <!-- [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. --> 14) <!-- [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. --> 15) <!-- [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). --> 16) <!--[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]. --> 17) <!-- [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. --> 18) <!-- [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> <tt>directoryName</tt> <tt>ecPublicKey</tt> <tt>Extension</tt> <tt>ExtensionReq</tt> <tt>Extensions</tt> <tt>ExtensionTemplate</tt> <tt>extKeyUsage</tt> <tt>extnID</tt> <tt>extnValue</tt> <tt>GeneralName</tt> <tt>id-aa-extensionReqTemplate</tt> <tt>id-ExtensionReq</tt> <tt>iPAddress</tt> <tt>keyUsage</tt> <tt>macAddress</tt> <tt>NULL-DN</tt> <tt>OCTET STRING</tt> <tt>otherNames</tt> <tt>pkcs-9-at-extensionRequest</tt> <tt>publicKey</tt> <tt>rsaEncryption</tt> <tt>secp256r1</tt> <tt>secp384r1</tt> <tt>signature</tt> <tt>SingleAttributeTemplate</tt> <tt>subject</tt> <tt>subjectAltName</tt> <tt>subjectPKInfo</tt> <tt>subjectPublicKey</tt> <tt>SubjectPublicKeyInfoTemplate</tt> <tt>type</tt> <tt>value</tt> <tt>values</tt> <tt>version</tt> --> 19) <!-- [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"?] --> 20) <!-- [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) --> 21) <!-- [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. --> Thank you. Madison Church and Karen Moore RFC Production Center On Dec 5, 2025, at 4:56 PM, [email protected] wrote: *****IMPORTANT***** Updated 2025/12/05 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * [email protected] (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * [email protected], which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, [email protected] will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9908.xml https://www.rfc-editor.org/authors/rfc9908.html https://www.rfc-editor.org/authors/rfc9908.pdf https://www.rfc-editor.org/authors/rfc9908.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9908-diff.html https://www.rfc-editor.org/authors/rfc9908-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9908-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9908 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9908 (draft-ietf-lamps-rfc7030-csrattrs-23) Title : Clarification and enhancement of RFC7030 CSR Attributes definition Author(s) : M. Richardson, Ed., O. Friel, D. Oheimb, D. Harkins WG Chair(s) : Russ Housley, Tim Hollebeek Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
