How would folks feel about updating the SMIMEA draft to use language similar to section 3 in the OPENPGPKEY draft:
Location of the OPENPGPKEY record The DNS does not allow the use of all characters that are supported in the "local-part" of email addresses as defined in [RFC2822<https://tools.ietf.org/html/rfc2822>] and [RFC6530<https://tools.ietf.org/html/rfc6530>]. Therefore, email addresses are mapped into DNS using the following method: o 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 Wouters Expires October 03, 2015 [Page 4] ________________________________ <https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03#page-5> Internet-Draft DANE for OpenPGP public keys April 2015 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 turned into lowercase and 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. o The string "_openpgpkey" becomes the second left-most label in the prepared domain name. o The domain name (the "right-hand side" of the email address, called the "domain" in RFC 2822<https://tools.ietf.org/html/rfc2822>) is appended to the result of step 2 to complete the prepared domain name. For example, to request an OPENPGPKEY resource record for a user whose email address is "[email protected]", an OPENPGPKEY query would be placed for the following QNAME: "c93f1e400f26708f98cb19d936620da35 eec8f72e57f9eec01c1afd6._openpgpkey.example.com". The corresponding RR in the example.com zone might look like (key shortened for formatting): c9[..]d6._openpgpkey.example.com. IN OPENPGPKEY <base64 public key> 3.1<https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03#section-3.1>. Email address variants Mail systems usually handle variant forms of local-parts. The most common variants are upper and lower case, which are now invariably treated as equivalent. But many other variants are possible. Some systems allow and ignore "noise" characters such as dots, so local parts johnsmith and John.Smith would be equivalent. Many systems allow "extensions" such as john-ext or mary+ext where john or mary is treated as the effective local-part, and the ext is passed to the recipient for further handling. This can complicate finding the OPENPGPKEY record associated with the dynamically created email address. [RFC5321] and its predecessors have always made it clear that only the recipient MTA is allowed to interpret the local-part of an address. A client supporting OPENPGPKEY therefor MUST NOT perform any kind of mapping rules based on the email address. As the local- part is converted to lowercase before hashing, case sensitivity will not cause problems for the OPENPGPKEY lookup. -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 http://vbsdcon.com A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
