Re: [Spasm] Name Constraints on Email Addresses

[Viktor Dukhovni <[e-mail]>]

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.

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.

> 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?

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

Looks good to me.

-- 
	Viktor.