On 4/13/13 8:56 PM, "Piyush Jain" <piyush(_at_)ditenity(_dot_)com> wrote:
[Piyush] From an RP's perspective finding status of serial numbers
serves no purpose unless they can associate that serial number with a
certificate.
Absolutely, that is the client's perspective of this.
Great. We agree
When an OCSP client extracts the serial number from a certificate and
sends it the responder to determine the status, it is acting under a
very important assumption - the CA has issued that certificate and that
it has issued only one certificate with that serial.
Absolutely
Great. We agree.
Let me reiterate -OCSP client extracts the serial number assuming that the
CA issued the certificate and issued only one certificate with that serial
number. So why do we need the responder to return non-issued for the same
certificate?
Because of your lack of fantasy :)
Shift your focus from the client to the server.
A client have control over never asking for a non-issued certificate,
unless the CA is broken.
The server have not.
A bad, broken or malicious client may for what ever reason it may have,
send a request for a non-issued certificate.
If that happens, the protocol should allows ways to handle that.
Just imagine a such benign situation of a client with a bug, that sends
the wrong serial number if the most significant bit is set.
For half of it's requests it sends requests for completely non existent
certs.
Perhaps not likely, but possible.
The chance of discovering this error increase significantly if the
non-issued serial number requests returns "revoked" instead of "good".
This just on top of the case of a broken CA.
If you say that this assumption is invalid, your trichotomy of serial
status is not mutually exclusive any more. Same serial can now be
associated with a good, revoked and non-issued status.
I didn't say that. I said it can "only be good, revoked or non-issued"
Notice the difference? My sentence contains the word "or", yours the
word
"and".
I stand by my words :).
Feel free. But saying a million times that a black stone is white, does
not change its colour.
These are the three possible states of a serial number. It must always
be
in
ONE of these states.
As long as you assume that a certificate signed by the CA cannot be
non-issued i.e. CA knows what certificates it issued.
If you break that assumption, you have to deal with the possibility of
different certificates with same serial numbers (after all certificates
are
getting issued without CA's knowledge). This implies that the same serial
number can be associated with a good certificate and a non-issued
certificate.
Let me frame it in a different way. If you get a "good" response from a
responder that issues "revoked" for "non-issued", can you be sure that the
certificate you are checking is not a non-issued certificate?
No, to take it to that level, you need a new white list extension.
You see this from the wrong angle.
This change is not intended to provide the client indisputable knowledge
about whether a certificate is non-issued or not.
It is intended to give the responder a means of causing the client to
reject rather than accept something that is known not to be good.
And also the client cannot be sure if
the CA delegated responder's certificate is good or non-issued. This
renders OCSP completely useless.
I did not talk about responder certificates.
You did not. But that does not make my statement any less relevant or
incorrect and strengthens Henry's point about this spec achieving what it
is
trying to do.
It makes your statement totally irrelevant until the point where you can
demonstrate its relevance.
/Stefan