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

"Jeremy Rowley" <jeremy.rowley@digicert.com> Tue, 30 October 2012 16:46 UTC

Return-Path: <jeremy.rowley@digicert.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 CF8DC21F871E for <pkix@ietfa.amsl.com>; Tue, 30 Oct 2012 09:46:05 -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 2gJWPHTy7DZv for <pkix@ietfa.amsl.com>; Tue, 30 Oct 2012 09:46:04 -0700 (PDT)
Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id C911F21F872A for <pkix@ietf.org>; Tue, 30 Oct 2012 09:46:04 -0700 (PDT)
Received: from JROWLEYL1 (unknown [64.78.193.228]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 78FCF7FC144; Tue, 30 Oct 2012 10:46:04 -0600 (MDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1351615564; bh=IA9JCI8VMZOF3GiGqKv1Ybi8Z5XeSeKM1eJrXY3r4nE=; h=Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=uQLRICMYNR7bM+f/HaDPpQ73Nf8nAxP2Fj3B7xPS9Pm2J27g1Z82NYbIQdcYM4Be4 hc92SjIjqROzvlMUXSFoITcnwvHK931vutfjpkCHhq7SMriL1dJkBG/3xFQsqltBzd cGz1aCWgFzup3/SBPxEubgQrrvdnR+ilqsgDUuv4=
From: Jeremy Rowley <jeremy.rowley@digicert.com>
To: 'Rick Robinson' <rick@goldbugtech.com>, pkix@ietf.org
References: <20121029232328.BF5D91A309@ld9781.wdf.sap.corp> <CCB55CA3.52588%stefan@aaa-sec.com> <002e01cdb6ba$4b1e9480$e15bbd80$@com>
In-Reply-To: <002e01cdb6ba$4b1e9480$e15bbd80$@com>
Date: Tue, 30 Oct 2012 10:46:04 -0600
Organization: DigiCert
Message-ID: <02af01cdb6be$0d677d60$28367820$@digicert.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGVV/pKG3iHd0l1fUM/6+5gHz6tmwH1lk8JAjuKqQSYIUIjUA==
Content-Language: en-us
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
Reply-To: jeremy.rowley@digicert.com
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:46:05 -0000

3 - Many CAs already respond with either unknown or unauthorized.  

-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Rick
Robinson
Sent: Tuesday, October 30, 2012 10:19 AM
To: pkix@ietf.org
Subject: Re: [pkix] Straw-poll on OCSP responses for non-revoked
certificates.

3) Neither. Add new optional response = unissued.

-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of
Stefan Santesson
Sent: Tuesday, October 30, 2012 3:53 AM
To: pkix@ietf.org
Subject: [pkix] Straw-poll on OCSP responses for non-revoked certificates.

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

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix