378673 - OCSP signature verification does not allow intermediates

Status: RESOLVED INVALID

(NSS :: Libraries, defect)

Description

[Kai Engert [:KaiE:]]

Given the following certs (common names):

(A) root: Certum CA
(B) intermediate: Certum Level IV
(C) server: *.certum.pl
(D) OCSP signer: Certum Validation Service

with the following hierachy:

A
|-B
| |-C
|
|-D

When connecting to a server using (C) 
and talking to the OCSP responder listed in (C), 
the response we get is signed by (D),

and NSS fails with error code:
SEC_ERROR_OCSP_UNAUTHORIZED_RESPONSE.

I looked at function ocsp_AuthorizedResponderForCertID.

NSS is very strict.
It requires that (C) and (D) have been issued by the same cert,
which is not true in this case.


In other words, when NSS tries to verify a leaf cert using OCSP, it requires both the leaf cert and the responder's signer cert have been *directly* issued by the same root, it does not allow intermediates.

Is this a bug or intended behaviour?


Is this a bug in NSS?

Comment 1

[Alexei Volkov]

Kai, section 4.2.2.2(Authorized Responders) of rfc 2560 sais:
  (clients) MUST reject the
   response if the certificate required to validate the signature on the
   response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

In your case the response would be valid if it would be signed by authorized responder cert issued by CA B. But not CA A.

I think bug is invalid.

Comment 2

[Michal Proszkiewicz]

(In reply to comment #1)
> Kai, section 4.2.2.2(Authorized Responders) of rfc 2560 sais:
>   (clients) MUST reject the
>    response if the certificate required to validate the signature on the
>    response fails to meet at least one of the following criteria:
>    [...]
> 
> In your case the response would be valid if it would be signed by authorized
> responder cert issued by CA B. But not CA A.
> 
> I think bug is invalid.
> 

RFC 2560 section 2.2, one can read:

2.2  Response

   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requester
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, indicating
      that the responder may issue OCSP responses for that CA

Please, bear in mind that Trusted Responder variant is adequate to Certum VS key. I mean, Certum VS similar to Certum Level IV inherits trust directly from Certum CA - a NSS valid and built-in object. So, in my opnion that is why it SHALL always be trusted by the requester and responses not rejected.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

A trusted responder is a responder that the requester has directly trusted. 
It doesn't inherit trust from other CAs.  
The requester (browser user) says "This is my trusted responder".  
NSS supports that.  
Some mozilla client products provide UI to configure a trusted responder.

So, if the browser user wants to directly trust a certain responder,
he can do that, and then it doesn't matter who signed that responder's
cert, because the user trusts it directly, much like the way that a user
may trust a root CA cert. 

I agree with Julien.  I think this bug is invalid.

Comment 4

[Wojtek Slusarczyk]

(In reply to comment #3)

> A trusted responder is a responder that the requester has directly trusted. 
> It doesn't inherit trust from other CAs.  

According to RFC 2560 a trusted responder is only a responder: "whose public key is trusted by the requester"... nothing else. We do not know if that key is signed by other CA or just selfsigned, there is not the word "directly" either. Trusted root CA - with its own Certification Policy, Certification Practice Statement, repository, etc. is a different story than simple OCSP trusted responder, I am sure.

> The requester (browser user) says "This is my trusted responder".  
> NSS supports that.  

It is a good way to support trusted responder mode, but IMHO certificates with URI (ext. AuthorityInformationAccess) should be verified automatically in that way too.

/WS

Comment 5

[Julien Pierre]

Nelson,

Actually, it was Alexei who made the statement about it being invalid. I haven't looked at this issue closely yet.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 4,
> According to RFC 2560 a trusted responder is only a responder: 
> "whose public key is trusted by the requester".

Right.  And "trusted by the requester" is NOT the same thing as 
"is in a certificate verifiable with the cert from some other CA that
is trusted by the user."  

Think about it.  If the intent of RFC 2560 had been to allow OCSP 
responses from any OCSP responder whose cert comes from ANY trusted CA,
then the RFC would not have contained this specific provision:

   2. Is the certificate of the CA that issued the certificate in
   question; or

That provision is there specifically to limit the set of CAs whose 
signatures may server to qualify the OCSP responder to the one CA
that issued the cert being tested.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Attachment: Certum's OCSP responder cert

Here is a copy of the DER cert with which Certum's OCSP responder signs its 
responses.  It is a self-signed binary X.509 v3 EE cert (not a CA cert).
I'm attaching it here to facilitate people playing with this as an 
explicitly trusted OCSP responder cert.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 420496 [details]
Certum's OCSP responder cert

My previous statement about this cert was mistaken.  It is not self-signed.  
Here is some info from the cert.

     Version: 3 (0x2)
     Serial Number: 293462 (0x47a56)
     Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
     Issuer: "CN=Certum CA,O=Unizeto Sp. z o.o.,C=PL"
     Validity:
         Not Before: Tue Mar 03 13:02:56 2009
         Not After : Sun Mar 03 13:02:56 2024
     Subject: "CN=Certum Validation Authority,OU=Certum Certification Auth
         ority,O=Unizeto Technologies S.A.,C=PL"

Comment 9

[Michal Proszkiewicz]

FYI last weekend we changed our OCSP service, it's no longer in trusted responder  mode and is working fine with FF.