[cryptography] Auditable CAs

Florian Weimer fweimer at bfk.de
Tue Dec 6 05:48:20 EST 2011


* Ben Laurie:

> Given the recent discussion on Sovereign Keys I thought people might
> be interested in a related, but less ambitious, idea Adam Langley and
> I have been kicking around:
> http://www.links.org/files/CertificateAuthorityTransparencyandAuditability.pdf.

Why wouldn't the problem we have with CAs now resurface again with the
entity which maintains the log?  And why is a new protocol needed?
Couldn't you just treat certificates from existing browser CAs as
signing requests for an uber-CA which issues traditional X.509
certificates?

Viewed from another perspective, "The CA must publish a list of
certificates it has issued" is a perfectly auditable requirement (in
particular if you specify availability and format), so if this is what
we want, browser vendors could just make it a requirement for being on
the root list.  However, this seems rather unrealistic at this point.

Therefore, I have written a proposal for TLS extension which adds some
additional transparency regarding the certificates which are floating
around, without mandatory publication by the CAs or a third party.  It
relies on the phenomenon that nowadays, we have a fair number of mobile
devices which migrate between networks with and without a clear path,
and sufficient local storage capacity to keep track of the certificates
they see.

<http://tools.ietf.org/html/draft-weimer-tls-previous-certificate-00>

I still think the concept is sound, and some discussion in this thread
(on TLS-intercepting proxies) makes it clear why the complexity of
sending the entire certificate chain is necessary.

(Quite deliberately, this proposal matches my first rule for evaluating
improvements to the browser PKI: if more cryptography is proposed, it
unlikely to work.)

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99



More information about the cryptography mailing list