Johannes Merkle writes: > As I wrote to Dan, there is actually also the option of not > specifying the parameters in the cert, but this method > (implicitCurve) is supposed to be used only if the parameters are > known to the other pier by other means (e.g. by local configuration)
So for IKEv2 use we can say that ECDSA MUST be used with certificates which give domain parameters in the certificate? That should solve the problem that we do not need separate auth methods for every different EC curve. > Even if the pier supports both SHA-1 and all SHA-2 functions, it > would require try-and-error to find out which one was used for the > signature. I now understand, when it was point out in some later emails, that in the ECDSA signatures there is no way to know the hash algorithm from the signature alone (compared to RSA, where is possible to extract the hash algorithm from signature). But there is still two different problems there. One is which hash algorithm to use, and another is how the other end knows which hash algorithm was used. There are multiple solutions to the problems. One solution to both of the problems would be to add new transform type for HASH algorithms and negotiate it. This would most likely be the cleanest way, but would require more changes than other solutions. Another option is to use method like or RSA to select which hash algorithm to use, and encode the hash algorithm to the auth payload reserved bytes. Yet another option is to specify the mandatory hash algorithm to be used for each specific curve, so hash function is known because of specific group is used. This is bit like what existing ECDSA groups are doing, i.e. each group defines hash function that must be used for it. This option does not require that every group will be given separate authentication method number. > > 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be > > done as individual draft, and does not need to be WG item, but if > > we are doing the rest in WG then I think this should also be WG > > item too). > I am not sure. If the rest is not specific for the Brainpool curves > (e.g. defining a generic ECDSA auth method) it is not so clear that > both efforts should be bundled. I do not think they need to be bundled. Thats why I proposed adding two separate charter items for them. I.e. this first step is something that can be done quickly and without any problems with just one informational RFC. I do not also expect there to be too much discussion whether this should be done or not, and how this should be done. > > 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) > > in the IKEv2. This may require new standard track RFC defining new > > generic ECDSA method, and might also need solutions how hash > > function is selected for each group. > > > According to the policy of the IANA registry for ath methods, > standard track is not required but only IETF consensus, > i.e. an informational WG document would suffice. Yes information draft would be enough, but if we are really making generic ECDSA method, then we most likely do want to also say what we are going to do for the old ECDSA methods. For example if we do want to say that those methods are NOT RECOMMENDED then we need to update the standard track document (RFC4754). Also at least I would prefer that this kind of generic work should be standard track document. > From a cryptographic point of view, the correctness (and hence, the > integrity and authenticity) of the domain parameters is crucial, it > is not a restriction to require that, if a raw (trusted) EC public > key is used, the parameters must also be available by trusted means > (e.g. local configuration). In my draft-kivinen-oob-pubkey-00.txt which adds raw EC public keys, we did plan to use SubjectPublicKeyInfo part of the PKIX certificate, thus that would have the domain parameters in there. The local configuration would then indicate whether that raw key is trusted or not. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
