On Mon, Jan 6, 2025 at 6:14 PM Eric Rescorla <e...@rtfm.com> wrote:
>
>
>
> On Mon, Jan 6, 2025 at 11:31 AM Michael Richardson <mcr+i...@sandelman.ca>
> wrote:
>>
>>
>> Please note and respect the Reply-To: u...@ietf.org.
>>
>>
>>
>> 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 -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
--
Astra mortemque praestare gradatim
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
