Ben, Thanks for pointing that out, you are right. A client is jointly authoritative if there was in-handshake client auth followed by a post-handshake client auth. Subsequent client authentications can be computed in any order and are disambiguated by the context id.
Nick On Tue, May 23, 2017 at 1:12 PM Benjamin Kaduk <bka...@akamai.com> wrote: > On 05/23/2017 03:07 PM, Nick Sullivan wrote: > > 3) In TLS 1.3 post-handshake authentication, each successive certificate > added to the connection is incorporated into the handshake state. The last > certificate in a sequence of authentications would result in a connection > in which the party could say they were jointly authoritative a over > multiple identities. In exported authenticators, the only state that is > signed comes from the original handshake, so there's no way to order them. > Each exported authenticator is tied to the connection, but not tied > directly to another authenticator, and therefore there is no proof that the > party is "jointly authoritative". I welcome text changes to make this more > clear. > > > I thought at least for "normal" post-handshake auth, the handshake hash > used was always just the initial handshake, and did not include > intermediate certificates that had been transmitted. > > -Ben >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
