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

"Ryan Sleevi" <ryan-ietftls@sleevi.com> Thu, 07 May 2015 21:37 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 DF3271B2B2C for <tls@ietfa.amsl.com>; Thu, 7 May 2015 14:37:41 -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 s7Htq8B_UnZE for <tls@ietfa.amsl.com>; Thu, 7 May 2015 14:37:40 -0700 (PDT)
Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D78AF1B2B3D for <tls@ietf.org>; Thu, 7 May 2015 14:37:40 -0700 (PDT)
Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 45F4794065 for <tls@ietf.org>; Thu, 7 May 2015 14:37:40 -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:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=aiecN4yua3QTlXoeFvSg8yehCJw=; b=tgEaecqNyXxMfDD2P 6v8DpmbBo8uqIbMtLVmZayIkFDnSJjASRt9SkNEvKUkgtxxATuq8MfNIAmYmK8uu 0lv7tMFfQ/FlvZVMA1z1k7ottz4l32a6FW4BzmpAD8VxY9prfCuUhp+3t3qpVeef NkmcOm82BEy+1wGqZ0/piDVCL4=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id 8DA139406D for <tls@ietf.org>; Thu, 7 May 2015 14:37:37 -0700 (PDT)
Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 7 May 2015 14:37:40 -0700
Message-ID: <e89927d5fe72c8a2ddfeb9738093a5e1.squirrel@webmail.dreamhost.com>
In-Reply-To: <20150507201833.GY17272@mournblade.imrryr.org>
References: <9A043F3CF02CD34C8E74AC1594475C73AB0165D9@uxcn10-tdc05.UoA.auckland.ac.nz> <20150507155147.GO17272@mournblade.imrryr.org> <f06dfb0c50e3044f85a52ffa55089f2c.squirrel@webmail.dreamhost.com> <201505071435.15754.davemgarrett@gmail.com> <20150507201833.GY17272@mournblade.imrryr.org>
Date: Thu, 7 May 2015 14:37:40 -0700
From: "Ryan Sleevi" <ryan-ietftls@sleevi.com>
To: tls@ietf.org
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/THnYPLj-pXecIkoPtnPDVa-y07s>
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: Thu, 07 May 2015 21:37:42 -0000

On Thu, May 7, 2015 1:18 pm, Viktor Dukhovni wrote:
>  That's mostly fine (singular/plural conflict), though one might
>  clarify the MAY further:
>
>    certificate_list
>       This is a list of certificates needed for authentication.
>       The sender's certificate MUST come first in the list.  Additional
>       certificates needed to construct a valid certificate chain
>       SHOULD be ordered by increasing scope of authority.  (e.g.
>       sender, intermediate(s), certificate authority).  Root
>       certificate authority certificates MAY be omitted from the
>       list, provided supported peers are known to possesses any
>       omitted certificates they may require in their trust stores.
>       (When DANE-TA(2) trust-anchors are self-signed roots, they
>       MUST not be omitted [draft-ietf-dane-ops]).

While I appreciate the attentiveness to DANE's needs, it seems unnecessary
to specify profile-specific details in the TLS specification, much in the
same way we don't discuss profile-specific aspects of ciphersuite
negotiations or the like. That is, I consider DANE-TA(2) trust anchors as
a profile of how the TLS exchange works, not an intrinsic property that
belongs in this spec.

Regarding Dave's suggested rewording on the additional certificates, I
think there's actually sizable ambiguity with respect to the terms chosen
(sender, intermediate(s), certificate authority) that the original
language is much clearer and less ambiguous on.

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.