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

In message <CFE92643-438F-4878-BB21-C81C39A8B123@netherlabs.nl>, Peter van Dijk
 writes:
> Hello Paul,
> 
> On May 16, 2012, at 21:53 , Paul Hoffman wrote:
> 
> > 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-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 Chris@example.com 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
> Netherlabs Computer Consulting BV - http://www.netherlabs.nl/
> 
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org