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]
