[dane] SMIMEA, record locating as in OPENPGPKEY

["Wiley, Glen" <[e-mail]>]

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 "[e-mail]", 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.
[phone]

http://vbsdcon.com

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A