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:
johnny(_dot_)apple(_at_)example(_dot_)com
"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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp