randombit
OIDs for ECDH Keys in Certificates
RFC 5480, Section 2.1 defines two OIDs that can be used for EC Algorithms in certificates:
o id-ecPublicKey indicates that the algorithms that can be used with the subject public key are unrestricted. The key is only restricted by the values indicated in the key usage certificate extension (see Section 3). id-ecPublicKey MUST be supported. See Section 2.1.1. This value is also included in certificates when a public key is used with ECDSA.
o i_d-ecDH_ indicates that the algorithm that can be used with the subject public key is restricted to the Elliptic Curve Diffie- Hellman algorithm. See Section 2.1.2. id-ecDH MAY be supported.
In short: id-ecPublicKey can be used with ECDSA or ECDH, while id-ecDH can only be used with ECDH. In Botan, we always use id-ecPublicKey when encoding SubjectPublicKeys with ECDSA and id-ecDH when encoding them with ECDH. Also, Botan always imports SubjectPublicKeys with OID id-ecPublicKey as ECDSA keys.
While this is standard-compliant, there is the following issue: Almost nothing out there supports the id-ecDH OID. OpenSSL and Bouncycastle do not recognize this OID. Tools like the Windows certificate view or XCA also do not recognize it. It seems there is a silent agreement to always use id-ecPublicKey for both ECDSA and ECDH.
The main problem I see is that Botan currently exports certificates with ECDH keys in a way most tools do not understand. A minor inconvenience is that Botan imports public keys from certificates always as ECDSA keys, which could be ECDH keys. What do you think?
Well that is unfortunate. The semantics of id-ecPublicKey have always seemed horrible to me considering cross-algorithm key reuse is one of the classic blunders. But if nobody else recognizes id-ecDH at all, it's not doing us any favors.
Also, Botan always imports SubjectPublicKeys with OID id-ecPublicKey as ECDSA keys.
What do other implementations do here? I guess we can use key usage to guide the decision, assuming only one of signatures vs key exchange is enabled; supporting this might be messy though. And if both usages are allowed ¯\_(ツ)_/¯ pick one I guess??
A minor inconvenience is that Botan imports public keys from certificates always as ECDSA keys, which could be ECDH keys.
I guess we are doing this anyway, for certs that anyone else created.
My thoughts at the moment
-
Clearly we have to account for other implementations not using
ic-ecDH, and use key usage to at least attempt to detect ECDH certificates instead of assuming the cert is ECDSA. -
We should continue to accept
id-ecDHgoing forward, as the actually sane choice. I'm not sure how good our tests are for this so I'd want to check on that before anything happens with (3) -
For creating new ECDH certs, I'm not sure what the best choice is. We could just switch to
id-ecPublicKeyright away, switch later after some notice period, or make it some kind of runtime decision.
Found this OpenSSL bug which seems to indicate they'd at least consider a patch adding id-ecDH support.
What do other implementations do here?
At least for OpenSSL and Bouncycastle, only one type of EC public key is used for KEX (ECDH) and signatures (ECDSA). For Botan, we could also deprecate ECDH and ECDSA keys and collect the logic for both in the EC_PublicKey/EC_PrivateKey pair with a key_agreement_op, signature_op, and a verification_op (similar to RSA). Something for Botan 4?
We should continue to accept id-ecDH going forward
Agreed!
We could just switch to id-ecPublicKey right away, switch later after some notice period, or make it some kind of runtime decision.
I'm also not sure. My intuition is that only a few applications need to create certificates with ECDH keys anyway. However, breaking the logic causes trouble for users only working with Botan for importing and exporting certificates. Probably, we only want to export ECDH certificates with id-ecPublicKey if the entire roundtrip works with Botan, i.e., importing the certificate can recover the ECDH key.
For Botan, we could also deprecate ECDH and ECDSA keys and collect the logic for both in the EC_PublicKey/EC_PrivateKey pair with a key_agreement_op, signature_op, and a verification_op (similar to RSA). Something for Botan 4?
Not happening.
My intuition is that only a few applications need to create certificates with ECDH keys anyway.
That seems very likely to me. I've never seen one in the wild myself.
Probably, we only want to export ECDH certificates with id-ecPublicKey if the entire roundtrip works with Botan, i.e., importing the certificate can recover the ECDH key.
Absolutely yes.
I've never seen [an ECDH-certificate] in the wild myself.
I wouldn't be surprised if that changed once people migrate their "authenticated key exchange"-protocols towards hybrid PQC. More people might want to go the AuthKEM route and ditch the live signature in favor of a long-lived KEM public key where authentication is achieved by a successful key confirmation. I'm leaving the question of perfect-forward secrecy aside for now.
For Botan, we could also deprecate ECDH and ECDSA keys and collect the logic for both in the EC_PublicKey/EC_PrivateKey pair with a key_agreement_op, signature_op, and a verification_op (similar to RSA). Something for Botan 4?
This does sound like a hard sell to me as well. Though, one could consider introducing a notion of "allowed key usage" to the (asymmetric) key objects. For most algorithms that could be completely transparent, because they support exactly one usage type anyway. For ECC and RSA one could enforce specifying a key usage at construction (just like today for ECC via explicit derived types). Certificates could then just "project" their key restrictions onto whatever falls out of X509_Certificate::public_key(). (Disclaimer: @FAlbertDev initially suggested that in a discussion earlier.)
Anyway, I'm not saying that this is optimal either, just putting it up for discussion.
I have seen ECDH certificates (sorry, can't post an example). And, as @reneme said, with PQ I fully expect to see more of similar for ML-KEM and other KEM algorithms - in a wider space than before.
I wouldn't be surprised if that changed once people migrate their "authenticated key exchange"-protocols towards hybrid PQC.
Sure, that transition is going to happen, but hopefuly the OIDs for hybrid PQC KEMs don't make a similar mistake here, and just encode exactly what they are. Vs, oh this key? Yeah it's ECDH+ML-KEM. Or ECDSA+ML-KEM if you want it to be. 😬