[Anima] sending full certificate chains in ClientCertificate
Michael Richardson <mcr+ietf@sandelman.ca> Tue, 24 October 2017 21:26 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD5C138467; Tue, 24 Oct 2017 14:26:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 CAobuSryUlXu; Tue, 24 Oct 2017 14:26:44 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4828C13A292; Tue, 24 Oct 2017 14:26:44 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 52BEF200F1; Tue, 24 Oct 2017 17:27:10 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 40C7D81DB3; Tue, 24 Oct 2017 17:26:43 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: tls@ietf.org
cc: anima@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 24 Oct 2017 17:26:43 -0400
Message-ID: <7457.1508880403@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/or7uMTnlnUbM1FlKJ79KzBoWTxY>
Subject: [Anima] sending full certificate chains in ClientCertificate
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Oct 2017 21:26:46 -0000
In ANIMA's BRSKI enrollment protocol we use TLS to communicate across realms. ( https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ > We are connecting the (prospective) device owner's realm (the Registrar) to the manufacturer's realm (the MASA). The MASA's certificate is either a webpki, or has been provided to the Registrar via some supplier agreement. In the other direction, we specify using a client certificate, and since are going cross-realm, we want to specify that the entire chain (including the trust anchor) be transmitted. We need the entire chain as we want to pin the device ownership while also permitting the Registrar's certificate to be rolled over time. In the browser space there has been pushback against including the trust anchors in the Server->Browser direction, including Google's Chrome browser complaining about unnecessary certificates, and TLS scanners. I understand that some of this is the result of some client libraries that could be confused (due to bugs) into validating a bogus chain if there was a self-signed certificate in the certificates sent from the server. What's unclear to me if there is any kind of specification that we would be violating if we state that we want the full chain in the Client's Certificate extension. Section 4.4.2 of draft-ietf-tls-tls13-21 says: a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. and there is a note about versions prior to 1.3 that the ordering wasn't always respected, but that some implementations accepted it anyway. In our document we simply want to say that the trust anchor MUST be included (MUST NOT be omitted...) which as far as I can see, is permited by tls1.3. Is there something I'm missing that would prevent us from doing this? -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Anima] sending full certificate chains in Client… Michael Richardson