Live data from Hacker News

DigiCert Statement on Trustico Certificate Revocation

digicert.com

41–50 of 76 posts

Re: DigiCert Statement on Trustico Certificate Revocation

#41
post #34

Earlier quoted context omitted.

CAA records help with that now. You can just specify your certificate issuer at the DNS level.

See, that requires trusting that all CAs actually respect the CAA records. AFAIK, CAA records aren't validated by end-user client software during SSL negotiation. I would love to see some technical measure implemented where DV SSL certificate issuance and validation was tied to the TLD registry and the domain's particular registrar. It would eliminate the frankly unnecessary trust we put in all root CAs and their sub…

> See, that requires trusting that all CAs actually respect the CAA records. AFAIK, CAA records aren't validated by end-user client software during SSL negotiation.

I think the CAB rules require respecting CAA records? If a CA gets caught on that, they'll have some amount of hell to pay.

Client software can't go back in time to verify what the CAA records were at the time the certificate was issued. CAA records are not intended as a means to revoke previously issued certificates, only an indication of which CAs are _currently_ allowed to issue new certificates.

That said, I agree with you, but the general consensus doesn't seem to, that we de facto trust registries/registrars as stewards of domain ownership, so we may as well de jure make them CAs, since they already have an account relationship.

Re: DigiCert Statement on Trustico Certificate Revocation

#42
post #34

Earlier quoted context omitted.

CAA records help with that now. You can just specify your certificate issuer at the DNS level.

See, that requires trusting that all CAs actually respect the CAA records. AFAIK, CAA records aren't validated by end-user client software during SSL negotiation. I would love to see some technical measure implemented where DV SSL certificate issuance and validation was tied to the TLD registry and the domain's particular registrar. It would eliminate the frankly unnecessary trust we put in all root CAs and their sub…

"They should have a public key upload button next to your domain name in your registrars domain name control panel..."

What about putting the public key in a subdomain.

DNSCurve uses this approach to encrypt DNS packets.

If an authoritative nameserver for a domain can manage encryption of DNS packets without SSL/TLS, x509 and a CA system, is there any reason why an httpd could not do the same?

Management is handled by a "forwarder" daemon that is placed between the nameserver or httpd and the internet.

IMO, much less complex than SSL/TLS, x509 and commercial CAs and control over encryption does not require third parties.

Re: DigiCert Statement on Trustico Certificate Revocation

#43
post #41
post #34

Earlier quoted context omitted.

See, that requires trusting that all CAs actually respect the CAA records. AFAIK, CAA records aren't validated by end-user client software during SSL negotiation. I would love to see some technical measure implemented where DV SSL certificate issuance and validation was tied to the TLD registry and the domain's particular registrar. It would eliminate the frankly unnecessary trust we put in all root CAs and their sub…

> See, that requires trusting that all CAs actually respect the CAA records. AFAIK, CAA records aren't validated by end-user client software during SSL negotiation. I think the CAB rules require respecting CAA records? If a CA gets caught on that, they'll have some amount of hell to pay. Client software can't go back in time to verify what the CAA records were at the time the certificate was issued. CAA records are n…

I found your last paragraph especially well phrased!

You're also on point regarding the CAA records. But to me the current system still feels too reactionary. I'd love to see a system where we need to put less trust in all third parties playing by the rules pinkie-promise. Diginotar, StartSSL and Symantec are all examples of CAs gone wild, and I think we've just seen the tip of the iceberg yet.

Re: DigiCert Statement on Trustico Certificate Revocation

#44

The situation is unfolding in this Mozilla security policy mailing list thread: https://groups.google.com/forum/m/#!topic/mozilla.dev.securi...

From that thread, as a snarky aside: "I know from dealing with Let's Encrypt users that people can get some ideas about what's going on with the Web PKI that bear no resemblance to reality, and although we have no formal duty to teach them better, there's no benefit to the world from pretending they're right."

oh snap, as they say

Re: DigiCert Statement on Trustico Certificate Revocation

#45
post #28

The situation is unfolding in this Mozilla security policy mailing list thread: https://groups.google.com/forum/m/#!topic/mozilla.dev.securi...

I hope it's not overly pedantic to point out that what you linked to is not a CAB forum thread. That's a thread on the Mozilla security policy list, which many root programs and CAs make use of for disclosure and discussion. CAB forum has its own lists elsewhere. A relevant difference is that CAB forum discusses creating and modifying policy but is not involved in enforcement. The root programs typically deal with en…

To elaborate slightly::

The CA/B is a standing meeting between two groups with very different objectives that have an ongoing need to reach some sort of agreement: the Certificate Authorities and the Browsers (in reality more or less the Operating System vendors except Mozilla represents the Free Unixes). This meeting must not appear to be a cartel because cartels are illegal, so it mustn't discuss prices or agree what products should or should not be marketed.

m.d.s.policy is de facto the only public oversight for the entire Web PKI. Mozilla as a Browser vendor (and as hinted above, on behalf of all the Free Unixes) gets to insist upon Rules, not only enforcing rules agreed at CAB, but also making its own rules on top for Certificate Authorities in its Trust Store. As a Charity one of its rules is that it insists on doing almost everything in Public using m.d.s.policy, there is no other obligation on a Certificate Authority to engage with the public at all, but Mozilla's rules force them to tell Mozilla important things via this public group and to answer questions impertinent members of the public (like me) ask them on m.d.s.policy.

