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

"Ryan Sleevi" <ryan-ietftls@sleevi.com> Wed, 13 May 2015 00:21 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 BF1CD1A8772 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 17:21:17 -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 MGjo8YxYvA6P for <tls@ietfa.amsl.com>; Tue, 12 May 2015 17:21:17 -0700 (PDT)
Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B4E521A8715 for <tls@ietf.org>; Tue, 12 May 2015 17:21:06 -0700 (PDT)
Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 7A3462005E619; Tue, 12 May 2015 17:21:06 -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=rrBqlTTZMXGO/wRDylAQfDARwJY=; b=PDyoHg76ylPZDEtB9 gn1HjiYGydVgpFEP8zRNYDJFmAjTpwBCYFD+sVCbNdoEru9IgnI1P3XYrP4suZ54 cqO1EXUwW+l5Tufk6mxUGD+DfQL5rSviORCDHhc0h4a09nhQWNvC59UgGVROF9rD g35/eLUGMFiOMwVmrJ7Ghs4+xM=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 04C412005E605; Tue, 12 May 2015 17:21:06 -0700 (PDT)
Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 17:21:06 -0700
Message-ID: <652608d7316105c234ad043db5997945.squirrel@webmail.dreamhost.com>
In-Reply-To: <20150513001636.3C5141B2EB@ld9781.wdf.sap.corp>
References: <20150513001636.3C5141B2EB@ld9781.wdf.sap.corp>
Date: Tue, 12 May 2015 17:21:06 -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/TH0Gyzj4X_-cA1UVEJGIGCMgorg>
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: Wed, 13 May 2015 00:21:17 -0000

On Tue, May 12, 2015 5:16 pm, Martin Rex wrote:
>  Has adding the crossCA variant of the new Baltimore rootCA cert ever
>  been considered/tried?

Yes. It doesn't work.

> I mean dropping the old 1024-bit rootCA should
>  become irrelevant when the the 2048-bit crossCA variant is added
>  as trust anchor.  There is no practical difference between the
>  self-signed variant and the crossCA variant of that trust-anchor.
>  And if the PKIX implemenation is a little dense and does not recognize
>  the equivalence all by itself, then configuring both variants as
>  trust anchors should do the necessary magic.

In a world different than our own, anything is possible.
In the world we have, we deal with an imperfect reality and make it work.

>  Did the supplier of the relevant PKIX implementation fix this
>  implementation
>  shortcoming?

Nope.

Considering it is not required of an RFC 5280-compliant implementation to
support that, any claims that the relevant supplier should would largely
be inconsistent with your past messages. Even if you'd be correct in
arguing they should.