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

[Juan Gonzalez <[e-mail]>]

Option 3) Neither 1 or 2

I agree about responding Unknown.

On Tue, Oct 30, 2012 at 3:52 AM, Stefan Santesson <[e-mail]>wrote:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix
>



-- 

*AVISO DE PRIVACIDAD*
Los datos personales que usted nos proporcione están sujetos a los términos
de la Ley Federal de Protección de Datos Personales en Posesión de los
Particulares (LFPDPPP). Para mayor información acerca del tratamiento y de
los derechos que puede hacer valer, usted puede acceder al Aviso de
Privacidad completo a través de la página www.seguridata.com/privacidad.htm.
Es importante que lo lea previamente a cualquier envío de información sobre
datos personales. SeguriData Privada S.A. de C.V.,  tiene su domicilio en
Insurgentes Sur, 2375 tercer piso, Colonia Tizapán, C.P. 01000, Delegación
Álvaro Obregón, en México, D.F.,  y utilizará sus datos personales
únicamente para la finalidad para la que sean obtenidos.