> 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
signature.asc
Description: Message signed with OpenPGP
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
