Re: [TLS] Extensibility in SCVP draft

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 wrote: > > On Tue, Jul 26, 2022 at 9:08 AM Ashley Kopman > wrote: > > Are you concerned that if additional

Re: [TLS] Extensibility in SCVP draft

On Tue, Jul 26, 2022 at 9:08 AM Ashley Kopman 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

Re: [TLS] Extensibility in SCVP draft

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 likel

Re: [TLS] Extensibility in SCVP draft

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’r

Re: [TLS] Extensibility in SCVP draft

That is a fair point. I will make the update and submit a new draft. Thank you for the feedback. Ashley Kopman > > On Jul 25, 2022, at 4:25 PM, Russ Housley wrote: > > I was thinking the same thing during the presentation. An extension for > SCVP seems fine to me. Then in the future, if

Re: [TLS] Extensibility in SCVP draft

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 wrote: > > Take this: > > str

Re: [TLS] Extensibility in SCVP draft

> 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. Yes! For example, the "SNI hostname" is such a nested construct, nobody uses anything other than "a hostname string." Wrappin

[TLS] Extensibility in SCVP draft

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