On Apr 13, 2013, at 4:24 PM, Stefan Santesson <stefan@xxxxxxxxxxx> 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.B.Hotz@xxxxxxxxxxxx, or hbhotz@xxxxxxx