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

"Ryan Sleevi" <ryan-ietftls@sleevi.com> Thu, 07 May 2015 17:08 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 1188F1A032D for <tls@ietfa.amsl.com>; Thu, 7 May 2015 10:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.233
X-Spam-Level:
X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 uj0j2u9YJV9b for <tls@ietfa.amsl.com>; Thu, 7 May 2015 10:08:18 -0700 (PDT)
Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0211A19E5 for <tls@ietf.org>; Thu, 7 May 2015 10:08:05 -0700 (PDT)
Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id BD45C27BC084 for <tls@ietf.org>; Thu, 7 May 2015 10:08:04 -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:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=uFGwP/Mjm4WtKh15/ETyl70NHaM=; b=DU70VBTFSTQ5UlLrX bUDL8Kh2qcVgMCggw6pHQ/DcUrTjaWJvvGB0QGGXECT81PEgfISCbiwBO5QHK1Z8 SYWrohncs487t44SkYxwgODA9gpIKTfRmCLAVMY8UaR1tOTTXdBZYO7gnQ2vFGE+ zuKapSPkgxQdTz+3W+EUAe2SD8=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id 8B4B627BC05D for <tls@ietf.org>; Thu, 7 May 2015 10:08:03 -0700 (PDT)
Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 7 May 2015 10:08:04 -0700
Message-ID: <f06dfb0c50e3044f85a52ffa55089f2c.squirrel@webmail.dreamhost.com>
In-Reply-To: <20150507155147.GO17272@mournblade.imrryr.org>
References: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> <20150507155147.GO17272@mournblade.imrryr.org>
Date: Thu, 7 May 2015 10:08:04 -0700
From: "Ryan Sleevi" <ryan-ietftls@sleevi.com>
To: tls@ietf.org
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/j5qffMNsqqlWIZ1WXNOocdPTnvY>
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
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: Thu, 07 May 2015 17:08:20 -0000

On Thu, May 7, 2015 8:51 am, Viktor Dukhovni wrote:
>  I summary, the only thing that could be tweaked is the requirement
>  to order the intermediate certificates.  The first MUST and final
>  MAY are correct as they stand.  And I think that the second MUST
>  is a fine example of Postel's principle.  Tolerance by many clients
>  of servers that ignore the requirement does not invalidate the
>  requirement.

To the extent this problem was caused (largely) by browsers, it's a
problem that could (largely) be solved by browsers.

The root cause I think is best captured by the fact that we don't have an
X.500 directory, and thus RFC 2459/3280/5280 have never been sufficient to
work in isolation because there's no notion of a global, shared trust
store for who is authoritative and all of the trust relationships.
Instead, we have the ad-hoc trust stores of major software vendors, and
you find them in various different states through time and versions (e.g.
the massive amounts of cross-signing that go on for CAs like
Symantec-Verisign, StartCom, or Verizon-(GTE/Baltimore) Cybertrust)

The disconnect exists because the TLS and X.509 subsystems are
disconnected (as they reasonably can be), with TLS opting for RFC 5246
(and earlier), and X.509 clients needing to implement something like RFC
4158. In an RFC 4158 world, your inputs of intermediate CAs are unsorted (
https://tools.ietf.org/html/rfc4158#section-2.7.2 ) - and may even be
ignored ( https://tools.ietf.org/html/rfc4158#section-3.5.10 )

These sections aren't specs-leading-implementations - the leading
implementations of path building were already doing what the spec merely
documented after-the-fact.

If a client wanted to ensure RFC 5246 compliance, it would need to
explicitly add code to test that - coupling the TLS and X.509
implementations more tightly.

In recent years, with the necessary attention on PKI, more clients (not
exclusively browsers, but especially browsers) are bringing their
PKI/X.509 implementations closer to their TLS implementations, and maybe
this coupling isn't so bad.

In an ideal world, I'd prefer the second MUST remain a MUST, because it
makes implementing a TLS + RFC 5280 validator easier (e.g. without
*requiring* an RFC 4158 discovery phase).

However, in a pragmatic world, because major clients implement RFC
4158-like behaviours, and because in the changing landscape of CA
hierarchies (both through acquisitions, but also through the deprecation
of weak crypto like SHA-1 or RSA-1024 bit keys and the adoption of
stronger crypto, such as ECC), it's increasingly necessary to implement
something like RFC 4158 to work on the Internet at large, changing the
second MUST to a SHOULD seems imminently sensible and reflects the reality
today and going forward.

The first MUST should remain - I can't see how any sane client would or
could avoid that. The final MAY is also necessary/correct, judging by how
the Web PKI actually works (plus the whole "self-issued for key rollover"
captured in https://tools.ietf.org/html/rfc5280#section-6.1 that makes it
problematic for a client to determine whether or not the 'root CA' is
actually a 'self-issued for key rollover' intermediate)

There's always the possibility that as browsers become increasingly
proactive in communicating 'bad' (misconfigured), 'insecure', and
'sub-optimal' configurations, we'll find a world where major clients can
safely and correctly *enforce* the 5246 behaviour as part of encouraging
good server hygiene...