Hi Watson, Some points that should help clarify your questions: 1) The certificate used in the construction is no the plain certificate chain, it's the TLS 1.3 certificate message which could contain extensions. 2) The finished message is used to bind the certificate+certificateverify to the connection state. It mirrors TLS 1.3 post-handshake authentication. 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. 4) We can add the prefix in the next draft, thanks for the note.
On Tue, May 23, 2017 at 12:40 PM Watson Ladd <wat...@cloudflare.com> wrote: > Dear all, > > I don't think this design needs to be as complex as it is. Why isn't > signing a party-dependent (server or client) exporter with the key of the > certificate, and then appending the certificate chain, enough? I am fairly > certain this gets the properties we need. Further, the language around > jointly authoritative remains very opaque to me. > > My other (much more minor) comment is that exporters labels should start > with "EXPORTER" in RFC 5705, and I don't see why this draft shouldn't do > it. > > Sincerely, > Watson Ladd > _______________________________________________ > 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
