Re: [pkix] An alternative proposal Was: Fwd: New Version Notification for draft-hamilton-cmr-00.txt

[Kyle Hamilton <[e-mail]>]

On Wed, Oct 26, 2011 at 2:02 PM, Phillip Hallam-Baker <[e-mail]> wrote:
> Thinking laterally on this issue.
> The issue here seems to come up with the problem that OCSP does not have a
> proper response code for 'does not exist',

I have no problem at all with improving OCSP, as a separate item.  I
really want to improve it, actually.  The problem is that by
definition, any OCSP responder which can respond with a "does not
exist" will be required to respond in that manner for any and every
certificate serial number which is not listed on the CRL.  CRL cannot
meaningfully feed such a responder.

 Now let us imagine for a moment
> that we borrow from the prior art in DNSSEC and have an NSEC3 type
> capability that provides a status for the 'gaps' between certificates.
> Wouldn't this meet all the essential use cases?
> The gaps could be specified either as gaps between certificate serial
> numbers or gaps between cert hashes. I would like to see an OCSP extension
> to allow the hash of the cert to be specified in any case.
> So the old style OCSP token is (essentially)
>    Sign (key, { {status-value, issuer, serial, {extensions}} } )
> I would like to change that for certs that exist to:
>    Sign (key, { {status-value, issuer, serial, {certhash, extensions}} } )
> And if there is a query for a cert that does not exist and the request
> indicates that you can process it, you would get back:
>    Sign (key, { {non-existent, issuer, dummy-serial, {{start-indicator,
> end-indicator}, extensions}} } )

How about,

Sign(key, { {status-value, issuer, serial, { certhash,
extended-status-value, extensions } } })

and

Sign(key, { { status-value REVOKED, issuer, serial, {certhash,
extended-status-value NeverIssued, otherextensions } } })

-Kyle H