One more: In C.3 the aside should include “NOTE:” at the beginning: OLD:
The example certificates in this section have NEW: NOTE: The example certificates in this section have > On Oct 22, 2025, at 18:24, Sean Turner <[email protected]> wrote: > > Sandy, > > Three more things: > > > 0) We should latinize xi too! There are 5 instances of xi in s6 and 3 in s8.1. > > For the first instance, i think it’s: > > OLD: > a 32-octet seed (xi) and > > NEW: > a 32-octet see (ξ) (GREEK SMALL LETTER XI, U+039E) and > > > 1) I suspect I was overzealous when I was copying the following text into > notes: > > See [RFC5280 <https://www.rfc-editor.org/authors/rfc9881.html#RFC5280>] for > the 1988 ASN.1 syntax > > I think we should drop it from the notes in s3, s4 (2nd one), and s6. There’s > not algorithms defined in 5280 and there certainly isn’t ASN.1 for any of > these algorithms in that document. The text. can remain in s2 and the 1st > instance in s4. > > > 2) s8.3 last para: > > s/TBSCertificate/<<tt>>TBSCertificate</tt> > > spt > >> On Oct 17, 2025, at 20:16, Sandy Ginoza <[email protected]> wrote: >> >> Hi Sean, >> >> Thanks for your review. We have updated the document as noted below and >> posted the revised files here: >> https://www.rfc-editor.org/authors/rfc9881.xml >> https://www.rfc-editor.org/authors/rfc9881.txt >> https://www.rfc-editor.org/authors/rfc9881.pdf >> https://www.rfc-editor.org/authors/rfc9881.html >> >> Diffs highlighting the updates below: >> https://www.rfc-editor.org/authors/rfc9881-lastdiff.html >> https://www.rfc-editor.org/authors/rfc9881-lastrfcdiff.html (side by side) >> >> AUTH48 diffs: >> https://www.rfc-editor.org/authors/rfc9881-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9881-auth48rfcdiff.html (side by >> side) >> >> Comprehensive diffs: >> https://www.rfc-editor.org/authors/rfc9881-diff.html >> https://www.rfc-editor.org/authors/rfc9881-rfcdiff.html (side by side) >> >> >> Please review and let us know if any further updates are needed or if you >> approve the RFC for publication. >> >> Thank you, >> Sandy Ginoza >> RFC Production Center >> >> >> >>> On Oct 14, 2025, at 7:36 AM, Sean Turner <[email protected]> wrote: >>> >>> Hi! I think we should make the following changes: >>> >>> 0) s3: SIGNED doesn’t actually appear in 5280, it’s in 5912. I’m suggesting >>> we do something like what we did in the previous paragraph that talks about >>> Certificate: >>> >>> OLD: >>> >>> Signatures are also used in the CRL list ASN.1 representation from >>> [RFC5280] below. >>> >>> NEW: >>> >>> Signatures are also used in the CRL list ASN.1, the representation below is >>> equivalent to that in [RFC5280]. >>> >>> 1) s3: We refer to "TBSCertificate/TBSCertList” in the previous para and in >>> 5912 there is actually no "tbsCertificate/tbsCertList” - that’s from the >>> ’88 syntax. While I am pretty sure nobody will incorrectly implement this I >>> am pretty sure that one of our an eagle eyed participants will submit an >>> editorial errata, which I’d like to avoid. >>> >>> OLD: >>> >>> The signatureValue field contains the corresponding ML-DSA signature >>> computed upon the ASN.1 DER-encoded tbsCertificate/tbsCertList [RFC5280]. >>> >>> NEW: >>> >>> The signatureValue field contains the corresponding ML-DSA signature >>> computed upon the ASN.1 DER-encoded TBSCertificate/TBSCertList [RFC5280]. >>> >>> 2) XML twiddling: use (<<tt>xi<\\tt))) like we did for tr - in s6 (twice >>> once in the 1st sentence and then in #1 in the list): >>> >>> OLD: >>> >>> (xi) >>> >>> NEW: >>> >>> (<tt>xi</ttd>) >>> >>> 3) s7: Add a Title for Table 1: >>> >>> OLD: >>> >>> Table 1 >>> >>> NEW: >>> >>> Table 1: Registered ASN.1 Module >>> >>> 4) s8.2” XML twiddling: Make font match other ASN.1 fields (make it match >>> the last sentence in the 1st para) - I think the seed and expandedKey need >>> to be wrapped in <tt> </tt>: >>> >>> OLD: >>> >>> seed and the expandedKey, >>> >>> NEW: >>> >>> <tt>seed</tt> and the <tt>expandedKey</tt>, >>> >>> 5) s8.3: Tweak tbsCertificate to TBSCertificate: >>> >>> OLD: >>> >>> tbsCertificate >>> >>> NEW: >>> >>> TBSCertificate >>> >>> 6) s9: Don’t use contraction :) >>> >>> s/can’t/cannot >>> >>> 7) Appendix A: Remove new line: >>> >>> OLD: >>> >>> END >>> >>> <CODE ENDS> >>> >>> NEW: >>> >>> END >>> <CODE ENDS> >>> >>> 8) Appendix C.4. Step 1: Add “Key” - it refers to the ASN.1 field: >>> >>> OLD: >>> >>> and <tt>expanded</tt> values >>> >>> NEW: >>> >>> and <tt>expandedKey</tt> values >>> >>> 9) Appendix D: Change to Mu: >>> >>> OLD: >>> >>> # Referred to as 'ExternalMu-ML-DSA.Sign(sk, μ)’ >>> >>> NEW: >>> >>> # Referred to as 'ExternalMu-ML-DSA.Sign(sk, mu)' >>> >>> >>> spt >>> >>>> On Oct 13, 2025, at 21:09, Sandy Ginoza <[email protected]> >>>> wrote: >>>> >>>> Hi Jake, >>>> >>>> Thank you for your review. We have noted your approval on the AUTH48 page >>>> <https://www.rfc-editor.org/auth48/rfc9881>. We will continue with >>>> publication once we hear from Sean as well. >>>> >>>> Thank you, >>>> Sandy Ginoza >>>> RFC Production Center >>>> >>>> >>>> >>>>> On Oct 13, 2025, at 5:51 PM, Massimo, Jake <[email protected]> wrote: >>>>> >>>>> Hi Sandy, >>>>> >>>>> Approved! >>>>> >>>>> Cheers, >>>>> Jake >>>>> >>>>> On 10/12/25, 12:03 PM, "Sandy Ginoza" <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>> CAUTION: This email originated from outside of the organization. Do not >>>>> click links or open attachments unless you can confirm the sender and >>>>> know the content is safe. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Hi Bas and Panos, >>>>> >>>>> >>>>> Thank you for your reviews. We have noted your approvals on the AUTH48 >>>>> page <https://www.rfc-editor.org/auth48/rfc9881>. Once >>>>> <https://www.rfc-editor.org/auth48/rfc9881>. Once> we have >>>>> received approvals from you coauthors, we will continue with the >>>>> publication process. >>>>> >>>>> >>>>> Thank you, >>>>> Sandy Ginoza >>>>> RFC Production Center >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Oct 11, 2025, at 8:39 PM, Kampanakis, Panos <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> Approved >>>>>> >>>>>> -----Original Message----- >>>>>> From: Sandy Ginoza <[email protected] >>>>>> <mailto:[email protected]>> >>>>>> Sent: Friday, October 10, 2025 4:16 PM >>>>>> To: Bas Westerbaan <[email protected] <mailto:[email protected]>> >>>>>> Cc: Sean Turner <[email protected] <mailto:[email protected]>>; Massimo, Jake >>>>>> <[email protected] >>>>>> <mailto:[email protected]>>; Kampanakis, Panos >>>>>> <[email protected] <mailto:[email protected]>>; RFC Editor >>>>>> <[email protected] <mailto:[email protected]>>; >>>>>> [email protected] <mailto:[email protected]>; [email protected] >>>>>> <mailto:[email protected]>; Russ Housley <[email protected] >>>>>> <mailto:[email protected]>>; Deb Cooley <[email protected] >>>>>> <mailto:[email protected]>>; [email protected] >>>>>> <mailto:[email protected]> >>>>>> Subject: RE: [EXTERNAL] AUTH48: RFC-to-be 9881 >>>>>> <draft-ietf-lamps-dilithium-certificates-13> for your review >>>>>> >>>>>> CAUTION: This email originated from outside of the organization. Do not >>>>>> click links or open attachments unless you can confirm the sender and >>>>>> know the content is safe. >>>>>> >>>>>> >>>>>> >>>>>> Hi Jake, Bas, and Sean, >>>>>> >>>>>> We have updated the document and posted the revised files here: >>>>>> https://www.rfc-editor.org/authors/rfc9881.xml >>>>>> <https://www.rfc-editor.org/authors/rfc9881.xml> >>>>>> https://www.rfc-editor.org/authors/rfc9881.txt >>>>>> <https://www.rfc-editor.org/authors/rfc9881.txt> >>>>>> https://www.rfc-editor.org/authors/rfc9881.pdf >>>>>> <https://www.rfc-editor.org/authors/rfc9881.pdf> >>>>>> https://www.rfc-editor.org/authors/rfc9881.html >>>>>> <https://www.rfc-editor.org/authors/rfc9881.html> >>>>>> >>>>>> Diffs highlighting only the recent changes: >>>>>> https://www.rfc-editor.org/authors/rfc9881-lastdiff.html >>>>>> <https://www.rfc-editor.org/authors/rfc9881-lastdiff.html> >>>>>> https://www.rfc-editor.org/authors/rfc9881-lastrfcdiff.html >>>>>> <https://www.rfc-editor.org/authors/rfc9881-lastrfcdiff.html> (side by >>>>>> side) >>>>>> >>>>>> AUTH48 diffs: >>>>>> https://www.rfc-editor.org/authors/rfc9881-auth48diff.html >>>>>> <https://www.rfc-editor.org/authors/rfc9881-auth48diff.html> >>>>>> https://www.rfc-editor.org/authors/rfc9881-auth48rfcdiff.html >>>>>> <https://www.rfc-editor.org/authors/rfc9881-auth48rfcdiff.html> (side by >>>>>> side) >>>>>> >>>>>> Comprehensive diffs: >>>>>> https://www.rfc-editor.org/authors/rfc9881-diff.html >>>>>> <https://www.rfc-editor.org/authors/rfc9881-diff.html> >>>>>> https://www.rfc-editor.org/authors/rfc9881-rfcdiff.html >>>>>> <https://www.rfc-editor.org/authors/rfc9881-rfcdiff.html> (side by side) >>>>>> >>>>>> >>>>>> Bas - regarding the following, the lines in RFC 5912 are already >>>>>> outdented (see https://www.rfc-editor.org/rfc/rfc5912.txt >>>>>> <https://www.rfc-editor.org/rfc/rfc5912.txt>, p17). The lines in RFC >>>>>> 5912 are actually outdented 3 additional spaces; we are unable to make >>>>>> them match with our current tools. >>>>>> >>>>>>>> Note that instead of breaking the line, we outdented — please let us >>>>>>>> know if you prefer otherwise. >>>>>>> >>>>>>> Outdenting looks good to me, I'm assuming both "Current" and "From >>>>>>> [RFC5912]" will be outdented to match eachother. >>>>>> >>>>>> >>>>>> Please review and let us know if any further updates are needed or if >>>>>> you approve the RFC for publication. >>>>>> >>>>>> Thanks, >>>>>> Sandy Ginoza >>>>>> RFC Production Center >>>>>> >>>>>> >>>>>> >>>>>>> On Oct 10, 2025, at 6:01 AM, Bas Westerbaan <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> Yes, good catch. >>>>>>> >>>>>>> On Fri, Oct 10, 2025 at 2:57 PM Sean Turner <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> Just want to make sure I didn’t introduce an error, but wanted more >>>>>>> eyes: >>>>>>> >>>>>>> Appendix D includes this: >>>>>>> >>>>>>> # Referred to as 'Externalμ-ML-DSA.Prehash(pk, M, ctx)' >>>>>>> # in the FIPS 204 FAQ. >>>>>>> >>>>>>> and this: >>>>>>> >>>>>>> # Referred to as 'Externalμ-ML-DSA.Sign(sk, μ)' >>>>>>> # in the FIPS 204 FAQ. >>>>>>> >>>>>>> Do we need to change these μ to Mu because that’s how the are actually >>>>>>> referenced in the FIPS FAQ? >>>>>>> >>>>>>> spt >>>>>>> >>>>>>> >>>>>>>> On Oct 10, 2025, at 06:03, Bas Westerbaan <[email protected] >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> Hi Sandy, >>>>>>>> >>>>>>>> Thank you for the quick updates. >>>>>>>> >>>>>>>> I see some changes are still required. >>>>>>>> >>>>>>>> - Section 2. Regarding changes for your origin point 1: you added an >>>>>>>> ampersand in front of "Params", but not in front of "id" on the line >>>>>>>> before that. >>>>>>>> >>>>>>>> - References. Regarding changes for your original point 7: you haven't >>>>>>>> updated the URL of the reference CDFFJ21 to the specific version >>>>>>>> correctly. It should be >>>>>>>> https://eprint.iacr.org/archive/2020/1525/20231023:114351 >>>>>>>> <https://eprint.iacr.org/archive/2020/1525/20231023:114351> >>>>>>>> >>>>>>>> Otherwise it looks great, thanks! >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Bas >>>>>>>> >>>>>>>> On Fri, Oct 10, 2025 at 4:50 AM Massimo, Jake >>>>>>>> <[email protected] >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> Hey Sandy, Bas, >>>>>>>> >>>>>>>> I can check a few confirmations off of this list: >>>>>>>> >>>>>>>>> Note that instead of breaking the line, we outdented — please let us >>>>>>>>> know if you prefer otherwise. >>>>>>>> >>>>>>>> Outdenting looks good to me, I'm assuming both "Current" and "From >>>>>>>> [RFC5912]" will be outdented to match eachother. >>>>>>>> >>>>>>>>> We updated to use “pre-hash” except in the following: >>>>>>>>> # Referred to as 'Externalμ-ML-DSA.Prehash(pk, M, ctx)' >>>>>>>>> Please let us know if any updates are needed. >>>>>>>> >>>>>>>> Confirming this is ok, and that we would not want to change >>>>>>>> 'Externalμ-ML-DSA.Prehash'. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Jake >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
