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

"Ryan Sleevi" <ryan-ietftls@sleevi.com> Tue, 12 May 2015 17:07 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 4BB4C1ACD0F for <tls@ietfa.amsl.com>; Tue, 12 May 2015 10:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 FtvbxhE-lhhK for <tls@ietfa.amsl.com>; Tue, 12 May 2015 10:07:51 -0700 (PDT)
Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFD81A9107 for <tls@ietf.org>; Tue, 12 May 2015 10:07:51 -0700 (PDT)
Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id E25F56780C6; Tue, 12 May 2015 10:07:50 -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=5rWfoBMMmCZgoNHVdHrCzJ1QqR0=; b=WKOmDXDfcO8X1u9XV SxGhDvN4q2eT0/gcEvusxn40AuPM/bcRCmmVfMtG5S/bUByVoBzBwxnnmeqbW5AY AfJNKfdD6DJhZhTT4ky0dor5kCEH/TEW02QkPL1r7c4oLcWYsKuEjLfVgbf+Mqc3 T/hT05c+PtPxgwEMbwOlokhmNk=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id 7F7B1678063; Tue, 12 May 2015 10:07:44 -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:07:50 -0700
Message-ID: <5ec0a679151b6aad1473a8e1f4ee3e0d.squirrel@webmail.dreamhost.com>
In-Reply-To: <20150512160556.3923C1B2EB@ld9781.wdf.sap.corp>
References: <20150512160556.3923C1B2EB@ld9781.wdf.sap.corp>
Date: Tue, 12 May 2015 10:07:50 -0700
From: "Ryan Sleevi" <ryan-ietftls@sleevi.com>
To: mrex@sap.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/UgzAhR9rDgnlQOGq3fMRsBSMlfI>
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
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:07:52 -0000

On Tue, May 12, 2015 9:05 am, Martin Rex wrote:
>  New 2048-bit rootCA certs have been around for several years, and the
>  transition from old 1024-bit rootCAs to 2048-bit rootCAs is a non-problem.
>
>  It definitely is *NOT* a problem for the existing requirements on
>  the Certificate handshake message.

I'm sorry, but I'm going to have to disagree with you again, because while
this is the way the world looks on paper, it's not the way the world works
in practice.

Your example (access.redhat.com) is one that we had to work around on OS X
due to quirks of the client not supporting trust anchors (e.g.
https://code.google.com/p/chromium/issues/detail?id=236112 ).

That is, if you supply your (b) or (c), for example, you'll break any
application using Security.framework for certificate verification
(including all those that use CFURL & friends). It seems that Safari has
special logic not present in the OS to work around that issue.

So servers supply (a) or (d).

Now you can rail about clients all you want, and I might be inclined to
agree with you, but it highlights that the world is not as pretty as you
want.

Now, with respect to cross-certificates, it's a regular occurrence to see
situations like

(1) Leaf-signed-by-(2)
(2) Intermediate-signed-by-(3)
(3a) Intermediate-signed-by-(4)
(3b) Intermediate-signed-by-(5)
(4) Root 1 [an existing root]
(5) Root 2 [a new root applying for inclusion]

In this case, valid paths are
[for old clients]
(1)+(2)+(3a)+(4)

[for new clients]
(1)+(2)+(3b)+(5)

As much as you might wish to yell that they shouldn't have done (3a)/(3b)
like that, and instead (5) should have been certified by (4), there are a
large number of reasons why that doesn't happen, and the above is actually
quite common (I know of at least three different organizations who will
have to go through the above flow right now to avoid issues)

The maximum compatibility with clients is
(1)+(2)+(3a)+(4)+(3b)+(5)

As gross and as ugly as that may seem, when working with various clients'
libraries, that config is what gets the most working. That's why I support
the language relaxation, in its simplest form.

Now, if clients did AIA fetching ubiquitously, you might supply
(1)+(2)+(3a) and have (2)'s AIA point to (3b). Clients that trust (4) will
work "out of the box", while clients that trust (5) will do an AIA chase
off (2) to get (3b). Over time, you might determine that more clients have
(5) than (4), so then you invert it to (1)+(2')+(3b), where (2') is a
version of 2 whose AIA points to (3a).

This is the PKI we live in. It's not going away - it's here and has been
for the past decades.

If you fully control your client, server, and PKI, the language is
entirely reasonable. But few people do.