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

From: "David A. Cooper" <[email-masked]>
Date: Thu, 1 Nov 2012 10:04:17 -0400

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).

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 01 Nov 2012 15:34:21 +0100

I have proposed nothing of the kind you suggest.

The use of "bad" was an attempt to make the poll generic. It was said that
the meaning of "bad" is for later discussion.

No one have proposed anything but "non-issued" as a case for "bad" in this
context and no-one have suggested "non-issued" to mean anything other than
never issued.

/Stefan

From:  "David A. Cooper" <[email-masked]>
Date:  Thursday, November 1, 2012 3:04 PM
To:  Stefan Santesson <[email-masked]>
Cc:  IETF PKIX <[email-masked]>
Subject:  Re: [pkix] Proposed resolution to non-issued certificates -
2560bis

>     
>  
> 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
>  
>>> 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
> 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.
>>  
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix