Hi Yoav,
No this was different issue. I remember that discussion very well (since
I initiated it) and I wouldn't start it over again.
The issue we came across is not about different algorithms
(say indicating whether we need to use RSA or ECDSA if we have
both certificates). The algorithm is essentially one - RSA, and we have exactly one RSA certificate. However, we can
create AUTH
payload using RSA-PKCS 1.5 or using RSASSA-PSS signature
formats. And we came across that the peer from different
vendor doesn't understand RSASSA-PSS signatures while
supporting RFC7427. This is the issue. We have no clue
whether it is safe to use RSASSA-PSS or not and
the RFC gives us no means to get this clue. This is the problem.
There is one clue. The signature in the certificate. If the certificate is signed with PKCS #1.5 it is safest to use
PKCS #1.5 for authentication.
If the certificate is signed with PSS then it’s probably safe to use PSS in the
signature.
That was my first thought when we came across this issue. I thought that if
peer's certificate
is signed with RDASSA-PSS then it must be safe to use RSASSA-PSS in IKEv2.
To my disappointment our peer did understand certificate with PSS, but at the
same time
failed to understand PSS in IKEv2. That was a sad truth of life. So,
unfortunately
it doesn't reliably work.
I know this greatly delays the deployment of PSS, because for a certificate
issuer PKCS #1.5 is the safest route,
but I don’t know that we can do better without either a negotiation or prior agreement (which just means configuration
from an implementer’s POV)
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")?
Regards,
Valery.
Yoav
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
