Yoav, > As Tero said, the signature algorithms can be specified in the 3 reserved > bytes, but support for such things should be indicated in the Notify payload.
Yes, I agree. > 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. > After sleeping on your idea, I realize that it may work very well for ECDSA. The main problem with elliptic curve signature schemes is that there are so many different domain parameters. Tero has pointed out that the authentication methods registry for IKEv2 is only 8-bit, limiting the number of assignable methods. On the other hand, the domain parameters are specified in the subject public key info in the certificate, either explicitly (listing all parameters) or by reference (registered OID). Thus, it is possible to define an authentication method ECDSA_generic where the domain parameters are read from the certificate. One code point for an unlimited number of domain parameters. For the hash function to be used, there are several options: 1. An RFC could specify the default for each domain parameter set, e.g. SHA-256 for Brainpool Curve p-256. 2. Alternatively or a means to override the default setting, a hash algo ID could be encoded in the 3 reserved bytes in the authentication payload 3. Since the authentication payload has variable length, it could also include a leading byte specifying the hash algorithm. Of course, this contradicts the current specification of the ECDSA authentication payload from RFC4754, but RFC4754 specifies the encoding only for the specific NIST curves ECDSA authentication methods defined therein. Johannes _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
