Hi Authors,
Thank you for your reply! We have updated the document as requested and we have
a few followup questions below. Note that resolved questions have been trimmed
from the thread for readability.
> 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) Thank you for the suggestions! Please review the changes to the lines above
in the updated files and let us know any objections.
For Section 3.4, would the following structure work?
Perhaps:
EXTENSION.&ExtnType({ExtensionSet}{@extnID}))
OPTIONAL
> <!-- \[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.
2) We have replaced RFC 9480 with RFCs 9810 and 9811. Note that we have updated
the text below as follows to reflect this change. Please let us know any
objections.
Original:
A similar method has been defined in CMP Updates [RFC9480] and the
Lightweight CMP profile [RFC9483], Section 4.3.3, using a CSR
template as defined for CRMF [RFC4211].
Current:
A similar method has been defined in "Internet X.509 Public Key
Infrastructure -- Certificate Management Protocol (CMP)" [RFC9810],
"Internet X.509 Public Key Infrastructure -- HTTP Transfer for the
Certificate Management Protocol (CMP)" [RFC9811], and "Lightweight
Certificate Management Protocol (CMP) Profile" ([RFC9483],
Section 4.3.3) using a CSR template as defined for CRMF [RFC4211].
>
> 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.
3) We ask to update this text because of the following note in the IANA Section:
"For the Certification Request Information Template and Extension Request
Template attributes in Appendix A…"
We have updated to the Perhaps text above.
> 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...)
4) Thank you for your suggestion. We have sent mail to request that
"base64-encoded-der" be added to the sourcecode-types list.
The files have been posted here (please refresh):
https://www.rfc-editor.org/authors/rfc9908.txt
https://www.rfc-editor.org/authors/rfc9908.pdf
https://www.rfc-editor.org/authors/rfc9908.html
https://www.rfc-editor.org/authors/rfc9908.xml
Diff files:
https://www.rfc-editor.org/authors/rfc9908-diff.html (comprehensive diff)
https://www.rfc-editor.org/authors/rfc9908-rfcdiff.html (side by side)
https://www.rfc-editor.org/authors/rfc9908-auth48diff.html (diff showing
AUTH48 changes only)
https://www.rfc-editor.org/authors/rfc9908-auth48rfcdiff.html (side by side)
AUTH48 status page:
https://www.rfc-editor.org/auth48/rfc9908
Thank you!
Madison Church
RFC Production Center
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
