Closed Bug 91401 Opened 23 years ago Closed 10 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

(Blocks 1 open bug)

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: 10 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.