Russ, My apologies for the delay. My mistake for not replying to your mail before starting the holiday break. Hope your holidays were joyful!
Thank you for your reply. The document has been updated accordingly, and the revised files are here (please refresh): https://www.rfc-editor.org/authors/rfc9708.html https://www.rfc-editor.org/authors/rfc9708.txt https://www.rfc-editor.org/authors/rfc9708.pdf https://www.rfc-editor.org/authors/rfc9708.xml This diff file shows all changes from the approved I-D: https://www.rfc-editor.org/authors/rfc9708-diff.html https://www.rfc-editor.org/authors/rfc9708-rfcdiff.html (side by side) This diff file shows the changes made during AUTH48 thus far: https://www.rfc-editor.org/authors/rfc9708-auth48diff.html We will wait to hear from you again and from your coauthors before continuing the publication process. This page shows the AUTH48 status of your document: https://www.rfc-editor.org/auth48/rfc9708 Thank you. RFC Editor/ar > On Dec 21, 2024, at 12:48 PM, Russ Housley <[email protected]> wrote: > > > >> On Dec 20, 2024, at 7:12 PM, [email protected] wrote: >> >> Greetings, >> >> While reviewing this document during AUTH48, please resolve (as necessary) >> the following questions, which are also in the XML file. >> >> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on https://www.rfc-editor.org/search. >> The ones from RFC 8708 are "digital signature, message content".--> > > I think the keywords should be the same a RFC 8708. > >> 2) <!--[rfced] May this be rephrased to avoid repetition of 'depend'? >> >> Original: >> As a result, there is a need to prepare >> for a day when cryptosystems such as RSA and DSA that depend on >> discrete logarithms and factoring cannot be depended upon. >> >> Perhaps: >> As a result, there is a need to prepare >> for a day when cryptosystems such as RSA and DSA that use >> discrete logarithms and factoring cannot be depended upon. >> --> > > Yes, that is an improvement. > >> 3) <!-- [rfced] For clarity, should the four variants be listed in this >> sentence? >> (We note they were listed in RFC 8708.) >> >> RFC 8554 [HASHSIG] contains one instance of 'variant' but not regarding >> this concept. Also, perhaps drop the "The" because within this document it's >> referred to as "the [HASHSIG] specification" or simply "[HASHSIG]". >> >> Original: >> The [HASHSIG] specifies four LM-OTS variants. >> >> Perhaps (A): [or, it could be a bulleted list as in RFC 8708] >> >> [HASHSIG] specifies four LM-OTS variants (LMOTS_SHA256_N32_W1, >> LMOTS_SHA256_N32_W2, LMOTS_SHA256_N32_W4, and LMOTS_SHA256_N32_W8). >> >> Or (B): [referring to Table 1] >> >> [HASHSIG] specifies four LM-OTS variants (as listed in Table 1 >> of [HASHIG]). >> --> > > I prefer choice (B). Thanks it is more clear. > >> 4) <!--[rfced] FYI, this sentence was updated per mail from the author on >> 25 September 2024. >> >> Original: >> When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo >> field of an end entity X.509 certificate [RFC5280], the certificate >> key usage extension MUST contain at least one of the following: >> digitalSignature or nonRepudiation. >> >> Current: >> When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo >> field of an end-entity X.509 certificate [RFC5280], the certificate >> key usage extension MUST contain at least one of the following: >> digitalSignature, nonRepudiation, or cRLSign. >> --> > > Yes, thanks for remembering to do this update. > >> 5) <!--[rfced] Regarding this comment in the ASN.1 (two instances >> in this document), could it be rephrased for clarity? Yes, this >> comment is part of the referenced [Err7963]. >> (Below, two hyphens have been replaced by one in order to include >> this as a comment in the XML file.) >> >> Original: >> - KEY no ASN.1 wrapping - >> >> Perhaps (A): >> - KEY has no ASN.1 wrapping - >> >> Or (B): >> - No ASN.1 wrapping for KEY - >> --> > > I prefer the original. > >> 6) <!-- [rfced] [ASN1-B] references the 2015 version of ITU-T Recommendation >> X.680. This ITU-T Recommendation has been superseded a new version published >> in February 2021 (https://www.itu.int/rec/t-rec-x.680/en). Would you >> like to update this reference to use the most current version and add that >> URL >> to the reference? >> --> > > Referencing the latest version is preferred. Thanks. > >> 7) <!-- [rfced] [ASN1-E] references the 2015 version of ITU-T Recommendation >> X.690. This ITU-T Recommendation has been superseded by the version in >> February 2021 (https://www.itu.int/rec/t-rec-x.690/en). Would you like >> to update this reference to use the most current version and add that URL to >> the reference? >> --> > > Referencing the latest version is preferred. Thanks. > >> 8) <!-- [rfced] For [LM], we found the following URL: >> https://patents.google.com/patent/US5432852A/ >> Would you like to add it to the reference? >> --> > > I cannot find a simple URL at the US PTO. That seems more appropriate than a > Google URL. I'd rather none. > >> 9) <!--[rfced] May usage of "MTS" be updated as follows? >> >> Original: a variant of Merkle Tree Signatures (MTS) >> Perhaps: a variant of the Merkle Tree Signature (MTS) scheme. >> >> Original: Merkle Tree Signatures (MTS) are a method >> Perhaps: The Merkle Tree Signature (MTS) scheme is a method >> >> We find zero usage of "Merkle Tree Signatures (MTS)" (with plural >> 'Signatures') >> outside of RFC 8708, and the Wikipedia entry for "Merkle signature scheme" >> does not use "MTS". [For background, we did ask about this usage during >> AUTH48 for 8708; the current question is slightly different.] >> --> > > Okay. Use "Merkle Tree Signature (MTS) scheme". > >> 10) <!-- [rfced] Please review each artwork element and let us know if any >> should >> be marked as sourcecode (or another element) instead. >> >> In addition, please consider whether the "type" attribute of any sourcecode >> element should be set and/or has been set correctly. >> >> 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. >> --> > > These look correct to me. > >> 11) <!-- [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 to make more inclusive. > > Russ > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
