554598 - Accept OCSP responses whose signers don't conform to RFC 2560

Status: RESOLVED INVALID

(NSS :: Libraries, enhancement)

Description

[Iñigo Barreira]

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; EJGVNET; InfoPath.2; .NET CLR 2.0.50727; EJGVNET) chromeframe/5.0.342.0
Build Identifier: 

Hi,

I´ve tracked a bug in the Bugzilla years ago [316957], and now the options are to modify my OCSP response or ask or track a bug for you to modify the behaviour of the Firefox.
Our VA is signed by a technical CA (which is not published in our tree) and this VA answers all the requests coming from any of our sub CAs which issues certificates. This is commonly used in many CSPs.
the question is that you are asking me to modify my infrastructure just to have a VA for every sub CA we have, more or less, you are asking me that the VA that response for a specific CA must be signed by that one. This is an easy solution for those CAs that only issue a few certificates policy (typically for those american CAs that issue only SSL certs) but in Europe we have a few more policies and I can have a VA for each CA, so that´s why many use a VA for all the CAs.
This configuration hasn´t been a problem in Internet Explorer, Opera, Chrome and Safari and I don´t know why this is very problematic for firefox.
As you can see in the bug opened, you´re suggesting to follow the RFC2560 and indicates the 3 options a CSP need to follow. That´s ok as explained but is also mentioned that "They MAY provide a means of locally configuring one
  or more OCSP signing authorities, and specifying the set of CAs for
  which each signing authority is trusted" and this is what we have done as some other CSP.

So, I´d like you to modify that behaviour in Firefox for us to be in the root program and show our green bar for our SSL EV certs.

Regards

Reproducible: Always

Comment 1

[Jo Hermans]

that's bug 361957 ...

Comment 2

[Iñigo Barreira]

Hi Jo,

I don´t get you. In this bug I´m requesting a change in the Firefox, in 361957 I´m requesting to be accepted in the Mozilla root program.

Regards

Comment 3

[Eddy Nigg (StartCom)]

(In reply to comment #0)
> So, I´d like you to modify that behaviour in Firefox for us to be in the root
> program and show our green bar for our SSL EV certs.

I believe that Mozilla follows the RFC and you can add manually a dedicated OCSP responder to the configuration. However - as I understand it - the green address bar will be only shown with successful response from the OCSP responder. Hence all your users would have to configure your OCSP manually (and invalidate all other OCSP responses from the other CAs).

The correct way to do this, is to include the OCSP URI in the AIA extension. This OCSP responder must be signed by an OCSP responder certificate which was issued by the issuer. In this case, no manual configuration must be performed and this is how all EV issuing CAs operate.

FYK, CAs have typically multiple issuers and your situation is far from being unique. For example StartCom has currently 9 intermediate CAs, all with working and conforming OCSP responders. I suggest to consider such an implementation with your CA as well. :-)

Comment 4

[Iñigo Barreira]

Thanks Eddy for your comments, I really appreciate it but before posting this request we have been working in several solutions, and these 2 were among them.

Let me explain.

1.- This first option we discarded because it´s problematic for 2 things mainly:

a) Each VA must hear using a different port and all of our certificates issued until now point to the same port
b) We have old CAs that don´t issue certificates anymore, so we couldn´t response for those certificates. We upgraded our tree in february 2009 generating new CAs, so for the old ones we stil must give an answer.

2.- For the second option we need to develop some tasks to improve the product that allows to use a different OCSP signing certificate for every CA configured but this is also complicated, because:

a) This development is really difficult
b) Our current PKI product version does not allow to do this, so we will need a new version
c) The same than point B for the first solution, the old CAs.

