[cabfpub] FW: Short lived OCSP signing certificate

[Jeremy Rowley]

Our proposal was a seven day validity period.  We selected that time period
because of clock synchronization issues and because it's a typically caching
interval for longer-lived certificates. 

The whole point of short-lived certs is their fast processing compared to
certs containing certificate revocation information.  Like you said Gerv,
the whole advantage of short lived certs is eviscerated if revocation
information is included.

The baseline requirements are not intended to stifle innovation and
progress.  That is the reason the validation sections are broad and open
ended.  We should be permitting new ideas and developments provided that
these ideas  provide similar levels of security and assurance.

Jeremy

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Gervase Markham
Sent: Tuesday, September 18, 2012 10:18 AM
To: richard.smith at comodo.com
Cc: 'Mads Egil Henriksveen'; 'CABFPub'
Subject: Re: [cabfpub] FW: Short lived OCSP signing certificate

On 18/09/12 17:05, Rich Smith wrote:
> I am still opposed to issuance of any certificate without revocation 
> information.  Yes, the BRs allow a signed OCSP response to be good for
> 10 days.

I've not heard a proposal for short-life certificates for as long as 10
days. 3 was what was on the table last time, IIRC.

> similar fashion.  The disconnect here seems to be that the relying 
> parties take that 10 day lifespan to mean that they can leave off 
> checking to 10 day intervals and that is faulty reasoning.

I don't think that's so. AIUI CRLs define how often they should be rechecked
and Firefox, when checking CRLs, respects those time periods. 
Do you know of a browser which doesn't?

> contention.  There is absolutely no reason that a short-lived 
> certificate REQUIRES the absence of revocation information.

If a certificate contains revocation information, what advantage would there
be in making it short-lived?

To put it another way: my understanding is that short-lived certificates
were a proposed solution, requiring no client-side changes, to various
issues with revocation (and certificate size). We can debate whether they
actually work in that role or not, but I don't see the value of the
short-livedness if revocation info is included.

> The only
> reason I can see is that some parties don't want to be held to account 
> for not properly checking the revocation status, so if the information 
> is not there they're off the hook.

I'm not sure who you mean here, but my interest in this is nothing to do
with any advantage to Firefox. I just think it might be a good solution to
some problems - as do, or at least did, Google, from a "owner of lots of big
servers" point of view.

Gerv
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public