We received feedback from the aviation community that there is a need for this extension to be included in the CertificateRequest message for the case where the server rather than the client is the constrained resource (the aircraft in our use case). I have updated the draft to reflect the addition of the CertificateRequest extension and submitted a new draft 04. I would greatly appreciate any feedback on this draft as well as any feedback on the next steps for working with the TLS working group.
https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-04.html <https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-04.html> Thank you, Ashley Kopman > On Aug 4, 2022, at 1:51 PM, Ashley Kopman <akop...@conceptsbeyond.com> wrote: > > Hi, > > We presented this work at IETF 114. Thank you to everyone who provided > feedback. > > I have removed the extensibility to future path validation types and limited > the scope of this extension to just SCVP. I have also added discussion on how > the server should handle it if other path validation extensions are added in > the future (at the end of Section 2). Version 03 is available for review > https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-03.html > <https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-03.html> > > I am new to the IETF, so I apologize in advance if this is not the correct > process, but I believe the next step is to ask that this draft be considered > for adoption by the TLS Working Group. > > Thank you, > > Ashley Kopman
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
