Closed Bug 91401 Opened 24 years ago Closed 11 years ago

OCSP's Response Signer confusing

Categories

(Core Graveyard :: Security: UI, defect, P2)

Product:
Core Graveyard
Component:
Security: UI
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: thomask, Unassigned)

References

Details

(Whiteboard: [kerh-coz])

Is this "Response Signer" really necessary, and PSM has to have it to make validation decision? If not, we should delete it, because there is no easy way to import an OCSP signer certificate into the browser. (We can use certutil, or treat the OCSP signer certificate as a CA certificate and import. But these hack is not user-friendly enough). I have customers who are asking what it is.
P2 t->future. ->javi Thomas, can you elaborate a little here? I assume you're talking about pref->privacy and security->validation dialog. I believe we want to be able to let user specify a specific URL for response signer.
Assignee: ssaux → javi
Priority: -- → P2
Target Milestone: --- → Future
Let me explain a bit more here. We can currently configure our OCSP feature in PSM in 3 different ways (under Pref->Privacy->Validation). 1) No OCSP 2) OCSP with AIA extension in the certificate. The extension indicates the location of the OCSP server 3) Use a hardcore location of the OCSP server 1) is not that interesting. We are doing very well in 2). But for option 3), we requires the URL to the OCSP server **AND** the OCSP signer's certificate. I do not know why we need the OCSP server certificate in the database. We do not need that for option 2. If we can get rid of the the OCSP signer certificate option and just requires the URL to the OCSP server. It will make the UI simpler. Also, there is no standard way to get a OCSP server certificate into PSM. PSM can get CA certificate, but not OCSP server certificate.
The reason we need the OCSP responder to be in the cert db is because PSM needs to know who the default responder is. A CA can make this option more deployable by including the AIA extension in it's root at which point it will bubble up to the top of the list and pre-fill in the URL if the 3rd option is chosen. An OCSP responder is installed into the cert db just like any other CA. The fact that most OCSP services don't forward requests about certs they don't know about has been the limiting factor in making the 3rd scenario deployable. :(
But I thought the OCSP responder certificate will be sent to the client as part of the OCSP response. So do we really need to store it?
Yeah, but the default responder mode (ie option 3) says, "The following responder will respond to *all* of my OCSP requests." That's why we need it. Otherwise, option 2 would suffice.
But the real question is why do we need to OCSP server certificate? The URL should be the sufficient information to lead to the server. The client can send all the OCSP requests to the server that is indicated by just the URL. The server then returns the OCSP response to the client. The OCSP response will include the OCSP server certificate. So in this picture, why do we need to store the OCSP server certificate, or why do we need to prompt for it? In option 3, the current message is ?The following responder will respond to *all* of my OCSP requests.? My interpration of the above message is the client will send all its OCSP requests to the OCSP server listed below. Now, my point is that we can identify the OCSP server by just its URL. Once the client has the URL, it can forward all its OCSP requests to the server. What role does the "selected" OCSP server certificate play? Maybe I am not totally understand the option 3. :(
How do we know to trust the certificate that was sent back in your scenario for case 3? That becomes a much harder problem with a new trust chain to implement. :( "The following responder will respond to *all* of my OCSP requests." should say "The following responder will respond and sign all responses to my OCSP request." To change this, will require many NSS changes.
In most cases, the OCSP server certificate is signed by a Certificate authority. We should trust the OCSP server certificate if the CA that signs the certificate is trusted. I guess what you talk about is direct trust on the OCSP server certificate, which is sometime we should support also. In that case, we can just the OCSP server certificate as a CA certificate (because it signs itself, siging is an operation done by CA, so it is ok to put it under CA I guess). So in summary, my suggestion is as follows: 1) remove the extra OCSP signer certificate listbox in option 3 2) keep the URL textbox in option 3 because PSM need to know the location of the server My thought is that, in real-life deployement, company has setup a CA, and a OCSP server. The OCSP server certificate will be signed by the CA. So for client, it should only requires the CA certificate in the browser. No more, no less. More certificates for end-user to manage is just not a good idea.
Your suggestions require many changes to NSS :(
The reason for supplying the OCSP signing certificate is to verify that the signed OCSP response matches the expected signature. Verifying the RSC (response signing certificate) against a known value is a very common practice. The majority of CP / CPS' that I have written require this verification. Without the check you would not know if the OCSP responders' certificate has been revoked, unless the PSM can "walk the chain" and check all certs (via OCSP or LDAP CRL pull)in the target certs chain. I agree with Thomas that giving more certificates for an End User to manage is not the most desirable option. Could a check box be utilized to optionally match the Response Signing Certificate? There is no easy way to get an RSC into the PSM. In order to import an RSC into the PSM, the RSC: 1. Needs to be self-signed 2. Needs the OCSP Response Signing extended key usage Having the OCSP responder issue it's own RSC is allowable per the RFC, but is rarely implemented this way. The strong majority of implementations require that the Root CA or a level 1 sub CA sign the responders certs. The OCSP Response Signing eku is either a critical or non-critical extension. If it was always critical, the PSM could justify requiring it. Since it can be implemented as non-critical I feel that the PSM should not require it. It would be nice if there were an easier way to import a responders certificate into the PSM. Sorry for the ramblings :) -Chris
Mass assigning QA to ckritzer.
QA Contact: junruh → ckritzer
Marking nEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS > all
OS: Windows 2000 → All
QA Contact: ckritzer → junruh
Hardware: PC → All
Version: 2.0 → 2.1
Blocks: 157555
Mass reassign Javi's old PSM bugs to nobody
Assignee: javi → nobody
QA Contact: junruh → nobody
Target Milestone: Future → ---
Product: PSM → Core
Whiteboard: [kerh-coz]
QA Contact: nobody → ui
Version: psm2.1 → 1.0 Branch
having touched other bugs here, i agree w/ thomas k. the ui here is bad.... i heard that nss got a major upgrade recently that enabled web walking instead of simple chain walking.... is it really impossible for NSS to talk to an OCSP server and figure out if we can trust it to any CA we have? If that's possible, then we could simplify this ui by removing all CAs that don't offer AIA (resolving some other bug I touched earlier), and splitting the AIA <select> from the url input.
Version: 1.0 Branch → Trunk
As of bug 531067, we don't support default OCSP responders.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.