Closed Bug 405139 Opened 17 years ago Closed 17 years ago

EV certs should be treated as providing less certainty of identity if OCSP is disabled.

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: wgianopoulos, Assigned: KaiE)

References

Details

Attachments

(1 file)

Patch v1
(deleted), patch
rrelyea
: review+
mtschrep
: approval1.9+
Details | Diff | Splinter Review 
Currently, the code treats an EV Certificate as being just as trusted if it is validated via OCSP and if it is not.  My opinion is that an EV Certificate that has not be validated as still in effect via OCSP is no better than plain old vanilla SSL Certificate.
In bug 404591 Johnathan Nightingale said:

> As for OCSP, I don't know - we ship with that enabled by default, and the EV
> guidelines even demand that CAs maintain quality of service on OCSP responders
> (by 2010 - they complain that existing OCSP server infrastructure isn't there
> yet) but if a user deliberately turns off OCSP checking, it seems like a pretty
> surprising side effect to me that we would also stop trusting valid,
> non-expired certs from EV roots.  Would we downgrade them to regular SSL
> status?  Why - the domain verification is arguably the most important point,
> since that's what ties it to the current site.

Exactly the point.  Ev Certificates can last up to 2 years.  The ownership of the domain may have changed during that time, or the owners of the certificate may have closed up shop at the address indicated and leave no forwarding address.

The entire point of an EV Certificate is that it is tied to known people at a known address and it has been verified that those people own the domain in question.

All of this could change over a 2 year period.

The point is the people who issued the certificate may have have subsequently revoked it because the people or entity the certificate was issued to no longer exists or if they/it no longer own the domain name in question.

