[cryptography] Auditable CAs

Florian Weimer fweimer at bfk.de
Mon Dec 12 09:34:29 EST 2011


* Ben Laurie:

> I don't know how to answer that without just regurgitating the
> document again. You have read it, right?

I don't think it adequately addresses the "too big to fail" problem
(that is, a compromised log which cannot be retired because too much
depends on it).

> Our proposal does not require CAs or third parties to publish
> anything.

Okay, the subscriber can submit the certificate to the applicable logs.
But it's still forced publication, isn't it?

Anyway, submission by the CA seems more desirable to me because there
are fewer of them, and all of them could be told to resubmit their
certificates to other logs if it turns out that a log has to be closed
down.  It is impossible to do that when subscriber action is required.

I stand by my initial statement that if publication is the goal, browser
vendors should simply demand it because it's a fairly auditable
requirement, as far as such things go.

> Interesting proposal: two comments immediately spring to mind:
>
> 1. You probably need to allow for sending more than one certificate
> chain.

More than chain in what sense?  The default is to send what the server
presented during the last successful handshake, completely unprocessed.
However, the size constraints for TLS extensions and server certificate
chains are different, so only a subset of the chain might fit into the
extension.

It seems that there are implementations which already impose a 63K limit
on server certificate chains, so they wouldn't even need to implement
chain subsetting.

> 2. What about server farms that have a different cert per machine? Or
> CDNs?

In those cases, operators will see several certificates reported back to
them.  I expect that this days is collected like any other event log
(probably both locally on the host and centrally on a dedicated log
server).  Then someone needs to know the complete set of valid
certificates for the organization.  For many folks, this will be a
challenge, but there's really no way around that.  (Your proposal is
exactly the same in this regard.)

-- 
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