Sean, >> The EC group is assumed to be known from the certificate or raw key, >> and there is no need to explicitly negotiate or identify it. > > For the certificate case, I assume this means the draft will follow what's in > the RFC 5480 wrt the SPKI > AlgorithmIdentifier - i.e., the curve is always named by the OID.
Yes, although it would also work with specifiedCurve which is deprecated in RFC 5480. > > Aside: For RSA-PSS parameters don't always appear in the SPKI > AlgorithmIdentifier field - see RFC 5756. > RSA-PSS has certainly not been in the focus of our design, but only a side-product. Thus, we have tried support it only as far as possible *without extending the mechanisms*. For this reason, only RSA-PSS SPKI AlgorithmIdentifiers with parameters specified (either explicit or by using the defaults) are supported. Adding a means to signal RSA-PSS parameters in IKEv2 would have introduced considerable complexity. > >> The old EC-DSA method should be deprecated, but only after the new >> methods are supported, meaning the document should say that if new >> method is supported by both ends it SHOULD/MUST be used. > > Make sure the draft indicates it updates RFC 5996. > > In the examples above, *WithRSAEncryption and dsa-with-* are listed so are we > really talking about deprecating all of > the previous "signature" values from the IANA registry: > > V Alg Ref > -------------------------------------------------- > 1 RSA Digital Signature [RFC5996] > 3 DSS Digital Signature [RFC5996] > 9 ECDSA with SHA-256 on the P-256 curve [RFC4754] > 10 ECDSA with SHA-384 on the P-384 curve [RFC4754] > 11 ECDSA with SHA-512 on the P-521 curve [RFC4754] > The design team decided to deprecate DSS in case that the new method is supported. There was no decision (or even discussion) on whether to deprecate RSA Digital Signature. This is still to be discussed. >> Sending this notification tells that new "Digital Signature" >> authentication method is supported and that following hash functions >> are supported by sending peer. Both ends sends their list of supported >> hash-algorithms and when calculating signature a peer MUST pick one >> algorithm sent by the other peer. Note, that different algorithms can >> be used in different directions. The actual algoritm used when >> calculating the signature is sent inside the Authentication Data field >> of the Authentication Payload. > > Assuming here that this new notify is normally sent during the IKE_SA_INIT > exchange from the responder to the initiator: > > a) The initiator actually figures out the signature algorithms supported by > the responder based on the new Notify > message, Alg ID parameter, and the cert's key usage extension? The SPKI will > include id-ecPublicKey not ecdsa-with-* > right so you can't rely on that. You can't rely on just the Alg ID parameter > because the key usage extension can have > any combination of digitalSignature, nonRepudiation, and keyAgreement set. So > don't you have to look at all three? > I am not sure I get your point regarding the key usage extension. As we talk about authentication through digital signatures, I guess that digitalSignature MUST be set in the KE extension anyway. You correctly point out a limitation of the negotiation mechanism (through the notify payload) to the hash algorithm. Negotiation of the signature algorithm was not considered as the focus was on the digital signature algorithms currently supported in IKEv2, i.e. ECDSA, DSA and RSA. EC-based signature schemes other than ECDSA are hardly used in practice and RFC 5480 does not list any. If someone desires to use Nyberg-Rueppel, EC-ElGamal or EC-Schnorr signatures, she can do so but without negotiation. Do you advocate a negotiation of the signature algorithm? Note: ECGDSA keys (which are actually used for IKE in Germany) are not specified by id-ecPublicKe but by a dedicated OID ecgPublicKey as the relation between private and public key differs from ECDSA keys. -- Johannes _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
