Re: [pkix] a question of cert (and OCSP) extension syntax

Rob Stradling <rob.stradling@comodo.com> Wed, 18 March 2015 09:32 UTC

Return-Path: <rob.stradling@comodo.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC5C1A015F for <pkix@ietfa.amsl.com>; Wed, 18 Mar 2015 02:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxU8vkbL7IVr for <pkix@ietfa.amsl.com>; Wed, 18 Mar 2015 02:32:05 -0700 (PDT)
Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8431A0154 for <pkix@ietf.org>; Wed, 18 Mar 2015 02:32:04 -0700 (PDT)
Received: (qmail 26174 invoked by uid 1004); 18 Mar 2015 09:32:03 -0000
Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 18 Mar 2015 09:32:03 +0000
Received: (qmail 30200 invoked by uid 1000); 18 Mar 2015 09:32:03 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 18 Mar 2015 09:32:03 +0000
Message-ID: <55094613.5050402@comodo.com>
Date: Wed, 18 Mar 2015 09:32:03 +0000
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, IETF PKIX <pkix@ietf.org>
References: <9A043F3CF02CD34C8E74AC1594475C73AAFB6418@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB6418@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/Nw_l5wVLT0BA8mXpV7hn5cs0q3Q>
Subject: Re: [pkix] a question of cert (and OCSP) extension syntax
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Mar 2015 09:32:07 -0000

On 18/03/15 07:10, Peter Gutmann wrote:
> Melinda Shore <melinda.shore@gmail.com> writes:
>
>> it's what's in the document until someone can either point to some normative
>> specification that it violates or can point to something that actually would
>> break.
>
> This isn't a case of standards rules-lawyering though (in any case the PKIX
> spec is flexible enough that you can stuff anything you want into a
> certificate if you interpret things just right, see the famous MPEG-of-cat
> quote), it's that this is creating a situation where an *X.509 standards-
> compliant certificate* contains data that can't be processed by an *X.509
> standards-compliant certificate application*.

Peter, are you saying that _all_ X.509 standards-compliant certificate 
applications MUST be able to process _all_ data in _all_ certificates?

That would make it impossible to define any new certificate extensions 
in the future, because existing software cannot possibly already support 
extensions that haven't even been defined yet!

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online