Ah yeah, and I didn't notice that the draft already cited 9881 elsewhere, but under the name MLDSACERTS, or I'd have used the same naming the draft did and been less confusing. :-)
On Fri, Apr 10, 2026, 17:28 Michael StJohns <[email protected]> wrote: > Hi David - > > I think we are. I got confused when you cited 9881, but there was already > a reference to MLDSACERTS nearby - which is still pointing to the > datatracker draft instead of the updated RFC. Hmm.. that reference > (MLDSACERTS/RFC9881) should be moved to be Normative. > > I thought Carl was talking about repeating the AlgorithmIdentifier > definition here and you were agreeing... my bad. > > So that table becomes SignatureScheme/FIPS > 204/SignatureAlgorithmIdentifier - all referenced back to RFC9881 section > 3. The names change from id-ml to sa-ml and the OIDs can stay or go. > > Lastly in section three, first para: > s/adds three new/maps three new/ > and > s/as follows/to the SignatureAlgorithmIdentifiers from RFC9981 > Section 3 as follows/ > > I think that cleans up Carl's general concern. > > Mike > > On 4/10/2026 17:11, David Benjamin wrote: > > 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]
