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

"Ryan Sleevi" <ryan-ietftls@sleevi.com> Tue, 12 May 2015 19: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 8F32C1A87EF for <tls@ietfa.amsl.com>; Tue, 12 May 2015 12:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.266
X-Spam-Level:
X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 cKRgLmhOJTl0 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 12:07:17 -0700 (PDT)
Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DA83F1A8703 for <tls@ietf.org>; Tue, 12 May 2015 12:07:17 -0700 (PDT)
Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 0BBDF2AC085; Tue, 12 May 2015 12:07:17 -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=QHZOgKELVuZJ3nGvhPoOQ8FdaZI=; b=rvdsstMh1wVwyEWYk t1ZqOzxVU6ySotHkmpv2MPN7Ogtutbrl4IxntfNYzlAaHBw7SWEy7+FdB0VIrJtD 9aQOo0HaDEH0+IRj1Ni/p3LXfwOjwXpigM4HcwVeX8S5hBGqOC01fc1dsCIh26oM ntikzUVFIRN7hyMcaSiI8dVgxM=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPA id 024942AC06E; Tue, 12 May 2015 12:07:14 -0700 (PDT)
Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 12:07:16 -0700
Message-ID: <17a92a9a6272ba2735dd0553fb527c3a.squirrel@webmail.dreamhost.com>
In-Reply-To: <20150512190452.5470E1B2EB@ld9781.wdf.sap.corp>
References: <20150512190452.5470E1B2EB@ld9781.wdf.sap.corp>
Date: Tue, 12 May 2015 12:07:16 -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/6yfTheDDT1MJ8PWCGbh6RynpQEs>
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 19:07:18 -0000

On Tue, May 12, 2015 12:04 pm, Martin Rex wrote:
>  The *CORRECT* approach would be to issue a cross-CA certificate
>  for (5) Root 2 signed by (4) Root 1, lets call it (5b), and
>  the correct path to send for servers would be
>
>  (1)+(2)+(3b)+(5b)+(4)
>
>  that would be fully conforming with the existing requirements,
>  fully comprehensible for clients that feed the certificate_list
>  from the Certificate handshake message into "Basic Path Validation".

How did I know you would suggest this?

Ah, because I addressed it in the original email, when I said

"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)"

So, moving on :)