Hah, forgot to discuss this topic today. Well, it's not running away. I am really only interested to be diligent with pledge requirements because those will have the biggest variety of potentially crappy software stacks. Registars/MASA ci expect to be much more software agile. But SNI is one such example, where the pledge does need to signal the right info (SNI) to enable "cheaper" cloud registrars, aka: those not owning a separate IPv4 address. See e.g.: AWS cost for IPv4 address.
Now, cloud is a separate case from this threads subject (registar->masa), but i think technically it is correct to ask for SNI support on Registrar. But i am not adament to make a fuzz about it. Lets just agree on the final text for this errata so Rob can close the book on it. Cheers toerless On Fri, Feb 02, 2024 at 08:49:06AM -0500, Michael Richardson wrote: > > Toerless Eckert <[email protected]> wrote: > > Lets maybe finalize next tuesday during our meeting. > > > In general i think that whenever a TLS initiator did learn the TLS > > responder through a URL with a domain name, then it needs to insert the > > domain name as the SNI "server_name". > > > If thats not an unwritten rule, then i'd like to understand why not. > > I think it is. I'm not objecting to that. > As you said, sometimes old/rusty TLS libraries don't do this. > But, the manufacturer knows that, and this can build their MASA based upon > SNI (or not) assumption, and it's fine. > > But, for BRSKI-EST link, we can assume enough modern TLS to allow for SNI > based virtual hosting. > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
