[cabfpub] FW: Short lived OCSP signing certificate

[Hill, Brad]

The exact same same thing that having a cache or receiving a stapled 6 day old, still-valid, OCSP response does for him.

Are you also proposing to forbid OCSP caching/stapling?

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Rich Smith
> Sent: Tuesday, September 18, 2012 11:59 AM
> To: jeremy.rowley at digicert.com; 'Gervase Markham'
> Cc: 'Mads Egil Henriksveen'; 'CABFPub'
> Subject: Re: [cabfpub] FW: Short lived OCSP signing certificate
> 
> That's all very nice.  What does it do for the guy who goes to the site on day 6
> of a 7 day duration (first time visit, so he doesn't have anything
> cached) whose certificate I revoked for fraud on day 2?
> -Rich
> 
> > -----Original Message-----
> > From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
> > Sent: Tuesday, September 18, 2012 2:04 PM
> > To: richard.smith at comodo.com; 'Gervase Markham'
> > Cc: 'Mads Egil Henriksveen'; 'CABFPub'
> > Subject: RE: [cabfpub] FW: Short lived OCSP signing certificate
> >
> > As many have already pointed out, a short-lived certificate is as
> > secure as a certificate with OCSP/CRL information because it has the
> > same time for distribution as a cached response.  The only exception
> > was the scenario pointed out by Kirk where a certificate is revoked
> > immediately after issuance (because there wouldn't be cached
> > revocation responses).
> >
> > We could go with a lower time period for short lived certificates
> > (such as three or five days), however seven days is where clock
> > synchronization problems are remedied and was calculated based on
> > Windows' caching behavior.
> > Windows caches OCSP responses for 80% of the value of the next update.
> > The
> > baseline requirements specify that this value should be 10 days or
> > less.
> > Therefore, short lived certificates with 7 days or less will provide
> > the same assurance as a regular certificate issued under the baseline
> > requirements.
> >
> > The advantage of a short lived certificates is apparent on high
> > traffic sites. The lack of a check back to the CA makes the website
> > perform much faster and permits an entity to achieve always-on SSL.
> >
> > Jeremy
> >
> > -----Original Message-----
> > From: Rich Smith [mailto:richard.smith at comodo.com]
> > Sent: Tuesday, September 18, 2012 11:54 AM
> > To: jeremy.rowley at digicert.com; 'Gervase Markham'
> > Cc: 'Mads Egil Henriksveen'; 'CABFPub'
> > Subject: RE: [cabfpub] FW: Short lived OCSP signing certificate
> >
> > > -----Original Message-----
> > > From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
> > > Sent: Tuesday, September 18, 2012 12:57 PM
> > >
> > > 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.
> > [RWS] If that's what the current spec allows then IMO if you want to
> > make something more secure, concentrate on changing that.  Caching
> > revocation information for 7 days is insane.
> > >
> > > 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.
> > [RWS] Why and how?  Like I said, what the relying party does with the
> > information once we've provided it is up to them.
> > >
> > > 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.
> > [RWS] I don't see how leaving a certificate which should be revoked
> > un-revoked for up to 7 days provides any level of security or
> > assurance.
> > >
> > -Rich