On Sat, Apr 15, 2017 at 6:42 AM Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Fri, Apr 14, 2017 at 02:44:25PM +0300, Ilari Liusvaara wrote: > > On Thu, Apr 13, 2017 at 09:29:27PM -0700, Joseph Salowey wrote: > > > Hey Folks, > > > > > > At the IETF 98 meeting in Chicago there was support in the room to > adopt > > > draft-sullivan-tls-exported-authenticator [0]. We are looking for > feedback > > > on adopting this draft form the list. Please respond if you support the > > > draft and are willing to review it. If you object to its adoption, > please > > > let us know why. Please respond to the list by 20170501 > > > > > > > Looking at the draft and reviewing it: > > Another edge-case I figured: > > 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). > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
