Web Key Directory

[Werner Koch]

On Sat, 14 May 2016 00:05, guilhem at fripost.org said:

> I don't have data to confirm or refute your claim that “almost all MTAs
> treat the "local-part" case-insensitive”, but doing so client side
> violates RFC 5321 sec. 4.1.1: “The syntax of the local part of a mailbox

Two support my view let me quote from the Exim specs:

  10.20 Case of letters in address lists
  --------------------------------------
  
  Domains in email addresses are always handled caselessly, but for
  local parts case may be significant on some systems (see
  caseful_local_part for how Exim deals with this when routing
  addresses). However, RFC 2505 (Anti-Spam Recommendations for SMTP
  MTAs) suggests that matching of addresses to blocking lists should be
  done in a case-independent manner. Since most address lists in Exim
  are used for this kind of control, Exim attempts to do this by
  default.
  
  The domain portion of an address is always lowercased before matching
  it to an address list. The local part is lowercased by default, and
  any string comparisons that take place are done caselessly. This means
  that the data in the address list itself, in files included as plain
  file names, and in any file that is looked up using the "@@"
  mechanism, can be in any case. However, the keys in files that are
  looked up by a search type other than lsearch (which works caselessly)
  must be in lower case, because these lookups are not case-independent.
  
  To allow for the possibility of caseful address list matching, if an
  item in an address list is the string "+caseful", the original case of
  the local part is restored for any comparisons that follow, and string
  comparisons are no longer case-independent. This does not affect the
  domain, which remains in lower case.  However, although independent
  matches on the domain alone are still performed caselessly, regular
  expressions that match against an entire address become case-sensitive
  after "+caseful" has been seen.

I recall from the days I used sendmail, that it works the same.  (Anyone
here with examples for mail providers who compare case-sensitive?)

I assume that the IETF mail folks will complain about this violation, as
they did for OpenPGP-DANE.  The final RFC may need to remove the
downcasing.  In this case GnuPG may simply not comply to the RFC - as it
does not for OpenPGP-DANE.  The downcasing addresses a real world case:
People often write their mail address like Werner.Koch at example.org even
if the canonical name would be werner.koch at example.org - that makes the
address easier to read adn remember.

> MUST conform to receiver site conventions”.  (By the way RFC 2821 and
> 2822 have respectively been obsoleted by RFC 5321 and 5322 in 2008 :-)

That is actually interesting.  RFC-822 is in the status INTERNET
STANDARD and also listed as STD0011.  However the nits checker of the
IETF's submission system complains about 822 and recommends 2822.  2822
is a PROPOSED STANDARD and 5322 has even moved to DRAFT STANDARD - the
nits check still recommends 2822.  That is what I did.

> protocol should leave the local-part as is, and maybe recommend to try
> again with a canonical local part (lower case and maybe even Unicode
> normalization, see RFC 6530 sec. 10.1) upon 404.

You don't want to get into Unicode normalization.  This makes homograph
attacks even easier.  In fact, I consider the entire i18n of the
local-part and also of domains to be a bad decision which creates more
problems than it solves.  Identifiers should be made up of concise set
of symbol; the real name and the comments should be subject to i18n.

> On the other, while I don't understand why the domain part would appear
> twice in each lookup URI, lowercasing the second occurrence (within the

I thought long about this but then introduced it with the idea to help
implementing the directory for a multi-domain service.  Meanwhile I
think the advantages and disadvantages are balanced out and removing the
second occurrence would make the protocol simpler.  Unless I hear another
opinion, I am going to change this for -01.

> needs to decode each XN-label into an U-label (or vice versa) using the
> Punycode algorithm of RFC 3492 (cf. RFC 5890).

That was my very original idea: Leave this stuff to the web server so
not to get into this trouble.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
    /* EFH in Erkrath: https://alt-hochdahl.de/haus */