I think we are saying the same thing. I am saying that it should reference the complete signature algorithm definitions, i.e. the SIGNATURE-ALGORITHM objects. Specifically, this draft needs to cite the ones for ML-DSA, which are defined in RFC 9881, i.e. MLDSACERTS.
I was *replying* to a message which suggested that the TLS document repeat the parameter definition. It sounds like you and I agree that the TLS document should instead cite the existing complete definition. On Fri, Apr 10, 2026 at 3:16 PM Michael StJohns <[email protected]> wrote: > Hi David - > > That doesn't quite work. What you're looking for here are the names of > the SIGNATURE-ALGORITHM declarations (which are bound to those OID > identifiers) not the OID declarations. Those are in the MLDSACERTS > document. Import/use sa-ml-dsa-* instead of id-ml-dsa-* and omit the OID > definitions (or note them in a different column for reference). The > SIGNATURE-ALGORITHM declarations already say that the parameters field is > omitted for each of these three declarations. > > The AlgorithmIdentifier column should reference > SignatureAlgorithmIdentifier from RFC 5911 vice AlgorithmIdentifier. The > MLDSACERTS document expands the definition of SignatureAlgorithmIdentifier > properly to include the ML DSA signatures. > > Mike > > > > On 4/10/2026 11:35, David Benjamin wrote: > > Ah, good call. Though I'd suggest we just instead cite RFC 9881, which > defines the OID and params together, rather than duplicate the definition. > > On Fri, Apr 10, 2026 at 11:33 AM Corey Bonnell <Corey.Bonnell= > [email protected]> wrote: > >> I read the document and support publication. >> >> A nit on the use of "AlgorithmIdentifier" in the document: >> AlgorithmIdentifier >> is an ASN.1 SEQUENCE of an "algorithm" OID field and an optional >> "parameters" >> field. To fully specify the AlgorithmIdentifier for each of the three >> parameter sets, it's also necessary to specify that the "parameters" >> field >> must be absent. I suggest modifying Table 1 to explicitly state that >> "parameters" are absent. >> >> If that's unpalatable, then I suggest changing all instances of >> "AlgorithmIdentifier" to "algorithm identifier". >> >> Thanks, >> Corey >> >> -----Original Message----- >> From: Sean Turner <[email protected]> >> Sent: Thursday, April 9, 2026 3:30 PM >> To: TLS List <[email protected]> >> Subject: [TLS] Working Group Last Call for Use of ML-DSA in TLS 1.3 >> >> This is the working group last call for Use of ML-DSA in TLS 1.3. Please >> review draft-ietf-tls-mldsa [1] and reply to this thread indicating if >> you >> think it is ready for publication or not. If you do not think it is ready >> please indicate why. This call will end on April 23, 2026. >> >> REMINDER: If you have not done so recently, review the TLS WG's Mail List >> Procedures; see [2]. >> >> The Chairs, >> Deirdre, Joe, and Sean >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mldsa/ >> [2] >> https://mailarchive.ietf.org/arch/msg/tls/ucdImHExlbOf4Q3BCG81gjzi2xE/ >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
