I'm confused by the line "These messages are not encrypted", because on a plain reading it could mean that the authenticator is sent outside the encrypted TLS session. That would be bad because it would mean that clients that wanted to authenticate themselves but to the server only wouldn't be able to use this mechanism. I assume that's not the intent? If that isn't the intent, suggest rephrasing as "These messages are not encrypted, other than the encryption provided on transmission by the TLS session".
Cheers, William On Mon, Oct 31, 2016 at 5:29 PM, Nick Sullivan <[email protected]> wrote: > <https://tools.ietf.org/html/ > <https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00> > draft-sullivan-tls-exported-authenticator-00> > <https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00> > > I just posted a new Internet-Draft called "Exported Authenticators in TLS" > in the TLS working group. > > The intent of this draft is to enable participants in a TLS connection to > prove ownership of additional certificates. This differs from previous > proposals (https://tools.ietf.org/html/draft-sullivan-tls-post- > handshake-auth-00) in that these proofs are not sent as part of the TLS > connection, but instead exported so that they can be sent out of band (as > part of an application layer message, for example). > > This proposal should enable a radical simplification of the Secondary > Certificate Authentication in HTTP/2 proposal ( > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01), > and should generally be a useful tool for binding a certificate ownership > proof to a TLS connection. > > Nick Sullivan > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
