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)
Tracking
(Not tracked)
RESOLVED
FIXED
3.10
People
(Reporter: nelson, Assigned: nelson)
References
Details
Attachments
(1 file)
956 bytes,
patch
|
wtc
:
review+
rrelyea
:
superreview+
|
Details | Diff | Splinter Review |
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 1•20 years ago
|
||
Assignee | ||
Comment 2•20 years ago
|
||
Julien, what do you think of this proposal? (Feel free to review the patch :)
Status: NEW → ASSIGNED
Comment 3•20 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•20 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•20 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•20 years ago
|
Attachment #146065 -
Flags: review?(rrelyea0264)
Assignee | ||
Comment 6•20 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•20 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•20 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•20 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•20 years ago
|
Whiteboard: awaiting checkin
Assignee | ||
Comment 10•20 years ago
|
||
/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
Assignee | ||
Comment 11•19 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.
You need to log in
before you can comment on or make changes to this bug.
Description
•