Launching in 2015: A Certificate Authority to Encrypt the Entire Web

Looking at the spec [0] I'm concerned about the section on 'Recovery Tokens'.

"A recovery token is a fallback authentication mechanism. In the event that a client loses all other state, including authorized key pairs and key pairs bound to certificates, the client can use the recovery token to prove that it was previously authorized for the identifier in question.

This mechanism is necessary because once an ACME server has issued an Authorization Key for a given identifier, that identifier enters a higher-security state, at least with respect the ACME server. That state exists to protect against attacks such as DNS hijacking and router compromise which tend to inherently defeat all forms of Domain Validation. So once a domain has begun using ACME, new DV-only authorization will not be performed without proof of continuity via possession of an Authorized Private Key or potentially a Subject Private Key for that domain."

Does that mean, if for instance, someone used an ACME server to issue a certificate for that domain in the past, but then the domain registration expired, and someone else legitimately bought the domain later, they would be unable to use that ACME server for issuing an SSL certificate?

[0] https://github.com/letsencrypt/acme-spec/blob/master/draft-b...

They do. You just don't have their root installed so it gives an error. You can install their root here http://www.cacert.org/index.php?id=3

If you can corrupt both the authority signing the certificate and the authority signing the Certificate Transparency append-only log, you can successfully MITM a connection.

However, if the client is ever subsequently on a non-MITMed connection, it can detect the certificate disappearing from the append-only log - and the signed certificate and signed append-only log constitute irrefutable evidence that the two authorities were compromised.

As all legitimately issued certificates are in the Certificate Transparency logs, browser vendors can grandfather them in so they keep working after they drop the CA certificate from the trust root. This kills the CA.

This would give CAs the power to refuse requests from the NSA, because their hands are tied - no matter what coercion the NSA threatens, the CA can't issue an MITM certificate without getting shut down.

Obviously it remains to be seen whether this will work in practice.

The extent to which this is true depends on browser behavior. With some browser behavior self-signed certs could make some users safer against some threats; with other browser behavior they could make some users more vulnerable to some threats.

An opportunistic privacy solution with no legacy installed base to worry about is tcpcrypt:

http://www.tcpcrypt.org/

So if anyone wants to make progress on opportunistic unauthenticated encryption without having to fight about UA behaviors, tcpcrypt may be more fertile ground than self-signed certificates.

> Why this wasn't done a long time ago is beyond me.

While probably not officially scriptable, free certificates have been available since a long time ago: https://www.startssl.com/?app=1

Also, no free wildcard certs. Which I really want.

> What happens if a CA is compromised?

Looking at past compromises, if they have been very irresponsible they are delisted from the browsers' list of trusted roots (see diginotar). If they have not been extremely irresponsible, then they seem to be able to continue to function (see Comodo).

https://en.wikipedia.org/wiki/DigiNotar#Refusal_to_publish_r... https://blogs.comodo.com/uncategorized/the-recent-ra-comprom...