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

#1 

The system should fail closed. I agree with Paul Hoffman's point that this extends the definition of the 'revoked' response during this protocol exchange which must be noted. I'd also accept a new "unknown, fail closed" type response so long as clients that don't yet understand this new response fail closed.

- max

On Oct 30, 2012, at 3:52 AM, Stefan Santesson <stefan@aaa-sec.com> 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
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix