HackerTrans
TopNewTrendsCommentsPastAskShowJobs

sleevi

no profile record

comments

sleevi
·السنة الماضية·discuss
All the time. Many CA distrust events involved some degree of “amateurs” reporting issues. While I hesitate to call commenters like agwa an amateur, it certainly was not professionally sponsored work by root programs or CAs. This is a key thing that Certificate Transparency enables: amateurs, academics, and the public at large to report CA issues.

At the same time, it sounds like the issues you describe aren’t CA/issuance issues, but rather, simple misconfigurations. Those aren’t incidents for the ecosystem, although definitely can be disruptive to the site, but I also wouldn’t expect them to call trust or identity into disrepute. That’d be like arguing my drivers license is invalid if I handed you my passport; giving you the wrong doc doesn’t invalidate the claims of either, just doesn’t address your need.
sleevi
·قبل 3 سنوات·discuss
Because it wasn’t actually a server misconfiguration, nor was it, as others have speculated, about Postel’s Law.

The way X.509 was designed - to the very first version - was the notion that you have your set of CAs you trust, I have my set, and they’re different. Instead of using The Directory to resolve the path from your cert to someone I trust, PKIX (RFC 2459-et-al) defined AIA.

So the intent here was that there’s no “one right chain to rule them all”: there’s _your_ chain to your root, _my_ chain to my root, all for the same cert, using cross-certificates.

Browsers adopted X.509 before PKIX existed, and they assumed just enough of the model to get things to work. The standards were developed after, and the major vendors didn’t all update their code to match the standards. Microsoft, Sun, and many government focused customers did (and used the NIST PKITS test to prove it), Netscape/later Mozilla and OpenSSL did not: they kept their existing “works for me” implementations.

https://medium.com/@sleevi_/path-building-vs-path-verifying-... Discusses this a bit more. In modern times, the TLS RFCs better reflect that there’s no “one right chain to rule them all”. Even if you or I aren’t running our own roots that we use to cross-sign CAs we trust, we still have different browsers/trust stores taking different paths, and even in the same browser, different versions of the trust store necessitating different intermediates.

TLS has no way of negotiating what the _client’s_ trust store is in a performant, privacy-preserving way. https://datatracker.ietf.org/doc/draft-kampanakis-tls-scas-l... or https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-t... are explorations of the problem space above, though: how to have the server understand what the client will trust, so it can send the right certificate (… and omit the chain)
sleevi
·قبل 3 سنوات·discuss
Because this is not the “start of drafting” but roughly “final text that is largely a rubber stamp approval.” This is the output of having been through the the trilogue process - where the Parliament would/has shut things down before - and not been shut down.

[1] https://en.m.wikipedia.org/wiki/Formal_trilogue_meeting
sleevi
·قبل 3 سنوات·discuss
> and the recent legislation coming from there seems very inspired by the great firewall.

https://www.europarl.europa.eu/RegData/etudes/STUD/2020/6487...
sleevi
·قبل 3 سنوات·discuss
The EU is currently proposing to mandate the inclusion of roots that have been government approved, and to limit browsers from removing/distrusting them without notice/approval.

https://www.eff.org/deeplinks/2022/12/eidas-20-sets-dangerou...