Live data from Hacker News

Entrust Certificate Distrust

security.googleblog.com

51–60 of 118 posts

Re: Entrust Certificate Distrust

#51
post #48
post #39

Earlier quoted context omitted.

This kind of thing was one of the reasons CT was introduced :D

CT was introduced to detect misissued certificates, but it was never intended to be used as a timestamping system like this. The point of the SCT timestamp was to start the clock on the deadline for the log to publish the certificate, not for use in trust decisions. So when Chrome announced they were using SCT timestamps for trust decisions, my first question[1] was whether anyone was auditing CT logs to detect backd…

Sorry I think my phrasing was not great.

The goal of CT was not to make staged distrust of a CA possible (that's just a happy coincidence). It was to make it possible to detect CAs misissuing certificates, which includes CAs back dating certificates.

Re: Entrust Certificate Distrust

#52
post #15

I’m one of the people who really went in depth with Entrust (Amir on Bugzilla). I’m also an author on https://webpki.substack.com . I will be writing my thoughts on the distrust soon. I can try to answer any questions folks may have. I can also help folks find ways they can also be involved! Root programs can only do so much and need surveillance of the CAs from the community.

I am a layperson so I appreciate the attention on the matter. Regardless of how Entrust is operated, there appears to be significant complexity in CA program that the browsers operate. On the flip side, Let’s Encrypt is basically effortless for me to use, as an end user of an LE secured site and as a developer. Why misallocate all this toil on root CA compliance on the one hand, when LE could redirect that labor towa…

Let's Encrypt is just a player in the same ecosystem. Effectively they're no different from Entrust, GoDaddy, Google Trust Services, Digicert, Sectigo, etc etc.

Let's Encrypt started their operations with _automated_ certificate issuance only. They also do not do OV/EV certificates that are much, much harder to automate without providing any real benefits.

So, LE's mission is to issue certificates under the rules set by CAs and Browsers. (Yes, CAs do participate in setting up rules for CAs.

> Where does the proverbial political strength of Entrust and similar entities come from

Generally supporting non-automated certificate issuance. Effectively, technical debt. A lot of older enterprises have done manual certificate issuance, and they don't feel the pressure/reason to switch.

Re: Entrust Certificate Distrust

#53
> Additionally, should a Chrome user or enterprise explicitly trust any of the above certificates on a platform and version of Chrome relying on the Chrome Root Store (e.g., explicit trust is conveyed through a Group Policy Object on Windows), the SCT-based constraints described above will be overridden and certificates will function as they do today.

This continues to annoy me. Chrome (and other browsers) have detailed trust constraints, e.g. SCTNotAfter, in their own root stores. Why can’t administrators do the same thing?

Re: Entrust Certificate Distrust

#54

It always fascinates me when this happens. Don't the CAs understand that the browser vendors can and will kill their business if they don't comply with the rules? It's not like a fine that can be ignored. How dysfunctional does a company have to be to let this happen?

All you need is one single [cc]?.gov as your client and you are in business forever.

Re: Entrust Certificate Distrust

#57

All the google root security team's due diligence email are just a list of links to firefox's bugzilla who documented and followed up on all the issues. https://groups.google.com/a/ccadb.org/g/public/c/29CRLOPM6OM...

Representatives from the Chrome and Apple root programs participate in the Bugzilla discussions in an official capacity. But yes, there is significant help from the community in uncovering evidence and grilling CAs.

Re: Entrust Certificate Distrust

#58

All the google root security team's due diligence email are just a list of links to firefox's bugzilla who documented and followed up on all the issues. https://groups.google.com/a/ccadb.org/g/public/c/29CRLOPM6OM...

In practice the Web PKI is overseen by the general public, via Mozilla's m.d.s.policy. It makes no sense for the proprietary vendors, including Google, to insist on doing something themselves badly when Mozilla is the obvious host for this work.

The older vendors are even less able to be properly open with their customers (let alone the general public) than Google. At Apple it's probably a firing offence to even confirm obvious decisions - it seemingly took months to get Apple's chosen representative to confirm that Apple's new 398 day rule was an issuance requirement, rather than just something where Apple wouldn't trust longer lived certs in Safari.

Re: Entrust Certificate Distrust

#59

All the google root security team's due diligence email are just a list of links to firefox's bugzilla who documented and followed up on all the issues. https://groups.google.com/a/ccadb.org/g/public/c/29CRLOPM6OM...

In practice the Web PKI is overseen by the general public, via Mozilla's m.d.s.policy. It makes no sense for the proprietary vendors, including Google, to insist on doing something themselves badly when Mozilla is the obvious host for this work. The older vendors are even less able to be properly open with their customers (let alone the general public) than Google. At Apple it's probably a firing offence to even conf…

none of what you list are good excuses for anything. I fail to see the point. Is it that marketing trumps technical know how and it should be ok?

Re: Entrust Certificate Distrust

#60

It always fascinates me when this happens. Don't the CAs understand that the browser vendors can and will kill their business if they don't comply with the rules? It's not like a fine that can be ignored. How dysfunctional does a company have to be to let this happen?

I saw company being killed by failed backup system. One unfortunate hardware failure, bad backups and company service goes offline with no way to recover in timely manner. Big clients require big compensation, company goes bankrupt. One shell script put in crontab could have prevented that, but nobody cared enough. It was not a big company, though. But consequences of one simple overlook were dire.
Post reply on HN