On Apr 13, 2013, at 4:24 PM, Stefan Santesson <stefan(_at_)aaa-sec(_dot_)com>
wrote:
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.
Disagree.
The protocol is intended to provide information ("Status") about an identified
cert (or serial number if you prefer) so an RP can make the best decision
possible about how to treat it within the scope if its own application. That
means that the OCSP responder SHOULD NOT (IMO) conceal the distinction between
non-issued and good, nor should it conceal the distinction between non-issued
and revoked (for exactly the same reason). Doing either one of those
effectively prevents the information from one of the white- or black-lists from
contributing to OCSP responses.
I don't think it's safe in the first place to assume we know what all the
current clients do or want. I likewise don't think it's safe to assume we know
what they will do, should do, or want in the future. It may be clear how to
handle a white-listed or black-listed cert. However, I can think of several
different scenarios for how a non-issued cert ought to be handled. All of that
is outside the scope of OCSPs perview.
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.
I likewise haven't' addressed responder cert's as a special case. :-/
I need to study the spec more carefully. IIUC Martin seems to imply that you
can infer if a cert is white-list/black-list/neither based on new extensions,
if enough of them are present. IIUC Stefan seems to imply the opposite, though
the extensions should tell you where the ambiguity is. My read supported the
latter, but I don't want to stake my reputation on it.
------------------------
Assuming what Stefan implies, would people be happy if we updated the
abstract/introduction to say that a "new" OCSP response, combined with the CRL
would allow an RP to infer which of the three status's a cert has?
When I opposed this draft, I had not yet thought of this combination of
protocols. I see the combination as unnecessarily high-overhead, but a step
forward.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(_dot_)B(_dot_)Hotz(_at_)jpl(_dot_)nasa(_dot_)gov, or
hbhotz(_at_)oxy(_dot_)edu