Alice: I hope you holiday was full of joy. We had a big crowd for Christmas dinner.
The document looks ready to me. Russ > On Jan 6, 2025, at 4:25 PM, Alice Russo <aru...@amsl.com> wrote: > > 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 <hous...@vigilsec.com> wrote: >> >> >> >>> On Dec 20, 2024, at 7:12 PM, rfc-edi...@rfc-editor.org 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 -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
