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

The reason I think that we should take a look at what the clients actually
do here is that experience suggests that the specification is a poor guide
to behavior even in the cases where it is unambiguous.

On Mon, Nov 5, 2012 at 9:08 PM, Tom Gindin <tgindin@us.ibm.com> wrote:

>         Phill:
>
>         Why do you think that a non-critical CRL entry extension will
> result in clients accepting the referenced cert?  RFC 5280 5.3 says that
> RP's can ignore unrecognized extensions to an entry, not that they can
> ignore entries containing unrecognized extensions.  A CRL entry without an
> extension (indeed, almost any CRL entry except one containing reasonCode
> removeFromCRL) implies that the certificate should be rejected for current
> use.  So marking reason non-critical shouldn't hurt anything.
>
>                 Tom Gindin
>
>
>
>
> From:   Phillip Hallam-Baker <hallam@gmail.com>
> To:     Stefan Santesson <stefan@aaa-sec.com>,
> Cc:     "pkix@ietf.org" <pkix@ietf.org>
> Date:   11/01/2012 09:46 AM
> Subject:        Re: [pkix] Straw-poll on OCSP responses for non-revoked
> certificates.
> Sent by:        pkix-bounces@ietf.org
>
>
>
> 1 and 3b
>
> Reading through the thread it appears that the poll has actually turned
> into
>
> 3a Do nothing
> 3b Add in unknown.
>
> But going back to the original straw poll, I think that it is pretty clear
> that any viable implementation of 'unknown' would have to be implemented
> as a CRL or OCSP entry that is marked 'Revoked' with a NON CRITICAL
> extension giving the revocation reason as 'It never existed'
>
> Marking the reason as non-critical looks like it is only going to result
> in the undesired behavior as clients will reject the CRL entry completely
> and accept the cert as good. Which is stupid behavior but so was not
> having the status 'never existed'.
>
> I would prefer the form of the OCSP 'does not exist' entry to specify a
> range of cert serial numbers that do not exist. This permits pre-signing
> of the responses and avoids a potential DoS issue.
>
>
>
> On Tue, Oct 30, 2012 at 5: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
>
>
>
> --
> Website: http://hallambaker.com/
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>
>
>

-- 
Website: http://hallambaker.com/