Web Key Directory

[Guilhem Moulin]

Hi Werner,

On Mon, 16 May 2016 at 09:47:40 +0200, Werner Koch wrote:
> 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:
> […]

Which is totally fine as long as it only concerns the last hop, not the
submission servers or SMTP clients along the way.  Section 2.3.11 of RFC
5321 is actually clearer than section 4.1.1 I previously cited:

    “Consequently […] the local-part MUST be interpreted and assigned
     semantics only by the host specified in the domain part of the
     address.” — https://tools.ietf.org/html/rfc5321#section-2.3.11

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

Postfix does the same for virtual(5) users and lookup table types other
than those based or regular expressions:

    CASE FOLDING
       The search string is folded to lowercase before database lookup.
       As of Postfix 2.3, the search string is not case folded with
       database types such as regexp: or pcre: whose lookup fields can
       match both upper and lower case.

    http://www.postfix.org/virtual.5.html
 
> 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.

FWIW I also think it's a pity that RFC 5321 allows the local part to be
treated in a case-sensitive manner.  But standard there is, and while I
don't expect humans to be RFC-compliant I do expect software and
protocols to be.  (At least I would file a bug upon finding out that my
MUA turns the envelope sender address to lowercase.) 

>> 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.

Right.  IMHO name-based virtual hosts is the way to go for multi-domain
services.  Whether the https://$hostname/.well-known/openpgpkey/ URL is
mapped to the directory ‘/path/to/wkd/$hostname/’ or something else
(including database queries) is a webserver configuration detail left to
the discretion of the service operator, and should be beyond the scope
of this standard.

Cheers,
-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20160516/750fe273/attachment-0001.sig>