[cabfpub] FW: Short lived OCSP signing certificate

[Rich Smith]

Gerv, short-lived certs have certain advantages, but I don't see them as a 
solution to revocation.  I do see them as a solution to requiring browsers 
needing to add a long-lived cert to an internally maintained blacklist which 
can only be updated by an application update.  No matter how short the life 
may be I see no real world disadvantage to including revocation information so 
that those parties who do check and have not cached that data beyond the life 
of the certificate can take advantage of it if the cert does get revoked.  I 
have not yet seen a compelling argument for allowing revocation information to 
be left out.  If a CA wants to issue a short-lived cert, great, but that CA 
MUST still be required to revoke if a problem presents itself during the life 
of that cert and the relying party SHOULD still be checking the revocation 
status.  I simply don't understand why short-lived certs and revocation 
information/checking must be mutually exclusive.  Until I do I will remain 
opposed to lifting the requirement to include revocation information in any 
issued certificate.  What you do with that information is yours to decide, but 
IMO the CA has a responsibility to revoke a certificate if there is a problem 
that warrants it, and to make known the method of checking for such a 
revocation, and the term of validity of the certificate doesn't absolve us of 
that responsibility.

Regards,
Rich


> -----Original Message-----
> From: Gervase Markham [mailto:gerv at mozilla.org]
> Sent: Tuesday, September 18, 2012 12:18 PM
> 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
-------------- 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/9cbeb2a4/attachment.bin