Valery Smyslov writes:
> The reasons can be various. For example, after wide adoption
> of EdDSA some vulnerability is found in the scheme and some
> modifications are introduced to eliminate it (analogously to
If there would be vulnerability in the signature scheme, I think we
would say you MUST NOT use the old format and you MUST use the new
format...
> appearance of RSASSA-PSS). Or more efficient signature
> algorithm for exactly the same elliptic curve is found.
If more efficient signature algorithm is found, I would still
recommend using different keys for different methods.
> I don't know. If you asked me few years ago why would new
> RSA signature format ever appear, I wouldn't know what to
> answer and would probably agree with you that there were no reasons.
> But it happened.
RSASSA-PSS was specified in 2003, in the RFC3447, which then obsoleted
the RFC2437, which then obsoleted the RFC2313. Both RFC2437 and
RFCC2313 were from 1998.
On the other hand the RSASSA-PSS and RSASSA-PKCS1-v1_5 both are still
defined in the RFC3447, but RSASSA-PKCS1-v1_5 was there for gradual
transition to the RSASSA-PSS:
Although no attacks are known
against RSASSA-PKCS1-v1_5, in the interest of increased robustness,
RSASSA-PSS is recommended for eventual adoption in new applications.
RSASSA-PKCS1-v1_5 is included for compatibility with existing
applications, and while still appropriate for new applications, a
gradual transition to RSASSA-PSS is encouraged.
It also says:
A generally good cryptographic practice is to employ a given RSA key
pair in only one scheme. This avoids the risk that vulnerability in
one scheme may compromise the security of the other, and may be
essential to maintain provable security.
...
As another example, suppose
an RSA key pair is employed in both RSASSA-PSS (Section 8.1) and
RSASSA-PKCS1-v1_5. Then the security proof for RSASSA-PSS would no
longer be sufficient since the proof does not account for the
possibility that signatures might be generated with a second scheme.
Similar considerations may apply if an RSA key pair is employed in
one of the schemes defined here and in a variant defined elsewhere.
I.e., it does recommend that one key pair is used with only one
scheme.
So reading the RFC3447 you should not use same RSA key with both
RSASSA-PKCS1-v1_5 and RSASSA-PSS. So you are supposed to have two key
pairs one for each scheme, and then you need to pick one based on
other things, like the certificate request, ID payloads (==
configuration), or use the same key pair type than other end used.
RSASSA-PSS also appeared more than ten years ago, so it is not new,
and we have supposedly being doing transition to it for long time...
Note, that there is no way of knowing whether your certificate using
RSASSA-PSS is going to be acceptable for the other end. If it only
supports RSASSA-PKCS1-v1_5 signature method in certificates, you are
in same problem, and you have to somehow know that and use the
certificate using RSASSA-PKCS1-v1_5 signature method.
So in the initiator: do not configure RSASSA-PSS key pair before you
know that the responder can accept such key pair.
In responder: pick the key pair you are using based on the auth
payload the other end sent, or if other end did not use signatures to
authenticate, then select key based on the IDr or certificate request.
Or just add manual configuration based on the vendor ids to pick
RSASSA-PKCS1-v1_5 if you know that implementation do not support
RSASSA-PSS.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
