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+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls