Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)
"Ryan Sleevi" <ryan-ietftls@sleevi.com> Tue, 12 May 2015 17:13 UTC
Return-Path: <ryan-ietftls@sleevi.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 299BD1ACD59 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 10:13:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 PrZ_m3g6mdc1 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 10:13:27 -0700 (PDT)
Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCC31ACD58 for <tls@ietf.org>; Tue, 12 May 2015 10:13:27 -0700 (PDT)
Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 9BADD2004F323; Tue, 12 May 2015 10:13:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=s39T4xEm9Sz3ZZ4PrkvSrsAkhOs=; b=KglT8F0/hYRpCF+c2 3jHRgXH3AStWdPzqKsV5LJQ7C0racMLeugfGN5iPgDEpKhSJEmpanPFyPV5j6Sna K5HxZtpRtp3LEu3V0jos34Ve0JZYW8AhX4XcVcis/bMszamVE61YLWMFPyVEf06b jRilBn6Yq45oCGwtz8N2S8vEw0=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id B35CE2004F328; Tue, 12 May 2015 10:13:22 -0700 (PDT)
Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 10:13:26 -0700
Message-ID: <e7afe21aa3093b64348a12e77fc287f4.squirrel@webmail.dreamhost.com>
In-Reply-To: <1431442136.16387.11.camel@redhat.com>
References: <tlswg/tls13-spec/pull/169@github.com> <tlswg/tls13-spec/pull/169/c101001652@github.com> <8425a2f40ddc46ac91aca136a955fc53@ustx2ex-dag1mb4.msg.corp.akamai.com> <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> <1431442136.16387.11.camel@redhat.com>
Date: Tue, 12 May 2015 10:13:26 -0700
From: Ryan Sleevi <ryan-ietftls@sleevi.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/0phSi4ryA4iUACtvFzCWQ51aQRQ>
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
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
Reply-To: ryan-ietftls@sleevi.com
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 17:13:28 -0000
On Tue, May 12, 2015 7:48 am, Nikos Mavrogiannopoulos wrote: > Nevertheless, RFC 4158 is > far from being a standard (just an informational RFC), I don't think I presented it as a standard - just what the major PKI clients that most users interact with on a daily basis do. I didn't suggest it was the whole Internet. But for the PKI that people rely on for their daily interactions online (aka the Web PKI), which is used far beyond *just* web browsers (as https://access.redhat.com/articles/1413643 reminds us), the security here is relevant, and perhaps essentially so. > and there are > standard's track extensions which can address the issue [0] and can > allow the server to decide which path to send. Does your good for > Internet implementation utilize it? > [0]. https://tools.ietf.org/html/rfc6066#section-6 There are no plans at present to implement, and it's unlikely we would. Without wanting to get into a separate discussion, the privacy and performance implications of such an extension are extremely undesirable. Just because there's a Standards Track I-D doesn't mean it is wise or desirable ( http://tools.ietf.org/html/rfc6961 is another example), and just because it's an Informational Draft doesn't mean it's not widely supported (CryptoAPI, Java, and NSS, for example, all follow the logic of 4158) If I phrased your concern more objectively, would ubiquitous support "tomorrow" for RFC 6066 cause me to remove support for relaxing the language? No, because we still have the world we live in today. And having spec language reflect an idealized, unrealistic future instead of the reality we live in just does more harm than good. Much like references to the X.500 Global Directory.
- Re: [TLS] [tls13-spec] relax certificate_list ord… Salz, Rich
- Re: [TLS] [tls13-spec] relax certificate_list ord… Ryan Sleevi
- Re: [TLS] [tls13-spec] relax certificate_list ord… Andrei Popov
- Re: [TLS] [tls13-spec] relax certificate_list ord… Salz, Rich
- Re: [TLS] [tls13-spec] relax certificate_list ord… Salz, Rich
- Re: [TLS] [tls13-spec] relax certificate_list ord… Ben Laurie
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Watson Ladd
- Re: [TLS] [tls13-spec] relax certificate_list ord… Nikos Mavrogiannopoulos
- Re: [TLS] [tls13-spec] relax certificate_list ord… Ryan Sleevi
- Re: [TLS] [tls13-spec] relax certificate_list ord… Ryan Sleevi
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Ryan Sleevi
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Yoav Nir
- Re: [TLS] [tls13-spec] relax certificate_list ord… Daniel Kahn Gillmor
- Re: [TLS] [tls13-spec] relax certificate_list ord… Santosh Chokhani
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Viktor Dukhovni
- Re: [TLS] [tls13-spec] relax certificate_list ord… Yoav Nir
- Re: [TLS] [tls13-spec] relax certificate_list ord… Dave Garrett
- Re: [TLS] [tls13-spec] relax certificate_list ord… Dave Garrett
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Ryan Sleevi
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Ryan Sleevi
- Re: [TLS] [tls13-spec] relax certificate_list ord… Fabrice Gautier
- Re: [TLS] [tls13-spec] relax certificate_list ord… Brian Smith
- Re: [TLS] [tls13-spec] relax certificate_list ord… Yoav Nir
- Re: [TLS] [tls13-spec] relax certificate_list ord… Viktor Dukhovni
- Re: [TLS] [tls13-spec] relax certificate_list ord… Peter Gutmann
- Re: [TLS] [tls13-spec] relax certificate_list ord… Santosh Chokhani
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex