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

Ben Laurie <> Fri, 08 May 2015 12:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1CDE91B2A89 for <>; Fri, 8 May 2015 05:23:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.389
X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5uPnSr9aTCQr for <>; Fri, 8 May 2015 05:23:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AEA891B2A11 for <>; Fri, 8 May 2015 05:23:42 -0700 (PDT)
Received: by qcbgu10 with SMTP id gu10so35892062qcb.2 for <>; Fri, 08 May 2015 05:23:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fGskV1R47YFCz3/P/3rwrc7bd/DWhKhgIt3JuoMwc8k=; b=BzL7nqm14JNBZC+iRhvNrg0HX/QXxyeMBc/z/he9l94ojS9NjtBjbe4239DalS5CVY qHA1/8jQE25xxIzpb/4ZpZQ/mvrhUGdjelVj9s7O9k5GXh0MALrd7vOotTFTVbzDcr5D EHhXTvQiIbfIip7wt4dKEbamMw4cq6REH2nKTz8zMniBYBbPHuh8bSfhJQn8AErmJyzh neUWAw7GAjydKeHtcfGzobkq5Vlag4uBIwvK1rV8Vzn6TAI9vfmZVB9UqxlvOqmHuZUY RZJWLAaVy6ssY3MWuNZ0VTsz1Zb24eYMHPv+vu760ltx1Z0miDS7gU7iKUnhlQxh3Tcm pMbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fGskV1R47YFCz3/P/3rwrc7bd/DWhKhgIt3JuoMwc8k=; b=MGm4OrEG6b6bFuNAtSmnO0dX6/x7jpabm7YmvNdL7ICxt5Cqjzd3NCT8Et+0iwn+OG hgOS1+oIwRbZtZutk+372SqY386Vc+ia6GFZL2R0XZaIaaOWc6KGxfAmhhImVJGVTCug UKrajce9tQfVIyoJ+4zJPn1XDVyZuDTu82RM5kXW3w+rZ8I4l2RX0DJbV6n2DNIjGgSX CQHYVckd9YG0xJW7Yts8vcpwwkqwZgthzB1C+uNAYIq9g0orviwHBma1UIlJ+A2eErrI yORFtd345kQDwhRNbdr3mun2ovHLWIy4reatkkgSanXZkSbwB1DNnxm6eYzzDLZnL6fZ HsLQ==
X-Gm-Message-State: ALoCoQk8pOWEsgqVlIOLJ72ixgj2s86aSUg0L7ksszD04PL5JuodnGoyj2TNhIuoj0fNkgrtrxus
MIME-Version: 1.0
X-Received: by with SMTP id a48mr4405187qge.30.1431087821912; Fri, 08 May 2015 05:23:41 -0700 (PDT)
Received: by with HTTP; Fri, 8 May 2015 05:23:41 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Fri, 8 May 2015 13:23:41 +0100
Message-ID: <>
From: Ben Laurie <>
To: Dave Garrett <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
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: Fri, 08 May 2015 12:23:44 -0000

On 7 May 2015 at 04:13, Dave Garrett <> wrote:
> ----------------------------------------------------------------------
>    certificate_list
>       This is a sequence (chain) of certificates.  The sender's
>       certificate MUST come first in the list.  Each following
>       certificate MUST directly certify the one preceding it.  Because
>       certificate validation requires that root keys be distributed
>       independently, the self-signed certificate that specifies the root
>       certificate authority MAY be omitted from the chain, under the
>       assumption that the remote end must already possess it in order to
>       validate it in any case.
> ----------------------------------------------------------------------
> It seems that in practice, nobody cares about that second "MUST".
> I'd like to propose simply changing that second "MUST" to a "SHOULD" or possibly even a "RECOMMENDED", thus allowing for clients to accept cert chains in different orderings as they already seem to do. (no change proposed for the first "MUST")

No thanks. Let's not encourage bad practices. For a start, if you
relax the requirement you allow for ambiguous chains.

> I think there was also discussion on this list at some point suggesting changing that "MAY" for omitting the root CA cert to a "SHOULD" or a "MUST". (I think the argument for the latter was to reduce wasted bandwidth)
> Any reason this would be problematic? It'd be a simple change to add for the TLS 1.3 spec that would align things better with real-world usage.
> Dave
> _______________________________________________
> TLS mailing list