Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates.

From: "Ben Wilson" <[email-masked]>
Date: Tue, 30 Oct 2012 09:46:36 -0600

Not 2 because requiring a "good" response when a certificate has never been
issued is equally equivocal to "revoked" - and we're only talking about OCSP
- not CRLs.  Definitely "1" because allowing a "revoked" response does no
harm and in practice it provides the flexibility needed until a better
solution is implemented and broadly made available.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Art
Allison
Sent: Tuesday, October 30, 2012 8:00 AM
To: [email-masked]
Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked
certificates.

3) Neither. Add new optional response = unissued.

The conflation of revoked and unissued that seems to be unresolvable by the
current protocol says to me the current protocol is inadequate and a new
response is needed.  

Responding revoked for an unissued cert is a lie.  No RFC should ever
attempt to make implmentors lie, as some will refuse to do so and lack of
interoperablity across implementations results.  And, relevant to
implementation decisions; I am responsible for a contract with a vendor that
has an OCSP function.   

Art Allison

Senior Director Advanced Engineering, Science and Technology

National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418
Fax  202 775 4981
www.nab.org <http://www.nab.org/> 
*Advocacy  Education  Innovation*

  _____  

From: [email-masked] on behalf of Stefan Santesson
Sent: Tue 10/30/2012 5:52 AM
To: [email-masked]
Subject: [pkix] Straw-poll on OCSP responses for non-revoked certificates.

Before we loose everyone engaged in this, I would like to make a
straw-poll:

Background:
A client may do a request for a certificate that has never been issued by
the CA.
This request may be done deliberately, by mistake or as a consequence of a
compromised CA.

The OCSP protocol does not require OCSP responders to have any knowledge
about issued certificates. It must only know about revoked certificates
that are within it's current validity period. However, some OCSP
responders closely coupled with the CA may also know if a certificate with
a particular serialNumber value has been issued or not.

The following is agreed:
   - An OCSP responder is allowed to respond "good" to a status request
for a non-revoked certificate, disregarding if it has ever been issued.

   - A client, having no additional out-of-band knowledge about the OCSP
responder, will just know that the certificate is "not revoked" when
receiving a "good" response, unless the response includes one or more
response extensions that provides additional information.

The following is debated:
   - Is an OCSP responder allowed to respond "revoked" even if a requested
certificate serial number is not on the list of revoked certificates, IF
the OCSP responder has positive knowledge that the requested serial number
does NOT represent a valid certificate issued by the identified CA?

Rationale for:
There are a number of reasons to allow this that has been mentioned, such
as:
 - It breaks nothing. A legitimate request for an issued certificate will
get a legitimate deterministic response.
 - It's safer. Responding "revoked" may not prevent a compromised CA from
being exploited. But if a request for a serialNumber that is known to be
bad is done nevertheless, a "revoked" response will at least be safer than
responding "good".
 - Allowing extension definitions with further semantics. A response
extension may be defined in the future that adds more information about
the requested certificate. This may include a positive confirmation that
the certificate has been issued as well as information that this
particular OCSP responder will only respond "good" if it knows that the
requested certificate has been issued, otherwise it will respond
"revoked". An extension with such semantics can only be defined if the
base standard allows a status other than "good" in such situation.
 - Supporting Web-PKI. The CAB-Forum has indicated that they will profile
the OCSP protocol for use with web server authentication. In such profile
they have indicated that they will NOT allow the "good" response unless
the requested certificate is known to have been issued. This means that
they will require OCSP responder in their infrastructure to have this
knowledge. Such profile would have to break the base OCSP standard if this
states that "good" MUST be returned unless the certificate has been
revoked.

Rationale against:
The basic rationale against raised on this list has been the argument that
it is wrong and confusing to allow anything but "good" as a response to a
non-revoked certificate (if the cert is issued by a CA that is served by
this OCSP responder).
Another strong opinion is that it basically does not solve anything. A
broken CA is broken and can't be fixed by responding "revoked". It would
be easy to adapt an attack to circumvent such response, for example by
issuing a fake certificate that duplicates a legitimate serialNumber.

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

Note: both alternatives are placed in a context where the certificate is
claimed to be issued by a CA that is served by this OCSP responder. The
exact meaning of "bad" is for later discussion.

