On Sat, Dec 12, 2015 at 03:54:36PM +1100, Martin Thomson wrote:
> I think that the best way to deal with the status_request_v2 extension
> is to make it a proper part of the TLS 1.3 messages, probably
> Certificate or CertificateVerify. This is a fairly heavily important
> extension.
If one wants to incorporate it, I would think Certificate for two
reasons:
- So CertificateVerify signs it without hacks. It is easier to analyze
things if the only thing not covered are the signature and Finished.
- Because Certificate message is modifed anyway for authentication
contexts (CertificateVerify is not sent if the client refuses
authentication, and server should be able to tell which
authentication is refused).
Something like:
struct {
opaque certificate_request_context<0..255>
ASN1Cert certificate_list<0..2^24-1>
opaque wrapped_status<0..2^24-1>
} Certificate;
Where wrapped_status payload is what would be the CertificateStatus
message payload (empty if CertificateStatus would not have been
sent).
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
