On Tue, Apr 18, 2017 at 10:18:03PM +0000, Nick Sullivan wrote: > On Sat, Apr 15, 2017 at 6:42 AM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > > How do certificate type extensions (#9, #19 and #20) work with exported > > authenticators? > > > > Where other extensions are either meaningless or are edditional info, > > certificate types actually change the format of the first certificate, > > which the library needs to understand in order to extract the SPKI for > > validating the following CertificateVerify. > > > > I think it would be fair to only support server-generated exported > authenticators with the certificate_type negotiated by the TLS handshake. > If the client sent a list of server_certificate_types in its client hello, > then only authenticators of that type can be used (with the chosen type > included an extension to the certificate message). Similarly, if the > server's EE message contains a single client_certificate_type, that would > be the only type supported by client-generated exported authenticators. I > can add text to this effect ( > https://github.com/grittygrease/tls-exported-authenticator/issues/12).
There are two bad problems with this: - The certificate types in TLS 1.3 are a bad hack just for bare minimum support for RPK. Using the thing for client post-handshake auth is completely unworkable. And adding new certificate types is pretty much only workable in special applications[1]. - Relying on TLS capability negotiation is fundamentally problematic. There capabilties may not match. And things get downright unworkable when things like signature algorithms are considered. [1] The recent ITS stuff might be one of these applications. Basically, you can only handle one certificate per type, any more and one gets issues. And one certificate per type impiles that one does not need post-handshake authentication. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
