Certificate Transparency Hack Day

Alec Muffett alec.muffett at gmail.com
Sat Jul 20 11:22:35 BST 2013


> Roughly: http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf
> Exactly: http://tools.ietf.org/html/rfc6962
>

Briefly:

- All Certificate Authorities publish attestable lists of all certificates
they issue, so that fake certs may promptly be identified
- Any CA found to be knowingly/unknowingly generating fake certs can be
called-out, blackballed or somehow spanked


I think it's a great idea, I think we need it, I think it's an advancement
on where we are, and as Ben knows, I don't feel that it's a complete
solution in and of itself; it creates complexity and hierarchy which - if
implemented as described - would doubtless be beneficial, and adds all
manner of lovely proofs of naughtiness, but I am worried about the new
possibilities for Layer-8/9 problems, ie: Finance and Bureaucracy.

And I worry about use of words like "anticipate" and "clearly":

*The log promises to incorporate the certificate and chain within a certain
amount of time. Failure *
*to do so is considered a breach of contract by the log. This time is known
as the Maximum Merge *
*Delay (MMD). We anticipate the MMD being measured in hours. Clearly, the
MMD is the longest *
*possible time a rogue certificate can be used without detection.*

Yep. I love the idea. Do it. And then keep innovating and do more.

    - a <grump/>

-- 
http://dropsafe.crypticide.com/aboutalecm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20130720/1ff4187a/attachment.html>


More information about the ukcrypto mailing list