Rob, I apologize, I am not sure that I fully understand your question. I originally created the structure of path_validation_type to make it easier in the future to potentially expand the extension to use other protocols for path validation. But Martin, Rich and Russ pointed out that this likely adds an unnecessary layer of nesting complexity that may never be utilized.
Are you concerned that if additional validation extensions were added it could lead to multiple validations for the same handshake? If that is the case, I believe that this is somewhat mitigated by it being optional for the server to choose to perform the SCVP validation. If the TLS server were to receive multiple validation requests it could potentially select to perform only one. If I have missed your point, please let me know. Thank you, Ashley Kopman > On Jul 25, 2022, at 11:30 PM, Rob Sayre <say...@gmail.com> wrote: > > Hi, > > Doesn’t it depend on whether it would be easier to do this select* or deal > with multiple validations in the same message? No one’s said that exactly > afaik, but I haven’t watched the meeting yet. > > thanks, > Rob > > * in the recent past, the stuff I’ve worked on has made this easy, but I > agree they’re a bit annoying. > > On Mon, Jul 25, 2022 at 13:25 Russ Housley <hous...@vigilsec.com > <mailto:hous...@vigilsec.com>> wrote: > I was thinking the same thing during the presentation. An extension for SCVP > seems fine to me. Then in the future, if another validation comes along some > day, a new extension can be assigned for that protocol. > > Russ > > > On Jul 25, 2022, at 4:13 PM, Martin Thomson <m...@lowentropy.net > > <mailto:m...@lowentropy.net>> wrote: > > > > Take this: > > > > struct { > > PathValidationType path_validation_type; > > select (path_validation_type) { > > case scvp: SCVPValidationRequest; > > } request; > > } PathValidationRequest; > > enum { scvp(1), (255) } PathValidationType; > > > > This adds a layer of extensibility that doesn't do a lot. Please consider > > making this less generic. If we want a different validation design, then > > another extension can be defined. We have a poor track record of being > > able to use these nested extension points and it will be more efficient to > > just put the SCVP pieces in their own extension. > > _______________________________________________ > TLS mailing list > TLS@ietf.org <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
