Sandy: Yes, please.
Sadly, both have been used for many years. They are essentially synonyms, and the on-the-wire encoding only cares about the (9) part. Russ > On Jan 10, 2025, at 1:59 PM, Sandy Ginoza <[email protected]> > wrote: > > Hi Russ, > > For RFC 9709, you suggested "pkcs-9(9)” is correct (replacing "pkcs9(9)”) — > does that apply to this document as well? > > Section 3: > id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1) > member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) > smime(16) alg(3) 17 } > > Appendix A: > MTS-HashSig-2013 > { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) > id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) } > > … > > id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { iso(1) > member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) > smime(16) alg(3) 17 } > > > Thanks, > RFC Editor/sg > > > >> On Jan 7, 2025, at 1:05 PM, Russ Housley <[email protected]> wrote: >> >> Removing the second expansion is fine. >> >> Russ >> >>> On Jan 7, 2025, at 3:50 PM, Alice Russo <[email protected]> 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 <[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]
