Subject: [ietf-smtp] "decoded local-part" for dane-smime and dane-openpgp

From: Sean Leonard <[email-masked]>
Date: Wed, 9 Mar 2016 15:51:44 -0800

Currently, dane-smime says:
Section 3:

    1.  The user name (the "left-hand side" of the email address, called
        the "local-part" in the mail message format definition [RFC2822 <https://tools.ietf.org/html/rfc2822>]
        and the "local part" in the specification for internationalized
        email [RFC6530 <https://tools.ietf.org/html/rfc6530>]) should already be encoded in UTF-8 (or its
        subset ASCII).  If it is written in another encoding it should be
        converted to UTF-8.  Next, it is hashed using the SHA2-256
        [RFC5754 <https://tools.ietf.org/html/rfc5754>] algorithm, with the hash truncated to 28 octets and
        represented in its hexadecimal representation, to become the
        left-most label in the prepared domain name.  Truncation comes
        from the right-most octets.  This does not include the at symbol
        ("@") that separates the left and right sides of the email
        address.

The problem is that this text does not distinguish between the 
local-part production, and the decoded (unescaped) local-part characters.

As I am discussing in another Internet-Draft elsewhere (in progress, not 
necessary to cover right now here), the local-part has evolved basically 
to be a string of Unicode scalar values, which may or may not be escaped 
or quoted. Specifically:

[email-masked]
"johnny\.apple"@example.com
"johnny.ap\ple"@example.com

all have the same local-part characters:
johnny.apple

It is therefore appropriate that the local-part be isolated from the 
entire e-mail address production, and unescaped/unquoted (i.e., 
decoded). All three of the above examples should result in the same 
SHA-2-256 value, namely 
A3E3740AD57C3A2D1927DFED24B719FA8C4BBC006E1D0DE30670974B257D4FDD. Note 
that this issue has nothing to do with case.

While we are at it, RFC 5322 (Internet Message Format) still permits 
CFWS (but not RFC 5321 (SMTP)). Therefore, these also have equivalent 
local-parts:

johnny.apple (seed!) @ example.com
    (could be a song)
       (mis(ter)) "j\oh\nny.apple"@example.com

Note that the term "user name" is not really ideal or correct in 
draft-ietf-dane-smime-10. Details were already hashed out a long time 
ago and are discussed in RFC 5322 sec. 3.4.1 and RFC 5321 sec. 2.3.11.

I therefore propose the following text:
Section 3:

    1.  a.  The local part of the address ("local-part" [RFC5321]
        [RFC5322] [RFC6530]) is isolated and decoded, i.e., de-commented,
        whitespace-folded, unquoted, and unescaped, as appropriate. The
        resulting UTF-8 string is the "decoded local part". Note that
        the at symbol ("@") that separates the left and right sides
        of the email address is not part of the local part.

        b.  The decoded local part is hashed using the SHA2-256
        [RFC5754 <https://tools.ietf.org/html/rfc5754>] algorithm, with the hash truncated to 28 octets and
        represented in its hexadecimal representation, to become the
        left-most label in the prepared domain name.  Truncation comes
        from the right-most octets.

I propose similar text for draft-ietf-dane-openpgpkey. Assuming we have 
agreement, I can tackle that draft accordingly.

Sean

---

From: Sean Leonard <[email-masked]>
Date: Fri, 11 Mar 2016 04:59:35 -0800

On 3/11/2016 4:51 AM, Paul Wouters wrote:
> On Wed, 9 Mar 2016, Sean Leonard wrote:
>
>> Subject: [dane] "decoded local-part" for dane-smime and dane-openpgp
>
>> As I am discussing in another Internet-Draft elsewhere (in progress, 
>> not necessary to cover right now here), the local-part has evolved 
>> basically to be a string of Unicode scalar values, which may or may 
>> not be escaped or quoted. Specifically:
>
>> decoded). All three
>> I propose similar text for draft-ietf-dane-openpgpkey. Assuming we 
>> have agreement, I can tackle that draft accordingly.
>
> I believe the chairs stated that the experiments of dane for
> openpgpkey and smime can continue without tackling every corner case
> of local-parts. Fixing the local-parts is up to th email community,
> not the dane community.

There is nothing to "fix" in this comment.

"paul"@nohats.ca
"p\a\u\l"@nohats.ca
[email-masked]

are all distinct e-mail address strings, that represent the local part:
paul

This is hardly a corner case; it's just the way that e-mail addresses work.

Are you saying that you believe that those three variations should 
result in three different SHA-256 hashes?

Sean

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Mar 2016 07:51:38 -0500 (EST)

> The problem is that this text does not distinguish between the local-part 
> production, and the decoded (unescaped) local-part characters.
>
> necessary to cover right now here), the local-part has evolved basically to 
> be a string of Unicode scalar values, which may or may not be escaped or 
> quoted. Specifically:

> It is therefore appropriate that the local-part be isolated from the entire 
> e-mail address production, and unescaped/unquoted (i.e., decoded). All three

So while I encourage your comments and drafts, I don't believe at this
point any changes should be made to either dane document.

Paul