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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 07 May 2015 21:45 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 12EE91ACE09 for <tls@ietfa.amsl.com>; Thu, 7 May 2015 14:45:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Bjn9ocC-o910 for <tls@ietfa.amsl.com>; Thu, 7 May 2015 14:45:04 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 718FF1B29BF for <tls@ietf.org>; Thu, 7 May 2015 14:45:04 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6A255283031; Thu, 7 May 2015 21:45:03 +0000 (UTC)
Date: Thu, 7 May 2015 21:45:03 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150507214503.GB17272@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> <e89927d5fe72c8a2ddfeb9738093a5e1.squirrel@webmail.dreamhost.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e89927d5fe72c8a2ddfeb9738093a5e1.squirrel@webmail.dreamhost.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/MJq6KOk02l5xgdFVknPhYGGhDvg>
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: tls@ietf.org
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:45:06 -0000

On Thu, May 07, 2015 at 02:37:40PM -0700, Ryan Sleevi wrote:

> 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.

Sure, the parenthetical is by way of a "footnote", and can be droppped.
The key point is the preceding sentence.

>   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.

Works for me.

> 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.

No problem, I had no major issues with the current MAY, and this
new language improves on it by covering the essential caveat.

-- 
	Viktor.