Please keep any motivation short and do not use this thread for long
debates.

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: [email-masked]
Date: Wed, 31 Oct 2012 11:51:53 +0100

Hi,

If the CA does not know the certificate has been issued, for some reasons explained here, the OCSP should respond "good", once is revoked, should respond "revoked". How to automate the response that the certificate that has been issued shouldn´t have ever been issued, so in my opinion, the key question is not how the OCSP should respond, the key question is that this option cannot ever happen and then, you can trust on the OCSP responder.

If we choose revoked for a "non issued" certificate, would mean that you know somehow that the CA has been compromised somehow and then you have to revoke the certificate, so a new CRL is created and the response of the OCSP is reliable
If we choose option 3, "unknown" you rely on a third party to decide whether trust or not on you certificate and your OCSP response, so in my opinion, this is not good for the CA nor for the RP because some can trust and some others not.
Option 2 should be the "right" answer but being the right answer will put someone in danger because of a "rogue" certificate if the CA has been compromised.

So, as said, I think the key question should be another not about the OCSP responder.

In any case, and for the record (and the poll) I prefer option 1 for security reasons, just in case. At least I don´t give a positive false answer and wouldn´t let RP take the decission for me wether I´m a trustable CA or not.

Regards

Iñigo Barreira
Responsable del Área técnica
[email-masked]
945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Stefan Santesson
Enviado el: martes, 30 de octubre de 2012 10:53
Para: [email-masked]
Asunto: [pkix] Straw-poll on OCSP responses for non-revoked certificates.

Background:
A client may do a request for a certificate that has never been issued by the CA.
This request may be done deliberately, by mistake or as a consequence of a compromised CA.

The OCSP protocol does not require OCSP responders to have any knowledge about issued certificates. It must only know about revoked certificates that are within it's current validity period. However, some OCSP responders closely coupled with the CA may also know if a certificate with a particular serialNumber value has been issued or not.

The following is agreed:
   - An OCSP responder is allowed to respond "good" to a status request for a non-revoked certificate, disregarding if it has ever been issued.

   - A client, having no additional out-of-band knowledge about the OCSP responder, will just know that the certificate is "not revoked" when receiving a "good" response, unless the response includes one or more response extensions that provides additional information.

The following is debated:
   - Is an OCSP responder allowed to respond "revoked" even if a requested certificate serial number is not on the list of revoked certificates, IF the OCSP responder has positive knowledge that the requested serial number does NOT represent a valid certificate issued by the identified CA?

Rationale for:
There are a number of reasons to allow this that has been mentioned, such
as:
 - It breaks nothing. A legitimate request for an issued certificate will get a legitimate deterministic response.
 - It's safer. Responding "revoked" may not prevent a compromised CA from being exploited. But if a request for a serialNumber that is known to be bad is done nevertheless, a "revoked" response will at least be safer than responding "good".
 - Allowing extension definitions with further semantics. A response extension may be defined in the future that adds more information about the requested certificate. This may include a positive confirmation that the certificate has been issued as well as information that this particular OCSP responder will only respond "good" if it knows that the requested certificate has been issued, otherwise it will respond "revoked". An extension with such semantics can only be defined if the base standard allows a status other than "good" in such situation.
 - Supporting Web-PKI. The CAB-Forum has indicated that they will profile the OCSP protocol for use with web server authentication. In such profile they have indicated that they will NOT allow the "good" response unless the requested certificate is known to have been issued. This means that they will require OCSP responder in their infrastructure to have this knowledge. Such profile would have to break the base OCSP standard if this states that "good" MUST be returned unless the certificate has been revoked.

Rationale against:
The basic rationale against raised on this list has been the argument that it is wrong and confusing to allow anything but "good" as a response to a non-revoked certificate (if the cert is issued by a CA that is served by this OCSP responder).
Another strong opinion is that it basically does not solve anything. A broken CA is broken and can't be fixed by responding "revoked". It would be easy to adapt an attack to circumvent such response, for example by issuing a fake certificate that duplicates a legitimate serialNumber.

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

Note: both alternatives are placed in a context where the certificate is claimed to be issued by a CA that is served by this OCSP responder. The exact meaning of "bad" is for later discussion.

Please keep any motivation short and do not use this thread for long debates.