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

RESOLVED FIXED in 3.10

Status

NSS
Libraries
P2
normal
RESOLVED FIXED
14 years ago
12 years ago

People

(Reporter: Nelson Bolyard (seldom reads bugmail), Assigned: Nelson Bolyard (seldom reads bugmail))

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
(Assignee)

Comment 2

14 years ago
Julien, what do you think of this proposal?  (Feel free to review the patch :)
Status: NEW → ASSIGNED

Comment 3

14 years ago
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 ?
(Assignee)

Comment 4

14 years ago
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.  
(Assignee)

Comment 5

14 years ago
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?
(Assignee)

Updated

14 years ago
Attachment #146065 - Flags: review?(rrelyea0264)
(Assignee)

Comment 6

14 years ago
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 7

14 years ago
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 8

14 years ago
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+
(Assignee)

Comment 9

14 years ago
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
(Assignee)

Updated

14 years ago
Whiteboard: awaiting checkin
(Assignee)

Comment 10

14 years ago
/cvsroot/mozilla/security/nss/lib/certdb/certdb.c,v  <--  certdb.c
new revision: 1.70; previous revision: 1.69

Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Whiteboard: awaiting checkin
(Assignee)

Comment 11

12 years ago
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.
(Assignee)

Updated

12 years ago
Blocks: 217721
You need to log in before you can comment on or make changes to this bug.