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

"Ryan Sleevi" <> Tue, 12 May 2015 19:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 542961ACE81 for <>; Tue, 12 May 2015 12:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JFlTOntFc-aH for <>; Tue, 12 May 2015 12:22:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 907861A8955 for <>; Tue, 12 May 2015 12:22:38 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 5AB9C3B80A0; Tue, 12 May 2015 12:22:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s=; bh=DADSz0rT/i6VOxfiXqOypwt/m94=; b=FazH5UpfOkPPZujHi k3YapaFk3WmoxFsRCF5EU/K2oUeJKyCan6Wia7z7QH5Kb9NDmiR9drc+bGJZFvK2 pPcgfuuRdZ2SkxrlE3uAmVGxlBXRwAR27i4UkAgpP+L12BBapCC40lxUBaUXinVR 7Y7asYcDb07yj7AJvK9+YYxJAc=
Received: from ( []) (Authenticated sender: by (Postfix) with ESMTPA id 6A44C3B8057; Tue, 12 May 2015 12:22:37 -0700 (PDT)
Received: from (SquirrelMail authenticated user by with HTTP; Tue, 12 May 2015 12:22:38 -0700
Message-ID: <>
In-Reply-To: <>
References: <>
Date: Tue, 12 May 2015 12:22:38 -0700
From: Ryan Sleevi <>
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: <>
Subject: Re: [TLS] Update spec to match current practices for certificate chain order
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 May 2015 19:22:41 -0000

On Tue, May 12, 2015 12:14 pm, Martin Rex wrote:
>  there is no "shouldn't have done (3a)/(3b)".  They can simple create
>  that crossCA cert *NOW* and start distributing it, and things will
>  work just fine.

Again, that's an assumption about the possibilities of change that are not
bourne out by the realities of the PKI.

In a variety of circumstances, there are actively reasons why creating a
crossCA is *not* valid or will *not* resolve issues for clients. In
particular, issuing such a cross-CA may violate appropriate WebTrust or
ETSI guidelines that CAs are required to adhere to, or violate the CA's
own CP/CPS. I'm sure that's an invitation for more decrying, but it's the
reality we live in, and compared to the alternatives, it's actually a
*good* thing, even if it makes spec purity hard.

>  The problem with your original proposal is, that no *CORRECT* TLS
>  implementation will allow you to send such junk in a TLS Certificate
>  handshake message, so this will simply not be an option.

Not an option conforming with the TLS spec, I fully acknowledge.

But it's an area where a number of clients never implemented (again,
layering - it's more work and more attack surface to actually enforce that
requirement), and it's an area where a number of servers actively ignore
because "working for clients" is more important than theoretical spec

Which is sort of why we're here discussing this in the first place -
whether or not we want to acknowledge reality or not.

But I don't think we're making productive progress here, so it's probably
worth me bowing out. It does seem like we're at a fundamental and
ideological impasse with regards to path discovery, and while I can try to
convince you that RFC 4158-like behaviours are good for all clients, I
suspect neither this list nor this issue is the right medium for it.

I leave it up to the editors & chairs to evaluate consensus, the relevant
arguments for and against, and the behaviours of clients (both for and