If we don't use OCSP to ask if the Certificate is still valid, then we are acting on up to 2 year old information instead of current information.
Summary: EV certs need to be treated as providing less certainty of authentication if OCSP is disabled. → EV certs should be treated as providing less certainty of authentication if OCSP is disabled.
Summary: EV certs should be treated as providing less certainty of authentication if OCSP is disabled. → EV certs should be treated as providing less certainty of identity if OCSP is disabled.
The EV SSL Certificate Guidelines (http://www.cabforum.org/EV_Certificate_Guidelines.pdf) do *not* mandate the use of OCSP for EV SSL Certificates issued before the end of 2010. Until that time, EV-capable CAs are only required to support OCSP *OR* CRLs.

So whilst we're still this side of 2010...if "a user deliberately turns off OCSP checking", then surely the correct behaviour should be to try to obtain revocation information from a CRL (if available) instead.  If a CRL can be downloaded and verified, and it does not mark a certain EV SSL Certificate as revoked, then surely the Mozilla code should accept that certificate as a currently valid EV SSL Certificate?

(In reply to comment #2)

> So whilst we're still this side of 2010...if "a user deliberately turns off
> OCSP checking", then surely the correct behaviour should be to try to obtain
> revocation information from a CRL (if available) instead.  If a CRL can be
> downloaded and verified, and it does not mark a certain EV SSL Certificate as
> revoked, then surely the Mozilla code should accept that certificate as a
> currently valid EV SSL Certificate?
> 

Yes. Sorry.  Either OCSP validation or verified not on a CRL should be fine.  I just think it ought to check something to make sure the certificate is still valid.


Right, Revocation of some kind is required. Downloading CRLs are not yet working, so for now mozilla needs OCSP.
Will "mozilla needs OCSP" still be true when Firefox 3.0 gets launched?

Or will the issue of "Downloading CRLs...not yet working" be resolved by then?

So the challenge here is:
Whenever NSS can neither use CRL nor OCSP for verification, it must reject the cert as invalid.

This is a blocker for FF 3.

First, NSS bug 403853 must get fixed.

Second, once OCSP+libPKIX works, we must undo portions of the patch from bug 404592. In particular, the following block of code must be changed to request OCSP with a hard failure.

  cvin[0].type = cert_pi_policyOID;
  cvin[0].value.arraySize = 1; 
  cvin[0].value.array.oids = &oid_tag;
  cvin[1].type = cert_pi_revocationFlags;
  cvin[1].value.scalar.ul = CERT_REV_FAIL_SOFT_CRL
                            | CERT_REV_FLAG_CRL
                            ;
  cvin[2].type = cert_pi_end;


Bob, what flag would be used to express the following:

- I want either CRL or OCSP check
- one soft failure is allowed
- two soft failures mean => hard failure
Blocks: evtracker
Depends on: 403853, 404592
Flags: blocking1.9?
Kai, reject the cert as invalid?  I think not.  
Rather, treat it as an ordinary non-EV cert.
(In reply to comment #7)
> Kai, reject the cert as invalid?  I think not.  
> Rather, treat it as an ordinary non-EV cert.

No. I really mean "reject as invalid".

I'm talking about the behavior of function CERT_PKIXVerifyCert, which takes a flexible list of input parameters.

IMHO, if the input parameters asks for checks, but the function is unable to perform the checks, then the function is supposed to return a failure.


Are we going to get CRL + OCSP working in time in NSS and Gecko for FF3?
Jonathan or Kai can you help us understand the priority of this bug and whether it should block the release...
(In reply to comment #9)
> Are we going to get CRL + OCSP working in time in NSS and Gecko for FF3?

Quick Recap:
- OCSP is already on and active by default.

- NSS has long supported CRL checking, but we don't automatically fetch CRLs at the moment.  Our users never manually fetch these things, so for our purposes, support for CRLs is inactive at the moment.  AIUI, this was a patent problem for a long time, but over the summer the mozilla project was given license to use that code, so I hope Kai, Nelson or Bob can comment on the current state of CRL auto-fetch in NSS.

- This bug is asking for us to do those checks (a given cert will only require one of the two) and *if we don't receive a response*, to downgrade the cert or treat it as invalid.  Normally we'd only do that if we received a declarative, "this cert has been revoked" response.

In practical terms, I think that EV certificate fraud is not a very attractive target for attackers because the cost and difficulty of obtaining one is high.  And this bug is not addressing revocation anyhow - certainly a cert whose OCSP responder says it's revoked will be treated as such.  This is about what to do when we don't get a timely OCSP response.  So a discussion like this is more about correctness than about responding to a known and active threat.

In my opinion, and I can readily imagine people disagreeing, if we got nowhere with this bug, I would still ship Firefox 3.

If we expect to have the support for CRL auto-fetch though, (or if Frank, cc'd, tells us that all our EV roots offer OCSP) it seems like a containable piece of work with a clear benefit.  So in terms of blocking priority, I would say it is a P2 or P3.

If we don't expect to have CRL auto-fetch, then resolving this bug within an FF3 timeframe seems impossible, and it would be wanted+ at best.

(In reply to comment #11)
> In practical terms, I think that EV certificate fraud is not a very attractive
> target for attackers because the cost and difficulty of obtaining one is high. 
> And this bug is not addressing revocation anyhow - certainly a cert whose OCSP
> responder says it's revoked will be treated as such.  This is about what to do
> when we don't get a timely OCSP response.  So a discussion like this is more
> about correctness than about responding to a known and active threat.

It's also about liability, cf. this excerpt from the CA/B Forum guidelines, section 37(a)(2): the CA need not "defend, indemnify, and hold harmless" the Application Software Vendor

  "[...] where such claim, damage, or loss was directly caused by such
  Application Software Vendor’s software displaying [...] as trustworthy: [...]
  (2) an EV Certificate that has been revoked (but only in cases where the
  revocation status is currently available from the CA online, and the browser
  software either failed to check such status or ignored an indication of
  revoked status).

Assuming that an EV certificate has both an AIA extension with one or more OCSP responders and a CDP extension with one or more CRL URIs, then PSM should only display the EV indicators if up-to-date revocation information is available, either from one of the OCSP responders or from the CRL. (If *all* OCSP responders and *all* CDPs are unavailable, then PSM could theoretically display the certificate as trustworthy, though I don't think that's a good idea.)
(In reply to comment #12)
> Assuming that an EV certificate has both an AIA extension with one or more
> OCSP responders and a CDP extension with one or more CRL URIs...

As noted in comment #2, EV SSL Certificates issued before the end of 2010 may legitimately include one or more CDP URLs and *zero* OCSP responder URLs.

Therefore, if EV-enabled NSS/PSM does not implement CRL auto-fetch, and it encounters a "CRL-only" EV SSL Certificate, it will *always* "fail to check such status" of that certificate...even if the CRL is always up-to-date and available.

Per comment #11, marking wanted.
Flags: blocking1.9? → wanted1.9+
(In reply to comment #11)
> I hope Kai, Nelson or Bob can comment on the current state of
> CRL auto-fetch in NSS.

It might happen that we get CRL auto fetch in the upcoming version of NSS,
as part of libpkix functionality, but the verification of whether CRL checking happened and succeeded is buried deep down in the verification logic.

Most likely the EV verification step will have no direct link to know whether CRL checking was done.

So for the time being, Johnathan's statement is still correct, we rely on OCSP.


> - This bug is asking for us to do those checks (a given cert will only require
> one of the two) and *if we don't receive a response*, to downgrade the cert or
> treat it as invalid.

According to my testing, with the next upcoming snapshot of NSS, together with patch v2 attached to bug 399590, a failure in OCSP communication will cause our EV verification to fail.


There is one more scenario to handle: A user might have explicitly turned off OCSP in the prefs.

Right now, when OCSP is turned off, the EV verification will not try OCSP, there will be no hard failure, and the verification succeed.

Ideally, a change would have to be made in NSS. The verification (at the NSS level) should check whether OCSP is disabled, and if OCSP was requested, should return a failure.

However, in a NSS confcall last wednesday, we agreed, for now, to do this check in PSM.


In other words:

- this bug requests to use an UI with "less certainity" if OCSP is disabled
- when OCSP is disabled, we would like to use the "basic / standard SSL" or
  "domain validated SSL" UI for EV certs.
- we will solve this at the PSM level
- when OCSP is disabled, PSM will not attempt a EV policy verification
- when OCSP is disabled, PSM will immediately decide "this is not valid EV"
Attached patch Patch v1 (deleted) — — Splinter Review 

        Attachment #296582 -
        Flags: review?(rrelyea)

    
    

    
  
Comment on attachment 296582 [details] [diff] [review]
Patch v1

This patch isn't necessary now that that the attachment 296573 [details] [diff] [review] of bug 399590


has been approved.

    
    

    
  
(In reply to comment #15)
> Most likely the EV verification step will have no direct link to know whether
> CRL checking was done.
> So for the time being, Johnathan's statement is still correct, we rely on OCSP.

Kai, do you think it's likely or unlikely that this situation will change in time for the launch of FF3 ?


    
    

    
  
(In reply to comment #18)
> Kai, do you think it's likely or unlikely that this situation will change in
> time for the launch of FF3 ?

Unlikely.

    
    

    
  
(In reply to comment #17)
> (From update of attachment 296582 [details] [diff] [review])
> This patch isn't necessary now that that the attachment 296573 [details] [diff] [review] of bug 399590
> has been approved.

Bob, I disagree, because of my test results. Maybe my test results indicate another bug, but the current state requires this patch.

Yes, when OCSP is enabled, using the mentioned attachment from bug 399590 (which asks to require an OCSP check) and OCSP is failing, then the NSS function will return with a failure.

Unfortunately, this is not true when OCSP is disabled.

In my tests, when using the mentioned attachment from bug 399590 and having OCSP disabled in prefs, the NSS function returns success and we get a false positive EV UI.

Only when using both patches (from 399590 and this bug) I got the desired "no EV UI" result with OCSP disabled in prefs.


    
    

    
  
Comment on attachment 296582 [details] [diff] [review]
Patch v1

OK, so turning off OCSP overrides the OCSP request for the libpkix library?

Anyway this code will create the semantics the user would expect so r+

        Attachment #296582 -
        Flags: review?(rrelyea) → review+

    
    

    
  
Comment on attachment 296582 [details] [diff] [review]
Patch v1

forgot to request approval...

        Attachment #296582 -
        Flags: approval1.9?

    
  

        Attachment #296582 -
        Flags: approval1.9? → approval1.9+

    
    

    
  
(In reply to comment #11)
> If we expect to have the support for CRL auto-fetch though, (or if Frank,
> cc'd, tells us that all our EV roots offer OCSP)

(My apologies for not answering this question before now.) I haven't done a complete check on this, but at least one EV candidate CA (Trustwave) doesn't offer OCSP service; they just have a CRL.



    
    

    
  
fixed
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED

    
    

    
  
I am currently trying to help SECOM Trust get their EV SSL cert into NSS at bug 394419.  SECOM Trust tells me that they currently only offer CRL and do not plan to support OCSP until 2010.  

Can I clarify that as things stand today, even if the SECOM Trust EV SSL cert was accepted into NSS, that due to this bug our full EV UI would not be presented?

    
    

    
  
> would not be presented?

Would not be presented to websites using the SECOM Trust EV SSL? (to clarify.)

    
    

    
  
(In reply to comment #25)
> I am currently trying to help SECOM Trust get their EV SSL cert into NSS at bug
> 394419.  SECOM Trust tells me that they currently only offer CRL and do not
> plan to support OCSP until 2010.  
> 
> Can I clarify that as things stand today, even if the SECOM Trust EV SSL cert
> was accepted into NSS, that due to this bug our full EV UI would not be
> presented?
> 

This bug is not about not presenting the cert as not being and EV cert if the CA does not provide OSCP.  CAs are not required to do so until 2010.  This bug is about not presenting the certificate as being an EV cert if the user has configured the browser to disable OSCP checking altogether.



    
    

    
  
In reply to comment 27,
4 not's in one sentence!  A new record?  ouch!

Bob, Bob, Frank and Kai, (and anyone else who cares :)
I think we need to put up a web page on some mozilla web site, explaining
EXACTLY what our rules are going to be regarding revocation checking and 
its impact on EV.  There are a large number of binary variables involved
and together they create a huge number of combinations.  We should be 
careful to describe the intended behavior for all cases.   

Here are some questions to ponder:
a) if the cert doesn't give an OCSP URI, does it matter if the user has 
disabled OCSP?  (and does the presence or absence of a CRLDP URI change 
that answer?)
b) if the cert doesn't give an OCSP URI, will mozilla recognize it as an 
EV cert, or not?


    
    

    
  
(In reply to comment #28)
> Bob, Bob, Frank and Kai, (and anyone else who cares :)
> I think we need to put up a web page on some mozilla web site, explaining
> EXACTLY what our rules are going to be regarding revocation checking and 
> its impact on EV.

I've put a stub page up at

http://wiki.mozilla.org/CA:EV_Revocation_Checking

and linked to it from

http://wiki.mozilla.org/CA:Overview

Please feel free to edit the above page and add additional questions, answers, or comments.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: