> On Feb 24, 2017, at 11:38 AM, Eric Mill <[email protected]> wrote: > > On Fri, Feb 24, 2017 at 10:46 AM, [email protected] > <mailto:[email protected]><[email protected] > <mailto:[email protected]>> wrote: > > You are misrepresenting what I am saying. Do not put words in my mouth again. > You do not speak for me. Only I speak for me. > > Is that totally clear? > > It's clear, but not relevant. As best as I can tell, it is an accurate > representation of what you said, and nothing in the rest of your message > indicated otherwise.
You are not me, you will not speak for me. not now, not ever. Your interpretation was wrong. The White House is looking for a new press spokesperson I hear. > > There is a WebPKI mechanism for dealing with certificates that were issued to > people who should not have them. It is called revocation. It has been part of > the PKIX specification from the very start. > > Revocation is required for much more than dealing with situations like > DigiNotar. The vast majority of certificates that are revoked for cause were > validly issued and then revoked because of actions by the subject like > setting up a phishing site. > > > If a browser provider decides not to support revocation as per the > specification for the sake of shaving off a few milliseconds from their > response, that is a choice they have made. They are the party that has > decided to put their customers at risk. If they then go round pointing > fingers at others for not mitigating the consequences of their decision, they > are going to have the fingers pointed back to them. > > This just comes across as bitterness. While you may think their calculus is > wrong, Chrome's rationale for dropping support for most end-entity revocation > has been clearly expressed and defended, in blog posts, articles, and many > mailing list posts here. Disagree, but don't suggest it's bad faith -- and > don't use it as an excuse to not budge on improving the security of another > aspect of the Web PKI. There is an open standard that was agreed by a wide technical community. A community that includes people that know a lot more about PKI than either you or Mr Sleevi have demonstrated to date. I think that it is entirely reasonable to point out that the WebPKI is not a science project that individuals can adapt to their own whims no matter who they happen to be working for at the time. > In the PKIX architecture, the choice of certificate validity interval has no > security consequences whatsoever. The only consequence of a longer or shorter > validity interval is that the revocation infrastructure has to track > certificate status for longer or shorter periods of time. > > That's flatly wrong, and dangerous. Even if we were in a world where > revocation was fully enforced and hard-failed by all relying parties -- a > world we're so very far away from -- revocation requires that someone *know* > to revoke the certificate. You can only use revocation to mitigate a known > attack. Lets say that there was a CA ‘LaxCA’ that decided to have the absolute minimum validation check and not do revocation. That CA could operate very cheaply. When it is notified that a certificate is being used on a phishing site it does nothing, it merely waits for the certificate to expire. And then it automatically re-issues a new cert to the subject when it expires. What is the difference between LaxCA and a 100 year cert? None that I can see. Certificate validity only has effect if you are going to do something different on expiry. > Expiration will remove a compromised certificate from being used in an > attack, whether or not any human is aware of the compromise. But will not prevent the malefactor being issued a new one. Because in your attack scenario, no CA would have reason not to re-issue. It is very easy to devise attack scenarios in which a failure occurs. But they have no real significance unless you can show that your proposed course of action results in a different outcome. This scenario does not.
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
