4 ms·

My greatest pain with certificates and especially the X509 standard is that it‘s so large / loosely designed, it‘s hard to call it a standard at all. X509 is mo

My greatest pain with certificates and especially the X509 standard is that it‘s so large / loosely designed, it‘s hard to call it a standard at all. X509 is more of a bucket you can almost drop anything in. Perhaps my greatest grievance is that it’s a leaky abstraction by design. There are small to huge differences between different CA vendors, SSL implementations and the internal DER/Asn1 structures they emit. This also includes key encodings. Error codes are incredibly opaque. Ever tried parsing a wrapped SPKI key with Ring/BoringSSL? It crashes with „Wrong Tag“ and incromprehensible letter soup. OpenSSL‘s Base64 toolset only works with aligned/padded input and a specific alphabet. Try inputting non-padded data, all you get is „Error“. That‘s it. Incredible. Does this SSL implementation expect raw SubjectPublicKeyInfo, or can it accept Keys with additional headers? Can I trust that extended attributes are handled correctly? OpenSSL just emits „some“ DER here, while BoringSSL expects my public key to be of „ECDSA__ASN1“ format - or was it „ ECDSA__FIXED“? I have embedded devices that use MbedTLS or WolfSSl, Rust backend servers which depend on Ring/BoringSSL, Users which want to use OpenSSL EE certs and a public CA which could use any of these. How the hell do I generate certificates and keys in a way they all understand? I don‘t know, and neither do you. It‘s all a massive headache.

lmz 2y ago
X509 certs are more or less interoperable as seen everyday on the Internet where your HTTPS sites mostly work. Keys are another matter (and a private one at that).
- selfmodruntime 2y ago
  That's mostly only if you use them for HTTPS/SSL. There are many more uses for certificates, like signing payloads via JWS/Jose, CWS or CMS/PKCS7.
  - candiddevmike 2y ago
    X.509 isn't used for JWTs?
    - lmz 2y ago
      Unfortunately they are. https://datatracker.ietf.org/doc/html/rfc7517 https://datatracker.ietf.org/doc/html/rfc7517
      - candiddevmike 2y ago
        JSON Web Keys include (optional) X.509-related properties but don't necessarily use X.509 for anything. X.509 isn't used in JWT signing or really with any part of a JWT.
        selfmodruntime 2y ago
        You can deliver x5c certificates that need to have been signed by the same public key as the token signature.
- michaelt 2y ago
  That's because some people came along and produced a parallel standard [1] adding loads more rules, clarifications and constraints to convert X509 into something approximately fit for purpose. [1] https://github.com/cabforum/servercert https://github.com/cabforum/servercert
woodruffw 2y ago
> How the hell do I generate certificates and keys in a way they all understand? When we built Python Cryptography's X.509 validator[1], we also built an entire test suite that compares different implementations for RFC 5280/CABF compliance for exactly this purpose[2]. It's already found a decent number of bugs (both public and non-public) in widely used implementations; you may find it useful! (I agree that X.509's constellation of standards are a mess. But I also think a huge part of the mess in practice is implementations trying to do too much: if all you need is to verify client/server chains in the Web PKI, then "all" you need is CABF. There's no point in implementing RFC 3280, etc.) [1]: https://blog.trailofbits.com/2024/01/25/we-build-x-509-chains-so-you-dont-have-to/ https://blog.trailofbits.com/2024/01/25/we-build-x-509-chain... [2]: https://x509-limbo.com/ https://x509-limbo.com/
- selfmodruntime 2y ago
  That is very nice work. Thank you so much! One thing I would be interested in is if there were any differences between rust-webpki and BoringSSL itself. Also, I would love if MbedTLS or WolfSSL would also be compared. However, their state is in itself a bit questionable.
  - woodruffw 2y ago
    > One thing I would be interested in is if there were any differences between rust-webpki and BoringSSL itself. Adding BoringSSL as a harness would probably be pretty easy! We have an existing OpenSSL harness[1] that would probably be straightforward to adapt. We could also probably improve the visualization of differences between implementations: right now you can find them either by looking at individual testcases[2] or on each harness's "anomalies" page[3], but it'd be cool to have a more unified UI. [1]: https://github.com/C2SP/x509-limbo/blob/main/harness/openssl/main.cpp https://github.com/C2SP/x509-limbo/blob/main/harness/openssl... [2]: https://x509-limbo.com/testcases/rfc5280/#rfc5280akileaf-missing-aki https://x509-limbo.com/testcases/rfc5280/#rfc5280akileaf-mis... [3]: https://x509-limbo.com/anomalous-results/rust-webpki/ https://x509-limbo.com/anomalous-results/rust-webpki/
