Subject: [dane] local-part case-sensitivity (was: draft-hoffman-dane-smime-03.txt)

From: Peter van Dijk <[email-masked]>
Date: Wed, 16 May 2012 19:43:34 +0200

Hello Paul, list,

On Mar 9, 2012, at 19:53 , Paul Hoffman wrote:

> We have updated the S/MIME draft based on some new interest from a few folks. We cleaned up one technical detail (look for "Base32"), and added a privacy-related security consideration.

Applying base32 in this way ignores that local-parts are case sensitive (RFC5321 2.4, 4.1.2; RFC6530 10.1, 13). I feel that case-sensitivity in SMTP is a mistake, but it's a mistake SMTP/email-related drafts/specs cannot just ignore.

A few suggestions:
1) specify that the local-part is lowercased before encoding it with base32, and clarify that this deviates from relevant specification.
2) specify that whatever choice of case a sender picks has to be present under the _smimecert label.
3) investigate whether Punycode&friends solve this problem in a more satisfying manner.

Other suggestions are welcome, of course.

Kind regards,
-- 
Peter van Dijk
Netherlabs Computer Consulting BV - http://www.netherlabs.nl/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 May 2012 12:53:16 -0700

> 3) investigate whether Punycode&friends solve this problem in a more satisfying manner.

I am completely confused here. The current draft says:
   1.  The user name (the "left-hand side" of the email address, called
       the "local-part" in [RFC2822] and the "local part" in [RFC6530]),
       is encoded with Base32 [RFC4648], to become the left-most label
       in the prepared domain name.  This does not include the "@"
       character that separates the left and right sides of the email
       address.
This preserves any case in the local part. Your suggestion (1) destroys the case. It is also not valid for local parts that do not have clean lower-casing rules; we went through this mess with IDNA2003.

Why not just leave the case as-is?

--Paul Hoffman

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 16 May 2012 22:04:06 +0200

Hello Paul,

> This preserves any case in the local part. Your suggestion (1) destroys the case. It is also not valid for local parts that do not have clean lower-casing rules; we went through this mess with IDNA…

I will try to clarify. Base32 certainly preserves case, and in that sense appears to honor the case-sensitivity requirement in 2822/6530.

However, most (if not almost all) mail servers on the internet treat [email-masked] and [email-masked] as the same user - and 2822/6530 do not prohibit this. If we base32-encode 'chris' but the user chooses to mail from 'Chris', the DNS lookup will not match and his S/MIME cert cannot be verified.

I cannot conceive of an encoding scheme that honors case-sensitivity without hampering the 99% of implementations that are actually case insensitive. Base32 enforces case-sensitivity, which breaks most implementations; a more plain encoding (like encoding 'chris' as 'chris') (apart from having other issues - the exact reason you went with base32) would be case-insensitive and would thus violate 2822/6530.

Kind regards,

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 May 2012 15:18:40 -0700

But we are not talking about sending mail to this name: we are talking about how to find the DNS record for the user. I can add something to the effect of "you need to know what the exact name that would be used is, and it is likely to be lowercase".

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 May 2012 12:38:06 +1000

In message <[email-masked]>, Peter van Dijk
 writes:
> > This preserves any case in the local part. Your suggestion (1) destroys the
>  case. It is also not valid for local parts that do not have clean lower-casi
> ng rules; we went through this mess with IDNA2003.
> 
> 
> I will try to clarify. Base32 certainly preserves case, and in that sense app
> ears to honor the case-sensitivity requirement in 2822/6530.
> 
> However, most (if not almost all) mail servers on the internet treat chris@ex
> ample.com and [email-masked] as the same user - and 2822/6530 do not prohi
> bit this. If we base32-encode 'chris' but the user chooses to mail from 'Chri
> s', the DNS lookup will not match and his S/MIME cert cannot be verified.

You can down case the lookup and return multiple certs with different
cases in the appropriate field in the cert itself.  The client just
needs to do a little bit more work to pick out the correct cert
from the DNS response.

Now I don't know if a cert can specify that it should be matched
case insenitively for the local field or not but if the system
treats the local part as being case insensitive that should be
reflected in the cert or else there are already lots of mis-match
issues.

> I cannot conceive of an encoding scheme that honors case-sensitivity without 
> hampering the 99% of implementations that are actually case insensitive. Base
> 32 enforces case-sensitivity, which breaks most implementations; a more plain
>  encoding (like encoding 'chris' as 'chris') (apart from having other issues 
> - the exact reason you went with base32) would be case-insensitive and would 
> thus violate 2822/6530.
> 
> Kind regards,
> -- 
> Peter van Dijk
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]