That is a good suggestion. I will look into expanding on the text to address this concern.
Thank you, Ashley > On Jul 26, 2022, at 1:33 PM, Rob Sayre <[email protected]> wrote: > > On Tue, Jul 26, 2022 at 9:08 AM Ashley Kopman <[email protected] > <mailto:[email protected]>> wrote: > > 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. > > Hi, > > It's correct that this is my concern, and I thought you might consider adding > text along these lines to the document. > > I don't feel strongly about this issue, though. > > thanks, > Rob > > > > > > > If I have missed your point, please let me know. > > Thank you, > Ashley Kopman > >> On Jul 25, 2022, at 11:30 PM, Rob Sayre <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> > <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/tls >> <https://www.ietf.org/mailman/listinfo/tls> >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
