On Wed, May 25, 2022 at 12:40:13PM -0400, Ashley Kopman wrote: > Hi TLS, > > I have just submitted a draft TLS Extension for Path Validation > https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-00.txt > <https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-00.txt> > > The proposal is for a Path Validation Extension to provide a new > protocol for TLS/DTLS allowing inclusion of certificate path > validation information in the TLS/DTLS handshake. Specifically, it > covers the use of Server-based Certificate Validation Protocol > (SCVP) for path validation.
Looking at how this is integrated to (D)TLS: For (D)TLS 1.2, the server extension does not seem to be technically necressary, and omitting it could simplify things. Yes, this design is the same as one used for OCSP stapling (status_request), but I found the server hello extension in OCSP to be seemingly unnecressary extra complexity. For (D)TLS 1.3, why there are seemingly two server extensions, one in server hello, which is usually only used for low-level crypto stuff, which this is not, and another in certificate message (which makes sense for certificate-related thing. And this is maybe a stupid question, but I didn't find an answer by quickly looking at the draft nor the SCVP RFC, does the server need to send the certificate chain to the client if it sends the SCVP response, or just the end-entity certificate? Omitting the chain could save quite a bit of handshake size. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
