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 <[email protected]> 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 <[email protected]> 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 <[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]
