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

Stefan Santesson <stefan@aaa-sec.com> Wed, 10 April 2013 04:31 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 4C20721F92E8 for <pkix@ietfa.amsl.com>; Tue, 9 Apr 2013 21:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.249
X-Spam-Level:
X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 sKa9ZeK-mILw for <pkix@ietfa.amsl.com>; Tue, 9 Apr 2013 21:31:10 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id AAAB521F92F2 for <pkix@ietf.org>; Tue, 9 Apr 2013 21:31:06 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 6E5D0203CF6F for <pkix@ietf.org>; Wed, 10 Apr 2013 06:31:02 +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 Y7QLuGYSeCB9 for <pkix@ietf.org>; Wed, 10 Apr 2013 06:31:02 +0200 (CEST)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id DBFF6203CF74 for <pkix@ietf.org>; Wed, 10 Apr 2013 06:31:01 +0200 (CEST)
Received: (qmail 14616 invoked from network); 10 Apr 2013 04:31:01 -0000
Received: from 81-236-19-140-no39.tbcn.telia.com (HELO [192.168.1.69]) (stefan@fiddler.nu@[81.236.19.140]) (envelope-sender <stefan@aaa-sec.com>) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <piyush@ditenity.com>; 10 Apr 2013 04:31:01 -0000
User-Agent: Microsoft-MacOutlook/14.3.2.130206
Date: Wed, 10 Apr 2013 06:30:57 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Piyush Jain <piyush@ditenity.com>, "'Black, David'" <david.black@emc.com>, 'Sean Turner' <turners@ieca.com>
Message-ID: <CD8AB3B0.60302%stefan@aaa-sec.com>
Thread-Topic: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
In-Reply-To: <08d601ce3538$c67d1550$53773ff0$@ditenity.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:15 -0700
Cc: ambarish@gmail.com, slava.galperin@gmail.com, cadams@eecs.uottawa.ca, gen-art@ietf.org, sts@aaa-sec.com, 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: Wed, 10 Apr 2013 04:31:10 -0000

It is impossible to write a text that cannot deliberately be misunderstood.

This debate is so full of constructed, non-existent problems.

Nothing has changed for the clients. The client can receive an error, or
they can receive (good, revoked or unknown).
The meaning of those responses are pretty clearly explained.

The only thing we talk about here is an extremely unlikely and rare
exception case where the responder is allowed to respond revoked even if a
cert was never issued.

I'm sorry to say, but this is getting ridiculous.

/Stefan



On 4/9/13 4:41 PM, "Piyush Jain" <piyush@ditenity.com> wrote:

>> 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.
>[Piyush] 
>Thanks for clarifying your position on this Stefan.
>This is the position I disagree with. I think several people in the WG
>expressed that the meaning should be clearly conveyed if "revoked" is
>extended to communicate "non-issued".  Expectation that clients should
>treat
>these responses as normal revoked is not aligned with WG consensus IMO.
>> 
>> 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.
>[Piyush]
> And I think this is the only case that is interesting to the clients. I
>combed through the WG discussion and did not find a single case being
>discussed where clients benefit from sending OCSP requests for serial
>numbers for non-existent certificates.
>
>> 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.
>[Piyush]
>These are the issues that implementers will have to deal with. If there
>are
>going to be disagreement, they should be dealt with before the document is
>published IMO, unless 2560bis is considered a stop gap measure and OCSP v2
>is on the radar.
>I understand the desire to wrap up the pending documents so pkix can be
>disbanded on schedule. However, I'll leave that to the AD to decide that
>the
>benefits of meeting that schedule outweighs the cons of publishing a
>document that can potentially lead to confusion among implementers.
>
>
>