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> 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> 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
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
