Hi Russ, We appreciate your quick reply! We have posted the updated files and just have one followup question in this thread regarding item #5 (see the comment marked [rfced] below).
Updated files (please refresh): https://www.rfc-editor.org/authors/rfc9690.txt https://www.rfc-editor.org/authors/rfc9690.pdf https://www.rfc-editor.org/authors/rfc9690.html https://www.rfc-editor.org/authors/rfc9690.xml Updated diff files (please refresh): https://www.rfc-editor.org/authors/rfc9690-diff.html https://www.rfc-editor.org/authors/rfc9690-rfcdiff.html (side by side)\ https://www.rfc-editor.org/authors/rfc9690-auth48diff.html https://www.rfc-editor.org/authors/rfc9690-auth48rfcdiff.html (side by side) The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9690 Once we receive approvals from all parties listed on the AUTH48 status page, we will move this document forward in the publication process. Thank you! RFC Editor/mc > On Jan 22, 2025, at 3:24 PM, Russ Housley <hous...@vigilsec.com> wrote: > > Dear RFC Editor, > >> 1) <!-- [rfced] Should "and/or" be updated to simply "and" or "or" in this >> sentence for clarity? >> >> Original: >> (In other padding schemes, such as PKCS #1 v1.5 >> [RFC8017], the input has structure and/or depends on the keying >> material, and the provable security assurances are not as strong.) >> >> Perhaps: >> (In other padding schemes, such as PKCS #1 v1.5 >> [RFC8017], the input has structure and depends on the keying >> material. Additionally, the provable security assurances are not as strong.) >> >> Or: >> (In other padding schemes, such as PKCS #1 v1.5 >> [RFC8017], the input either has structure or depends on the keying >> material, and the provable security assurances are not as strong.) >> --> > > Please use the first suggestion: > > (In other padding schemes, such as PKCS #1 v1.5 > [RFC8017], the input has structure and depends on the keying > material. Additionally, the provable security assurances are not as strong.) > >> 2) <!-- [rfced] Please review whether any of the notes in this document >> should be in the <aside> element. It is defined as "a container for >> content that is semantically less important or tangential to the >> content that surrounds it" >> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). >> --> > > I do not think any text should become an aside. > >> 3) <!-- [rfced] Please review the following reference. We found the >> following >> URL: https://webstore.ansi.org/standards/ascx9/ansix9442007r2017. We have >> added this URL to the reference. Please let us know if you prefer otherwise. >> >> Original: >> [ANS-X9.44] >> American National Standards Institute, "Public Key >> Cryptography for the Financial Services Industry - Key >> Establishment Using Integer Factorization Cryptography", >> American National Standard X9.44, 2007. >> >> Current: >> [ANS-X9.44] >> American National Standards Institute, "Public Key >> Cryptography for the Financial Services Industry - Key >> Establishment Using Integer Factorization Cryptography", >> ANSI X9.44-2007 (R2017), 2007, >> <https://webstore.ansi.org/standards/ascx9/ >> ansix9442007r2017>. >> --> > > Addition of the URL is fine with me. > >> 4) <!-- [rfced] Please review the "type" attribute of each sourcecode element >> in the XML file to ensure correctness. If the current list of preferred >> values for "type" >> (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) >> does not contain an applicable type, then feel free to let us know. >> Also, it is acceptable to leave the "type" attribute not set. >> >> In addition, review each artwork element. Specifically, >> should any artwork element be tagged as sourcecode or another >> element? >> --> > > There are four places when <artwork> is used that could be <sourcecode > type="asn.1">. > These are at lines 417, 825, 835, and 856 of the .xml file. > >> 5) <!-- [rfced] We note that the following terms appear inconsistently >> throughout the document. If there are no objections, we will use the >> form on the right. >> >> PKCS #1 v1.5 vs. PKCS #1 v1.5 algorithm >> RSA-KEM vs. RSA-KEM algorithm vs. RSA-KEM Algorithm >> Key Derivation Function vs. key-derivation function vs. key derivation >> function (per RFC 9629) >> --> > > Please fix "key-derivation function" by dropping the hyphen. > > Please fix "RSA-KEM Algorithm" by making the A lower case. [rfced] In places where "RSA-KEM" appears on its own (6 instances), should the term be updated to "the RSE-KEM algorithm" for consistency? Or should these instances be left as is? Example (Section 2.3): The fact that the recipient will accept RSA-KEM with this public key is not indicated by the use of this object identifier. Also note that we will await further guidance re: the use of "PKCS #1 v1.5" vs. "PKCS #1 v1.5 algorithm". > I ask Sean to look at the others. I think that they read fine in the > document. > >> 6) <!-- [rfced] FYI - We have added abbreviations to expanded terms upon >> first >> use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >> expansion in the document carefully to ensure correctness. >> --> > > These look fine to me. > >> 7) <!-- [rfced] Because this document obsoletes RFC 5990, please review the >> one errata report for RFC 5990 (https://www.rfc-editor.org/errata/rfc5990) >> and confirm that it has been addressed or is not relevant in this document. >> (It seems the latter, as the word "exception" is not in this document.) >> --> > > This erratum has been resolve. The paragraph does not exist in the document. > >> 8) <!-- [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 practice. --> > > I do not see any language that is not inclusive. > > Russ -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