So, even more, we have thought in 2 other options, like an alternative to the first one is to set up a new VA that only server the CA that issues the SSL certs and signed by this CA. This option is the one we´re working, it only affects the CA that issues the SSL EV certs but it only works with the certificates issued since then, the old ones won´t work but well, it´s a solution, of course I don´t like to create patches for a situation like this one.
The other option could be to re-certify our VA but instead of doing with our technical CA, so it with the SSL EV CA, but it will apply to many applications in the Government that again it´s not a good idea. 

So this is where we are and that´s why I´m asking for this change in the Firefox behaviour. I think it´s easiest for Mozilla than for me and even more, it will work the same than the rest of the browsers.
The spanish national Id (DNIe) will have the same problem, but maybe they fall in the root program down in a different way.

Thanks

Comment 5

[Jo Hermans]

(In reply to comment #2)
> Hi Jo,
> 
> I don´t get you. In this bug I´m requesting a change in the Firefox, in 361957
> I´m requesting to be accepted in the Mozilla root program.
> 
> Regards

You quoted the wrong number in comment 0

Comment 6

[Iñigo Barreira]

Oh, I see. Thank you

Comment 7

[Eddy Nigg (StartCom)]

(In reply to comment #4)
> So this is where we are and that´s why I´m asking for this change in the
> Firefox behaviour. I think it´s easiest for Mozilla than for me and even more,
> it will work the same than the rest of the browsers.

Realistically it probably will never happen, secondly you are very optimistic about how easy it is to change a specific behavior of Firefox affecting perhaps all CAs. :-)

But you are certainly free to propose and submitted patches in order to speed things up - no guaranty that they'll be accepted though. :-)

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Iñigo, you claim that your OCSP responses with signatures from signers whose
certs are neither
a) the issuing CA's cert, not 
b) issued by the issuing CA's cert
are accepted and "work" with IE and other browsers.

I suspect that the reality is that those other browsers simply are not 
making OCSP checks, or are ignoring the OCSP responses.  Of course, users
who want to operate that insecurely can configure Firefox to do so, and then
your certs will work as well for those Firefox users as they allegedly do 
for other browser users.  But Firefox is trying to take the "high road" and
lead in stronger security here.  

Nearly all other CAs have made their OCSP responders work in accordance with RFC 2560, and so they work with Firefox. That's the right answer for you, too.

Comment 9

[Eddy Nigg (StartCom)]

It's widely known that for example IE will try the CRL (if one exists) after a failed OCSP response. Obviously no browser can trust an arbitrary OCSP response, it could be just anything really.

Comment 10

[Iñigo Barreira]

Hi,

you´re assuming that we´re not working accordance to RFC2560 which is not true, and you´re suspecting the other browsers work incorrectly or not so secure, which is also not true.

The solution we have implemented is not "my" solution, some other CAs have the same solution, because dependign on the number of certs issued is easier to manage and configure.

I can configure a VA for every CA I run and manage but that is a nonsense, independently what RFC2560 says, when you run several CAs, not just one or two. Having a centralized VA solution for all the CAs is a much better solution than having a VA for each CA.

What I see is that Firefox or Mozilla is not aiming or intending to accept or modify its behaviour, well, it´s OK. Maybe, i´ll propose a change in the RFC2560.

About the IE behaviour, well, it´s one, but the same does Adobe for example and it´s not a browser.

Regards

Comment 11

[Erwann Abalea]

