5 ms·

> Yes, there isn't adequate browser (or other client) support to use Curve25519 signatures in a public CA's certificate. I'm not so sure about that. https://e

> Yes, there isn't adequate browser (or other client) support to use Curve25519 signatures in a public CA's certificate. I'm not so sure about that. https://en.wikipedia.org/wiki/Curve25519#History https://en.wikipedia.org/wiki/Curve25519#History "Also in 2018, RFC 8446 was published as the new Transport Layer Security v1.3 standard. It requires mandatory support for X25519, Ed25519, X448, and Ed448 algorithms.[24]" I haven't confirmed this myself, but it seems like anything that supports TLS 1.3 (a lot of things, relatively speaking) supports both curve25519 and curve448. > Another thing I don't understand is what the threat model looks like for applying hypothetically backdoored curves. Maybe this article can provide some insight into what people are concerned about: https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG Obviously, no one has proof that the NIST curves are backdoored, so who knows what kind of backdoor they would have? No one really wants to find out the hard way, though.

nicoburns 6y ago
> but it seems like anything that supports TLS 1.3 (a lot of things, relatively speaking) A lot of things, but probably not enough things for a certificate authority that has to support pretty much everything in widespread use to use.
- coder543 6y ago
  Could a certificate authority not have several root certificates? I really don't see any reason they would have to have only one root certificate. They could let people choose what kind of certificate they want issued to them, and the default could be whichever is most widely supported or whatever.
  - CydeWeys 6y ago
    Supporting a variety of options instead of just doing one thing has its own costs in terms of added complexity and maintenance. Maybe they thought about it and decided it wasn't worth it, at least not for now. There's nothing prohibiting them from offering more curves in the future.
  - aaronmdjones 6y ago
    People can already choose what kind of certificate they want issued to them, because the CA does not generate your private keys. Them giving you a certificate with an RSA public key in it is impossible if you submit a Certificate Signing Request with an ECDSA public key in it (or vice versa). Then it's only down to what intermediate certificate you want to serve. That's the constraining factor; since you don't get to choose which private key the CA signs your certificate with, you have to use the intermediate certificate whose public key corresponds to the private key that made that signature. The sensible thing for a CA to do is to sign with (and supply) an ECDSA intermediate if they get handed an ECDSA CSR, and an RSA intermediate if they get handed an RSA CSR. I imagine this is what Let's Encrypt does already.
    - tialaramex 6y ago
      It can't be what they do already because Let's Encrypt does not currently operate an ECDSA intermediate. This document describes a hierarchy they've just recently issued, and which is not yet in production use. If you present a CSR for an ECDSA public key today, Let's Encrypt will issue a certificate signed by their RSA intermediate Let's Encrypt Authority X3, for your ECDSA key. They haven't actually specified whether you'll get certificates in the new ECDSA hierarchy from the same API endpoint or need to use a different endpoint.
- elithrar 6y ago
  > A lot of things, but probably not enough things for a certificate authority that has to support pretty much everything in widespread use to use. TLS 1.3 is - in browser-centric scenarios - about 50% of clients today. Put another way: at least half of the internet does not support TLS 1.3, and that is larger still if you are in the embedded, large enterprise or similar spaces. It will take a while to close out that last 50%, and I do not blame Let’s Encrypt for taking the clearly practical approach here (by far).
toast0 6y ago
> "Also in 2018, RFC 8446 was published as the new Transport Layer Security v1.3 standard. It requires mandatory support for X25519, Ed25519, X448, and Ed448 algorithms.[24]" This is oversold, if not simply factually incorrect. RFC 8446 says > A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1(NIST P-256) and SHOULD support key exchange with X25519 x448 is not mandatory. x25519 is not mandatory, it's only a SHOULD. In addition, key exchange is for diffie-hellman ephemeral keys; that's separate from the keys used in the certificate. I don't think there's widespread support for X25519 (or X448) in X.509 certificates.
- throw0101a 6y ago
  > I don't think there's widespread support for X25519 (or X448) in X.509 certificates. The 2018 RFC if anyone is wondering: * https://tools.ietf.org/html/rfc8410 https://tools.ietf.org/html/rfc8410
  - tialaramex 6y ago
    Note that this document is (of course) not an implementation, or even an explanation of how to implement support for this, but only a description of how to spell X25519 in ASN.1 in order to write it into a PKIX X.509 certificate. So this document is a precursor to widespread support for X25519 in certificates only in the same way that coming up with a name for your kid is a precursor to giving birth. It's not strictly necessary, and it's certainly not the most important thing you needed to do, but I guess it can be part of the process.
    - GoblinSlayer 6y ago
      Huh? It doesn't write all the code for you, but it is an explanation, even provides an example of full certificate.
      - tialaramex 6y ago

