WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
> Adding them to ECDSA is more difficult. Adding them for Diffie-Hellman
> use requires updating of one expert review 16-bit registry for IKEv2.
> The same registry in the IKEv1 is RFC required, so it does not require
> standard track RFC.
> Adding them for authentication use (ECDSA use) will most likely get
> more opposition. First of all, I am not at all happy how the ECDSA
> groups are added to the IKEv2 authentication method. The
> authentication methods registry is only 8-bit in IKEv2 (it is 16-bit
> registry in IKEv1). This does not matter if we have only few ECDSA
> groups with one hash algorithm for each, but when we are adding more
> groups it seems to bad idea for each of them having separate number.
> Especially if someone later decides that they want to use all ECDSA
> groups with SHA 3 too...
> I think we should have made the ECDSA support for IKEv2 in such way
> that we had added some subfields to the authentication field, i.e.
> only allocated one value for ECDSA and put the curve number inside the
> authentication payload and perhaps even separated the hash algorithm
> from it. There is 3 bytes of reserved data in the authentication
> payload immediately after the auth method. Perhaps we could use those.
How about standardizing just one more authentication method?
Call it "public key signature" or some such, and make the signing algorithm depend on the public key in the CERT payload.
If it's RSA, go by bit strength:
- <=1024 - SHA-1 with RSA
- 1024<x<=2048 - SHA2-256 with RSA
- 2048<x<=4096 - SHA2-384 with RSA
- >4096 - SHA2-512 with RSA
DSA - always SHA-1
ECDSA will be defined by curve. The three NIST curves that everyone uses already have hashes associated with them. Any new curve would have to specify the signature algorithm in the same document.
Since the same certificate can be used with both the old authentication method and the new, we'd have to signal support in a Notify, and that Notify could have bits for indicating support for other signature algorithms such as those that go with SHA3.
Wouldn't this make adding future curves and other signature variants easier?