0x00cl 2y ago
> My greatest pain with certificates and especially the X509 standard is that it‘s so large / loosely designed, it‘s hard to call it a standard at all. X509 is more of a bucket you can almost drop anything in. I recently wrote a blog post[1] about the limits of TLS certs and from what I understood of X.509 is more of a framework and standards or applications can use it to define their certificates such as RFC 5280[2] which is the standard that defines their usage on the Internet. [1] https://0x00.cl/blog/2024/exploring-tls-certs/ https://0x00.cl/blog/2024/exploring-tls-certs/ [2] https://www.rfc-editor.org/rfc/rfc5280 https://www.rfc-editor.org/rfc/rfc5280

lmz 2y ago

X509 certs are more or less interoperable as seen everyday on the Internet where your HTTPS sites mostly work. Keys are another matter (and a private one at that).

selfmodruntime 2y ago
That's mostly only if you use them for HTTPS/SSL. There are many more uses for certificates, like signing payloads via JWS/Jose, CWS or CMS/PKCS7.
- candiddevmike 2y ago
  X.509 isn't used for JWTs?
  - lmz 2y ago
    Unfortunately they are. https://datatracker.ietf.org/doc/html/rfc7517 https://datatracker.ietf.org/doc/html/rfc7517
    - candiddevmike 2y ago
      JSON Web Keys include (optional) X.509-related properties but don't necessarily use X.509 for anything. X.509 isn't used in JWT signing or really with any part of a JWT.
      - selfmodruntime 2y ago
        You can deliver x5c certificates that need to have been signed by the same public key as the token signature.
michaelt 2y ago
That's because some people came along and produced a parallel standard [1] adding loads more rules, clarifications and constraints to convert X509 into something approximately fit for purpose. [1] https://github.com/cabforum/servercert https://github.com/cabforum/servercert

woodruffw 2y ago

> How the hell do I generate certificates and keys in a way they all understand? When we built Python Cryptography's X.509 validator[1], we also built an entire test suite that compares different implementations for RFC 5280/CABF compliance for exactly this purpose[2]. It's already found a decent number of bugs (both public and non-public) in widely used implementations; you may find it useful! (I agree that X.509's constellation of standards are a mess. But I also think a huge part of the mess in practice is implementations trying to do too much: if all you need is to verify client/server chains in the Web PKI, then "all" you need is CABF. There's no point in implementing RFC 3280, etc.) [1]: https://blog.trailofbits.com/2024/01/25/we-build-x-509-chains-so-you-dont-have-to/ https://blog.trailofbits.com/2024/01/25/we-build-x-509-chain... [2]: https://x509-limbo.com/ https://x509-limbo.com/

selfmodruntime 2y ago
That is very nice work. Thank you so much! One thing I would be interested in is if there were any differences between rust-webpki and BoringSSL itself. Also, I would love if MbedTLS or WolfSSL would also be compared. However, their state is in itself a bit questionable.
- woodruffw 2y ago
  > One thing I would be interested in is if there were any differences between rust-webpki and BoringSSL itself. Adding BoringSSL as a harness would probably be pretty easy! We have an existing OpenSSL harness[1] that would probably be straightforward to adapt. We could also probably improve the visualization of differences between implementations: right now you can find them either by looking at individual testcases[2] or on each harness's "anomalies" page[3], but it'd be cool to have a more unified UI. [1]: https://github.com/C2SP/x509-limbo/blob/main/harness/openssl/main.cpp https://github.com/C2SP/x509-limbo/blob/main/harness/openssl... [2]: https://x509-limbo.com/testcases/rfc5280/#rfc5280akileaf-missing-aki https://x509-limbo.com/testcases/rfc5280/#rfc5280akileaf-mis... [3]: https://x509-limbo.com/anomalous-results/rust-webpki/ https://x509-limbo.com/anomalous-results/rust-webpki/

0x00cl 2y ago

> My greatest pain with certificates and especially the X509 standard is that it‘s so large / loosely designed, it‘s hard to call it a standard at all. X509 is more of a bucket you can almost drop anything in. I recently wrote a blog post[1] about the limits of TLS certs and from what I understood of X.509 is more of a framework and standards or applications can use it to define their certificates such as RFC 5280[2] which is the standard that defines their usage on the Internet. [1] https://0x00.cl/blog/2024/exploring-tls-certs/ https://0x00.cl/blog/2024/exploring-tls-certs/ [2] https://www.rfc-editor.org/rfc/rfc5280 https://www.rfc-editor.org/rfc/rfc5280