I wouldn't have put it better myself.
I just added a new update on the website.
Saturday, April 12, 09:50 (GMT-3)
OK, so here's my reply to Nikolai:
"Let me address this question.
> Anything about free revocations there?
It doesn't, but that's not relevant.
It's pretty damn clear: You see the evidence,
that alone should be enough for you to take action.
If you take Mozilla's policy by the letter,
one doesn't even have to own a certificate to be able to request its revocation.
All that should be needed is the evidence of compromise.
If I disclosed the private keys for a certificat I don't own,
would you just ignore that information?
Or would you come after the certificate owner demanding payment first?
You're a CA, A CA!!!
You should be worried about the security of the internet above all things.
You should also be worried that you have a bunch of green padlocks around that don't mean what they once did.
You're not worried about that.
So in my opinion you don't deserve the trust of the internet anymore.
So now it's official. They got the evidence that the certificate is compromised yet they refuse to take action. If that's not violation of CA policy I don't know what is.
How dare they give you a free service, and then decide to charge for a revocation which they had said they would charge for (and is meaningless because by default all browsers ignore revocations).
Unfortunately for various historical fuckups, we consider self signed certificates to be more dangerous than cleartext unsecured http. Lots of scary warnings pop up. That is absurd. Starcom is helping fix this by issuing free certificates.
The Mozilla CA policy does not include a provision for obvious trolling and posturing. If Starcom were to be forced to revoke your certificate for free, why would anyone else (on any CA) ever pay for revocation?
> (and is meaningless because by default all browsers ignore revocations)
Strange, because when I revoked my cert at StartSSL yesterday (and payed for it), the browser, Firefox on Ununtu immediately showed it as revoked. With a big bold warning when visiting the page.
> The Mozilla CA policy does not include a provision for obvious trolling and posturing. If Starcom were to be forced to revoke your certificate for free, why would anyone else (on any CA) ever pay for revocation?
This is not your garden variety, "I screwed up my .htaccess file and accidentally leaked my private key to the world" situation. This is a special case, and some special case rules would be really appreciated by this one, at least.
> The Mozilla CA policy does not include a provision for obvious trolling and posturing.
This isn't really trolling, after Heartbleed we should consider all SSL certs used by OpenSSL based servers as compromised. This sites just tries to make the point more obvious by putting such compromised cert in public view.
Have you realized that not only OpenSSL, but any exploitable bug in any software that runs on servers (PHP, Apache, nginx, Linux, etc) should theoretically invalidate any certificate that is stored on those servers?
Any exploitable bug that allows to access private keys should invalidate certificates. There are many security vulnerabilities that don't give access to private keys.
Even if there's no publically-known way of using a particular security vulnerability to get access to private keys, how are we to be sure that somebody (perhaps malicious) didn't find a way and are just keeping it a secret?
If you understand a vulnerability, you can often tell for sure if it can lead to exposure of private keys. For example if a PHP app runs in a separate process with separate user credentials than nginx SSL endpoint, and if file access control flags for certificates are configured correctly, you can tell for sure that php bug alone won't allow for certificates access. This of course assumes that other components work correctly (like Linux access control mechanism), but without such assumptions you wouldn't be able to do anything productive.
I thought this post was simply making clear on an example domain what the policy was, and that because of the heartbleed issue, the author had legitimate concerns about the other certs' security. This one was just posted more obviously to prove the point.
It isn't compromised. You yourself handed out your private key to others who may act on your behalf. Not by mistake, not by Heartbleed, not by some hacking event, but out of your clear will and as part of your policy how to handle the key.
In terms of your business transaction with StartSSL, the private key is still only known to "you".
The private key being not private is the very definition of "compromised" when applied to the CA security architecture. Whether StartSSL has a different definition is completely immaterial to the Mozilla policy.
Now you're right that it's not StartSSL's fault that OpenSSL suffered Heartbleed, but nor is it the various end customers' fault (unless they introduced the bug themselves?). So pinning down the response to this as a simple exercise of assigning blame and responsibility completely misses the point and does nothing toward resolving what is admittedly a very difficult question.
So in your opinion the one who actually buys and gets the certificate from the StartSSL web site must not share it with the system administrator? Or some second-in-command?
IMO, as long as the key is only known to people who the rightful owner explicitly wanted it to possess, it is not compromised.
This is just an extreme case of a troll wanting the whole world to have the key.
It has nothing to do with Heartbleed! Posting your private key in a gist on the web is not the same as being victim to some hacking because of a OpenSSL bug.
> So in your opinion the one who actually buys and gets the certificate from the StartSSL web site must not share it with the system administrator? Or some second-in-command?
This key is now public and must be revoked. Bottom line. StartSSL can even conceivably invoice him for the work, but they have to revoke it if they want to be a CA in a secure public-key infrastructure.
I think you're right, if there's evidence the key is compromised, they should revoke first. Then they should bill you, and if you choose not to pay, they should send it to a collections agency.
My understanding is that the field, when working with a PostgreSQL database, is stored as a JSON field in PostgreSQL, rather than just a text field. I don't think django-jsonfield can do that.
They could hold up Dorian and ask Satoshi to post something requiring his key, although that couldn't discard the possibility of Dorian having instructed an acquaintance to do so in case of emergency.
There's really no way to prove (a posteriori) without doubt that someone is or isn't Satoshi, unless there was an encypted message left by him (a priori) saying "My DNA is (...)", to which he provides the key.
<a href="/anime/" class="a_very_big_button">See Anime List</a>