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

Dave Garrett <davemgarrett@gmail.com> Thu, 07 May 2015 03:13 UTC

Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 12A5E1A8709 for <tls@ietfa.amsl.com>; Wed, 6 May 2015 20:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Edy3KoG3HAqi for <tls@ietfa.amsl.com>; Wed, 6 May 2015 20:13:08 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0081A8701 for <tls@ietf.org>; Wed, 6 May 2015 20:13:08 -0700 (PDT)
Received: by qgej70 with SMTP id j70so14958231qge.2 for <tls@ietf.org>; Wed, 06 May 2015 20:13:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=BTObeeWXc2UUTXSd0WiubLlYsnWnIKYTEa5SUtUc7jo=; b=WbHRF9397XBWDmUKjYdxBqTppgxJSvj7MWLcxmBe4VHebwCxLYzVXPUxt3ozXwUzVv Ut+/6v51Kfg3Bpj0DMJiJ6qAjY4FZh+9eW9iKzFmc8oCfV5+CY7JycWV7i9nifeWFsVX IfD5RUEJRiSduNlSZ7e6hCfY/XbweLGYz/k4b50HeBGc7PHw622S4P/xzUcl4v/Lc4kd nvJ645CbvzMBZ3re1FBM9hNZ8HkdIcVWAfO707zJjDbUXB3nbsL+ee1b3uXeENe09T/7 KK5zFfEeLh+FiOnUhHJoorwyEw7Q9boeto3foncM1uYsOdHg0/arPJ3HJm29LqTS/cjQ thrw==
X-Received: by with SMTP id q20mr4066848qkq.68.1430968387691; Wed, 06 May 2015 20:13:07 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. []) by mx.google.com with ESMTPSA id q105sm592215qgq.11.2015. for <tls@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 06 May 2015 20:13:07 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Wed, 6 May 2015 23:13:05 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201505062313.06092.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/mvE2jox_BN7iNDg2_NenfaVe46Q>
Subject: [TLS] Update spec to match current practices for certificate chain order
X-BeenThere: tls@ietf.org
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." <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: Thu, 07 May 2015 03:13:10 -0000

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

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.