IETF Logo Mail Archive

Re: [TLS] Update spec to match current practices for certificate chain order

Dave Garrett <davemgarrett@gmail.com> Fri, 08 May 2015 23:07 UTC

Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B7E1A871E for <tls@ietfa.amsl.com>; Fri, 8 May 2015 16:07:58 -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 FA6HGA5B6Lvr for <tls@ietfa.amsl.com>; Fri, 8 May 2015 16:07:57 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 09AB01A871A for <tls@ietf.org>; Fri, 8 May 2015 16:07:49 -0700 (PDT)
Received: by qku63 with SMTP id 63so58001467qku.3 for <tls@ietf.org>; Fri, 08 May 2015 16:07:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=G0BbqF73XjDA9drk4cdFjj2hGWEJY4kNQMm3+08lKto=; b=BaNVloWEUfLX8nxAhK1NkDA9ZqGW3b8My4bQLyh+onm/4yCR/l0dJF7QDTGV8/n5zr eMvoFPepJnt9qAK9Tu4tCsdXh2wFhJLd1V8zCceHBVFut/KqMYjdX9vu8IEKy6nxGT4I MG2MIJeEiuuhRxbVaKQNYVFWY12LcCQXECkCgjtBPtGJWgR2+LmZw0miDgheaI9H5x7f 8xuiDPUTd42Kmv6Es/2na5QhomMkHGeJ3zsjVUDs0fFmfevWXz7IJQKrOpBXFJccHePG 2BhFOzSp6lgoK9YAZr0iDUdH2JmdumPTUOl+ROkWPhfbe5vNXlUtsds4z+yiIu4Alyj1 wFMQ==
X-Received: by 10.55.51.141 with SMTP id z135mr762522qkz.84.1431126468267; Fri, 08 May 2015 16:07:48 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id 143sm4619318qhw.21.2015.05.08.16.07.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 May 2015 16:07:47 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: ryan-ietftls@sleevi.com
Date: Fri, 08 May 2015 19:07:46 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
References: <20150508141926.1C16A1B2DE@ld9781.wdf.sap.corp> <201505081734.47783.davemgarrett@gmail.com> <7dd89312e9234c911e27edd81b2686d0.squirrel@webmail.dreamhost.com>
In-Reply-To: <7dd89312e9234c911e27edd81b2686d0.squirrel@webmail.dreamhost.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201505081907.46745.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/yEk4ykxrn7ZrXtj87V0DxZLKr5I>
Cc: tls@ietf.org
Subject: Re: [TLS] Update spec to match current practices for certificate chain order
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2015 23:07:58 -0000

On Friday, May 08, 2015 05:53:34 pm Ryan Sleevi wrote:
> I think you've misunderstood me.

I think we've both misunderstood each other a bit, which unfortunately tends to happen sometimes with larger responses and quotes. I'll be brief, as we're veering off-topic a bit.

> So by accepting the status quo and having the spec updated to reflect
> that, we agree that the decoupling/loose coupling is good.

Yes, in this case.

> By changing clients to enforce the second MUST, we promote more coupling
> at the clients. That's not good in my view.

What I was saying that I "don't fundamentally disagree" with is the notion that ideally the second MUST should be enforced more strictly. This is not a clean system where we can expect layers to be loosely coupled. We're just long past the point where this is realistic, and in this case strictness wouldn't give us any direct benefit.


Dave

v2.23.0 | Report a Bug | By Email