Is OCSP for validation?

[Michael Myers <MMyers@xxxxxxxxxxxx>]

Paul,

I'm going to split off the "Is OCSP for validation?" issue from the others.

You wrote:

> 
> Mike, you didn't respond to my previous statement about this, 
> so please do 
> so now: how? The semantics in the OCSP standard explicitly 
> talk only about 
> status, and not about validation. Yet now you are talking 
> about validation 
> through the extension mechanism. This is a violation of the 
> standard. You 
> can change the semantics of OCSP to handle topics other than 
> status, if you 
> want, but then it is a different protocol.

RFC2560 states:

"The "good" state indicates a positive response to the status inquiry. At a
minimum, this positive response indicates that the certificate is not
revoked, but does not necessarily mean that the certificate was ever issued
or that the time at which the response was produced is within the
certificate's validity interval. Response extensions may be used to convey
additional information on assertions made by the responder regarding the
status of the certificate such as positive statement about issuance,
validity, etc."

Note the last sentence.

I hope for the sake of those following this debate that we don't get into
debating shades of meaning, what is a "positive statement about . . .
validity" and what does the "etc." mean.

But in the end, the last sentence, along with the extensibility hooks in the
ASN.1, clearly establishes a basis for extension-based validation
mechanisms.  Yes, it might only be one sentence, but it reflects a great
deal of debate on the issue.  This resolution allowed the WG to solve the
revocation problem more quickly while positioning ourselves to incrementally
advance that framework forward to the more interesting validation problem,
should the group decide to take it on.  It's clear we do.

I believe what you might be reacting to is the fact that since the basic
response type is mostly about access to revocation information, alternative
response types must as well.  In fact, there is no such constraint asserted
in RFC2560 on this point, nor is such absence a defect.  The above sentence
reflects why.

Mike