Hi, > Am 11.12.2014 um 20:51 schrieb Rose, Scott W. <[email protected]>: > > Realized the other action item I was assigned to from the interim meeting was > email canonicalization for SMIMEA. I believe it stems from Viktor Dukhovni's > email to the endymail list: > http://www.ietf.org/mail-archive/web/endymail/current/msg00134.html > > I was wondering if we can borrow a page from RFC 4034 Section 6.2 and include > text in the draft Section 3, item 1 in the numbered list: > > 1. The user name (the "left-hand side" of the email address, called > the "local-part" in the mail message format definition [RFC2822] > and the "local part" in the specification for internationalized > email [RFC6530]), is hashed using the SHA2-224 [RFC5754] > algorithm (with the hash being represented in its hexadecimal > representation, to become the left-most label in the prepared > domain name. This does not include the "@" character that > separates the left and right sides of the email address. The > string that is used for the local part is a Unicode string > encoded in UTF-8 **with all upper case letters converted to their > corresponding lower case letters where appropriate.** > > > The text between the '**' is new. The goal is to prevent a situation when > the email address is "[email protected]" and the SMIMEA is created using > "jrandom" as the user name. Would this be enough, or are there scripts > where this would result in different or potentially conflicting owner names?
sorry, if my answer might be a little bit off-topic. When the draft for SMIMEA was posted the first time, I wrote to someone here on the list off-list. I asked, why to use SHA2-224 for the local part of an email address. I thought about useability for many of records in DNS for a large company. That seeing only hashes and nothing readable would make it nearly impossible to find a record again manually without technical help. So I thought about punycode RFC3492. I know the RFC might only be for domains, but I asked myself, why this would not be applied to a local part as well. Many countries would benefit from such a representation, because the have parts of the latin alphabet and therefor just a hand full of characters would need conversion. I am a layperson, so these are just my ideas and there might exists good reasons, why this is not applicable. But at least I did not want to miss the chance to bring up this discussion. And sorry, if this is not 100% answer to this thread. At least it focuses on parts of the SHA2-224 and I wanted to give an optional view. Kind regards Christian -- Bachelor of Science Informatik Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
