Re: [pkix] fyi: Sovereign Keys: an EFF proposal for more secure TLS authentication

[Rob Stradling <[e-mail]>]

On Tuesday 13 Dec 2011 16:05:52 Adam Langley wrote:
> On Tue, Dec 13, 2011 at 4:56 AM, Rob Stradling <[e-mail]> 
wrote:
> > If "requiring OCSP stapling from all sites" cannot reasonably be
> > deployed, then surely we cannot expect ubiquitous support for _any_ new
> > TLS extension?
> 
> I agree. In additional to the requirement to support a TLS extension,
> OCSP stapling requires constant, fresh data making it even harder.

Fair point.  CT Audit Proofs don't have this "even harder" requirement, of 
course, since they will be static data.

<snip>
> > So when you say that "most existing verification code will ignore it",
> > you are correct.  However, I concluded that "most" was not good enough.
> 
> Yep, if we can't wedge the extra data in anywhere then we're in
> trouble. But the sooner that we start working on making it possible,
> the better things will be.

I've thought of a couple of other ways of wedging the data into the TLS 
handshake, although these methods would require more collaboration from the 
CAs than you've thus far intended to require (or perhaps expected).

IDEA 1 - PUT THE AUDIT PROOF INSIDE THE END-ENTITY CERTIFICATE:
When a CA is about to issue a certificate, it publishes the "ToBeSigned" 
certificate data to the Public Log.  The Public Log generates an Audit Proof of 
the "ToBeSigned" data and returns this to the CA.  The CA encapsulates the 
Audit Proof in a certificate extension, appends this extension to the 
"ToBeSigned" certificate data, and recalculates ASN.1 tag lengths as necessary.  
Then the CA signs the certificate and provides it to the certificate applicant.
Browsers would recognize the Audit Proof certificate extension and would have 
code to strip this extension and reconstruct the original "ToBeSigned" 
certificate data, so that the Audit Proof can be verified.
Since the Public Log is involved prior to certificate issuance, the Public Log 
could conceivably check CAA records, the Google Safebrowsing blacklist, etc, 
etc, and refuse to generate an Audit Proof if any problems are encountered.

IDEA 2 - CERTIFICATE INSIDE A CERTIFICATE:
A certificate is issued and added to the Public Log in the manner your doc 
describes.  Then, the CA issues a second certificate, which contains (in a 
certificate extension) the Audit Proof and the first certificate's signature and 
serial number.  The second certificate's Subject, Issuer, Validity Dates, 
Extensions, etc, must exactly match those of the first certificate.
The site owner configures their TLS Server to send the second certificate.
Browsers would recognize the new certificate extension and would have code to 
pull apart the second certificate, reconstruct the first certificate, and verify 
the Audit Proof.
Since the first certificate would never be seen by legacy Browsers, its 
signature could use SHA-2.  The second certificate's signature would probably 
use SHA-1 whilst there remain a significant number of legacy Browsers that 
don't support SHA-2.
Certificate serial numbers are meant to be unique amongst the set of 
certificates issued by any particular CA, but maybe it would be OK to break 
this rule for each pair of certificates envisaged by this idea, since they are 
essentially the same.  If revocation is required, both certificates should be 
revoked together, so sharing a serial number would make sure this happens.

Comments welcome.

> This is not something that we expect to be done next year, it's going
> to take many years to deploy.

If at least one my ideas would work, I think it could be deployed more quickly 
than that.  You'd only need buy-in from the CAs and Browsers.  No need to 
update any webserver software, and no need for site admins to do anything any 
differently.

> Cheers
> 
> AGL

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online