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

Geoffrey Keating <geoffk@geoffk.org> Thu, 07 May 2015 22:49 UTC

Return-Path: <geoffk@geoffk.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 A9C561B2A07 for <tls@ietfa.amsl.com>; Thu, 7 May 2015 15:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2znMxnJ6MS10 for <tls@ietfa.amsl.com>; Thu, 7 May 2015 15:49:56 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC4C1B29BC for <tls@ietf.org>; Thu, 7 May 2015 15:49:56 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 3173333D1E6; Thu, 7 May 2015 22:49:55 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Yoav Nir <ynir.ietf@gmail.com>
References: <201505062313.06092.davemgarrett@gmail.com> <02805C01-924F-4B21-B61F-21414D4CE20D@gmail.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: 07 May 2015 15:49:55 -0700
In-Reply-To: <02805C01-924F-4B21-B61F-21414D4CE20D@gmail.com>
Message-ID: <m2oalwypd8.fsf@localhost.localdomain>
Lines: 59
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/9enpAI6EF1-kyhhKmNuqgxdCTLI>
Cc: tls@ietf.org
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:49:57 -0000

Yoav Nir <ynir.ietf@gmail.com> writes:

> Hi, Dave
> 
> > On May 7, 2015, at 6:13 AM, Dave Garrett <davemgarrett@gmail.com> wrote:
> > 
> > https://tools.ietf.org/html/rfc5246#section-7.4.2
> > ----------------------------------------------------------------------
> >   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”.
> 
> It’s not that nobody cares about that second MUST. It’s just that we’ve learned the hard way that a lot of servers get it wrong, so we anyway had to run the whole chain-sorting/chain-completing code anyway.
> 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=619445#c1
> > 
> > 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'd like to see wording as follows:

     This is a sequence of certificates.  The sender's certificate
     MUST come first in the list.  The remaining certificates MAY be
     used by the client to establish trust in the first certificate.
     The sender SHOULD order these remaining certificates so that each
     certificate is used to establish trust in a certificate earlier
     in the order, and so that its preferred certificates are listed
     first.

This answers the problem of multiple certificate paths, and doesn't
prevent re-ordering by the client, and also allows the server to guide
the client to the chain it prefers, which is important in some
circumstances.  For example, one chain might support EV, and another
might be necessary for older clients, but both might be valid in some
clients; the server would want to guide the client to the EV chain if
it will work.

Another alternative would be to say

     This is a sequence of certificates.  The sender's certificates
     MUST come first in the list.  The remaining certificates MAY be
     used by the client to establish trust in one of the sender's
     certificates.  The sender SHOULD order these remaining
     certificates so that each certificate is used to establish trust
     in a certificate earlier in the order, and so that its preferred
     certificates are listed first.

This explicitly allows the sender to send multiple certificates for
itself, which would simplify a bunch of problems; SNI is no longer
necessary (but still desirable), and it's no longer necessary to
negotiate the certificate signing algorithms.