On Mon, Oct 12, 2015 at 10:47:58PM +0200, Simon Josefsson wrote: > > The following document adds new EdDSA key/signature OIDs directly: > > https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04
The certificate example seems to contain OID 1.3.101.100.1... Is that intended or should it be 1.3.101.101? IIRC, someone pointed mistake in OIDs before, dunno if that has been corrected. > The following document adds new namedCurve OIDs, thus going indirectly > through the existing ECDSA 3279 route: > > https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01 I think this approach is unsuitable for signature keys, but it would be suitable for X25519/X448 DH public keys, which some people apparently have been requesting (IiRC, I have heard requests for that, don't remember from whom).. And AFAICT, those keys don't have associated hashes, and such public keys should be marked for DH only (1.3.132.1.12). > These two drafts take different approaches to including the new curves > into PKIX, and currently both lack applicability statements. There is > potential for overlap and conflict right now. It recently came up that > for PKCS#11 a namedCurve approach would be useful, but for normal PKIX > Certificates, it may be that the first direct approach is preferrable. > The former lack the possibility of encoding keys for DH. I believe each > approach can be useful on its own, but we need to include text adressing > use-cases that can be resolved by both documents to avoid conflicts. IMO, new algorithm is more suited for signature keys, whereas new curve is more suited for DH public keys. This is because there is currently no way to designate correct algorithm for signatures[1], whereas there is for DH, so one just needs to designate correct curve. [1] ECDSA uses "unrestricted", which has been implicated in TLS ECDH KCI MITM attack (equivalent attack doesn't work for "discrete" DH because signature keys are distinct from DH keys). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
