ietf
[Top] [All Lists]

Re: [pkix] Last Call: <draft-ietf-pkix-rfc2560bis-15.txt> (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

2013-04-13 12:36:02


On 4/13/13 6:51 PM, "Piyush Jain" <piyush(_at_)ditenity(_dot_)com> wrote:


An extension may differentiate which serial number that results in a
"revoked" response, that is actually issued and revoked, or if there is
any
other particular reason for responding "revoked".
In my universe a syntactically valid serial number can only be good,
revoked
or non-issued. But expressing this in general terms anyway.

[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.

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

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".

These are the three possible states of a serial number. It must always be
in ONE of these states.

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.




So with the help of extensions, a responder can provide both white and
black
list data.

[Piyush] May be you are right. But I doubt that you want a discussion on
feasibility/security implications of this, otherwise it would've been a
stated goal of 2560bis and would have been captured in the abstract.

If new extensions are defined, then the RFC defining these extensions will
discuss relevant security implications related to those extensions.

I tried to think ahead but I cannot figure out a way to communicate the
white listed status of a CA delegated responder to the client without
avoiding circular logic.

I can.

The "good" response provides by default a minimum level of positive
confirmation.
But it is also make clear that an extensions allows "good" to say more, as
long as it fits within that default statement of "good".

A white list falls within that basic statement.
That is, the serial numbers that will return "good" in a "white-list"
scenario would also return "good" if the responder provided default OCSP
status information.
White listing will simply reduce the number of "good" status to occasions
where it represent a known existing certificate.




I completely fail to see why revoked for non-issued is a pre-requisite for
future extensions that can be used to provide white-list data (if it is
even
possible under CA delegated responder trust model).

I'll try again. It is only possible to reduce the "good" status responses
to white listed certificates if another suitable status can be return for
any other requested serial number.
That is, the combined set of revoked and non-issued serial numbers that
does not belong in the while list.

Responding "unknown" may not be desirable, as it is likely to cause the
client to try another source.

With the update of RFC2560bis it is now being made clear (in the
definition of "revoked"), that it is conformant to respond "revoked" to
both revoked and "non-issued" certificates, while before, that could be
questioned as a stretch of semantics.

So yes indeed, the updates makes it easy to take the next step into a
white-list OCSP responder by adding a suitable extension.
Of course, only those understanding the new extension will know that it is
a "white list" response.

/Stefan


<Prev in Thread] Current Thread [Next in Thread>