> -----Original Message----- > From: John Mattsson <john.matts...@ericsson.com> > > Dan Brown <danibr...@blackberry.com> wrote: > > > ANSI X9.62-2005 was withdrawn in 2015 > > Ok, that TLS 1.3 is relying on a withdrawn publication that used to be > behind a > paywall is even worse.
[DB] Have mercy on TLS: I expect they had plenty of working code, and archived ECDSA specs for documentation, so it's not at all their fault that another organization's specs expired while they were undertaking a major improvement. > > > Also, I expect FIPS 186-5 is nearly ready, and will specify much of ECDSA > > That NIST FIPS 186-5 will include all the details needed to implement ECDSA > is > great. [DB] I think I also said that I was not sure if it will have any ASN.1 (i.e. resolution of ECDSA-Sig-Value). > > >IETF has specs for sigs and their formats already, no? > > At the time when RFC 8446 was published, there was probably no quick and > easy solution to the problem. But the fact that IETF has historically been > fine > with relying on specifications behind paywalls is part of the problem. If > IETF had > implemented a strong open-access policy a long-time ago, there would > probably be an open-access version of ECDSA (NIST or IETF) a long time ago. > [DB] SECG was created, among several other reasons, to provide a kind of open-read-access ECC specifications. I think some IETF docs even refer to SECG, maybe SEC2? Doesn't IETF have RFC 5480, 6090, 6979, which cover a fair amount of ground in specifying (some variation of) ECDSA? Although, that's not a policy, and maybe was not even an easy enough solution for RFC 8446, etc.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
