[cabfpub] FW: Short lived OCSP signing certificate

[Rich Smith]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120918/e631fbe8/attachment-0004.bin>