On Mon, Oct 21, 2019 at 3:34 PM Martin Thomson <[email protected]> wrote:
> On Thu, Oct 17, 2019, at 14:32, Watson Ladd wrote: > > In TLS 1.3 it seems to have been assumed this wouldn't happen and we > > could split signature algorithms from signature algorithms cert. > > > > If that's not actually the case it affects more than just DCs. DCs are > > a good way to restore extensibility if there is a problem here, > > provided we can come up with a solution. > > Yeah, I think that this is the clincher. > > FWIW, in Firefox we have a separation between TLS and the certificate > validation logic. The latter cares about the SPKI of all certificates in > the certification path because it applies policy related to choice of > keys. As a result, that code cares about DC also. So we don't really get > to advertise an algorithm until it is supported in both places. For that > reason signature_algorithms_cert, as much as it is intended to address this > sort of split, doesn't really help us. > > Logically, there is a split between the certification path construction > and the policy pieces, and the structure of the code recognizes this, but > in practice they are somewhat coupled. > This makes sense. In the current text, signature_algorithms_cert only applies to the cert chain, which is fine. It's slightly annoying that supporting new SPKIs in DCs makes implementations have to support the new SPKI in certificates, but it doesn't seem like too big of a deal. I'd be interested in hearing from other client implementations on this issue (cc: David Benjamin).
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
