Glen thank you for bringing this up. > On Jul 8, 2015, at 5:28 PM, Wiley, Glen <[email protected]> wrote: > > 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.
So are you proposing that SMIME use the same label as OPENPGP for looking for records ? <no-hat> If yes then I’m with you, and I would even be willing to go one step further and rename the label to _emailkey (or something similar) </no-hat> > > 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. > — If you are willing to use the same DNS location to store SMIMEA keys then the text in SMIME becomes even simpler “See RFC-openpgpkey[ref] for how to look up SMIMEA “ <hat=chair> In that case I see no reason to hold up the SMIME draft </hat=chair> Olafur Olafur
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
