Subject: [pkix] fyi: Detecting Certificate Authority compromises and web browser collusion

From: =JeffH <[email-masked]>
Date: Wed, 23 Mar 2011 10:44:55 -0700

Of possible interest...

Detecting Certificate Authority compromises and web browser collusion
https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion

Microsoft Releases Security Advisory 2524375
http://blogs.technet.com/b/msrc/archive/2011/03/23/microsoft-releases-security-advisory-2524375.aspx

=JeffH

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Mar 2011 15:26:28 -0700

> https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion

A response from the CA in question: <http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html>

In short:
- an attacker compromised a user account on an RA's server
- that account was used to generate certificates for some valuable domain names for which the parent CA is not authoritative
- the compromise was discovered
- the certs were quickly revoked in the normal way (CRLs and OCSP)
- the certs were also revoked in an abnormal way, namely some relying party software vendors who were alerted decided to hard-code the certs into rejection lists in their software
- the public was informed after a subset of software vendors pushed out the hard-coded changes

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 23 Mar 2011 20:56:42 -0400

It would be useful to know how the RA compromise was detected.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Wednesday, March 23, 2011 6:26 PM
To: =JeffH
Cc: [email-masked]
Subject: Re: [pkix] fyi: Detecting Certificate Authority compromises and web browser collusion

In short:

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: max pritikin <[email-masked]>
Date: Wed, 23 Mar 2011 18:42:50 -0700

> It would be useful to know how the RA compromise was detected.

I would find that interesting but unless the security failure was related to the PKI technologies it probably wouldn't be useful to this list. 

I suspect the more useful question is why the software vendors feel a hard-coded blacklist is a necessary alternative to the CRL and OCSP mechanisms. The tor blog entry argues that using OCSP should be the default behavior, even in the face of potential privacy concerns. Obviously denial-of-service issues will quickly raise their heads. Solving DoS and privacy issues would be an interesting nut to crack...

- max

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 23 Mar 2011 22:12:33 -0400

While I agree with you in part, secure PKI does not live and get deployed in a vacuum.

It depends on and contributes to other security technologies and non-technical processes.

