Subject: [Anima] sending full certificate chains in ClientCertificate

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Oct 2017 17:26:43 -0400

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-