Re: [Uta] Browser behavior in draft-ietf-uta-rfc6125bis

[Viktor Dukhovni <[e-mail]>]

On 26/1/2023 7:58 pm, Rob Sayre wrote:

> For instance, ☕.example becomes xn--53h.example and not failure. 
> [UTS46] [RFC5890]"

Yes, thus, for example, Postfix via libicu (my terminal doesn't actually 
display "☕", but it was part of the input argument anyway):

$ posttls-finger "☕.example"
posttls-finger: ☕.example asciified to xn--53h.example
posttls-finger: Destination address lookup failed: Host or domain name 
not found. Name service error for name=xn--53h.example type=MX: Host not 
found, try again

But but I don't see how this is relevant to the security of certificate 
validation. If the application wants to authenticate "☕.example", it 
matches the A-label form to the certificate. Perhaps it should have 
refused to communicate with "☕.example", but that question is I think at 
a different layer. If an EAI-capable MUA addresses email to "☕.example" 
(for some domain-name-valued "example"), and traffic to that domain is 
subject to authenticated TLS, then Postfix will authenticate 
"xn--53h.example", ignoring MX indirection for the moment).

-- 
Viktor.