[cabfpub] FW: Short lived OCSP signing certificate

[Rich Smith]

Brad,
No one has stated how having revocation information in the cert HURTS
anything.  If the browsers want to look at the validity dates, see a short
lived cert and make the decision not to check revocation status, that's
fine, that is their decision.  There is at least a slim chance that having
the information there MIGHT help the end user if revocation status is
checked and there is ZERO chance that having the information there is going
to hurt the end user whether the browser decides to check it or not.  That
being the case I really have absolutely no idea WHY it is so awfully
important that we change the BRs to allow issuance without revocation
information.  The browsers have the ability to decide to treat short lived
certificates any way they see fit whether revocation information is there or
not.  From a CA point of view the only correct decision is to put the
information in there so that we can revoke the certificate should
circumstances dictate that course of action.  What the browser then does
with that information is neither our decision, nor our responsibility.
-Rich

> -----Original Message-----
> From: Hill, Brad [mailto:bhill at paypal-inc.com]
> Sent: Tuesday, September 18, 2012 4:13 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
> 
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
Url : http://cabforum.org/pipermail/public/attachments/20120918/3fea833c/attachment-0001.bin