Re: [Spasm] Name Constraints on Email Addresses

[Russ Housley <[e-mail]>]

> On Apr 2, 2017, at 8:12 PM, Viktor Dukhovni <[e-mail]> wrote:
> 
> On Sun, Apr 02, 2017 at 12:25:36PM -0400, Russ Housley wrote:
> 
>> At the LAMPS WG session is Chicago, we discussed the concerns raised during
>> IETF Last Call on draft-ietf-lamps-eai-addresses.  The discussion proposed
>> a different way forward for constraints on email addresses.  The suggestion
>> has two parts.  First, an update to RFC 5280, Section 4.2.1.10.  Second,
>> have the constraints against the rfc822Name apply to the SmtpUTF8Name by
>> mapping any A-Labels that paper in the constraint to U-Labels.  No
>> SmtpUTF8Name constraints are ever needed.
> 
> The proposed interpretation of rfc822Name constraints as SMTPUtf8Name
> constraints will of course entail not only decoding A-labels from
> to U-labels, but also an identity mapping on NR-LDH labels.

Yes, indeed.

> The proposed direction of the mapping (decoding constraints to
> UTF-8, rather than encoding SMTPUtf8 subjectAltNames to A-labels)
> is crucial and correct.  Decoding from punycode to UTF-8 is a very
> mechanical process that does not involve any input normalization,
> or differences in the rules beteen IDNA2003 and IDNA2008.
> 
> In particular, I think we can add a punycode *decoder* to OpenSSL,
> without introducing any dependencies on external libraries.  Adding
> an encoder would probably require libicu or similar, and would be
> a significant burden.
> 
> Well, we could perhaps be able to continue to express mailbox
> constraints for ASCII localparts, but it is hardly worth it.

At the meeting, no one knew of anyone using a mailbox constraint, and eliminating that case really does make things much simpler.

> 
>> It was observed that the conversion of an A-Lable to a U-Label and back
>> to an A-Label may not alway give the same string.  Perhaps we could say:
>> Conforming CAs SHOULD only include A-Labels in the rfc822Name constraint
>> that result in the same result when converted to a U-Label and back again
>> to an A-Label.
> 
> It suffices for the domain names that will appear in SMTPUtf8Name
> subjectAltName elements of the certificate to match the decoded
> rfc822Name constraints.
> 
> The real complexity is in whatever mapping, if any, the application
> has to do to construct a "canonical" reference identifier from the
> sender address of the message.  The applications I use (at least
> all the browsers and the Postfix MTA) perform the mappings from
> UTS#46 (<http://unicode.org/reports/tr46/#Mapping>) thereby producing
> the same A-label form for many case-variants of UTF-8 strings.
> Thus, for example:
> 
>    $ posttls-finger -c -Lsummary духовный.org 
>    posttls-finger: духовный.org asciified to xn--b1adqpd3ao5c.org
>    posttls-finger: Verified TLS connection established to smtp.imrryr.org[108.5.242.66]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> 
>    $ posttls-finger -c -Lsummary Духовный.org 
>    posttls-finger: Духовный.org asciified to xn--b1adqpd3ao5c.org
>    posttls-finger: Verified TLS connection established to smtp.imrryr.org[108.5.242.66]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> 
> In OpenSSL I don't think that the library can reasonably be expected
> to perform the UTS#46 mappings.  Instead, the application will be
> responsible for applying any such mapping to hand the library an
> email address whose domain part is already suitably mapped.
> 
> Would it be appropriate for the draft to align to real-world practice
> and converge on UTS#46 mapping of U-labels?

I think that John Klensin strongly suggested alignment with IDNA2008.  I do not think John is on this list, so I will try to channel his comment.  The UTS#46 mapping results in more cases where A-Label —> U-Label —> A-Label translations do not return the string that one started with.

> 
>> The represent a significant change in direction for this document.  Please
>> speak promptly is you disagree with this new direction.
> 
> Looks good to me.

Thanks.

Russ