Is there any support for either of the following ideas: 1) moving the OCSP and SCT server extensions to inside the Certificate message 2) removing post-handshake client authentication from TLS 1.3 in favor of dedicated and more detailed draft
On Sun, Aug 7, 2016 at 11:42 PM Martin Thomson <[email protected]> wrote: > On 8 August 2016 at 16:14, Ilari Liusvaara <[email protected]> > wrote: > > In 2, I would imagine the context is probably usually a sequence > > number of some kind. > > The draft defines some rules for construction of identifiers that > prevent collisions and the like. > > >> Good question. Errors in encoding or otherwise problems following the > >> rules in the spec should result in a connection-level fatal error. > >> But if the certificate isn't trusted, handling that will be up to the > >> application. > > > > And that should presumably be communicated somehow... > > Of course. See > https://github.com/grittygrease/tls13-post-handshake-auth/issues/18 > (feel free to contribute) > > > Being able for application to to wait for certificate/cv/finised > > message to be sent, so it can do something special in application > > layer immediately after that. > > Sure. The usual async API guarantees apply here; I don't know that > this needs special treatment in the spec though. If you disagree, I'm > sure that my coauthors would be happy to take suggestions for > improvements. >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