-----Original Message-----
From: max pritikin [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2011 9:43 PM
To: Santosh Chokhani
Cc: Paul Hoffman; =JeffH; [email-masked]
Subject: Re: [pkix] fyi: Detecting Certificate Authority compromises and web browser collusion

- max

---

From: "Kyle Hamilton" <[email-masked]>
Date: Thu, 24 Mar 2011 00:36:41 -0700 (Pacific Daylight Time)

On Wed, Mar 23, 2011 at 6:42 PM, max pritikin <[email-masked]> wrote:
> I suspect the more useful question is why the software vendors feel a hard-coded blacklist is a necessary alternative to the CRL and OCSP mechanisms.

I think that it's because the current specification for OCSP and CRL information is inadequate to protect against against someone who can forge a CA's authority.

> The tor blog entry argues that using OCSP should be the default behavior, even in the face of potential privacy concerns. Obviously denial-of-service issues will quickly raise their heads. Solving DoS and privacy issues would be an interesting nut to crack...

There's another place where the same privacy issue exists: DNS.  The reason it exists: spam caused Verisign (the operator of the DNS registrar at the time) to remove the authoritative list of all registered domains -- i.e., the zone files for the TLD nameservers -- from the public ftp servers.

I think we should centralize where that attack surface is, and try to address this through the application of DNS.

I have an idea how to do this, securely, and I think parts of the potential solution have previously been floated here.  Other parts are original, and still other parts are administrative.

First: DNSSEC is a wonderful tool.  There's no reason why the glue records provided by the TLD servers must be the only things provided in return to a query, particularly in a signed response.  Another record type could be included which specifies the public key of the domain's main trust anchor (which would be used unless a signed DNS chain indicated that a particular host or subdomain had a different one).  This would be part of the registration process, and (if various bureaucratic hurdles are passed) could even be made mandatory.  (There's good justification for such bureaucratic action -- the entire infrastructure must be secure, including the binding of a CA to a domain.)  Even though most current software doesn't check DNSSEC, it's going to become imperative that identity-interacting software do so.

The concept of "bare keys are acceptable as trust anchors" must be completely divorced from PKIX.  There is additional metadata about the CA which the client must be provided to resolve this issue, and I believe that the threat justifies this action.  I propose that the Certificate be the only acceptable trust anchor type for compliant implementations, because the necessary metadata includes an OCSP URL and a CRL retrieval URL, as well as information about where to report suspected fraud.

I also propose that PKIX consider respecifying the meaning of AIA to include "and you can get authoritative information for the certificates I issue here too".  This would permit the intermediate CA's certificate to include information about where its own revocation information will be published.  (This violates the concept of "the authority is the authority for everything about its operations, and it can't be the authority if it's subject to restrictions about where it must publish its information."  Since serious CA operations plan everything out ahead of time, before the intermediate's key is ever certified, I believe that this is a reasonable course.

The mindset that PKIX-WG must work to prevent is "security is a good idea, but it's too much hassle to get it working".

As I mentioned in another mail, I also propose the creation of something much like basicConstraints for information on whether the CA knows the true state identity of a particular certificate's private key holder.  This will enable systems (such as web browsers) which previously relied on the trust they had that their CAs would only issue a certificate if they knew the state identity to explicitly regain that trust.

-Kyle H

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 24 Mar 2011 21:28:49 +1300

max pritikin <[email-masked]> writes:

>I suspect the more useful question is why the software vendors feel a hard-
>coded blacklist is a necessary alternative to the CRL and OCSP mechanisms.

Because they want to actually be certain the certs are regarded as invalid, 
rather than just going through the motions for compliance purposes.  For 
example my fully-patched, latest-updates Vista machine still regards the 
Stuxnet certs as valid despite the CA having declared them revoked months ago.  
If you can issue your own certs it's even worse, just fit them with a CRLDP 
pointing to an OCSP responder that you control and they can never be revoked.  
So what the vendors are doing is quite sensible, they want to ensure the certs 
aren't used so they're using something that works.

(Kind of amusing to see, by this action, what the software vendors *really*
think of CRLs and OCSP).

Peter.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 24 Mar 2011 09:29:46 -0400

A better question is "How do they know it's over?"

Recommend marking Comodo as untrusted.  

-- T

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 24 Mar 2011 10:46:42 -0400

One can never be sure on such matters.

But once the attack method and detection method are known one can determine the efficacy of the two methods and learn from them and take appropriate precautions.

I wanted to know the detection since it may have lessons learned regarding the type of vigilance.

-----Original Message-----
From: Miller, Timothy J. [mailto:[email-masked]]
Sent: Thursday, March 24, 2011 9:30 AM
To: Santosh Chokhani
Cc: Paul Hoffman; =JeffH; [email-masked]
Subject: Re: [pkix] fyi: Detecting Certificate Authority compromises and web browser collusion

-- T

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 24 Mar 2011 11:25:20 -0400

> A better question is "How do they know it's over?"

That's fairly easy to assume that they closely monitor the HSM activity 
log. After all, the account of the incident does not refer to a private 
signature key operating in an unexpected way.

It's the authorization process guarding the access to HSM services that 
has been subverted somehow.

-- 
- Thierry Moreau

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 24 Mar 2011 11:26:19 -0400

> has been subverted somehow.

The smart attacker threads his requests into the normal stream, reducing his visibility.  How many RA accounts were compromised and remain quiescent until some future need?

In the end my question is rhetorical; the answer is obviously "They don't."  

-- T

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 24 Mar 2011 14:28:53 -0400

That is not my impression.

The claim seems to be compromising the RA account to submit a request from a seemingly legitimate trusted person (i.e., an RA).

-----Original Message-----
From: Thierry Moreau [mailto:[email-masked]] 
Sent: Thursday, March 24, 2011 11:25 AM
To: Miller, Timothy J.
Cc: Santosh Chokhani; [email-masked]; Paul Hoffman; =JeffH
Subject: Re: [pkix] fyi: Detecting Certificate Authority compromises and web browser collusion

-- 
- Thierry Moreau

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 24 Mar 2011 17:39:15 -0400

The "do we trust CRL/OCSP use" question is one that is definitely relevant to this mailing list. There is a second one that is related to Santosh's question, however: does the PKIX sub-CA/RA model work in the real world? From the CA's response:

> The RA account in question has been suspended pending on-going forensic investigation.
>  
> We immediately introduced new controls in the wake of this new threat to the authentication platform.

--Paul Hoffman

---

From: Erwin Himawan <[email-masked]>
Date: Thu, 24 Mar 2011 18:15:12 -0500

Paul,

You quoted "PKIX sub-CA/RA model".  I am doing a research of various PKI
(trust) model.
I am not come across with the term you mentioned.  Can you point me to
a reference that define this term?

Thanks,
-Erwin

On Thu, Mar 24, 2011 at 4:39 PM, Paul Hoffman <[email-masked]> wrote:

> > I would find that interesting but unless the security failure was related
> to the PKI technologies it probably wouldn't be useful to this list.
> >
> > I suspect the more useful question is why the software vendors feel a
> hard-coded blacklist is a necessary alternative to the CRL and OCSP
> mechanisms. The tor blog entry argues that using OCSP should be the default
> behavior, even in the face of potential privacy concerns. Obviously
> denial-of-service issues will quickly raise their heads. Solving DoS and
> privacy issues would be an interesting nut to crack...
>
> The "do we trust CRL/OCSP use" question is one that is definitely relevant
> to this mailing list. There is a second one that is related to Santosh's
> question, however: does the PKIX sub-CA/RA model work in the real world?
> From the CA's response:
>

---

From: max pritikin <[email-masked]>
Date: Thu, 24 Mar 2011 16:34:45 -0700

On Mar 24, 2011, at 4:15 PM, Erwin Himawan wrote:

> Paul,
> 
> You quoted "PKIX sub-CA/RA model".  I am doing a research of various PKI (trust) model.
> I am not come across with the term you mentioned.  Can you point me to a reference that define this term?

RFC5280, Section 3:

   RA:         registration authority, i.e., an optional system to which
               a CA delegates certain management functions;

---

From: Tom Gindin <[email-masked]>
Date: Thu, 24 Mar 2011 23:03:36 -0400

I have a different type of suggestion.  Would it make sense for 
any CA receiving a request for a server certificate containing a PKCS#10 
to mail that request in PEM format, perhaps with the submitting IP address 
if that value is meaningful, to the domain's registrar for forwarding to 
that domain?  What about mailing it to a reserved e-mail address within 
the domain (e.g. csrverify@domain)?  The CA then waits a certain interval 
for an objection (or a hold request) before issuing the certificate.  It 
assumes that identifying the proper level of a domain for notification is 
generally not problematic, e.g. the immediate subordinates of .org, .com 
and .co.uk are the proper levels for those.  There are probably cases 
where this mechanism could not be used because of confusion as to the 
proper domain level to be notified.
        This would not prevent RA compromise, nor would it defend against 
CA compromise.  It would allow a domain owner an independent check before 
a server certificate in his domain was issued by an intact CA.  In the 
case covered in the media this week, some of the domain owners would 
likely have objected if given notice of half a business day or more, and 
the CA would then have suspended the RA before issuing the illegitimate 
certificates rather than afterwards.  That limits the damage caused by 
many browsers' not checking revocation.
        Would a suggestion like this be relevant to RFC 3647 or a possible 
successor?  I don't see any place in section 4.4.2 to put this, but that 
isn't a fatal objection.  This is probably inappropriate for individuals' 
certificates, because it is not privacy-friendly, but servers are not very 
private.

                Tom Gindin

P.S. - The above suggestion is mine, and not that of my employer.

From:
Paul Hoffman <[email-masked]>
To:
[email-masked]
Date:
03/24/2011 05:40 PM
Subject:
Re: [pkix] fyi: Detecting Certificate Authority compromises and web 
browser collusion
Sent by:
[email-masked]

On Mar 23, 2011, at 9:42 PM, max pritikin wrote:
> I would find that interesting but unless the security failure was 
related to the PKI technologies it probably wouldn't be useful to this 
list. 
hard-coded blacklist is a necessary alternative to the CRL and OCSP 
mechanisms. The tor blog entry argues that using OCSP should be the 
default behavior, even in the face of potential privacy concerns. 
Obviously denial-of-service issues will quickly raise their heads. Solving 
DoS and privacy issues would be an interesting nut to crack...

--Paul Hoffman

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 25 Mar 2011 10:41:01 -0400

Tom,

I am not sure how practical this is given the number server certificates continuously issued.

As to 3647, it is NOT a policy.  It is a framework.  The framework does accommodate this.  A given policy could put such requirements in Section 3.2.2 (Authentication of organization identity); 3.2.3 (Authentication of individual identity); and/or Section 3.2.4 (Validation of authority)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Gindin
Sent: Thursday, March 24, 2011 11:04 PM
To: Paul Hoffman
Cc: [email-masked]
Subject: Re: [pkix] fyi: Detecting Certificate Authority compromises and web browser collusion

                Tom Gindin

From:

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 25 Mar 2011 11:00:25 -0400

On Thu, 2011-03-24 at 00:36 -0700, Kyle Hamilton wrote:
> First: DNSSEC is a wonderful tool.  There's no reason why the glue
> records provided by the TLD servers must be the only things provided
> in return to a query, particularly in a signed response.  Another
> record type could be included which specifies the public key of the
> domain's main trust anchor (which would be used unless a signed DNS
> chain indicated that a particular host or subdomain had a different
> one).

You might as well just put the information in the child zone.  DANE
(https://tools.ietf.org/wg/dane/) is going to do that.

> This would be part of the registration process, and (if various
> bureaucratic hurdles are passed) could even be made mandatory.
> (There's good justification for such bureaucratic action -- the entire
> infrastructure must be secure, including the binding of a CA to a
> domain.)  Even though most current software doesn't check DNSSEC, it's
> going to become imperative that identity-interacting software do so.

DANE clients will check for the certificate information in DNSSEC or
fail if someone tries to downgrade it away.  See also CAA
(https://tools.ietf.org/html/draft-hallambaker-donotissue).

> I also propose that PKIX consider respecifying the meaning of AIA to
> include "and you can get authoritative information for the
> certificates I issue here too".

There's a separate extension for that called Subject Information Access.

-- 
Matt

---

From: Tom Gindin <[email-masked]>
Date: Fri, 25 Mar 2011 19:52:46 -0400

There are a lot more e-mails sent than server certificates issued. 
 I thought that somebody would complain that this suggestion was a way of 
pushing partial responsibility for vetting onto the customer, even though 
it doesn't really allow the CA to get off the hook.
        If we don't define a standard facility for CA's to use, the domain 
owner won't know where to check for these warnings, and they will be of no 
use.  If it's the general opinion that this would pose unreasonable 
burdens on domain owners, or would only work in rare cases such as this 
week's, then there's no point in publishing such a facility.

Tom Gindin
I/T Architect - Security
IBM Business Consulting Services - Public Sector

From:
Santosh Chokhani <[email-masked]>
To:
Tom Gindin/Watson/IBM@IBMUS, Paul Hoffman <[email-masked]>
Cc:
"[email-masked]" <[email-masked]>
Date:
03/25/2011 10:41 AM
Subject:
RE: [pkix] fyi: Detecting Certificate Authority compromises and web 
browser collusion

Tom,

I am not sure how practical this is given the number server certificates 
continuously issued.

As to 3647, it is NOT a policy.  It is a framework.  The framework does 
accommodate this.  A given policy could put such requirements in Section 
3.2.2 (Authentication of organization identity); 3.2.3 (Authentication of 
individual identity); and/or Section 3.2.4 (Validation of authority)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Tom Gindin
Sent: Thursday, March 24, 2011 11:04 PM
To: Paul Hoffman
Cc: [email-masked]
Subject: Re: [pkix] fyi: Detecting Certificate Authority compromises and 
web browser collusion

private.

                Tom Gindin

From:

> We immediately introduced new controls in the wake of this new threat to 

the authentication platform.

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Sat, 26 Mar 2011 05:05:16 -0400

At 5:39 PM -0400 3/24/11, Paul Hoffman wrote:
>O...
>
>The "do we trust CRL/OCSP use" question is one that is definitely 
>relevant to this mailing list. There is a second one that is related 
>to Santosh's question, however: does the PKIX sub-CA/RA model work 
>in the real world? From the CA's response:
>

The general CA/RA model admits a lot of variability in terms of the security
of the resulting system:

	A CA may operate exactly one RA, internally, so that the security
	of the RA is essentially that of the CA

	A CA may have several RAs with very tight security controls.

	A CA may have a lot of RAs with variable security controls.

The third example can result in highly variable secruity guarantees, 
relative to a single CA. One can try to ameliorate this by having the 
CA filter cert requests from each RA, based on imposing constraints 
on RAs. If any RA is
authorized to approve a request from any Subject, then ...

Steve

---

From: Yoav Nir <[email-masked]>
Date: Sun, 27 Mar 2011 00:22:47 +0200

On Mar 25, 2011, at 5:03 AM, Tom Gindin wrote:

> for an objection (or a hold request) before issuing the certificate.  

I think this suggestion has value even without the CA waiting a certain interval. Besides, there's no good interval to prescribe there. Some organizations would check the entries in csrverify@domain the same day. Others may wait for weeks. 

Even without a waiting interval, or with a very short one, this suggestion makes sure that fraud such as was committed against Comodo would be detected. Comodo has detected this one. We have no idea how, but more power to them. But we can't be sure that every security breach at every CA will be discovered. Most security breaches are never discovered. So this will help such breaches to be discovered. Sure, if we could choose, the first priority would be to prevent the breach, second would be to detect it in-house, with detecting it with the customer's help a distant third, but it's still way better than having this go undetected.

If csrverify is redirected to /dev/null that won't help either, but I think domain admins would like this extra control that it gives them.

---

From: Tom Gindin <[email-masked]>
Date: Sun, 27 Mar 2011 23:06:59 -0400

Yoav:

        Thanks for the kind words, but the fact that many browsers don't 
implement revocation checking makes revocation a significantly weaker 
option than stopping the CA from issuing the bad certificate in the first 
place.  Also, as the victims of the latest attack quite rightly pointed 
out, an attack on web server certificates is far more effective when 
carried out by someone with influence over global DNS results returned to 
a given set of users.  Someone with such influence can also prevent those 
same users from resolving the CRL Distribution Point or OCSP server.
        How many widely available browsers fail connections when they 
can't reach OCSP or distribution point?  I know of at least one which does 
try to connect to OCSP, but doesn't show a visual indication that the 
connection is insecure when it can't reach the server.  That browser ought 
to turn the padlock open if it tries to reach an OCSP server and fails.

                Tom Gindin

From:
Yoav Nir <[email-masked]>
To:
Tom Gindin/Watson/IBM@IBMUS
Cc:
Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Date:
03/26/2011 06:23 PM
Subject:
Re: [pkix] fyi: Detecting Certificate Authority compromises and web 
browser collusion

> for an objection (or a hold request) before issuing the certificate. 

I think this suggestion has value even without the CA waiting a certain 
interval. Besides, there's no good interval to prescribe there. Some 
organizations would check the entries in csrverify@domain the same day. 
Others may wait for weeks. 

Even without a waiting interval, or with a very short one, this suggestion 
makes sure that fraud such as was committed against Comodo would be 
detected. Comodo has detected this one. We have no idea how, but more 
power to them. But we can't be sure that every security breach at every CA 
will be discovered. Most security breaches are never discovered. So this 
will help such breaches to be discovered. Sure, if we could choose, the 
first priority would be to prevent the breach, second would be to detect 
it in-house, with detecting it with the customer's help a distant third, 
but it's still way better than having this go undetected.

If csrverify is redirected to /dev/null that won't help either, but I 
think domain admins would like this extra control that it gives them.

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 27 Mar 2011 23:22:58 -0400

On Sun, 2011-03-27 at 23:06 -0400, Tom Gindin wrote:
> That browser ought 

That's not really a solution, for the reasons explained at
https://bugzilla.mozilla.org/show_bug.cgi?id=327181#c14 .

-- 
Matt

---

From: Yoav Nir <[email-masked]>
Date: Mon, 28 Mar 2011 09:16:50 +0200

> to turn the padlock open if it tries to reach an OCSP server and fails.

I'm not arguing that (late) detection is as good as prevention. It isn't. But even with late detection, the situation can be remedied, as we've seen with this attack. The remedy this time was a bunch of hard-coded serial numbers added to the source code of three browsers. I hope that we can get a better solution if this happens again, but the issue was addressed (for those of use who regularly update our OS and browsers)

---

From: Tom Gindin <[email-masked]>
Date: Tue, 29 Mar 2011 08:11:15 -0400

The very next comment on bugzilla seems far more convincing to me 
than that one - "make a list of possible error conditions and work out 
what to do in each."  The person arguing against opening the padlock was 
suggesting that opening the padlock was too little change to the user's 
experience for self-signed certificates, not too much.  It isn't clear to 
me whether the open padlock is enough of an indication for OCSP not 
working, but it does seem evident that the user's being unable to tell 
that OCSP has failed even by looking closely is a bad thing.

                Tom Gindin

From:
Matt McCutchen <[email-masked]>
To:
Tom Gindin/Watson/IBM@IBMUS
Cc:
"[email-masked]" <[email-masked]>
Date:
03/27/2011 11:23 PM
Subject:
Re: [pkix] fyi: Detecting Certificate Authority compromises and web 
browser collusion

-- 
Matt

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 29 Mar 2011 08:16:05 -0400

The EV spec doesn't allow compliant browser to display the EV indicators when status checking fails.  E.g., in Firefox, Larry[1] comes up blue instead of green.  What's wrong with this kind of indicator?

-- Tim
[1] Larry the Passport Officer is the icon that displays when you click on the SSL site indicator on the URL bar.

---

From: "Ed Gerck, Ph.D." <[email-masked]>
Date: Tue, 29 Mar 2011 08:55:29 -0700

> [1] Larry the Passport Officer is the icon that displays when you click on the SSL site indicator on the URL bar.

First, "Larry" does not know what's going on.   This is the same Larry
that affirms "You are connected to xyz.com which is run by (unknown)"
for a valid cert for a known entity, which is clearly named in the O field
and is digitally signed in the cert.

I suspect that Larry is just a bouncer for non-EV certs. This is the same
  Larry who people may thus, rightly, do not  trust.

Second, and because of that, who clicks on Larry?  Even an end-user can
tell who runs xyz.com -- even if just by reading the cert that Larry can't. The
EV-push made Larry less important, not more.

Cheers,
Ed Gerck

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 29 Mar 2011 12:12:53 -0400

> EV-push made Larry less important, not more.

Anecdotally, Larry has been useful to me.  Frex., I was dinking with OCSP settings in Firefox and left them disabled.  When I later visited Paypal, the indicator bar failed to turn up green as expected.  Since Larry showed me the data was correct, I recalled the change and undid it and everything was fine again.  If that had been an actual spoof, I wouldn't have been able to resolve the problem and would have been alerted to malicious activity.

But I know I'm not a good sample population, so take that for what it is.

-- T

---

From: Tom Gindin <[email-masked]>
Date: Wed, 30 Mar 2011 08:05:48 -0400

That indication is a good thing as far as it goes.  However, this 
should apply even for non-EV certificates with OCSP, and it really should 
be perceptible to the color-blind as well as to the rest of us even if 
it's more obvious to the 95%+ of us with full color vision (different 
posture or shading would do).

                Tom Gindin

From:
"Miller, Timothy J." <[email-masked]>
To:
Tom Gindin/Watson/IBM@IBMUS
Cc:
Matt McCutchen <[email-masked]>, "[email-masked]" <[email-masked]>
Date:
03/29/2011 08:16 AM
Subject:
Re: [pkix] fyi: Detecting Certificate Authority compromises and web 
browser collusion

The EV spec doesn't allow compliant browser to display the EV indicators 
when status checking fails.  E.g., in Firefox, Larry[1] comes up blue 
instead of green.  What's wrong with this kind of indicator?

-- Tim
[1] Larry the Passport Officer is the icon that displays when you click on 
the SSL site indicator on the URL bar.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 30 Mar 2011 09:03:47 -0400

> posture or shading would do).

I just had an vision of "Red Larry" pulling a gun.  That would rock.  :)

-- T

---

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 30 Mar 2011 07:51:52 -0700

On Sun, Mar 27, 2011 at 8:06 PM, Tom Gindin <[email-masked]> wrote:
> can't reach OCSP or distribution point?

No browsers do that.

Firefox has a preference setting for that, which is disabled by default.
To enable that preference setting, open Tools > Options > Advanced >
Encryption > Validation, and check the "When an OCSP server
connection fails, treat the certificate as invalid" checkbox.

Windows Chrome shows a warning icon when it can't reach OCSP
servers or CRL distribution points.  This behavior is always enabled.
But it is just a warning; the connections still succeed.

Wan-Teh Chang

---

From: "Kyle Hamilton" <[email-masked]>
Date: Wed, 30 Mar 2011 17:52:17 -0700 (Pacific Daylight Time)

>> can't reach OCSP or distribution point?

Apple Safari can be configured to do so on MacOSX, as a Keychain preference.

> connection fails, treat the certificate as invalid" checkbox.

The problem is that Firefox's "invalid certificate" workflow doesn't really explain what's going on, and libels sites using self-signed certificates as not "legitimate".

> But it is just a warning; the connections still succeed.

This is what should happen.  It is a visually-distinguishable intermediate state between full-success and full-failure.

-Kyle H