IETF Logo Mail Archive

Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

Dave Garrett <davemgarrett@gmail.com> Tue, 12 May 2015 21:23 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 3E9C91ACD10 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 14:23:35 -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 xncdaROrt77K for <tls@ietfa.amsl.com>; Tue, 12 May 2015 14:23:33 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 5FC6D1ACCF2 for <tls@ietf.org>; Tue, 12 May 2015 14:23:33 -0700 (PDT)
Received: by qku63 with SMTP id 63so15506932qku.3 for <tls@ietf.org>; Tue, 12 May 2015 14:23:32 -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=tGvkzihuE9ZcgldHr824EaK4E5XQYM+Q5/0gXsLc+7M=; b=gwFLiSm88dn6rlF9NO5npdzwDJrCveabuGOt0uX3ZgjlMmPfFEPPCxhXuWXA+UgOmN JAYpTvN2JGWfMqbKGoiLCBh0tuiZcCRGhcM8+vi6SJXNaILVBAf1Swq4tNJy65HWTqcS dVG5iD5nAb8KkDySN20jOBrJvtYUZDdPt6mtt6Ke523LBkdBz0p2cw2m2x1Qpq39azcs c11k6Sihrbo2wjnSobK7CqxkI8F4o1f9+x2jHY5MrkIF7A70nPvJ9EsvKaJBjsReKDYa Y/4cdfNNnfvPGQrdE7uZ1mYbd/5NwwEafmx6zR7SKDnn+W3u8910qn9SM7u+3oJYjynQ FCuA==
X-Received: by 10.55.18.17 with SMTP id c17mr37775467qkh.25.1431465812692; Tue, 12 May 2015 14:23:32 -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 21sm14126983qhy.1.2015.05.12.14.23.31 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 12 May 2015 14:23:32 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Tue, 12 May 2015 17:23:30 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
References: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> <87lhgtbm1z.fsf@alice.fifthhorseman.net> <20150512210831.GQ17272@mournblade.imrryr.org>
In-Reply-To: <20150512210831.GQ17272@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201505121723.30855.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/3jc_bxZoUcq32q4JbAkTQQnePoQ>
Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)
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: Tue, 12 May 2015 21:23:35 -0000

On Tuesday, May 12, 2015 05:08:31 pm Viktor Dukhovni wrote:
> Thus one can take a middle ground, where servers are allowed to
> send non-chains (heaps/bags/...), but clients are *not* required
> or expected to try all possible paths.  To the extent that some
> clients try multiple paths, the server operator may benefit from
> such a configuration, but various clients will build some single
> path out of the heap and either succeed or fail with that.
> 
> Allowing servers to send a heap seems mostly harmless, provided
> we're not also *requiring* clients to do the full combinatorial
> explosion path construction.  If the extent of the change is
> to allow mutually consenting clients and servers to play that
> game, I have no objections.  

The current proposal is that implementations SHOULD support lists
that are not strictly linear, but not MUST. Implementations would
still be permitted to reject cert lists they can't handle, for whatever
reason.


Dave

v2.23.0 | Report a Bug | By Email