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

[Stefan Santesson <[e-mail]>]

Here is my own concerns with inclusion of an optional cert hash in the
extension.

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.

The alternative is to extend this process long enough that we feel sure we
got it right.

/Stefan


From:  Tom Ritter <[e-mail]>
Date:  Wednesday, October 31, 2012 8:32 PM
To:  Stefan Santesson <[e-mail]>
Cc:  IETF PKIX <[e-mail]>
Subject:  Re: [pkix] Proposed resolution to non-issued certificates -
2560bis

>> Question:
>> Would it make sense to require an OCSP responder that adopts the expanded
>> use of "revoked" to always include the new extension?
>> It would add the benefit that someone receiving "good" can know that the
>> OCSP responder has checked that the certificate in fact has been issued by
>> the CA.
>> In such case it may be reasonable to add an optional data structure which
>> MAY contain a hash of the cert.
>> Such hash would make the positive confirmation even stronger, adding proof
>> of existence of the certificate.
> 
> I'll register my vote for all these items also - I like the idea of providing
> transparency into the operations of the responders.
>