Scott Fluhrer \(sfluhrer\) writes: > I’m glad to see this work; however I see a potentially important > constraint on authentication that the current draft does not appear > to address. > > It allows the peers to specify which signature algorithms they > accept; however if we are talking about certificates, those include > internal signature algorithms, which may be different. One instance > where I expect this to come up is that the root certificate may have > a more conservative algorithm choice (e.g. a hash based signature, > or one with NIST level 5) than the device certificates (which may > have a short expiry time, and so being so conservative might not be > necessary). > > Does the AuthMethod apply to the algorithms within the certificate > as well? The RFC should clarify this.
The reason for this notify is that if the peer has multiple key pairs (i.e., private keys) it needs to pick one private key to sign the AUTH payload with. If one of those private keys is using EC and another is using RSA, then without this notification there is no way of knowing which one to pick (except perhaps by prior configuration or by heuristics based on the CERTREQ etc). Also in some cases same private key can be used with multiple hashing methods etc, thus indicating what formats of signature are accepted is also needed. On the other hand the signatures in the certificates are already there, and the peers do not have any way of changing them, thus negotiating what are accepted does not help. Peers can already send as many certificates they want and they can also indicate the CAs they trust using CERTREQs, so that should be enough for peers to get algorithms in the certificates sorted out. I.e., if they have multiple paths from certificate(s) matching their private key they are going to use for signing to the trusted roots trusted by other end, they can send all those paths out. The one who gets all those certificate payloads will then search from them, and from its local cache, or even querying more intermediate certificates from the CA and form a trusted path from the one EE certificate to any trusted root that matches the security policy required for the that end. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
