Re: Comments on OCSP draft

[Michael Myers <mmyers@xxxxxxxxxxxx>]

Al,

Good to hear from you, and thanks much for the detailed read.


At 12:02 PM 6/30/98 -0400, Arsenault, Al W. wrote:
>
>(Apologies if any of these are outdated; I've been wrapped up with other
>things for a while and am just catching up to PKIX, etc.)
>
>A few semi-random comments on the June 1998 OCSP draft
>(draft-ietf-pkix-ocsp-04.txt):
>
>1.  To support words Dave Solo has often spoken, the purpose of this
>protocol can probably be made more clear by inserting between the first
>and second paragraphs of section 2:
>
>	"This protocol serves to provide as current an answer as possible to
>the question, 'if I looked at the current CRL right now, would this
>certificate be on it?'
>It should be noted, however, that there are other
>questions that the application will have to provide answers to in
>deciding whether or not to accept a certificate, such as 'Has this
>certificate expired?', 'Is this certificate correctly signed?', etc.
>Providing this information is beyond the scope of OCSP."

Section 2.2 already states that:

"A notRevoked state by an OCSP responder DOES NOT absolve the application
of the responsibility of checking that the certificate is in its validity
period and has been correctly signed."

>
>2.  Section 2.2, "A definitive response message is composed of:..." -
>the first bullet says "version of the response".  Shouldn't this really
>be "version of OCSP?"  As worded now, it looks like the responder could
>put out something like "answer, version 1: revoked"; "answer, version 2:
>unknown", "answer, version 3:  revoked", etc.
>

Request and response versioning is purposefully decoupled.  There are no
plans to change anything, but this will enable downline flexibility should
there be a need to do so.

Implementations SHOULD return the same semantic content regardless of
response syntax version.

>3.  Section 2.3:  Will one or more of the authors please enlighten me as
>to the usefulness of the error type "internalError"?  In what case does
>this provide more useful information to the client than the response
>"unknown"?  I'm generally not a big fan of having a server send error
>messages back to the client that the client can't do anything about,
>anyway.  Certainly, the responder's System Administrator should be
>notified of the internal error, and possibly also a CA or two, but it
>seems to me that if a responder is working well enough to determine that
>it can't make a decision, it should just reply with "unknown".

The general notion was that the following set likely is not exhaustive of
all possible exception conditions:

- malformedRequest
- tryLater
- certRequired
- sigRequired

The problem is that many errors are implementation-specific.  Depending on
design, one could experience connectivity problems between a frontend
server and a backend database, somebody misconfigured the OCSP server and
the "signer" process died although the "receiver", "lookup" and "send"
processes are running, somebody pulled the card out of the reader, etc.

We didn't want to sign these responses (in the last case we might not be
able to), as implied by use of the "unknown" value of OCSPResponse, since
the response may differ in the absence of such an error.  Yet we wanted to
provide some conclusion to the protocol so that blocking clients wouldn't
block indefinitely.

>4.  Section 3.2:  you probably should specify that it's a
>"malformedRequest" error message.  (I know, I'm being somewhat retentive
>here, but let's be clear where we can.)

Yes.

>
>5.  Section 4.1, TBSRequest definition:  again, to what is this
>"version" referring?  If it's to "OCSP, version1", then it's fine - you
>should just say that.  If it means version of something else, then
>please clarify.

See prior response re: versioning.

>
>6.  Section 4.2.1 and 4.4.3 both say "OCSP responders SHALL be capable
>of recognizing and responding to the id-pkix-ocsp-basic response type."
>This wording seems wrong - I think it should be "OCSP responders SHALL
>be capable of recognizing requests and responding with the
>id-pkix-ocsp-basic response type."

Agreed.

>
>7.  Section 4.2.2.2, Time:  The fourth sentence seems to be wrong.  It
>says "Responses whose thisUpdate time is earlier than the local system
>time SHOULD be considered unreliable."  Those responses are generally
>reliable, it's when the thisUpdate time is LATER than the local system
>time that something may be wrong.  

Agreed.  Good catch.

>
>8.  Section 4.2.2.3.1:  It seems to me that allowing a CA to prevent a
>client from checking the validity of an Authorized Responder's
>certificate is wrong and should be dropped from the spec.  First of all,
>there doesn't seem to me to be any purpose for the CA to select this
>option.  If the check is unnecessary, then the clients can be told that
>their local policy can be set to not check - thus, the current third
>choice adequately covers the situation.  Second, if the client WANTS to
>make this check, it doesn't seem to me correct to allow the CA to tell
>it not to check.

On a personal note, I agree.  The prefatory note to this section is mine.
So there's my position.

As the lead instigator/editor of this thing though (it looked so simple 1
1/2 years ago!), I'm looking for the group's consensus on this point.  I
would note that this is an optional mechanism.  PKI designers are free to
choose whether or not to include this value in the certificate of an
authorized responder.

>
>9.  Section 5, fourth paragraph, last sentence:  insert "with" between
>"costs associated" and "its successful execution."

OK.

>
>				Al Arsenault
>
>-  speaking only for myself.  My views do not necessarily represent
>those of my employer.


Mike