Subject: [dane] SMIMEA, record locating as in OPENPGPKEY

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 8 Jul 2015 21:28:58 +0000

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-masked]", 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

---

From: "Peter van Dijk" <[email-masked]>
Date: Thu, 09 Jul 2015 15:04:36 +0200

Hello Glen,

On 8 Jul 2015, at 23:28, Wiley, Glen wrote:

> How would folks feel about updating the SMIMEA draft to use language 
> similar to section 3 in the OPENPGPKEY draft:

As I understand it, the SMIMEA draft, and *especially this part*, is on 
hold until we figure out what’s right for OPENPGPKEY, and perhaps even 
gain some operational experience with it. It would seem pointless to 
copy this language now, especially with the amount of disagreement 
people are having with the language as it stands now — we would just 
keep copying changes, better to just wait until OPENPGPKEY has settled 
down.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 9 Jul 2015 15:16:05 +0000

> On Jul 9, 2015, at 9:04 AM, Peter van Dijk <[email-masked]> wrote:
> 
> Hello Glen,
> 
> As I understand it, the SMIMEA draft, and *especially this part*, is on hold until we figure out what’s right for OPENPGPKEY, and perhaps even gain some operational experience with it. It would seem pointless to copy this language now, especially with the amount of disagreement people are having with the language as it stands now — we would just keep copying changes, better to just wait until OPENPGPKEY has settled down.

To be fair, I think I counted about 10 people on the list who urged to proceed with the SMIMEA draft.  In this case, I think the perfect is the enemy of the good.

Eric

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 10 Jul 2015 09:14:42 -0400

Glen
thank you for bringing this up. 

> On Jul 8, 2015, at 5:28 PM, Wiley, Glen <[email-masked]> wrote:
> 
>    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:
> 
>       the "local-part" in the mail message format definition [RFC2822 <https://tools.ietf.org/html/rfc2822>]
>       email [RFC6530 <https://tools.ietf.org/html/rfc6530>]) should already be encoded in UTF-8 (or its subset
>       using the SHA2-256 [RFC5754 <https://tools.ietf.org/html/rfc5754>] algorithm, with the hash truncated to

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>

>       called the "domain" in RFC 2822 <https://tools.ietf.org/html/rfc2822>) is appended to the result of step
> 3.1 <https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03#section-3.1>.  Email address variants
> 
>    [RFC5321 <>] and its predecessors have always made it clear that only
> — 

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

---

From: Florian Kirstein <[email-masked]>
Date: Fri, 10 Jul 2015 15:28:14 +0200

Hi,

> To be fair, I think I counted about 10 people on the list who urged to proceed with the SMIMEA draft.  In this case, I think the perfect is the enemy of the good.

I would count myself as 11th there, but those people voted against
delaying SMIMEA for another year, not for pushing without discussions.

There indeed are quite some points in heavy discussion about the
localpart lookup mechanism and I am pretty sure there will be an update
to the OPENPGPKEY draft in this respect soon. I would wait with updating
the SMIMEA draft in this respect until that point. 

Of course the option Olafur just mentioned, simply referencing the
OPENPGPKEY standard there, also would be OK. But copy&pasting the current,
possibly soon-to-be changed version, no.

The more important point to advance the draft is the assignment of a RRtype.
Viktor pointet out that a requirement for that is the settling on the
RRDATA format. This is different for SMIMEA (more like TLSA than
OPENPGPKEY) so the question would be: does anybody see any problems
on that side, or can we consider that agreed?

Greetings,
Florian

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstrasse 15, 81669 Muenchen

Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

---

From: "Wiley, Glen" <[email-masked]>
Date: Mon, 13 Jul 2015 22:10:32 +0000

Thanks Peter.

My hope here is that we settle the question for both as quickly as we can
and move forward with both drafts.  The goal in mind when I suggested that
is to try to nudge folks toward settling the question.

I agree that we don¹t want to ³keep copying changes².
-- 
Glen Wiley

Principal Engineer
Verisign, Inc.
(571) 230-7917

http://vbsdcon.com

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

On 7/9/15, 9:04 AM, "Peter van Dijk" <[email-masked]> wrote:

>hold until we figure out what¹s right for OPENPGPKEY, and perhaps even
>people are having with the language as it stands now ‹ we would just
>_______________________________________________
>dane mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dane