[cabfpub] FW: Short lived OCSP signing certificate

Hill, Brad bhill at paypal-inc.com
Tue Sep 18 13:12:36 MST 2012


OK, then what about short-lived certificates that lasted only 24 hours?  

At the logical conclusion of this, unless you insist on live revocation status checking for every connection, there is going to be some period of time for which a revocation response is considered valid, and a short-lived certificate with the same lifespan has quite similar security properties.

And while OCSP stapling isn't widely supported yet, I think there is a strong appetite for it, and very little for real-time revocation checking.  We, the customers and users, like the privacy properties of stapling and caching, we like the performance and latency properties of stapling, and we like not having our own availability be contingent on "a series of internal network events" at a CA (at least within a certain time window). 

I'm not sure I'm totally in favor of short-lived certificates until and unless we find a way to make it compatible with provable transparent issuance like in CT, but I don't think there's a strong argument that allowing experimentation with it degrades security vis-à-vis the current issuance/revocation status quo.

> -----Original Message-----
> From: Rich Smith [mailto:richard.smith at comodo.com]
> Sent: Tuesday, September 18, 2012 12:59 PM
> To: Hill, Brad; jeremy.rowley at digicert.com; 'Gervase Markham'
> Cc: 'Mads Egil Henriksveen'; 'CABFPub'
> Subject: RE: [cabfpub] FW: Short lived OCSP signing certificate
> 
> That assumes there is a cached response or that the server uses stapling
> (most still don't).  And I personally think that a cached or stapled
> response shouldn't live for more than 24 hours without having to retrieve a
> fresh response (even if it's the same one) from the authoritative OCSP
> server.  If current caching standards allow for more I would consider that
> something that we should take a close look at changing because if relying
> parties can go days without knowing a certificate has been revoked I don't
> think we're serving them very well.  Pointing out a problem in that area
> doesn't convince me that we should remove revocation information from a
> short lived certificate it just makes me think we have another problem area
> to address.  In short, you are extremely unlikely to convince me that the
> way to solve the revocation problem is to do away with revocation checking.
> I think short lived certs are a nice complementary strategy, but I don't
> think they are the solution and I don't think the end user is best served by
> removing revocation checking from them.
> 
> -Rich
> 
> > -----Original Message-----
> > From: Hill, Brad [mailto:bhill at paypal-inc.com]
> > Sent: Tuesday, September 18, 2012 3:02 PM
> > To: richard.smith at comodo.com; jeremy.rowley at digicert.com; 'Gervase
> > Markham'
> > Cc: 'Mads Egil Henriksveen'; 'CABFPub'
> > Subject: RE: [cabfpub] FW: Short lived OCSP signing certificate
> >
> > 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



More information about the Public mailing list