Re: [TLS] Consensus on PR 169 - relax certificate list requirements

Florian Weimer <fweimer@redhat.com> Mon, 31 August 2015 12:02 UTC

Return-Path: <fweimer@redhat.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 EAD1B1A0302 for <tls@ietfa.amsl.com>; Mon, 31 Aug 2015 05:02:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 lq7FataOlrup for <tls@ietfa.amsl.com>; Mon, 31 Aug 2015 05:02:05 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D3D11B3635 for <tls@ietf.org>; Mon, 31 Aug 2015 05:02:05 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 012398E3C4; Mon, 31 Aug 2015 12:02:04 +0000 (UTC)
Received: from oldenburg.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7VC23Rp028782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Aug 2015 08:02:04 -0400
To: Dave Garrett <davemgarrett@gmail.com>, tls@ietf.org
References: <CAOgPGoAPCXkzc=01_+FPSJcxV8vEQmBUYNGYaWMdKpSGU0M0Lg@mail.gmail.com> <201508261742.01242.davemgarrett@gmail.com>
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <55E4423B.3010101@redhat.com>
Date: Mon, 31 Aug 2015 14:02:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <201508261742.01242.davemgarrett@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/cx2Zs12Eu1exchbNQVIYPWBncPI>
Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 31 Aug 2015 12:02:07 -0000

On 08/26/2015 11:42 PM, Dave Garrett wrote:
> On Wednesday, August 26, 2015 05:11:01 pm Joseph Salowey wrote:
>> It looks like we have good consensus on PR 169 to relax certificate list
>> ordering requirements.  I had one question on the revised text.  I'm
>> unclear on the final clause in this section:
>>
>> "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 that supported peers are known to
>> possess any omitted certificates they may require."
>>
>> I just want to make sure there isn't the intention of omitting certificates
>> that are not seif-signed.
> 
> Well, technically anything can be omitted; it just won't validate. :p

Firefox completes chains with intermediate certificates it has seen in
other certificate chains.  This is an endless source of headaches if you
use headless clients which do not perform this caching.

In this light, MUST NOT automatically complete incomplete chains, except
with a trusted root certificate (self-signed or not) might an attractive
option.  Except that Mozilla could claim its self-learning trust store
is just magically growing root certificates in the sense of such a
requirement (although such certificates are necessarily intermediate,
otherwise it would not be safe to mark them as trusted automatically).

-- 
Florian Weimer / Red Hat Product Security