Re: [pkix] Proposed resolution to non-issued certificates - 2560bis

["David A. Cooper" <[e-mail]>]

Stefan,

In your message yesterday you raised the issue of OCSP responders that have access to a database of issued certificates that are currently valid, but not of the certificates that were issued but that have now expired.  I then noticed that in the straw poll you did not limit the "revoked" response to certificates that have been revoked and certificates that the CA knows haven't never been issued, but indicated that the response could be used whenever the responder 'knows the certificate to be "bad".'  So, it was my understanding that you thought responders could still make use of the proposed expanded definition of "revoked" even if they did not maintain information about expired certificates.

So, which is it?  If a responder has access to a database of issued certificates, but that database does not include certificates that have expired, may the responder reply "revoked" if asked about a serial number that doesn't appear in the database or is it required to respond "good," since the serial number may be referring to a certificate that was issued but that has now expired?

Dave

On 10/31/2012 06:35 PM, Stefan Santesson wrote:

Does your message below mean that you now intend to extend the meaning of "revoked" even further to include certificates that were issued by CA and that were never revoked, but that are now expired? 

No

You got me wrong.

Not issued = never issued.

/Stefan

On 10/31/2012 05:25 PM, Stefan Santesson wrote:

There might be OCSP responders that do have access to a database of issued certs that are currently valid, but not the history of issued certs (expired).

They could not use this extension to include a cert hash as they can't know if a particular serial number of an expired cert is asked for.

Thus it may be wise to separate these issues and keep it simple and just use an OID to indicate this particular behaviour with regard to "revoked" response.

It may be wise therefore to allow a separate process come up with a separate extension for positive confirmations.

Not that I don't like such functionality.

On 10/30/2012 05:52 AM, Stefan Santesson wrote:

Please reply with either:

1. Allow "revoked" response for a certificate that has not been "revoked"
but where that OCSP responder for any other reason knows the certificate
to be "bad".

2. Require that the OCSP responder MUST respond "good" in this situation.

3. Neither 1 or 2 (motivate).