On Fri, Sep 23, 2016 at 12:42:09AM +0000, Nick Sullivan wrote: > PR: https://github.com/tlswg/tls13-spec/pull/654 > > Hello, > > I'd like to propose a small to the Certificate message format to allow for > future extensibility of the protocol. > > This change adds a set of extensions to the Certificate message. With this > change, the Certificate message can now hold all extension messages that > are certificate-specific (rather than connection-specific). This change > also resolves the anomaly of OCSP messages appearing before certificates in > the handshake. > > Reasoning: > I've come to the conclusion that the current mechanism in TLS 1.3 for OCSP > and SCT is lacking forsight. OCSP and SCT are per-certificate metadata, not > per-connection metadata. By putting these responses in the > EncryptedExtensions, you limit these extensions to being shown once per > connection. This restricts future protocol extensions from using multiple > Certificate messages to support multiple certificates on the same > connection. An example of this is the post-handshake authentication > proposal ( > https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00), > which currently requires a modified post-handshake Certificate message. > This proposed change would simplify the post-handshake auth proposal > significantly and generally make more sense as more certificate-specific > extensions are created.
Also, this would presumably solve the user_mapping problem without introducing a new handshake message. Basically, there is extension user_mapping, that wants to send some certificate-associated auxillary data from client to server. Currnently, there is no place to put such data. And yeah, with post-handshake auth, it looks like one would want a lot more flexibility than currently exists. BTW: I would rather dump the current post-handshake auth for such extension proposal. The current post-handshake authentication is just plain annoying to implement in contexts where the client has no intention of ever supporting it. And the current post-handshake auth mechanism seems to be insufficient for real-world uses too... I recently got an idea of implementing freezing session state into octet stream and being able to thaw such. I quickly discovered I can't implement that without either having freezable hashes (which I don't have available) or just saying screw it with post-handshake auth and never responding to the requests, even to reject them. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
