Rich,

There is indeed a solution which uses the current text of RFC 2560, without the need to tweak any current meaning
of "good", "revoked" or "unknown".

The solution allows all current OCSP clients (if they comply with RFC 2560) to reject the target certificate.

The solution allows "new" OCSP clients, compliant of the solution, to know that a white list of certificates
has been used by the OCSP server and that the target serial number is unknown in that list.

In order to provide everybody with the opportunity to find the solution by himself, I will post additional  information
a little bit later in another post, as a reply to Henry B. Hotz.



Denis



De :        "Rich Smith" <richard.smith <at> comodo.com>
A :        "'David A. Cooper'" <david.cooper <at> nist.gov>, "'pkix'" <pkix <at> ietf.org>
Date :        15/08/2012 23:29
Objet :        Re: [pkix] Use of the OSCP unknown response
Envoyé par :        pkix-bounces <at> ietf.org



Whether you call the responses Good, Revoked and Unknown, OR; A, B and C,
OR; Alice, Bob and Charlie, the RFC is logically flawed in that Good, by
containing, "...but does not necessarily mean that the certificate was ever
issued..." overlaps status Unknown.  As long as that is the case
implementations will be flawed and confused.

And since the response is in fact called 'Good' and not 'A', and not
'Alice', a response of 'Good' for an unissued certificate may not, as Rob
has pointed out, misrepresent the truth as per the definition provided in
the RFC, but it most certainly does misrepresent the truth in terms of what
most people understand the word and concept of 'Good' to mean.

--
Regards,
Rich Smith
Validation Manager
Comodo
http://www.comodo.com
 



> -----Original Message-----
> From: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] On Behalf Of
> David A. Cooper
> Sent: Wednesday, August 15, 2012 4:03 PM
> To: pkix
> Subject: Re: [pkix] Use of the OSCP unknown response
>
>
> > I'm oversimplifying, but basically there are only ever two responses
> > that a responder can give:  if it has a CRL it can say "revoked" or
> > "unknown" (IMO it would be bad practice to say "good", though the
> > current spec implies you should say "good" instead of "unknown").  If
> > it has a white-list, it can say "good" or "unknown".  (While the spec
> > might allow it, I think it would be silly to respond "good" for a
> cert
> > not on the white list.
>
> By this logic, the only response a responder can give is "unknown,"
> unless the request includes a (yet to be defined) extension that
> includes a copy of the certificate or a hash of the certificate. Since
> the request only includes hashes of the issuer's name and public key
> and the serial number of the certificate, even if the responder has a
> white list, the responder cannot know whether the requester is
> referring to the certificate on the white list or to a different
> certificate that just happens to have the same issuer name and serial
> number, and that has been signed by the same key (or that at least
> appears to have been signed by the same key).  So, I guess that until a
> new request extension has been defined it would be "silly" for a
> responder to ever give a response other than "unknown."
>
> > The only way I see to justify three responses is if the responder has
> both a black and a white list.
>
> It is very easy to justify three responses as long as you accept that
> OCSP is a certificate status responder and not a validation server.  A
> response from an OCSP responder, by itself, it useless. The OCSP
> response only serves to help perform Step (a)(3) in Section 6.1.3 of
> the path validation algorithm in RFC 5280 (i.e., verify that the
> certificate is not revoked).
>
> Since the labels that are assigned to the three possible responses from
> the OCSP responder seem to object to the use of one particular response
> in the case of a certificate that has not been revoked, but for which
> the responder does not have sufficient information to ensure was
> issued, let's refer to the responses as (A), (B), and (C).
>
> 1.  A response of (A) indicates that the responder knows that the
> specified certificate has not been revoked (whether it was ever issued
> or not).  This means that the certificate satisfies the condition
> specified in Step (a)(3) in Section 6.1.3 of the path validation
> algorithm (i.e., it is not revoked).
>
> 2. A response of (B) indicates that the responder knows that the
> specified certificate has been revoked.  This means that the
> certificate does not satisfy the condition specified in Step (a)(3) in
> Section 6.1.3 of the path validation algorithm, which triggers the
> following:
>
>     If any of steps (a), (b), (c), or (f) fails, the procedure
>     terminates, returning a failure indication and an appropriate
> reason.
>
> 3. A response of (C) indicates that the responder does not know the
> status of the certificate.  In this case the client may try another way
> to verify that the certificate has not been revoked (e.g., ask a
> different responder or obtain a CRL).  [If the client is unable to
> verify the certificate's revocation status by another means, then it
> will either have to reject the certificate or make a risk-based
> decision to accept the certificate despite being unable to verify that
> it is not revoked.]
>
> I would guess that a response of (C) is most likely to occur in the
> case of a locally trusted OCSP responder.  My client may be configured
> to ask the locally configured OCSP responder first, and then if the
> response is
> (C) attempt to determine the certificate's status by using an OCSP
> responder referenced in the AIA extension in the certificate or by
> using a CRL obtained via the CDP extension in the certificate.
>
> > The only way I see for an OCSP responder to provide useful actionable
> information is if we change something so a client can consistently
> interpret and act on the responses, regardless of what kind of
> information the OCSP responder is using.
>
> As noted above, the current protocol already allows an OCSP responder
> to
> provide "useful actionable information."   Of course, clients won't be
> able to consistently interpret and act on responses if responders apply
> their own (personal) interpretations to the three possible status
> responses.  If some developers decide that it is "silly" for a
> responder to provide a response of (A) unless working from a white list
> and so have their responders provide a response of (C) for any
> certificate isn't known to be revoked, then clients will no longer have
> "useful actionable information."  This may not matter for some clients
> if they are configured to ask the OCSP responder about the certificate,
> but then continue on with validation unless a response of (B) is
> received (i.e., if all other aspects of path validation are successful,
> then accept the certificate even if no response is received from the
> OCSP responder or if a response of (A), (C), or even a error response
> is received).
> However, it will make a big difference to any client configured to fail
> safe by failing path validation unless it can actually verify that the
> certificate is not revoked.
>
> _______________________________________________
> pkix mailing list
> pkix <at> ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
[pièce jointe "smime.p7s" supprimée par Denis PINKAS/FR/BULL] _______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix