Removing the second expansion is fine. Russ
> On Jan 7, 2025, at 3:50 PM, Alice Russo <aru...@amsl.com> wrote: > > Russ, > Final question: Is it OK to remove this repeated expansion of PRNG, or do you > prefer that it remain as is (as it matches RFC 8708)? > > Proposed change in Section 6 (because PRNG is expanded in the preceding > paragraph). > > Old: > While the consequences of an inadequate pseudorandom number generator (PRNG) > to generate ... > > New: > While the consequences of an inadequate PRNG to generate ... > > Thank you. > RFC Editor/ar > >> On Jan 7, 2025, at 11:22 AM, Alice Russo <aru...@amsl.com> wrote: >> >> Russ, >> We have noted your approval on the AUTH48 page for this document >> (https://www.rfc-editor.org/auth48/rfc9708). We will move this document >> forward in the publication process. >> >> Thank you for your time. >> >> RFC Editor/ar >> >>> On Jan 6, 2025, at 1: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
