[HN Gopher] We build X.509 chains so you don't have to
___________________________________________________________________
We build X.509 chains so you don't have to
Author : ingve
Score : 161 points
Date : 2024-01-25 14:20 UTC (8 hours ago)
(HTM) web link (blog.trailofbits.com)
(TXT) w3m dump (blog.trailofbits.com)
| caeruleus wrote:
| 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
| reaperhulk wrote:
| 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.
| caeruleus wrote:
| Looking forward! Thanks for maintaining such an awesome
| library btw, most of my internal PKI (X.509 and OpenSSH) is
| managed with it. It's a bliss to work with, even more so
| compared to other crypto libs. :)
| EGreg wrote:
| Do we have this in PHP? Javascript ?
| tob_scott_a wrote:
| I think getting it into cURL would be more impactful, since
| that's already tapped into by many OSS projects.
| hlieberman wrote:
| I'm curious -- what was the inputs to the decision to redo the
| logic from scratch, rather than wrap something like the `webpki`
| crate?
| woodruffw wrote:
| This is a great question! The answer is twofold:
|
| 1. Compatibility: PyCA Cryptography has strict compatibility
| requirements, including being able to build with older versions
| of Rust that crates like webpki and rustls-webpki may not be
| interested in supporting.
|
| 2. Generality: PyCA Cryptography is a general purpose
| cryptographic toolbox, and the plan for X.509 validation is not
| _intrinsically_ linked to just the Web PKI profiles. In the
| future, they may wish to make their APIs more flexible than a
| strictly CABF validator would require, meaning that they would
| either need to carry patches against `webpki` or get such
| flexibility upstreamed (to the detriment of the crate 's single
| purpose).
|
| (I am not a maintainer of Cryptography; this is my
| understanding of the reasons as one of the implementors of this
| feature.)
| ivanr wrote:
| Genuine question: does the `webpki` crate provide a good path
| building implementation?
| tob_scott_a wrote:
| > Carcinize existing C and C++ X.509 users.
|
| This could be game-changing for a lot of open source software.
|
| I spent years avoiding X.509 (and ASN.1, for that matter) in my
| designs because every time someone I trust poked it, a remotely
| exploitable bug fell out. Most often, it was a Denial of Service
| issue rather than Remote Code Execution. Moving to Rust would
| demonstrably improve the security of the entire Internet.
|
| You might be tempted to ask, "What about BouncyCastle?" (or
| similar queries).
|
| Sure, you're not overwriting the EIP in most Java X.509 bugs, but
| check the release notes for X.509 and ASN.1 mentions:
| https://www.bouncycastle.org/releasenotes.html
|
| When I worked for Amazon, we disclosed a few X.509-related
| vulnerabilities to projects that we _almost found by accident_.
| otabdeveloper4 wrote:
| > Moving to Rust would ...
|
| ... do absolutely nothing to fix denial of service attacks.
| tob_scott_a wrote:
| By itself? No.
|
| The other details covered in the blog post, however, would
| absolutely do something to fix denial of service attacks.
|
| To wit: x509-limbo
| woodruffw wrote:
| I don't think this is true. Rust _cannot_ prevent all
| possible forms of denial of service, but there are plenty of
| underlying DoS causes that Rust either outright eliminates
| (such as memory corruption without further control) or
| mitigates through stronger types.
|
| A recent example of this is CVE-2024-0567 in GnuTLS: an
| invariant that otherwise would likely have been noticed at
| the type level is instead checked with an assert, leading to
| a remotely trigger-able DoS.
| saurik wrote:
| Nor the other myriad of logic and parsing bugs that led to
| incorrect behavior (more than just denial of service) in the
| Java library that was somehow not as good as Rust :/.
| bagels wrote:
| Exploiting a memory safety crash, leading to a downed
| service, is the first class of DOS that Rust can help with.
| blibble wrote:
| how would rust fix most of those issues?
|
| they're logic bugs
| tob_scott_a wrote:
| woodruffw already wrote an excellent comment for this
| question: https://news.ycombinator.com/item?id=39131723
|
| Rust isn't _just_ memory-safety. The type system also coaxes
| developers towards eliminating some types of logic bugs.
|
| Not all, granted, but it does move the needle.
| blibble wrote:
| I think that attitude vastly underestimates the complexity
| of a typical TLS implementation
|
| (and I say this as someone who grew up on SML)
| woodruffw wrote:
| This reasoning doesn't make sense. If TLS is
| astonishingly complex, which it is, then we _absolutely_
| want the strongest type system that can simultaneously
| represent its complexity _and_ afford developer
| ergonomics. TLS 's complexity is a good reason for types
| that reflect invariants, not a good reason to give up.
| blibble wrote:
| This reasoning doesn't make sense.
|
| I didn't say it didn't help at all, I said I wouldn't
| expect it to make a significant improvement over Java
|
| (and it's hardly the strongest type system with
| "developer ergonomics")
| k8svet wrote:
| I'm _not even that good at writing Rust_ and even I
| recognize that countless libs I 'm using are written in a
| way, with Rust types, that prevent serious mis-use. In
| ways that would be infeasible and unergonomic in other
| languages, or require internal library invariant
| assertions that are prone to bugs.
|
| Sometimes the errors wind up being nasty, but I've also
| gotten better at trusting that the compiler is giving me
| helpful info, even if it's a huge message. And usually
| those errors indicate some library invariant _that I 've
| missed_ that the type system is enforcing.
| blibble wrote:
| yes, hence my comment on SML
|
| while it's nice that the rest of the world is slowly
| waking up to type systems functional programmers have
| been bleating on about for the past four decades
|
| ... having read through the first couple of pages of bc
| vulns: even a much stronger type system than rust
| provides wouldn't appear to help very much in this
| specific example
|
| however if someone wants to rewrite OpenSSL in Rust that
| would be a massive massive improvement
| nindalf wrote:
| > however if someone wants to rewrite OpenSSL in Rust
|
| You mean rustls?
| tob_scott_a wrote:
| > I think that attitude vastly underestimates the
| complexity of a typical TLS implementation
|
| If you ever get the impression that I'm underestimating
| the complexity of a typical TLS implementation, I promise
| you that I'm not. I speak to improvements, not panaceas.
|
| Until the end of last year, I was one of the security
| engineers that the s2n team at AWS consulted on potential
| security issues. You will never hear me say anything will
| magically fix all our problems. Especially with TLS.
|
| However, Rust does bring a lot to the table, so I feel
| I'm allowed to be excited about not reviewing another
| X.509 library written in C.
| woodruffw wrote:
| The "classic" example of this is enums as sum types, rather
| than a thin wrapper over an integral type: Rust makes it
| possible to construct in invalid enum variant, whereas plenty
| of C logic bugs stem from taking untrusted user input and
| converting it into an enum variant.
|
| My understanding is that Java doesn't allow this directly,
| but has adjacent historical deficiencies (e.g., not allowing
| exhaustive enumeration handling until recently).
| e12e wrote:
| Fantastic!
|
| Curious about revocations though - the post doesn't mention it?
| woodruffw wrote:
| 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.)
| colechristensen wrote:
| Not planned for MVP or not planned ever?
| woodruffw wrote:
| 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.
| ivanr wrote:
| Do you think that it's possible to implement a good path
| building algorithm without support for revocation? For
| example, without revocation checking you may select a chain
| with a revoked certificate in it, only to discover that
| later. Then what? :) On the other hand, if you check the
| revocation status as part of the process, you can pivot to
| another certificate.
| woodruffw wrote:
| I think so -- I would consider crypto/x509's implementation
| good, and they similarly don't support revocation. More
| bluntly: it's not clear that revocation really works at all
| in the Web PKI; I've heard it described more as
| "homeopathic" than an actual security mechanism.
|
| What makes a path building implementation good is (IMO) its
| adherence to the rules Ryan Sleevi enumerates[1]: as long
| as you conceptualize the path building process as a dynamic
| search problem rather than a static one with a "single"
| result, any implementation you build will probably have the
| right "primitives" for future constraints (like
| revocations).
|
| [1]: https://medium.com/@sleevi_/path-building-vs-path-
| verifying-...
| mcpherrinm wrote:
| I recently gave a talk on this topic (sorry, haven't
| written as a blog post yet)
| https://www.youtube.com/watch?v=4TbtL73ibh0
|
| I do believe revocation in the webpki is important to
| implement, but it's not great today.
|
| There are two promising paths forward, which are
| complementary: The simple option is short-lived
| certificates (7 days), which essentially don't require
| revocation as that's the timeline existing revocation
| technology can revoke on, but that has some adoption
| hurdles to overcome in the future.
|
| The other solution is what Mozilla is doing with CRLite:
| https://blog.mozilla.org/security/2020/01/09/crlite-
| part-1-a...
|
| They are collecting all CRLs from all public web CAs and
| producing a small, compressed representation of all
| revoked certificates. That can be pushed to clients, so
| there's no need for any network traffic (like OCSP checks
| or CRL downloads) to the wide variety of CAs in the
| ecosystem.
|
| These "CRL Compact and Push" solutions benefit from
| shorter-lived certificates (eg, 90 days like Let's
| Encrypt does right now) because the set of revoked certs
| is smaller as they roll off once they expire.
|
| I suspect platform verifiers like on Windows and Mac will
| hopefully ship something like this in the future, though
| they already have CRL and OCSP fetching and caching.
|
| Non-platform verifiers like this one are really the
| hardest part to solve revocation. I would suggest
| supporting CRL checks, but that requires having disk
| space and caching infrastructure, which is hard for a
| library to know how to do universally. I think the answer
| is that we need to have most of our software outsource to
| a platform verifier, or at least some sort of system-wide
| revocation information cache or daemon. Maybe this means
| a new systemd component on Linux :)
| ivanr wrote:
| There is also the third option, via must-staple, where
| OCSP responses are attached to the TLS handshake. This
| resolves the privacy issue [because otherwise clients
| have to talk directly to CAs and reveal what sites
| they're visiting].
|
| All (big) browsers have mechanisms functionally similar
| to CRLite. Apple has "valid" (not sure if that's the
| official name) and Google has CRLSets.
| mcpherrinm wrote:
| Google's CRLSets don't cover nearly the full set of
| revocations (AFAIK).
|
| I don't know the details of how "valid" works, but as the
| Apple root program has recently required CAs to publish
| full CRLs, I assume they're planning something similar.
|
| I mostly cite CRLite as it's well-documented.
|
| I don't think OCSP must-staple is deployable. It requires
| code changes to effectively every webserver in the world,
| and that doesn't seem to be happening. I think it is
| stuck in a spiral of non-adoption, where there's no
| incentive for anyone to make progress. I believe short-
| lived certs (7 days) are more deployable in the ecosystem
| today than ocsp must-staple, with similar security
| properties. Certificate automation is already desirable,
| and it's not as big a leap once flows are automated.
|
| This isn't going to happen overnight at least. Years,
| probably many. But it's happening.
| tptacek wrote:
| "The spiral of non-adoption" is an interesting blog post
| someone should write. I bet there are a couple more
| examples besides the obvious one.
| ivanr wrote:
| I think you're right about CRLSets. IMO, Mozilla really
| wanted to solve the problem, whereas Chrome just wanted
| to have a solution that they could use for emergency
| revocation of certificates of high-profile sites (and
| intermediates/roots). Small-time sites won't be in
| CRLSets, although if you know the right people and make
| enough noise you may be added to their list. As for
| Apple, no one knows what's going on because they don't
| like to share :)
|
| OCSP must-staple doesn't require code changes. It's a
| "flag" you set on a certificate. Maybe what you mean is
| that OCSP stapling is not enabled by default on many
| installations, and that's true. IIS got it right, and
| Caddy (obviously, the only platform that got everything
| right).
|
| Again, we're in this place only because browsers don't
| care about revocation. If they pushed for it, things
| would fall into place very quickly. But they're going in
| the opposite direction.
|
| Short-lived certificates are great, assuming you're fine
| with a 3.5 day (on average) window of opportunity for
| exploitation. There's a potentially major problem with
| clock skew, as many clients have inaccurate clocks.
| Personally, I recommend that certificates are obtained at
| least a week before they're deployed; a month would be
| better. Then rotated a month before they expire. That's
| how you minimise the problems due to clock skew.
| e12e wrote:
| As far as I can figure out, most ocsp staples are valid
| for 7 days, so short lived certificates would be
| equivalent, but simpler?
| ivanr wrote:
| Indeed, you're right. Must-staple and short-lived
| certificates have the same problem with clock skew.
| ivanr wrote:
| Exactly. Because you currently don't check for
| revocation, you may end up selecting a path that's a dead
| end and you won't be able to recover. However, if your
| implementation has pluggable [dynamic] constraints, once
| you add support for revocation, it will work optimally.
|
| You can run into the same problem with any other
| constraint, for example hash function deprecation, CA
| block, and so on.
|
| Aside: Revocation works just fine, it's just that
| browsers decided not to implement it.
| woodruffw wrote:
| I don't think pluggability is the important thing here: a
| good path building implementation doesn't need to be
| pluggable to handle dynamic constraints correctly. More
| precisely: a "dead path" is only a problem if it somehow
| excludes otherwise present valid paths, which is not an
| issue if you chose to not support CRLs at all (you might
| _accept_ revoked paths, but you certainly won 't exclude
| non-revoked ones).
|
| One of the problems with X.509 PKIs is that you can make
| them fractally complex; every implementation ends up
| setting its own "I give up, doing this is too painful"
| point. CRLs are a common "give up" point, and that
| probably won't change until CRLite or similar changes
| things here.
|
| (AIA chasing and OCSP lookups are also similar pain
| points.)
| ivanr wrote:
| Well, yes. If you choose to ignore revocation entirely,
| you will never have a dead path because of it. That will
| happen only if you path-build, then check revocation as
| two steps. (IIRC, Windows used to do this, or is still
| doing it.)
|
| IMO, a good path building implementation has to support
| revocation, but that's for another conversation :)
| kachnuv_ocasek wrote:
| That's a whole another can of worms.
| ak217 wrote:
| 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.
| teddyh wrote:
| Note: If your application does not absolutely need it, there are
| alternatives to X.509 certificates in TLS, like raw public keys
| (RFC 7250).
| zokier wrote:
| Added to OpenSSL last November:
| https://www.openssl.org/blog/blog/2023/11/23/OpenSSL32/index...
| thadt wrote:
| 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
| ivanr wrote:
| Agreed. I don't see NIST's test suites [1] on the list, though.
| Maybe they're embedded somewhere and I've missed it?
|
| [1] https://csrc.nist.gov/projects/pki-testing
|
| EDIT If the authors are reading, are any of the test cases
| taken from Chrome's codebase?
| woodruffw wrote:
| (I'm one of the authors).
|
| I looked at NIST's PKITS while building the test suite. We
| ultimately decided to punt on it for the first round of
| tests, primarily because it fell slightly out of scope of our
| MVP on Python Cryptography (being strictly a RFC 3280 suite).
| We instead chose to integrate the BetterTLS suite[1]
| (warning: very large page) for the MVP.
|
| With that being said: x509-limbo is open source, and I would
| be _overjoyed_ if someone added a new `nist::pkits` or
| similar namespace for these :-). I can 't promise that it's
| an immediate priority for us to add ourselves, however.
|
| > are any of the test cases taken from Chrome's codebase?
|
| Nope. That would also be a valuable thing to have here.
|
| [1]: https://x509-limbo.com/testcases/bettertls/
| ivanr wrote:
| For reference:
| https://github.com/chromium/chromium/tree/main/net/data/ssl
|
| It's been a long time since I looked at them, not sure
| what's in there exactly any more. Ask Ryan perhaps :)
| woodruffw wrote:
| Thank you! I'll add that to
| https://github.com/C2SP/x509-limbo/issues/174.
| ivanr wrote:
| You may also want to look at
| https://github.com/digicert/pkilint
|
| There are other similar tools (cablint, x509lint, zlint),
| but there's been a lot of good talk about pkilint
| recently.
| baby wrote:
| Check Frankencerts as well if you're interested in that:
| https://github.com/sumanj/frankencert
| thriftwy wrote:
| Meanwhile, JVM ecosystem looks down on the choice between OpenSSL
| and pure-Rust Python chain, because it have been using a managed,
| pure-Java X.509 chain for 25 years now.
|
| I believe it also had various implementations under common API.
| notaluddite wrote:
| Given the ambiguities and degrees of freedom different TLS
| clients can exercise during chain validation (mentioned in this
| post), we wrote a paper proposing that validation policies should
| be expressed as interchangeable Prolog programs:
| https://dl.acm.org/doi/pdf/10.1145/3548606.3560594
| flumpcakes wrote:
| Aren't revocations a pretty important part of certificates,
| considering the whole point of this is security? I don't
| understand the rationale for skipping.
| woodruffw wrote:
| Revocations are a great idea. In practice, they're both
| operationally complicated and an unreliable source of truth
| about certificate validity. In practice, a _lot_ of
| implementations (including Go 's) simply ignore them.
|
| 'mcpherrim posted a comment below[1] with some additional
| information, including changes to the Web PKI and CRL
| distribution techniques that may eventually make them more
| useful.
|
| [1]: https://news.ycombinator.com/item?id=39132430
| ivanr wrote:
| Any chance you could expand on "In practice, they're both
| operationally complicated and an unreliable source of truth
| about certificate validity."?
| woodruffw wrote:
| I'm thinking about CRL update windows: a lot of CAs run
| weekly updates, meaning that CRL changes don't propagate to
| end users for up to a week at a time. That's well into
| "security theater" territory for me, given that a
| compromised CA or EE only needs to fool me for a matter of
| seconds, once.
| ivanr wrote:
| Sure, but then you can just use OCSP. If you care about
| privacy very much, support only stapled OCSP.
|
| CRL is better suited for "high-volume" exchanges, for
| example for a CA to publish all their revocations [so
| that a system such as CRLite can be built].
| woodruffw wrote:
| The comment I referenced before contains a talk by
| 'mcpherrim as well that explains OCSP stapling's own
| deficiencies.
|
| I think we all want a good solution here. But none of the
| currently widely deployed ones are that.
| ivanr wrote:
| I am sorry, I can't watch someone else's talk to
| understand what you mean. If you're willing to engage in
| a conversation, could you say here what you think the
| problems with OCSP are? (If you're not, just ignore me.)
|
| As I see it, the main problem is that browsers don't want
| to do OCSP any more. Sure, we have a problem with how
| stapling is implemented in _some_ popular platforms (but
| not Caddy--hi Matt), but today maybe even those are
| fixed. The main problem IMO is that browsers won't
| support must-staple.
|
| In the interest of full transparency, I have a pet peeve
| about people saying revocation doesn't work. I appreciate
| that that's the current reality, but--again--only because
| browsers choose not to implement it. Things would change
| overnight if Chrome (obviously) changed their stance.
| woodruffw wrote:
| Sure! I'm happy to discuss, my reason for referencing the
| video is because I think 'mcpherrim explains this stuff
| better than I do :-).
|
| My understanding is that the primary concerns with OCSP
| (meaning non-stapled OCSP) are that it (1) leaks end user
| intent to CAs, such as sites being visited, and (2) in
| its original form with no transport security, it is no
| stronger than the adversary that it needs to protect
| TLS/the Web PKI against (i.e., any network adversary can
| block the OCSP request and everything will fail open).
|
| OCSP stapling avoids both of those concerns, but requires
| web server and other stack changes that are not on the
| "enforcement" path in the way that CAs and other "direct"
| parts of the PKI are. The talk infers that this is why
| OCSP adoption has been so sluggish (which I didn't
| realize was the case before).
|
| FWIW, I'm sorry if I came across as dogmatic here --
| revocation is conceptually important, and I think it'd be
| great if we ended up in a Web PKI where revocation was
| more effective. But I can also see _why_ browsers have
| fumbled and /or dragged their feet on the CRLs and OCSP
| for so long.
| ivanr wrote:
| Yes, agreed on the primary problem with "classic" OCSP.
| OCSP stapling and must-staple (for the benefit of other
| readers: a flag that's set on a certificate to indicate
| that it's only valid with an attached--stapled--fresh
| OCSP response) solves that.
|
| When must-staple initially came out, it came to light
| that web servers viewed OCSP stapling as a performance
| optimisation. When viewed from this perspective, it's not
| necessary to staple 100% correctly; if you don't, clients
| just go to the CA directly. Unfortunately, this breaks
| apart with must-staple and clients who refuse to talk to
| Cash for privacy reasons.
|
| Browsers refused to enforce must-staple because that
| would mean broken web sites and they didn't want to be
| blamed for it. As a result, web servers didn't have an
| incentive to fix their broken OCSP stapling
| implementations.
|
| There's also some politics involved. Browsers don't
| actually want CAs to be able to revoke certificates for
| reasons other than security. Think one government
| pressuring a CA in their country to revoke a certificate
| of an entity outside the country, for political reasons.
|
| (EDIT I don't really support this argument. Any
| organisation that cares about their availability should
| always have two active certificates from difference CAs.
| There's a variety of CA jurisdictions to choose from as
| well.)
|
| I don't like these long discussion chains as much as the
| next guy, but there's a lot of nuance and history when it
| comes to certificate revocation, and I sometimes take the
| opportunity to gently question people's beliefs. The line
| "revocation doesn't work" is very often repeated and
| technically it's not wrong, but I think it's important
| for people to understand how we got here.
| ak217 wrote:
| [Not OP]
|
| CRL/OCSP (which are the only revocation mechanisms close to
| being generally used standards today) require either online
| verification (which is unsuitable or unsafe for many
| applications) or CRL distribution with CA trust root
| bundles, which is always in danger of being stale.
|
| You can read more in https://en.wikipedia.org/wiki/Certific
| ate_revocation_list#Pr..., https://en.wikipedia.org/wiki/On
| line_Certificate_Status_Prot...
|
| Revocation in PKI is a hard problem that exposes a
| fundamental tradeoff between time to revoke and
| privacy/offline capability.
| ivanr wrote:
| Not quite. OCSP responses can be stapled to TLS
| handshakes to provide fresh revocation information.
| Online is needed if you want 100% fresh information, of
| course.
| ak217 wrote:
| PKI uses are not limited to TLS, and TLS uses are not
| limited to those where revocation information is readily
| accessible (due to
| proxying/distribution/compartmentalization/federation
| constraints).
|
| There is a variety of signature standards and protocols
| out there that rely on PKI to manage trust, and whose
| users are not at all keen on calling an untrusted URL to
| check an intermediate cert.
| ivanr wrote:
| That's a fair point [PKI without TLS], but I'd argue that
| 99.9% of situations will be with TLS. Thus supporting
| revocation can provide value for those.
|
| Out of curiosity, what without-TLS use cases do you have
| in mind?
| ak217 wrote:
| Most SSO runs on SAML, which uses XML Signature, which
| uses PKI certificate chains without TLS.
|
| Even if you think all SSO will migrate to OIDC, the EU
| has enacted laws around electronic signatures that
| basically enshrine the use of XML Signature (with all its
| problems) for the foreseeable future. A lot of countries
| beyond the EU (many LatAm countries, for example) have
| followed suit.
|
| There are other signature protocols that use certificate
| chains as well, and devices and networks that should not
| be making network calls when validating such signatures.
|
| And as I mentioned, TLS uses are not limited to those
| where revocation information is readily accessible.
| baby wrote:
| can OpenSSL use this as well? This would be amazing
| im3w1l wrote:
| I'm sure it was even worse before, but I'm not entirely happy
| with the look of that.
|
| * I shouldn't have to care where the certificates are stored.
| Just load the os default ones without asking me.
|
| * I shouldn't have to know what a pem is, and I shouldn't have to
| open() one.
|
| * I don't want a PolicyBuilder. Just give me the normal policy.
|
| * I shouldn't have to construct some verifier object specific to
| a given dns. I don't want to verify a billion certificates for
| one domain, just one.
|
| * I shouldn't have to know what an untrusted intermediary is.
|
| Here's what I think it should look like verifier
| = Verifier() # constructs a verifier with sensible defaults,
| overrides are possible though verifier.verify(chain,
| "cryptography.io")
___________________________________________________________________
(page generated 2024-01-25 23:00 UTC)