58507 - OCSP requires the CA to have extendedKeyUsage extensions

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[Javier Delgadillo]

When testing OCSP, thomask found out that NSS requires the CA to have the 
extendedKeyUsage bit for OCSP responder even if the signer is the issuer of the 
cert in question.  This goes against the spec and should be fixed.

Subject: 
            Re: PSM
       Date: 
            Mon, 30 Oct 2000 13:36:53 -0800
      From: 
            [e-mail] (Javier Delgadillo)      Internal
        To: 
            Thomas Kwan <[e-mail]>
 References: 
            1 , 2 , 3




                                                                          
Invalid
                                                                        
Signature



You're right.  NSS requires the CA have the extendedKeyUsage bit set even if 
it's the issuing cert for the
cert in question. 

File a bug against NSS in bugzilla. 
  
  

Thomas Kwan wrote: 

  Sorry, the URL for the OCSP server is http://192.18.121.247:80/ocsp 

  Javier Delgadillo wrote: 

    What responder am I supposed to talk to?  The cert doesn't have the AIA 
extension. 

    Thomas Kwan wrote: 

     Hi Javier, 

     Last week, Brian, you and me was looking at the OCSP problem where we 
forgot to put the
     extendedKeyUsage extension 
     in the OCSP certificate, and PSm returned "....unknown problem". 

     I just setup a standalone CA and its OCSP signing certificate is its Ca 
siging certificate. I just
     looked at the OCSP spec., 
     and seems like we do not need the extendedKeyUsage extension in the CA 
certificate if the OCSP
     signing certificate 
     is actually the CA certificate. But I am getting the same error from PSM 
"... unknown problem". 

     I wonder if you can help me to try this out: 

     My CA is in http://192.18.121.247:80, use the directory-based enrollment 
with "thomask", and
     "netscape" to get 
     a user certificate. 

     The OCSP server is running in http://192.18.121.247:80 

     thanks a lot 
     Thomas

    -- 
    Javier Delgadillo 
    iPlanet a SUN / Netscape Alliance 
    [phone] 
    http://people.netscape.com/javi

Comment 1

[Wan-Teh Chang]

Is this easy to fix?  Terry, could you take a
look at this bug?  Thanks.

Comment 2

[Wan-Teh Chang]

Assigned the bug to Bob for triage.

Comment 3

[Wan-Teh Chang]

Changed the QA contact to Bishakha.

Comment 4

[Wan-Teh Chang]

Moved to NSS 3.6.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

I don't think we can turn OCSP on by default again until this is fixed.

Comment 6

[Kai Engert [:KaiE:]]

Is this bug already fixed?

I can see our OCSP code calls CERT_VerifyCert asking for usage certUsageStatusResponder.

We require that the OCSP signing cert has KU_KEY_CERT_SIGN and its type is
NS_CERT_TYPE_OBJECT_SIGNING_CA | NS_CERT_TYPE_EMAIL_CA | NS_CERT_TYPE_SSL_CA

If true, it will test whether the signing cert already has a direct trust.

          case certUsageStatusResponder:
            flags = cert->trust->sslFlags;
            /* is the cert directly trusted or not trusted ? */
            if ( ( flags & ( CERTDB_VALID_CA | CERTDB_TRUSTED_CA ) ) ==
                ( CERTDB_VALID_CA | CERTDB_TRUSTED_CA ) ) {
                goto winner;
            }
            flags = cert->trust->emailFlags;
            /* is the cert directly trusted or not trusted ? */
            if ( ( flags & ( CERTDB_VALID_CA | CERTDB_TRUSTED_CA ) ) ==
                ( CERTDB_VALID_CA | CERTDB_TRUSTED_CA ) ) {
                goto winner;
            }
            flags = cert->trust->objectSigningFlags;
            /* is the cert directly trusted or not trusted ? */
            if ( ( flags & ( CERTDB_VALID_CA | CERTDB_TRUSTED_CA ) ) ==
                ( CERTDB_VALID_CA | CERTDB_TRUSTED_CA ) ) {
                goto winner;
            }

I think in the mentioned scenario, that direct trust will be present?

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

This bug appears to be a reference to the code in ocsp_CertIsOCSPSigner() 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/certhigh/ocsp.c&rev=1.29#2433
Doesn't look fixed to me.

See also bug 338986 comment 3 for an issue that is related, or perhaps even
the same issue described in more depth.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Kai, please see my response to your question in the preceeding comment.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

I think the patch for bug 338986 fixes this problem.  I'm reluctant to mark
this old bug as a duplicate of a much newer one, so I'll mark the new one 
as blocking this old one, and assign this old bug to Alexei (who is working
on bug 338986).  Alexei can mark this bug resolved/fixed when bug 338986 is
marked that way.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Changing target to 3.11.6

Comment 11

[Alexei Volkov]

fixed as a part of the fix for bug 338986