[cabfpub] FW: Short lived OCSP signing certificate

Ryan Hurst ryan.hurst at globalsign.com
Fri Sep 21 04:44:31 UTC 2012


I too have had experience implementing browsers as I was part of the IE team
back when you were at Netscape as well as having an opportunity to work on
the certificate and TLS stacks for the last few releases at Microsoft.

We had the same experiences you mention, with that said I think the largest
issue is the user experiences the browsers have with these scenarios vs.  -
http://unmitigatedrisk.com/?p=207

Ryan
-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Robert Relyea
Sent: Friday, September 21, 2012 8:38 AM
To: public at cabforum.org
Subject: Re: [cabfpub] FW: Short lived OCSP signing certificate

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






More information about the Public mailing list