[cabfpub] Pre-Ballot - Short-Life Certificates

[Rick Andrews]

I realize the conversation has gone way afield of this, but I wanted to follow up.

I think that any CA that pre-issues a year's worth of short-lived certs and delivers them to the customer as a block completely misunderstands the concept of short-lived certs. In cases in which the site owner is found to have misrepresented information that the CA put into the cert, or perhaps when the site owner hasn't paid for the cert, the CA's response is to stop issuing new certs to that site owner, starting today. They won't be able to do that if they've pre-issued and delivered all the certs.

If this isn't obvious, then we'll need to spell it out in detail in the BRs, if/when we modify the BRs for short-lived certs.

-Rick

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Friday, October 24, 2014 12:01 AM
To: Rick Andrews; Ben Wilson; kirk_hall at trendmicro.com; CABFPub
Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates

On 23/10/14 19:20, Rick Andrews wrote:
> Gerv, I'm not sure that forbidding CAs to pre-issue short-lived certs 
> is auditable, or even desirable. If an attacker can get in to the CA's 
> database and extract information, that CA is in big trouble, not 
> specifically related to short-lived certs.

The risk I am attempting to mitigate here is the one of the CA who pre-issues a whole year's worth of "short-lived" certs with sequential notBefore dates and passes them on to the customer as a block. If the customer is then compromised, it's as if the attacker had stolen a cert of a year's duration with no revocation information, because they can do exactly what the site was doing, and keep deploying a new one of the certs every day.

So this is not a concern about CA compromise, but client compromise.

I'm very open to alternative wordings which address this risk.

Gerv