Closed Bug 240456 Opened 20 years ago Closed 20 years ago

OCSP fails if responder's cert key usage is non-repudiation only

Categories

(NSS :: Libraries, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nelson, Assigned: nelson)

References

Details

Attachments

(1 file)

For OCSP responders, NSS requires the responder's cert to have 
DigitalSignature key usage.

But the German ISIS-MTT PKI profile document, 
http://www.teletrust.de/Dokumente%5CISIS-MTT_Core_Specification_v1.1.pdf 
says in part 1, table 12, note 1, on pages 17-18:

"OCSP responders are issued end-entity certificates with only the
nonRepudiation bit set and including the ExtendedKeyUsage extension
with only the id-kp-OCSPSigning option (see Table 21)." 

Consequently, when NSS attempts to check the response from one of these 
German OCSP responders, it concludes the responder's cert has inadequate
key usage.  

I propose to change the code that checks this so that a cert with 
nonRepudiation key usage will always be acceptable when NSS thinks a
DigitalSignature usage is required.  I will shortly attach a patch that
effects this change.  

Any objections to this plan should be added to this bug ASAP.
Attached patch patch v1Splinter Review
Julien, what do you think of this proposal?  (Feel free to review the patch :)
Status: NEW → ASSIGNED
Nelson,

Why does requiredUsage have both KU_NON_REPUDIATION and KU_DIGITAL_SIGNATURE
bits set ? Shouldn't this be fixed in the caller of CERT_CheckKeyUsage ?
Julien,  
Sorry, I don't understand your question in comment 3, so here's some more info.

CERT_KeyUsageAndTypeForCertUsage gets called to ask "what is the required 
key usage and extended key usage (a.k.a. cert type) for an OCSP responder
(not CA) cert?"  It sets 

          case certUsageStatusResponder:
            requiredKeyUsage = KU_DIGITAL_SIGNATURE;
            requiredCertType = EXT_KEY_USAGE_STATUS_RESPONDER;
            break;

Then CERT_CheckKeyUsage gets called with a pointer to the OCSP responder's
cert and requiredUsage, which is the value KU_DIGITAL_SIGNATURE, due to 
the code above.  But the cert's keyUsage is the value KU_NON_REPUDIATION,
not KU_DIGITAL_SIGNATURE.  So, CERT_CheckKeyUsage sets error
SEC_ERROR_INADEQUATE_KEY_USAGE.  

Another way to fix this might be to create a new KU value named
KU_DIGITAL_SIGNATURE_OR_NON_REPUDIATION, and set that value in the OCSP 
case in CERT_KeyUsageAndTypeForCertUsage(), and implement it in
CERT_CheckKeyUsage as a special case, similar to the way that
KU_KEY_AGREEMENT_OR_ENCIPHERMENT is now implemented in CERT_CheckKeyUsage.

But that's a lot more work, and UNLESS there is some case where the cert
really MUST be DIGITAL_SIGNATURE and must NOT instead be KU_NON_REPUDIATION,
I'd rather just take the route shown in the patch.  
It has been observed that RFC 2560 requires an OCSP responder's cert to 
contain the extended key usage, but makes no requirement on key usage.
So, by requiring DigitalSignature keyUsage, NSS is requirement more than 
the RFC does.  

So, Yet another way to address this is to change the above quoted code so
that NSS requires ONLY the extended key usage and not the key usage.  
The change would be:

-            requiredKeyUsage = KU_DIGITAL_SIGNATURE;
+            requiredKeyUsage = 0;

I think that solution is less desirable than the one in my patch.  Comments?
Attachment #146065 - Flags: review?(rrelyea0264)
Comment on attachment 146065 [details] [diff] [review]
patch v1

I have verified that this patch solves the problem described in the original
bug report above.  I verified it using a signed message received from an
affected individual.
Attachment #146065 - Flags: review?(rrelyea0264) → review?(wchang0222)
Comment on attachment 146065 [details] [diff] [review]
patch v1

r=wtc.

This change has two effects.

1. It means KU_NON_REPUDIATION implies KU_DIGITAL_SIGNATURE.
I think this is correct, but I'd like Bob or Terry to confirm
this.

2. This change applies to not only OCSP responder cert but
also SSL client cert, email signing cert, and object signing
cert.
Attachment #146065 - Flags: superreview?(rrelyea0264)
Attachment #146065 - Flags: review?(wchang0222)
Attachment #146065 - Flags: review+
Comment on attachment 146065 [details] [diff] [review]
patch v1

1. I can't think of a case where KU_NON_REPUDIATION shouldn't also imply
KU_DIGITAL_SIGNATURE so the patch is safe.

2. because of certain international specs, certain cert should have
KU_NON_REPUDIATION without signature even though the certs are signature certs,
therefore the patch is desirable.
Attachment #146065 - Flags: superreview?(rrelyea0264) → superreview+
Putting on the NSS 3.10 radar screen.  This bug has a patch that is r+ and sr+,
so I intend to check it in very soon, barring any objections.
Priority: -- → P2
Target Milestone: --- → 3.10
Whiteboard: awaiting checkin
/cvsroot/mozilla/security/nss/lib/certdb/certdb.c,v  <--  certdb.c
new revision: 1.70; previous revision: 1.69

Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Whiteboard: awaiting checkin
I believe the fix for this bug (which is in NSS 3.10) also fixes bug 217721,
which is a PSM bug.  If that is confirmed, I will mark that bug as a duplicate
of this one.
Blocks: 217721
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: