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

Melinda Shore <melinda.shore@gmail.com> Wed, 18 March 2015 06:22 UTC

Return-Path: <melinda.shore@gmail.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 59D341A8A84 for <pkix@ietfa.amsl.com>; Tue, 17 Mar 2015 23:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 3-qLhn6YJ2Jx for <pkix@ietfa.amsl.com>; Tue, 17 Mar 2015 23:22:49 -0700 (PDT)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63891A002C for <pkix@ietf.org>; Tue, 17 Mar 2015 23:22:48 -0700 (PDT)
Received: by pdbcz9 with SMTP id cz9so33234994pdb.3 for <pkix@ietf.org>; Tue, 17 Mar 2015 23:22:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ZSS091FgElWlbv4kWPoZenC5ty47e7cRVFbwyZg0ukc=; b=Ba1y6QXHuEkmPGPgDRM3aJrPdS2fMb1ou+HrvqB9IGbVB3+PIC7Jn6OjAS/Y02kNf4 Ugts6S/AEJAkpk3peZbo3UASIxPdTYSDS7exEwVWWJx3393ohpgTq+4G5uXw9INDPSLz MF9+amaKfKgBTk4Gi3cOxZiDcMCy9TpleYZigQZfGDvfY6jVn+wpyah69dulYWP0Vr5D YYhwOxIBDO6LQiylmSrBfF1q6KyIOmJwiQXWfo3JFe+mxe5OkkIw9iTE1xaTMhg/nMJr NwZzi7JpEx5PH5LnweWSZEabpkBlvgqC5NL/QksN8IiK4juZdHLZjLzgIzZ9fPLCaCK0 L6Jw==
X-Received: by 10.70.91.167 with SMTP id cf7mr135837223pdb.7.1426659768517; Tue, 17 Mar 2015 23:22:48 -0700 (PDT)
Received: from spandex.local (209-112-223-215-rb1.sol.dsl.dynamic.acsalaska.net. [209.112.223.215]) by mx.google.com with ESMTPSA id qv9sm25586223pab.27.2015.03.17.23.22.46 for <pkix@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 23:22:47 -0700 (PDT)
Message-ID: <550919B4.6080401@gmail.com>
Date: Tue, 17 Mar 2015 22:22:44 -0800
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: pkix@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C73AAFB4AEE@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFB4AEE@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/sRIB4UsG6yDoqJOaXDyi30n-8Jw>
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 06:22:50 -0000

On 3/17/15 7:28 PM, Peter Gutmann wrote:
> The impression I got was that the decision to use the TLS encoding was a
> foregone conclusion and there wasn't much chance of changing it.

It's not so much that it's a foregone conclusion but rather that 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.  Finding it distasteful is not sufficient.  Unfortunately
none of the parties on either side of the discussion have shown even
a passing interest in compromise, I feel very strongly that chairs
should not be making unilateral decisions about technical content, and
there's implementation experience and running code based on 6962.  I
don't think the conditions for changing the encoding are particularly
onerous.  So, here we are.

Melinda