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]

 



Nothing has changed in this regard.

The good response is pretty clear that it by default provides information
that the cert is not on a black-list (is not know to be revoked).
However, it is also made clear that extensions may be used to expand this
default information about the status.

This is how it always have been, and still is in RFC 256bis.

The revoked response simply means that the certificate is revoked.
Combined with the new extension, it MAY also be used for non-issued certs.

It's really as simple as that.

It is only the discussion on this list that is confusing and that has
managed turn something really simple into a complicated debate.

/Stefan


On 4/8/13 9:35 PM, "Henry B. Hotz" <hotz@xxxxxxxxxxxx> wrote:

>Actually, what I get from this and all the other discussions is that it's
>unclear if the updated OCSP satisfies the "suitability for the intended
>purpose" test.  Or at least it fails the KISS principle w.r.t. that.
>
>Rephrasing:  an OCSP client should be able to tell from an OCSP response
>if:  a) the subject cert is on the CAs white list, b) the subject cert is
>on the CAs black list, c) the subject cert is not on either list, or
>finally d) the OCSP server is obsolete, and doesn't support making those
>distinctions.  It's not trivial to see how to parse 2560bis responses
>w.r.t. those cases, therefore it's highly likely that computational
>complexity will prevent us from doing so.  Even if that's not actually
>the case, then implementor misunderstandings will prevent us from doing
>so in practice.
>
>Therefore I vote against moving this draft forward.  I just don't see the
>point.
>
>If someone were to write an informational RFC which explained how to
>determine which of the 4 cases an OCSP response fell into, AND if said
>RFC also convinced me that the decision process was easy to understand,
>THEN I would change my vote.  Obviously an appendix in 2560bis would
>serve just as well.
>_______________________________________________
>pkix mailing list
>pkix@xxxxxxxx
>https://www.ietf.org/mailman/listinfo/pkix






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