IETF Logo Mail Archive

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

Stefan Santesson <stefan@aaa-sec.com> Fri, 29 March 2013 16:37 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 EB4BC21F93C9 for <pkix@ietfa.amsl.com>; Fri, 29 Mar 2013 09:37:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.179
X-Spam-Level:
X-Spam-Status: No, score=-102.179 tagged_above=-999 required=5 tests=[AWL=0.070, 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 2mCpxKQooe4q for <pkix@ietfa.amsl.com>; Fri, 29 Mar 2013 09:37:14 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 440EF21F93A0 for <pkix@ietf.org>; Fri, 29 Mar 2013 09:37:14 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id 5273B1F07DC9 for <pkix@ietf.org>; Fri, 29 Mar 2013 17:37:13 +0100 (CET)
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 BABtAnrQ4k8W for <pkix@ietf.org>; Fri, 29 Mar 2013 17:37:13 +0100 (CET)
Received: from s327.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id B73A81F07DC0 for <pkix@ietf.org>; Fri, 29 Mar 2013 17:37:12 +0100 (CET)
Received: (qmail 51098 invoked from network); 29 Mar 2013 16:37:12 -0000
Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.104]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender <stefan@aaa-sec.com>) by s327.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <piyush@ditenity.com>; 29 Mar 2013 16:37:12 -0000
User-Agent: Microsoft-MacOutlook/14.3.2.130206
Date: Fri, 29 Mar 2013 17:37:10 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Piyush Jain <piyush@ditenity.com>, "'Black, David'" <david.black@emc.com>, sts@aaa-sec.com, mmyers@fastq.com, ambarish@gmail.com, slava.galperin@gmail.com, cadams@eecs.uottawa.ca, gen-art@ietf.org
Message-ID: <CD7B80C0.5F100%stefan@aaa-sec.com>
Thread-Topic: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
In-Reply-To: <00fc01ce2c98$ddc41770$994c4650$@ditenity.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Mailman-Approved-At: Fri, 29 Mar 2013 09:41:07 -0700
Cc: pkix@ietf.org, ietf@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: Fri, 29 Mar 2013 16:37:15 -0000

On 3/29/13 5:17 PM, "Piyush Jain" <piyush@ditenity.com> wrote:

>' "revoked" status is still optional in this context in order to maintain
>backwards compatibility with deployments of RFC 2560.'
>
>I fail to understand this statement about backward compatibility.
>How does "revoked" being "optional/required breaks backward compatibility?
>The only reason cited in the WG discussions to use revoked for
>"not-issued"
>was that any other approach would break backward compatibility with legacy
>clients. And now the draft says that revoked is optional because making it
>required won't be backward compatible.

Yes. Making it required would prohibit other valid ways to respond to this
situation that is allowed by RFC 2560 and RFC 5019.
Such as responding "good" or responding with "unauthorized" error.

>
>And it gives the impression that best course of action for 2560bis
>responders is to start issuing revoked for "not-issued", which is far from
>the originally stated goal to provide a way for CAs to be able to return
>revoked for such serial numbers.

The latter is what optional means.

/Stefan

v2.23.0 | Report a Bug | By Email