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...
That won't happen overnight anyway regardless how many MUST and MUST NOT
we say. So the schemes will co-exist some time.
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.
[snip]
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.
How would you do it in practice? Are you suggesting to include
the intended purpose into the DN?
Otherwise, even if you get two certificates from single CA - one
for RSASSA-PKCS1-v1_5 and the other for RSASSA-PSS,
you cannot distinguish which to use based on certificate request
(will be the same) or ID payload (will be the same). Using the same
key pair type works only for Responder. The only workable
option for Initiator - preconfiguration, which doesn't scale.
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.
True. If we have something like SUPPORTED_SIGNATURE_FORMATS
notification that this problem will also be solved - the end entity
will indicate that it supports, say, RSASSA-PSS for both IKEv2
and certificates.
So in the initiator: do not configure RSASSA-PSS key pair before you
know that the responder can accept such key pair.
It works. But this approach will significantly slow down adoption of more
secure RSASSA-PSS scheme, since RSASSA-PKCS-1.5 will be
configured "by default" by most users.
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.
As I've already said, I can live with "do nothing" approach you describe.
From my point of view it is a bit more complex for implementers,
documentation (a lot of heuristics in implementations) and for configuration.
User experience will probably suffer too. Otherwise it is a valid
approach and I'm not against it. I just wonder if we (the WG)
can invent something better.
Regards,
Valery.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
