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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/13/13 2:53 AM, "Henry B. Hotz" <hotz@xxxxxxxxxxxx> wrote:

>You've just said that there are only two valid responses from an OCSP
>server which has access to a white list.  In other words such a server
>inherently cannot provide any information about the actual revocation
>status of a cert, and its responses cannot distinguish between a
>lost/forged/whatever cert and a known-bad (actually revoked) cert.

I realize it's unfair of me to take this quote out of context.  Apologies,
but I want to focus on it. (Stole your words :))


No that is NOT what I say.

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.

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

The legacy client will just look at the status and act accordingly. The
extension aware client and a later audit can use the extensions to further
determine what happened.

/Stefan






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]