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

"Peter Rybar" <rybar@nbusr.sk> Tue, 30 October 2012 15:40 UTC

Return-Path: <prvs=0650d28ae5=rybar@nbusr.sk>
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 D6BC621F85E1 for <pkix@ietfa.amsl.com>; Tue, 30 Oct 2012 08:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.906
X-Spam-Level: *
X-Spam-Status: No, score=1.906 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555]
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 EqMDrjTpIQeN for <pkix@ietfa.amsl.com>; Tue, 30 Oct 2012 08:40:15 -0700 (PDT)
Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1D21121F85CD for <pkix@ietf.org>; Tue, 30 Oct 2012 08:40:14 -0700 (PDT)
Message-Id: <201210301540.q9UFeCNT092240@mail.nbusr.sk>
From: Peter Rybar <rybar@nbusr.sk>
To: 'Stefan Santesson' <stefan@aaa-sec.com>, pkix@ietf.org
Date: Tue, 30 Oct 2012 16:40:12 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <CCB55CA3.52588%stefan@aaa-sec.com>
Thread-Index: Ac22joBvixJ6MwVlQVendyE+BLrQZgAIASAA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level: ***
X-NAI-Spam-Threshold: 6
X-NAI-Spam-Score: 3.5
X-NAI-Spam-Version: 2.2.0.9309 : core <4387> : streams <848411> : uri <1255923>
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 15:40:16 -0000

I vote for option 3, Neither (which is I hope "unknown").

Trusted services shall not cheat.

Status "revoked" is untruth.
RFC define: The "revoked" state indicates that the certificate has been revoked (either permanantly or temporarily (on hold)).

The status "good" shall be used with a positive statement extension like hash of certificate otherwise we have unclear status.

A client may do a request for a certificate that has "never" been issued by the CA according to information in "old" OCSP database.
This request may be done by 'extremely' quick request after issuing certificate and for that reason OCSP database is not updated and expectations like: deliberately, by mistake or as a consequence of a compromised CA are in this case not correct. 

Also deliberately created values of serialNumber which are expected that will be included in new certificates issued at any time later can harm validations services when "revoked" will be included in responses because any cache or archive databases containing such untruth responses of serialNumber marked as "revoked" with different thisUpdate values than later issued and successively revoked real certificates with the same serialNumber will cause unknown verification sates in many applications.