> On 4 Jul 2016, at 7:12 PM, David Benjamin <david...@chromium.org> wrote: > > On Mon, Jul 4, 2016 at 7:59 AM Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: > > > On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara <ilariliusva...@welho.com > > <mailto:ilariliusva...@welho.com>> wrote: > > > > On Mon, Jul 04, 2016 at 03:46:00PM +0300, Yoav Nir wrote: > >> Hi > >> > >> Based on an email exchange with Nikos Mavrogiannopoulos, I’ve submitted a > >> PR. > >> > >> https://github.com/tlswg/rfc4492bis/pull/23 > >> <https://github.com/tlswg/rfc4492bis/pull/23> > >> > >> If there are no objections, I will accept it and submit version -08 this > >> Friday. > > > > While scanning through, I noticed that the Ed25519 and Ed448 "curves" > > are still there. I think negotiating those should be done the same way > > as in TLS 1.3 (those would then appear as hash=7 signature=3/4 IIRC). > > IMO this makes it very complex. TLS 1.3 replaces the old signature_algorithms > extension that had pairs of signature algorithm/hash algorithm with one that > has 16-bit values. > > It changes things for ECDSA as well. We’re not going to change ECDSA in TLS > 1.2. So if we wanted to adopt that we would still interpret 0x04,0x03 as > ECDSA (with whatever curve) along with SHA-256, while 0x07,0x03 would be > Ed25519, not ECDSA with some unknown hash function 0x07. > > Seems strange to me, but I’ll make whatever changes the group wants. > > Oops, I think I agreed to backport this at IETF 95 and completely forgot. > Sorry about that! My bad. > > Although, thinking about it now, I'm not sure if we should bother. As you > mention, it's weird since ECDSA still needs to be interpreted in the 1.2 > style, despite being spelled in the 1.3 way. We'd also end up with the new > scheme being defined in two places. > > It seems better to get X25519 / X448 out the door first as that has no > prerequisites. X25519 in TLS already has running code today. Chrome ships it, > and Google servers have it enabled. The 1.1.0 release of OpenSSL is also > slated to have support. > > Ed25519 / Ed448, on the other hand, don't even have an embedding in X.509 yet > (though hopefully the main question remaining will get resolved in curdle > soon). Then there's the timeline for draft-irtf-cfrg-eddsa, which I'm not > familiar with. New signature schemes also depend on CAs being willing to sign > them which, for the web PKI, I expect will not be fast. Saying new signature > schemes are only defined for 1.3 and up seems reasonable enough to me, though > I suppose it depends on how the timelines for all the other drafts end up > looking.
The CFRG draft is not the limiting factor. We’re waiting for draft-ietf-curdle-pkix-00. But honestly, I don’t think anyone is going to be issuing EdDSA certificates any time soon. The commercial CAs have just recently starting using ECDSA, and even for local CAs you generally don’t use a new algorithm until every relying party in your environment supports it. Yoav
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
