On 7/20/12 7:13 AM, Johannes Merkle wrote:
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.

Just thought I'd point out here that in RFC 5480 the only option is namedCurve (i.e., OIDs). But, the brainpool curves all have OIDs assigned in RFC 5639.

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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to