Mozilla (and other Browser vendors) is entirely free to insist upon whatever rules they want. The CA/B does not bind them, like the UN it is a forum to meet, and to come to agreements, but it cannot force you to agree to anything you don't want. Two recent illustrative examples:

The CA/B took ages to reform the Domain Validation methods, terribly weak methods had been popular for years, with all sorts of stupid design flaws, and after it did finally vote on a reformed list of methods, CA members claimed a bunch of patents needed to be licensed stalling things for months extra. Mozilla cut through the bullshit and said essentially "See that list of ten methods you voted on that's stuck in Lawyer hell? Too bad, our policy now requires you obey the list which we're naming the Ten Blessed Methods"

Google wanted to reduce the maximum lifetime of new certificates. It takes ages to get CAs to introduce a new rule, and then years while the old certificates made under the old rule expire, too long for Google. So they made an ultimatum, fix it or we'll just tell Chrome to reject certificates after 90 days, and that's the new maximum certificate lifetime. The CA/B eventually voted through a compromise 825 days (which goes into effect tomorrow, 1 March 2018) instead of the previous 39 month limit.

Re: DigiCert Statement on Trustico Certificate Revocation

#46
post #36
post #35

Earlier quoted context omitted.

> I would love to see some technical measure implemented where DV SSL certificate issuance and validation was tied to the TLD registry and the domain's particular registrar Tying PKI to DNS veers pretty close to DANE, and I imagine most of the criticism against DANE would remain valid.

Maybe, but today's DV PKI is already trusting DNS 100%, since certificates are issued based on using DNS responses to validate the certificate request. If you don't trust the governing body of a specific ccTLD, for example, you are already worse off today - a hostile ccTLD DNS operator could very well arrange to fake DNS responses for the duration of a certificate request? Maybe it's not so bad to make it more obviou…

Even non DV PKI uses a lot of trust of the DNS. Where I work, I got our first non-DV certificate issued, and while the CA verified our organization exists (and made our certs show the city listed in our corporation filing instead of the city I wanted to show), the only reason they issued certificates to me is because I did essentially Domain Validation for the domain.

Re: DigiCert Statement on Trustico Certificate Revocation

#47
Trustico now posted a statement on their site[1]. My favourite part is this:

> Trustico® followed the requests of DigiCert by initially recovering Private Keys from cold storage and subsequently e-mailing the associated order number and Private Keys to DigiCert in a ZIP file. The file did not contain any other type of data.

[1]: https://www.trustico.com/news/2018/symantec-revocation/certi...

Re: DigiCert Statement on Trustico Certificate Revocation

#48
post #46
post #36

Earlier quoted context omitted.

Maybe, but today's DV PKI is already trusting DNS 100%, since certificates are issued based on using DNS responses to validate the certificate request. If you don't trust the governing body of a specific ccTLD, for example, you are already worse off today - a hostile ccTLD DNS operator could very well arrange to fake DNS responses for the duration of a certificate request? Maybe it's not so bad to make it more obviou…

Even non DV PKI uses a lot of trust of the DNS. Where I work, I got our first non-DV certificate issued, and while the CA verified our organization exists (and made our certs show the city listed in our corporation filing instead of the city I wanted to show), the only reason they issued certificates to me is because I did essentially Domain Validation for the domain.

Yep, it's a race to the bottom for CAs to perform the absolute minimum work necessary, because otherwise competitors come in and make things easier for customers. Paying a premium for the services of a stricter CA currently has no benefits, since end-users have no way to evaluate whether a certificate is legitimate vs sloppily or maliciously issued by a different CA.

Funny thing about ccTLDs are that end-users might actually have some sort of opinion one way or the other about their trustworthyness, foreign or not. At least a tld is somewhat more visible and relatable in URLs compared to unfamiliar CA company names.

Re: DigiCert Statement on Trustico Certificate Revocation

#49
post #47

Trustico now posted a statement on their site[1]. My favourite part is this: > Trustico® followed the requests of DigiCert by initially recovering Private Keys from cold storage and subsequently e-mailing the associated order number and Private Keys to DigiCert in a ZIP file. The file did not contain any other type of data. [1]: https://www.trustico.com/news/2018/symantec-revocation/certi...

What a bizarre defense. Do they think this makes them look...better?

The core issue is 1) they had the keys at all 2) they decided to compromise them by emailing them DigiCert

Saying "hey, we did nothing wrong, all we did is email the keys we had to DigiCert" just isn't a very compelling defense to claims they had the keys and emailed them to DigiCert. More like a "total admission of guilt" than a defense, really.

Re: DigiCert Statement on Trustico Certificate Revocation

#50
Nobody who has depth in the business would create keypairs online if they could avoid it. So I ask myself if key escrow requirements "back then" permitted this kind of engagement with an agent, on behalf of government or other constrained PKI contexts where escrow was a requirement.

If its just "for your convenience" I would have walked off this keypair years ago.

Private key generated for me one line and held in your keystore? No thank you.

Post reply on HN