nicoburns 6y ago

> but it seems like anything that supports TLS 1.3 (a lot of things, relatively speaking) A lot of things, but probably not enough things for a certificate authority that has to support pretty much everything in widespread use to use.

coder543 6y ago
Could a certificate authority not have several root certificates? I really don't see any reason they would have to have only one root certificate. They could let people choose what kind of certificate they want issued to them, and the default could be whichever is most widely supported or whatever.
- CydeWeys 6y ago
  Supporting a variety of options instead of just doing one thing has its own costs in terms of added complexity and maintenance. Maybe they thought about it and decided it wasn't worth it, at least not for now. There's nothing prohibiting them from offering more curves in the future.
- aaronmdjones 6y ago
  People can already choose what kind of certificate they want issued to them, because the CA does not generate your private keys. Them giving you a certificate with an RSA public key in it is impossible if you submit a Certificate Signing Request with an ECDSA public key in it (or vice versa). Then it's only down to what intermediate certificate you want to serve. That's the constraining factor; since you don't get to choose which private key the CA signs your certificate with, you have to use the intermediate certificate whose public key corresponds to the private key that made that signature. The sensible thing for a CA to do is to sign with (and supply) an ECDSA intermediate if they get handed an ECDSA CSR, and an RSA intermediate if they get handed an RSA CSR. I imagine this is what Let's Encrypt does already.
  - tialaramex 6y ago
    It can't be what they do already because Let's Encrypt does not currently operate an ECDSA intermediate. This document describes a hierarchy they've just recently issued, and which is not yet in production use. If you present a CSR for an ECDSA public key today, Let's Encrypt will issue a certificate signed by their RSA intermediate Let's Encrypt Authority X3, for your ECDSA key. They haven't actually specified whether you'll get certificates in the new ECDSA hierarchy from the same API endpoint or need to use a different endpoint.
elithrar 6y ago
> A lot of things, but probably not enough things for a certificate authority that has to support pretty much everything in widespread use to use. TLS 1.3 is - in browser-centric scenarios - about 50% of clients today. Put another way: at least half of the internet does not support TLS 1.3, and that is larger still if you are in the embedded, large enterprise or similar spaces. It will take a while to close out that last 50%, and I do not blame Let’s Encrypt for taking the clearly practical approach here (by far).

toast0 6y ago

> "Also in 2018, RFC 8446 was published as the new Transport Layer Security v1.3 standard. It requires mandatory support for X25519, Ed25519, X448, and Ed448 algorithms.[24]" This is oversold, if not simply factually incorrect. RFC 8446 says > A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1(NIST P-256) and SHOULD support key exchange with X25519 x448 is not mandatory. x25519 is not mandatory, it's only a SHOULD. In addition, key exchange is for diffie-hellman ephemeral keys; that's separate from the keys used in the certificate. I don't think there's widespread support for X25519 (or X448) in X.509 certificates.

throw0101a 6y ago
> I don't think there's widespread support for X25519 (or X448) in X.509 certificates. The 2018 RFC if anyone is wondering: * https://tools.ietf.org/html/rfc8410 https://tools.ietf.org/html/rfc8410
- tialaramex 6y ago
  Note that this document is (of course) not an implementation, or even an explanation of how to implement support for this, but only a description of how to spell X25519 in ASN.1 in order to write it into a PKIX X.509 certificate. So this document is a precursor to widespread support for X25519 in certificates only in the same way that coming up with a name for your kid is a precursor to giving birth. It's not strictly necessary, and it's certainly not the most important thing you needed to do, but I guess it can be part of the process.
  - GoblinSlayer 6y ago
    Huh? It doesn't write all the code for you, but it is an explanation, even provides an example of full certificate.
    - tialaramex 6y ago