(In reply to comment #10)
> you´re assuming that we´re not working accordance to RFC2560 which is not true,

That's true, this OCSP responder is not RFC2560 compliant.

> and you´re suspecting the other browsers work incorrectly or not so secure,
> which is also not true.

IE gets OCSP responses and CRLs (and probably discards the bad OCSP response), Safari on Windows does the same (it uses the CAPI), Opera only gets the CRL for the intermediate CAs and OCSP response for end-entity certificate (so it doesn't run into this problem), Chrome does the same as IE and Safari on Windows (they use CAPI) and the same as Firefox on Linux.

I still have to check Safari and Chrome on MacOSX, but I already know that Safari complains when it gets a "try again later" OCSP response.

> The solution we have implemented is not "my" solution, some other CAs have the
> same solution, because dependign on the number of certs issued is easier to
> manage and configure.

No. Your solution relies on something to be done on end-user side (configuration). And for a large scale user base, this is not practical at all.

> I can configure a VA for every CA I run and manage but that is a nonsense,
> independently what RFC2560 says, when you run several CAs, not just one or two.

Why? We run several dozens of CAs, other providers do much more, and I don't know of any other similar situation as yours. If you can't have a separate VA for each CA, then at least sign OCSP replies by your online CAs, and generate separate VAs for your off-line CAs.

> Having a centralized VA solution for all the CAs is a much better solution than
> having a VA for each CA.

Except that is needs the client to be configured. In fact, you must tell the client to trust a totally external entity to provide revocation information for a CA. That's insane.

> What I see is that Firefox or Mozilla is not aiming or intending to accept or
> modify its behaviour, well, it´s OK. Maybe, i´ll propose a change in the
> RFC2560.

Better things need to be changed in RFC2560. But the requirement that a dedicated responder be directly signed by the same CA is a good thing.

> About the IE behaviour, well, it´s one, but the same does Adobe for example and
> it´s not a browser.

Have to check that also.

Comment 12

[Erwann Abalea]

(In reply to comment #11)
> (In reply to comment #10)
> > and you´re suspecting the other browsers work incorrectly or not so secure,
> > which is also not true.
> 
> IE gets OCSP responses and CRLs (and probably discards the bad OCSP response),
> Safari on Windows does the same (it uses the CAPI), Opera only gets the CRL for
> the intermediate CAs and OCSP response for end-entity certificate (so it
> doesn't run into this problem), Chrome does the same as IE and Safari on
> Windows (they use CAPI) and the same as Firefox on Linux.
> 
> I still have to check Safari and Chrome on MacOSX, but I already know that
> Safari complains when it gets a "try again later" OCSP response.

I did check several browsers on MacOSX this week-end (Snow Leopard, up to date).

Safari 5.0.1 complains, after having tested the "8094" OCSP responder, on both www.it-txartela.net and www.balmaseda.net. Chrome also (it uses the OS API).

Firefox 3.5.11 and 3.6.8 don't display any warning, they only check the lowest level OCSP (8094 also in the case of www.balmaseda.net), and don't download any CRL. Since I took a production version and manually added the Izenpe.com's root, it's not declared EV, and I think some checks are not performed at all.

Opera 10.60 does the same as under Windows, i.e. OK with EV green bar for www.it-txartela.net because it doesn't try to check the intermediate OCSP (prefers to download the CRL), and a little KO (unnoticeable for the end-user) for www.balmaseda.net, without the EV green bar (replaced by a question mark, which when clicked tells the user that this website is not secure), probably because of the bad OCSP responder... I got the exact same behaviour with 2 other websites, again with 2 bad OCSP responses, one to check the intermediate CA (a "try again later"), one to check the website's certificate (an HTTP 403).

Comment 13

[Iñigo Barreira]

Hi

I´d like to let you know that we´ve been changing our infrastructure for the EV sites in order to meet the Mozilla requirements and also to improve our responses. The changes are these:

-	OCSP port has changed to 80
-	VA is signed by the EV issuing CA
-	Also adapted the profiles with the recent changes approved in the CABF although they´re not “live”.

OIDs remains the same and I can provide you with 2 sites for checking. Please let me know if you encounter any problem

EV (OID 1.3.6.1.4.1.14777.6.1.1)  https://servicios.izenpe.com
Sede EV (OID 1.3.6.1.4.1.14777.6.1.2) https://servicios1.izenpe.com

TIA

Comment 14

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Marking as INVALID since this isn't a bug, because the CA making the request wouldn't benefit from the change (if I am understanding comment 13), and because it seems like a bad idea. If I am misunderstanding things, please reopen.