-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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.
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
X25519 certificates #6072
Comments
FWIW, simply allowing X25519PublicKey (and X448PublicKey) in |
Is there official standard/RFC for X25519 in X.509? |
RFC 8410 |
This is both easier and harder now. Easier in that we now independently do signing and generate all the ASN.1 ourselves in rust. Harder in that to support this we'd need to expand the X25519/X448 APIs to support signing, which is a bit weird. I think if we're going to do this we need to be able to strongly articulate why in documentation. e.g. the normal model is ed25519 is for signing and x25519 is for kex, why would x25519 for signing be desirable (and if it's fine to use it, why ever use ed25519?). |
I believe there is a misunderstanding. First, there are no X25519 signatures in standard cryptography (and the pyca shouldn't invent them). There are ways to convert between Ed25519 and X25519 keys (since they're on a birationally equivalent curve), and it's probably OK to use one key for both signing and key exchange (there are some preprints on this), but also likely not a good idea (general principles are to separate identity/signing from key exchange, e.g. due to different lifecycles). That's not what this issue is about though: It asks for the possibility of certifying an X25519 key exchange key. With a separate signing key of any type (RSA, Ed25519, ...). Operationally, this "just' means putting the X25519 public key in the SPKI of the cert and signing over it with the signing key. It's useful for the usual reasons: extend a third party's trust in a signing key to the certified key exchange key. This may or may not be a niche use case (establishing secure channels via key exchange against a closed-universe of X25519 recipients) - it's definitely a legitimate use case, but I'd understand if pyca/cryptography prefers not so support it. The openssl snippet at the top was maybe confusing: In openssl, there must always be a CSR. This is just how its API works, and not an intrinsic requirement about X.509 certificates. For certificates for signing keys, the CSR is possible, and done to prove that the certificate is awarded to someone holding the private key. However, creating a certificate should really (additionally or mainly) mean that the certifier somehow legitimises the public key in its certificates. As a CA, I don't just sign any CSR, I inspect the public key and check that I want to extend it a certificate (I also review the other parameters of the certificate such as key uses, validity, extensions, etc.). Since there is precedent for non-signing keys in the openssl universe, the I don't think pyca/cryptography needs to follow the openssl API. In an ideal (from my perspective) world, there would be an API to create certificates for any algorithm's public keys (with either requester or granter choice of other parameters such as key uses, validity, extensions etc.), and an optional (additional) API that supports CSRs à la openssl (for signing keys only), implemented in terms of the more general API. Makes sense? |
Yes, I was definitely not reading your request correctly, thank you for being willing to explain it so clearly! This actually works with no issues in current Edit: To clarify, this works in |
Very cool, thanks! |
I'd like to equip entities with X25519 keys and certificates, so they can verify each others' identity as being inside my PKI hierarchy (Noise for IoT, kinda).
It turns out to be possible to do this with openssl using
-force_pubkey
(yes, lovely ^^):Would implementing this potentially be in scope here? It would be a little hacky presumably :) But if that's acceptable, I could try and prepare a PR.
The text was updated successfully, but these errors were encountered: