Alicja, John, thanks for your review. Onto Alicja's open comments:
- illegal_parameter alert if the peer used algorithm not advertised, or > signature algorithm does not match the certificate > - decrypt_error when verification of the signature failed Good points, but these stipulations are not specific to ML-DSA and belong, if not already present, in rfc8446(bis). Best, Bas On Wed, Oct 23, 2024 at 9:44 PM Tim Hollebeek <tim.hollebeek= 40digicert....@dmarc.ietf.org> wrote: > Agree completely, the only thing that can go wrong with this draft is > scope creep. > > > > -Tim > > > > *From:* Deirdre Connolly <durumcrustu...@gmail.com> > *Sent:* Wednesday, October 23, 2024 3:22 PM > *To:* Alicja Kario <hka...@redhat.com> > *Cc:* Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org>; <tls@ietf.org> > <tls@ietf.org> > *Subject:* [TLS] Re: ML-DSA in TLS > > > > I would rather have a separate I-D for anything beyond ML-DSA (and thanks, > this is great!) > > > > On Wed, Oct 23, 2024 at 2:13 PM Alicja Kario <hka...@redhat.com> wrote: > > On Wednesday, 23 October 2024 20:01:28 CEST, John Mattsson wrote: > > Let’s have an adoption call asap. > > > > I made some minor suggestions > > https://github.com/bwesterb/tls-mldsa/pull/3 > > good catch on the signature_algorithms_cert part! > > and on that front, I wonder if we shouldn't also include SLH-DSA > codepoints as those may be used by the CA certs, even if the EE use > ML-DSA... > > or make it a separate I-D? > > > John > > > > From: Alicja Kario <hka...@redhat.com> > > Date: Wednesday, 23 October 2024 at 19:59 > > To: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org> > > Cc: <tls@ietf.org> > > Subject: [TLS] Re: ML-DSA in TLS > > > > Hi, > > > > Thanks for the draft, will definitely be helpful. > > > > Few issues: > > * The range 0x0900-0x0903 is reserved for backwards compatibility > > I think it will be better to continue the numbering in the 0x08.. > space > > * the must in "must use id_ML-DSA(...)" probably should be capitalised, > as > > if it doesn't match, the connection needs to be aborted > > > > open question is if we should document error handling explicitly: > > - illegal_parameter alert if the peer used algorithm not advertised, or > > signature algorithm does not match the certificate > > - decrypt_error when verification of the signature failed > > > > On Wednesday, 23 October 2024 19:29:06 CEST, Bas Westerbaan wrote: > >> Hi all, > >> > >> Unless I overlooked something, we don't have a draft out to > >> assign a SignatureAlgorithm to ML-DSA for use in TLS. > >> > >> It's two days past the I-D submission deadline, but I wanted to > >> point you to a short draft we put together to fill this gap. > >> > >> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbwesterb.github.io%2Ftls-mldsa%2Fdraft-tls-westerbaan-mldsa.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8fef63d5eddc4cb44fee08dcf38c63f4%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638653031501883034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1oIREiL3cz5iRqrSRQ2PKnw5%2BdAkv89rBl9AnUJwAgs%3D&reserved=0 > <https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html> > >> > >> So far, I see only one open question: whether to set a non-zero > >> context string. > >> > >> Best, > >> > >> Bas > >> > >> > >> > > > > -- > Regards, > Alicja (nee Hubert) Kario > Principal Quality Engineer, RHEL Crypto team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
