Hi Russ,
Thanks for your reply and explanation.
The text has been updated and the RFC will be announced shortly.
Thanks,
RFC Editor/sg
> On Jan 10, 2025, at 12:08 PM, Russ Housley <hous...@vigilsec.com> wrote:
>
> 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 <sgin...@staff.rfc-editor.org>
>> 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 <hous...@vigilsec.com> wrote:
>>>
>>> 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
