On 1/06/2014 7:07 AM, Michael Gilbert wrote: > That's an incredibly difficult political, rather than technical > problem. It's up to the entire ecosystem to move toward short-lived > certificates, and that isn't happening any time soon. All other > existing solutions are simply "security theater". > > In the meantime, Google has decided to avoid those theatrics by > clearly stating not to trust anything, and I personally respect that > honesty.
If stapling can be made a compulsory feature for a cert AND this can be fully verified by a DNS RR, then so long as the domain's DNS isn't hijacked then it having normal expiry of certs isn't a problem. The life of the validation can be short with the life of the cert itself still being 1 to 10 years. So, you have a new cert with the ability to *require* stapling. You also require stapling responses to have a low TTL. You create the appropriate DNS RR to indicate these details. Make sure your old cert is revoked and that, consequently OCSP records reflect this. And no, it isn't perfect, but it is better than ignoring OCSP altogether. Client browsers (or anything else that relies on the cert), will need to check for the DNS RR record(s) to see that they match the cert provided with the stapled proof of validity. Granted, at this time, browsers have no way to deal with this properly -- but that will change if and when it is possible to include in the cert that it MUST be stapled (no soft fails allowed). Kind Regards A -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538aae93.7050...@affinityvision.com.au
