Hi Johannes,
Your proposal creates exactly the issue which the draft is trying to
solve: The lack of flexibility by relying on IPsec
code points for the signature algorithm (as opposed to using existing OIDs
commonly used in certificates and CMS) and
the coupling of signing algorithms and signature hash functions.
The main idea of my proposal is to allow node to advertise
what signature algorithms it supports along with what hash
functions it supports.
And the problem with the current SIGNATURE_HASH_ALGORITHMS
is that it decouples hash from signature, assuming that any hash
could be used with any signature algorithm.
This decoupling was explicitly stated as objective by the WG chairs when
the design team was set-up:
Yaron Sheffer wrote on 24.07.2012 18:08:
- Allows flexibility in associating hash functions with EC groups.
Therefore, this feature is not the problem, it is the solution.
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.
And proposed solution just moves this coupling from IPsec
registry to AlgorithmIdentifier ASN.1 object, where they are
coupled naturally. That's great and I don't have any objections against it.
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 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.
But again, we have some special cases when some signature
algorithms are defined only with particular hash functions.
--
Johannes
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
