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

Dave Garrett <davemgarrett@gmail.com> Thu, 07 May 2015 22:51 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DAE1B2BF9 for <tls@ietfa.amsl.com>; Thu, 7 May 2015 15:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcRTZemsFqL9 for <tls@ietfa.amsl.com>; Thu, 7 May 2015 15:51:02 -0700 (PDT)
Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (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 BC8AA1B2BF7 for <tls@ietf.org>; Thu, 7 May 2015 15:51:01 -0700 (PDT)
Received: by qgfi89 with SMTP id i89so28762288qgf.1 for <tls@ietf.org>; Thu, 07 May 2015 15:51:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=1zEYYFJGzKpjlG9TzN4q7FLZjHaSc4AexQdhk2oE770=; b=TeTGXBCW69kaV53BjGZ7QNWPtl5XhQBAOPfuw354mvZCnNXbUerD57mb0rHXtf2SOs TUm9zJV0sAvRmVIS9Ks2TfgosB3//cSwO4FM8jo9kz6torVKY+CD9yd89gt5KDIQ3tqH 77/iSDKHGF382uiwZOE/arFXeJGK+vmdtse4LjO8KId9i2EB92DHYzE/C3/02z1sdna6 Xt2dytsx57DUuLPrq/2XaqJOhScV3kCjutnBluEHy+sqeDRwUDEkjI3EgF4dHEf/7lBF XkK30dVxBS1rwimMw9nRZG4Mv1O5g2pDI3R+TzqWlTxaMggHiDEXDDH5r5qxGqwKvIz1 crrg==
X-Received: by 10.140.43.100 with SMTP id d91mr1296950qga.77.1431039061061; Thu, 07 May 2015 15:51:01 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id h14sm2367058qhc.46.2015.05.07.15.51.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 May 2015 15:51:00 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org, ryan-ietftls@sleevi.com
Date: Thu, 7 May 2015 18:46:51 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
References: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> <20150507201833.GY17272@mournblade.imrryr.org> <e89927d5fe72c8a2ddfeb9738093a5e1.squirrel@webmail.dreamhost.com>
In-Reply-To: <e89927d5fe72c8a2ddfeb9738093a5e1.squirrel@webmail.dreamhost.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201505071846.52147.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/CvMtpBtocFkDREdcSNkPqZbwbLE>
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
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 22:51:03 -0000

On Thursday, May 07, 2015 05:37:40 pm Ryan Sleevi wrote:
> At the risk of a bike-shed, I'll throw my contribution in, which aligns
> closer to the existing language, save for avoiding the notion of "root
> certificate authority certificates" in favour of the RFC 5280 term of
> trust anchor, which need not necessarily be a certificate. Functionally,
> this is equivalent, but hopefully provides clearer understanding.
> 
>   This is a sequence (chain) of certificates. The sender's certificate
>   MUST come first in the list. Each following certificate SHOULD
>   directly certify the one preceding it. Because certificate validation
>   requires that trust anchors be distributed independently, a
>   self-signed certificate that specifies the trust anchor MAY be omitted
>   from the chain, provided supported peers are known to possess any
>   omitted certificates they may require.
> 
> So, for the DANE-TA(2) trust-anchor form, it requires that the trust
> anchor be express as a self-signed certificate, and is not possessed by
> the peer, ergo the MAY doesn't apply and the peer MUST send the
> certificate. But it avoids the cross-reference to a particular trust
> validation method.

"Trust anchor" is notably better, yes.

However, the language of "directly certify the one preceding it" is problematic with multiple intermediates. I was looking to have the wording be more general to provide expectations there. I think the simplest way to resolve this might be to just drop usage of the word "the" here. So:

   This is a sequence (chain) of certificates. The sender's certificate
   MUST come first in the list. Each following certificate SHOULD
   directly certify one preceding it. Because certificate validation
   requires that trust anchors be distributed independently, a
   self-signed certificate that specifies a trust anchor MAY be omitted
   from the chain, provided supported peers are known to possess any
   omitted certificates they may require.

This has the same ordering expectations as the more significant rewordings, but is very similar to the current language.


Dave