[cabfpub] FW: Short lived OCSP signing certificate

[Robert Relyea]

On 09/20/2012 01:56 AM, Ryan Hurst wrote:
> I personally do.
As a security person, I would agree with you. As someone who at one 
point implemented this for a short period in what was a major browser at 
the time (early Netscape days), I can say there is a definite difference 
in the number of false positives. In the revocation case, there is very 
close to zero false positives. If I get an indication that the cert was 
revoked, I can be extremely confident that the cert is bad and that 
there is no reasonable reason the user should be able to override 
blocking the site. In the expiration case, there is a relatively high 
rate of false positives, that is certs that are expired because the 
admin forgot to renew them. The number of expired certs which are 
actually being used as attacks versus the number of expired certs that 
exist because of misconfiguration is small, so not allowing the user to 
override them generates bad will with the users (though we have 
progressively made overriding less friendly to users, which has reduced 
the actual number of expired certs active at any time in the wild).

We agree that expired certs are bad, and we treat them as untrusted, but 
because there is a high incidence of false positives, we allow them to 
be overridden (just like untrusted is overridable).

bob


>
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
> Behalf Of Rob Stradling
> Sent: Thursday, September 20, 2012 5:49 PM
> To: Eddy Nigg (StartCom Ltd.)
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] FW: Short lived OCSP signing certificate
>
> On 20/09/12 09:36, Eddy Nigg (StartCom Ltd.) wrote:
>> On 09/20/2012 11:26 AM, From Rob Stradling:
>>> Or, does the current treatment of expired long-lived certificates
>>> need to change? During a long-lived certificate's lifetime, many
>>> browsers will notice if it gets revoked. But as soon as that revoked
>>> certificate expires, those same browsers will presumably start
>>> treating that certificate no differently than they would treat an
>>> expired certificate that was never revoked.
>> Some browsers will check certificate status nevertheless.
> The PKIX specs don't require CRL/OCSP services to cover expired
> certificates, so there's no guarantee that a browser would be able to
> discover that an expired certificate was once revoked.
>
>> But certainly certificates that expired shouldn't be relied upon.
> Do you think browsers should block access to sites that use expired certs
> (in the same way that they block access to sites that use revoked certs)?
>
> --
> Rob Stradling
> Senior Research&  Development Scientist
> COMODO - Creating Trust Online
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4508 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120920/116334ad/attachment-0002.p7s>