Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

Stefan Santesson <stefan@aaa-sec.com> Tue, 09 April 2013 14:57 UTC

Return-Path: <stefan@aaa-sec.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 3809B21F8C3C for <pkix@ietfa.amsl.com>; Tue, 9 Apr 2013 07:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.65
X-Spam-Level:
X-Spam-Status: No, score=-99.65 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnQmxvsxuoJV for <pkix@ietfa.amsl.com>; Tue, 9 Apr 2013 07:57:16 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 5383521F8B1E for <pkix@ietf.org>; Tue, 9 Apr 2013 07:57:12 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id E8D6C2030CDA for <pkix@ietf.org>; Tue, 9 Apr 2013 16:57:10 +0200 (CEST)
X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se
Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aRik3ktmT9yC for <pkix@ietf.org>; Tue, 9 Apr 2013 16:57:10 +0200 (CEST)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 8CE392030CD3 for <pkix@ietf.org>; Tue, 9 Apr 2013 16:57:10 +0200 (CEST)
Received: (qmail 58890 invoked from network); 9 Apr 2013 14:57:10 -0000
Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.6]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender <stefan@aaa-sec.com>) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <david.black@emc.com>; 9 Apr 2013 14:57:10 -0000
User-Agent: Microsoft-MacOutlook/14.3.2.130206
Date: Tue, 09 Apr 2013 16:57:05 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: "Black, David" <david.black@emc.com>, Piyush Jain <piyush@ditenity.com>, 'Sean Turner' <turners@ieca.com>
Message-ID: <CD89F6C1.60183%stefan@aaa-sec.com>
Thread-Topic: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71293E22D3E@MX15A.corp.emc.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Mailman-Approved-At: Sat, 20 Apr 2013 16:53:14 -0700
Cc: "ambarish@gmail.com" <ambarish@gmail.com>, "slava.galperin@gmail.com" <slava.galperin@gmail.com>, "cadams@eecs.uottawa.ca" <cadams@eecs.uottawa.ca>, "gen-art@ietf.org" <gen-art@ietf.org>, "sts@aaa-sec.com" <sts@aaa-sec.com>, "pkix@ietf.org" <pkix@ietf.org>
Subject: Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
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, 09 Apr 2013 14:57:17 -0000

On 4/9/13 2:35 PM, "Black, David" <david.black@emc.com> wrote:

>Again speaking for myself, I think the current text in -16 is ok, in that
>I
>don't see the prohibition that Piyush is concerned about there.  OTOH,
>I'd also
>be ok with a couple of sentences added to say that (new) clients could use
>that response format to infer that the certificate is a known non-issued
>certificate, but that clients cannot rely on getting that form of response
>for all known non-issued certificate (i.e., may get an "unknown"
>response).


I'd rather not try to describe what clients should do or expect in terms
of non-issued certificates.
Clients are really not meant to know anything beyond "revoked" = this cert
should not be trusted.

This is a server choice to prevent the requested cert (if it exist at all)
from being accepted.
For requests for real certs, issued by a trusted CA, this case will never
even occur unless the CA is compromised.
And, if I put something in, given the discussion so far, the chance that
there will be some major disagreements with it, is really high.

The current text works.

/Stefan