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

Carl Wallace <carl@redhoundsoftware.com> Tue, 30 October 2012 16:09 UTC

Return-Path: <carl@redhoundsoftware.com>
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 7FE0721F86C4 for <pkix@ietfa.amsl.com>; Tue, 30 Oct 2012 09:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 xBt4ov5SDefw for <pkix@ietfa.amsl.com>; Tue, 30 Oct 2012 09:09:30 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BDFB621F868B for <pkix@ietf.org>; Tue, 30 Oct 2012 09:09:24 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id fc26so535915vbb.31 for <pkix@ietf.org>; Tue, 30 Oct 2012 09:09:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=EFeL3TjGpHx3HYe4zW2zmYV7PeXnEr6g69dI0uf0GAs=; b=as0woRpv4M1kgkf6K5DnlViw+c/yRK2h+zvwE8Dy+CgrMwG0Ei+qwHaxmDSek6tefl S4zvrm3yEp45gs1+HZ6vbZXdnxjFByjHACvkHQjnyGYJ/suL5z1PyqvmBkcM/vA53Fc7 EQSvRDGeoVBAU183PJgh36z8Ara4UrYTfTktWAiZvZOD2ksx3pIeyvDMW7Mc3pfXsd0/ 0KpAD05eOh7KWstKgg3Bw5JA7CMqeQ8LbrELZrbjS9O4YNNKFq1CoH8f0qFmo/uEjmI2 wr/XPE0VCS8EnkKXW6ImFWnDzff4fj/Vba4NO4K1wdedP9l24Fq1n/RsP9vlbXl3DjpE FhJw==
Received: by 10.52.94.225 with SMTP id df1mr43458933vdb.114.1351613364202; Tue, 30 Oct 2012 09:09:24 -0700 (PDT)
Received: from [192.168.1.25] (pool-96-255-241-185.washdc.fios.verizon.net. [96.255.241.185]) by mx.google.com with ESMTPS id qj8sm515357veb.2.2012.10.30.09.09.21 (version=SSLv3 cipher=OTHER); Tue, 30 Oct 2012 09:09:23 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Tue, 30 Oct 2012 12:09:19 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Stefan Santesson <stefan@aaa-sec.com>, pkix@ietf.org
Message-ID: <CCB57387.34DBF%carl@redhoundsoftware.com>
Thread-Topic: [pkix] Straw-poll on OCSP responses for non-revoked certificates.
In-Reply-To: <CCB55CA3.52588%stefan@aaa-sec.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Gm-Message-State: ALoCoQlwEGKJNeE5i4Y9GQ2B/UPl5FBAVM4BBoeiUStJiDSLfTDNQz8Cg35+rwgTchs2r7oFhLO6
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 16:09:31 -0000

1 but would like for the responder certificate or response to include some
indication that the responder is using these new semantics.

On 10/30/12 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