Hi Valery, > > As far as I remember, the main problem was that Auth Method field in AUTH > Payload > was only 8 bits and its codepoints coupled signature with particular hash.
Well, this was the initial problem, but then Yoav had the great idea of generalizing the mechanism by using the OIDs in CERT payload. Hash flexibility was added later and this finally resulted in the current draft. > And proposed solution just moves this coupling from IPsec > registry to AlgorithmIdentifier ASN.1 object, Experience shows that the standardization of ASN.1 AlgorithmIdentifiers is done much sooner than registration of code points for protocols. Consider the Brainpool curves or RSA-PSS as examples. > where they are coupled naturally. At least for RSA-PSS, ASN.1 AlgorithmIdentifiers provide more flexibility by the parameters field. > But the other part of solution - advertising supported algorithms, > is, IMHO, currently a bit deficient, as it lists only hash algoritms, > while supported signature algorithms must be guessed by some indirect means. > I do not object to this point. While I agree with Tero, that in most situations, a transition of the algorithm will be accompanied with a change of the CA, it may not always be the case. For instance, the usage of an RSA key specified in the certificate (SPKI) by a rsaPublicKey OID may change from PKCS#1v1.5 to RSA-PSS even without replacing the certificate. > I don't insist on coupling while advertising algorithms. > Another possible option is to use one more notification, > say SIGNATURE_ALGORITHMS (with associated registry), > listing signature algorithms (decupled from hashes) that node supports. > Then peer may assume that any combination of listed > signature algorithms and hashes is supported. This is ok for me. But of course any additional means of negotiation adds complexity which must be balanced with its benefits. > > But again, we have some special cases when some signature > algorithms are defined only with particular hash functions. > Yes, but I do not see a problem here with decoupling signature and hash. -- Johannes _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
