8000 OIDs for ECDH Keys in Certificates · Issue #4750 · randombit/botan · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

OIDs for ECDH Keys in Certificates #4750

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
FAlbertDev opened this issue Mar 5, 2025 · 6 comments
Open

OIDs for ECDH Keys in Certificates #4750

FAlbertDev opened this issue Mar 5, 2025 · 6 comments

Comments

@FAlbertDev
Copy link
Collaborator

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?
@randombit
Copy link
Owner

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

  1. 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.

  2. We should continue to accept id-ecDH going 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)

  3. For creating new ECDH certs, I'm not sure what the best choice is. We could just switch to id-ecPublicKey right 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.

@FAlbertDev
Copy link
Collaborator Author
FAlbertDev commented Mar 6, 2025 •
edited
Loading

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.

@randombit
Copy link
Owner

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.

@reneme
Copy link
Collaborator
reneme commented Mar 6, 2025

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.

@mouse07410
Copy link
Contributor

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.

@randombit
Copy link
Owner

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. 😬

@randombit randombit changed the title OIDs for EC Keys in Certificates OIDs for ECDH Keys in Certificates Mar 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@randombit @reneme @mouse07410 @FAlbertDev
0