On Mon, Jan 6, 2025 at 6:14 PM Eric Rescorla <[email protected]> wrote: > > > > On Mon, Jan 6, 2025 at 11:31 AM Michael Richardson <[email protected]> > wrote: >> >> >> Please note and respect the Reply-To: [email protected]. >> >> >> >> 4. Find a sensible way to extend RFC6066 to accomodote other forms of SNI. >> There isn't an IANA registry for this. > > > Just as a technical matter, it's not really possible to extend RFC 6066 > because there > is no way to skip past unknown name types. This is a bug, but it's a bug > we're stuck > with. > > struct { > NameType name_type; > select (name_type) { > case host_name: HostName; > } name; > } ServerName; > > enum { > host_name(0), (255) > } NameType; > > opaque HostName<1..2^16-1>; > > struct { > ServerName server_name_list<1..2^16-1> > } ServerNameList; > > Note that the only length field is in HostName, which means that you don't > know how > long the length field is in other NameTypes, so you can't ignore them. If > this is > the general route you want to take, you'll need a new extension.
Implementations might choke on any new name type alas, but there's no reason from a wire perspective we couldn't say all names are <1..2^16-1> > > -Ekr > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
