> On Feb 24, 2017, at 9:11 AM, philliph--- via Public <[email protected]> > wrote: >> On Fri, Feb 24, 2017 at 10:46 AM, [email protected]<[email protected]> >> wrote: >> >> 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. >> >> 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.
If we accept that the premise that a key objective of WebPKI is to only issue certificates to “good” sites and that phishing sites are not “good”, then I agree with your point. However if the premise in that WebPKI is designed to replace TOFU (trust on first use) to allow clients to have assurance they can authenticate they are talking to host at the named FQDN, then the focus is on making sure the initial validation of the binding of the key to the FQDN is secure. If we assume that x% of these are spoofed in some manner, but we don’t know exactly which, then we want to expire them every time we fix the spoofing issue. But if we combine this with the “don’t break existing certificates”, then the only solution is to rotate certificates on a reasonably frequent basis. I think the ideal for the TOFU-like scenario is DNSSEC+TLSA, but the infrastructure necessary to globally deploy is not yet there. Instead what we have (certs in the TLS handshake that chain to trusted CAs) is being used to get the same result. It feels like we need to clarify the reason we CAs exist. This has been the elephant in the room since I started paying attention to CABF and maybe now it is time to address it. Thanks, Peter _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
