We build X.509 chains so you don't have to • Hacker News Board

Re: We build X.509 chains so you don't have to

#11

Post by woodruffw » Thu, Jan 25, 2024, 4:18 PM UTC

e12e wrote: post #8

Fantastic! Curious about revocations though - the post doesn't mention it?

Thanks for calling this out. Revocations are not currently supported by the public API; we made a decision early in the MVP planning process to exclude them for complexity reasons.

(This is consistent with Go's crypto/x509, which does not do revocation checking as part of the `Verify` API.)

Re: We build X.509 chains so you don't have to

#12

Post by kachnuv_ocasek » Thu, Jan 25, 2024, 4:20 PM UTC

e12e wrote: post #8

Fantastic! Curious about revocations though - the post doesn't mention it?

That's a whole another can of worms.

Re: We build X.509 chains so you don't have to

#13

Post by ak217 » Thu, Jan 25, 2024, 4:21 PM UTC

This is an absolute game changer for the ability to write secure PKI-based software in Python. Before now, you had to use pyOpenSSL (ignoring its warning to not use it for anything other than an SSL connection) and avoid the many footguns associated with building the certificate chain on your own, or leave Python entirely and talk to a separate Rust or Go process.

Thanks to Trail of Bits for pulling this off.

Re: We build X.509 chains so you don't have to

#14

Post by Etheryte » Thu, Jan 25, 2024, 4:24 PM UTC

asylteltine wrote: post #3

[flagged]

A considerable number of common packages in the Python ecosystem are backed at least in part by another language. This is not a shortcoming, it's a feature. Give end users flexibility while figuring out performance and other beasts internally.

Re: We build X.509 chains so you don't have to

#15

Post by CogitoCogito » Thu, Jan 25, 2024, 4:25 PM UTC

asylteltine wrote: post #3

[flagged]

> Is it really “Python” if the underlying stuff is written in another language?

Given that "python" is basically synonymous with "cpython" and cpython has always been implemented in C, I guess the answer to your question is "yes".

Re: We build X.509 chains so you don't have to

#16

Post by reaperhulk » Thu, Jan 25, 2024, 4:32 PM UTC

caeruleus wrote: post #2

Congratulations to the authors, this was a feature that was dearly missing from pyca/cryptography. It took a long time to get right. For the history: https://github.com/pyca/cryptography/issues/2381

Thanks for posting! I had forgotten just how long a road this was, but I'm very pleased that the requirements we talked about years ago have been met. :)

That's not to say this is done! There's a set of features we still want to add and we'd like to gain some confidence in the APIs as structured before we mark them as stabilized.

Re: We build X.509 chains so you don't have to

#17

Post by colechristensen » Thu, Jan 25, 2024, 4:32 PM UTC

woodruffw wrote: post #11

e12e wrote: post #8

Fantastic! Curious about revocations though - the post doesn't mention it?

Thanks for calling this out. Revocations are not currently supported by the public API; we made a decision early in the MVP planning process to exclude them for complexity reasons. (This is consistent with Go's crypto/x509, which does not do revocation checking as part of the `Verify` API.)

Not planned for MVP or not planned ever?

Re: We build X.509 chains so you don't have to

#18

Post by teddyh » Thu, Jan 25, 2024, 4:37 PM UTC

Note: If your application does not absolutely need it, there are alternatives to X.509 certificates in TLS, like raw public keys (RFC 7250).

Re: We build X.509 chains so you don't have to

#19

Post by woodruffw » Thu, Jan 25, 2024, 4:42 PM UTC

colechristensen wrote: post #17

woodruffw wrote: post #11

Earlier quoted context omitted.

Thanks for calling this out. Revocations are not currently supported by the public API; we made a decision early in the MVP planning process to exclude them for complexity reasons. (This is consistent with Go's crypto/x509, which does not do revocation checking as part of the `Verify` API.)

Not planned for MVP or not planned ever?

Not planned for the MVP, but not necessarily excluded in the future. I think it'd require a substantial design period, but that's my impression as an external contributor.

Re: We build X.509 chains so you don't have to

#20

Post by thadt » Thu, Jan 25, 2024, 4:46 PM UTC

While the contribution to Python Cryptography is incredibly awesome, I'd suggest that perhaps the lede is slightly buried. Having a large suite of well documented test vectors, including both positive and negative examples, raises the bar for the entire ecosystem. Go and OpenSSL are mentioned, but any other environment implementing X.509 now has another very well developed test suite that can be plugged in directly.

While I'm a huge fan of formal methods for developing secure code, IMHO well developed suites such as x509-limbo[1] with common, good, problematic, and outright sadistically wrong vectors are the way forward for developing robust cross platform protocols. These are the kinds of unit tests a spec should come with.

[1] https://x509-limbo.com