Re: OCSP questions

[Dan Weinstein <danw@xxxxxxxxxxxx>]

Tom Arnold wrote:
> 
> I realize that OCSP Draft 5 is getting ready for last call, but ...
> 
> My point-of-view on the proposed standard is from an on-line transaction
> processing perspective where certificates are used to authenticate the
> sender of a transaction. And, where on-line processing, means respond in a
> few seconds or less...
> 
> Is it the intent for the thisUpdate field in section 2.4 to timestamp when
> a specific certificate being checked was reported as revoked? My concern
> being that we need to know the exact time that a certificate was reported
> as revoked.

No, the thisUpdate field just tells you how recent the information is. 
The revocationTime field in the revokedInfo structure, provide you with
the information on when the certificate was actually revoked.  One
source of the thisUpdate field, might be the time of issue on a CRL.

> To what extent will the timestamp field be certified by the OCSP responder?
> 
> The time fields being described as generalizedTime (ASN.1) is fine but I'd
> like to see that further qualified that the generalizedTime MUST be recored
> as UTC time (example: 19981106210627.3Z).

Aren't generalizedTime's used through out PKIX without any such
specification?  What exactly are you trying to buy, by doing this?  

> Lastly, what is the chance of a OCSP sender placing some quality-of-service
> requirement on the OCSP responder? This is to suggest that if I'm batch
> checking a database of certificates, I don't care if the OCSP message is
> resonded in several minutes. But if a high-value transaction is pending, I
> would want a response time in the sub-seconds range. Thoughts?

This is an interesting idea, but I see some obvious issues that need to
be discussed.  I think this might be an interesting feature for version
2.

Dan Weinstein
danjw1@hotmail.com