Hi Paul,
I don't think negotiation is needed. It's enough if each side announces its
capabilities,
the same way it is done in RFC7427 with hash functions. And the easiest way
to do
it is to add pseudo-hash value "RSASSA-PSS supported" into the hash
algorithms registry.
In this case each side will announces that it supports some set of hash
algorithms in signature and
announces whether RSASSA-PSS is supported. I understand that it is a clear
protocol hack
and I don't want to follow this way, but it is the easiest path. Can you
suggest better
solution (apart from "do nothing")?
I'm really against this solution. As you said, we can expect more of
this with ECC variants, and it will just be a large cluttering of the
integ registry.
I'm not happy with it either. But it is a "quick hack" that would fix this
particular problem.
What's wrong with adding a new notify type that can be used on the
initiator as well as on the responder? And so doesn't have the problem
of favouring the "old ways" for compatibility?
Nothing wrong. In my original message
https://mailarchive.ietf.org/arch/msg/ipsec/0XYpWpMrtU_IXmn_RxfWWvsXztM
I suggested three ways to deal with the problem:
1. Do nothing
2. Make a quick hack by defining a fake hash function "RSASSA_PSS" in IKEv2
Hash Algorithms registry.
3. Define new notification SIGNATURE_FORMATS that would list supported
signature formats
In my opinion the third option is the right way to go. However, I can leave
with the first two too. Just want to know what the WG thinks of it.
Paul
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
