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. 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
