> The problem is that, having done this, can we use the result in SNI?
> The answer is mostly no. That's why there was some push to do something SNI
> compatible, which means it has to look like a dNSName.
And pedantically the answer is it looks like an unqualified DNS name, which is
not what the
Achim Kraus wrote:
> I may fail to understandiung your question or intention. Maybe you
> clarify it.
> Your initial question in "draft-tls13-iot" was:
> "I was looking for a SN, or SAN that would encode EUI64, and I feel
> surprised not to find one."
> But, if you lik
Hi Michael,
> TL;DR> Help us avoid stuffing non-DNS strings into
>SubjectAltName dNSName when doing device to device (D)TLS.
I may fail to understandiung your question or intention.
Maybe you clarify it.
Your initial question in "draft-tls13-iot" was:
"I was looking for a SN, or SAN th
On Mon, Jan 6, 2025 at 9:31 PM Watson Ladd wrote:
> On Mon, Jan 6, 2025 at 6:14 PM Eric Rescorla wrote:
> >
> >
> >
> > On Mon, Jan 6, 2025 at 11:31 AM Michael Richardson <
> mcr+i...@sandelman.ca> wrote:
> >>
> >>
> >> Please note and respect the Reply-To: uta@ietf.org.
> >>
> >>
> >>
> >> 4. F
Hi Michael,
>> So, please: Is it about direct EUI64 support in x509? Or about omit
>> EUI64 in device certificates?
>
> This is about what SNI supports vs what X509 supports.
Thanks for the clarification.
br
Achim
___
Uta mailing list -- uta@ietf.or
