[dane] proposed text for openpgpkey email translation rules

Paul Wouters <paul@nohats.ca> Thu, 26 February 2015 14:33 UTC

Date: Thu, 26 Feb 2015 09:33:17 -0500
From: Paul Wouters <paul@nohats.ca>
To: Brian Dickson <brian.peter.dickson@gmail.com>, Viktor Dukhovni <ietf-dane@dukhovni.org>
Message-ID: <alpine.LFD.2.10.1502260917350.28451@bofh.nohats.ca>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="ISO-8859-15"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/95pccNGkLdsjAWEorQwDGaceEz8>
Cc: "dane@ietf.org" <dane@ietf.org>
Subject: [dane] proposed text for openpgpkey email translation rules
Precedence: list

On Wed, 25 Feb 2015, Brian Dickson wrote:

> To use the gmail example, I just did a test.
> 
> I was previously unaware of the "s/\.//g" behavior. But, it is real.
> 
> So, I sent mail to a never-before-used variant of my name, "br.i.an" instead of "brian".
> Lo and behold, it was delivered to my mailbox.
> 
> If the goal was to preserve this behavior, while having MUAs look up keys, without a policy mechanism, it would be necessary to publish
> 2^(N-1) records for every name of length N.
> 
> If the average length of a name were 11 characters, then 2^10 = 1024 records would be needed per user. 
> This takes O(10e9) and turns it into O(10e12), of thing which have to be hashed, signed, and then NSEC/NSEC3-ified.
> 
> So, the publishing side takes a disproportionate hit.
> 
> Have the client understand a very limited set of case-folding rules, which could be used universally, is clearly preferable, even to the
> client, IMHO.

Agreed. I think the document(s) should stay away from interpreting the
LHS. But it would be worth adding a subsection into the Location
section. How about:

 	3.1 Email address variants

 	Most SMTP servers treat the user part of the email address as case
 	insensitive. This means that "Hugh@example.com" could be different email
 	address from "hugh@example.com" but both email addresses would end up at
 	the same enduser. The OPENPGPKEY lookup for both addresses would result
 	in a different SHA-224 value. As some input methods to email clients
 	auto-correct to using an uppercase for a first name, an email client
 	supporting this document might want to interact with the user and try
 	a lower-cased username for an OPENPGPKEY lookup. Other mail servers
 	allow other kind of email translation rules, such as automatically
 	matching "username+anystring@example.com" to "username@example.com",
 	or allowing "." characters to be placed anywhere in the address so
 	"first.last@example.com" matches "firstlast@example.com". While publishers
 	can add duplicate or CNAME entries for the OPENPGPKEY records to match
 	these variants, email clients might want to try some (obvious) variations.

I think this would also apply to the SMIMEA document.

Paul

[dane] proposed text for openpgpkey email transla… Paul Wouters