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

David Chadwick <d.w.chadwick@kent.ac.uk> Tue, 30 October 2012 13:44 UTC

Return-Path: <d.w.chadwick@kent.ac.uk>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3802221F84E7 for <pkix@ietfa.amsl.com>; Tue, 30 Oct 2012 06:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMPtvZm7MVq7 for <pkix@ietfa.amsl.com>; Tue, 30 Oct 2012 06:44:05 -0700 (PDT)
Received: from mx2.kent.ac.uk (mx2.kent.ac.uk [129.12.21.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4DD21F84DB for <pkix@ietf.org>; Tue, 30 Oct 2012 06:44:04 -0700 (PDT)
Received: from dhcp29ca.kent.ac.uk ([129.12.41.202]) by mx2.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from <d.w.chadwick@kent.ac.uk>) id 1TTC6r-0006lR-BI; Tue, 30 Oct 2012 13:44:01 +0000
Message-ID: <508FD9A4.8080101@kent.ac.uk>
Date: Tue, 30 Oct 2012 13:44:04 +0000
From: David Chadwick <d.w.chadwick@kent.ac.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: Stefan Santesson <stefan@aaa-sec.com>
References: <CCB55CA3.52588%stefan@aaa-sec.com>
In-Reply-To: <CCB55CA3.52588%stefan@aaa-sec.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: pkix@ietf.org
Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates.
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Oct 2012 13:44:06 -0000

1

On 30/10/2012 09:52, Stefan Santesson 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
>