Web Key Directory

[Guilhem Moulin]

On Fri, 13 May 2016 at 21:11:55 +0200, Werner Koch wrote:
> Yes, that is the idea.  application/vnd.gnupg.wkd will be registered in
> the vendor-tree as per RFC-6833.  Given that the GnuPG Project controls
> the gnupg.{org,net,com} domains there should never be a conflict with
> the vendor name even without having done the registration.

Alright, that great to hear.  Something else I was something about:

   66 OpenPGP defines its User IDs, and thus the mail address, as UTF-8
   67 strings.  To help with the common pattern of using capitalized names
   68 (e.g. "Joe.Doe at example.org") for mail addresses, and under the premise
   69 that almost all MTAs treat the "local-part" case-insensitive and that
   70 the "domain-part" is required to be compared case-insensitive anyway,
   71 all upper-case ASCII characters in a User ID are mapped to lowercase.
   72 Non-ASCII characters are not changed.
   […]
   82 For example the URI to lookup the key for Joe.Doe at Example.ORG is:
   83 
   84       https://example.org/.well-known/openpgpkey/
   85       hu/example.org/iy9q119eutrkn8s1mk4r39qejnbu3n5q

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
MUST conform to receiver site conventions”.  (By the way RFC 2821 and
2822 have respectively been obsoleted by RFC 5321 and 5322 in 2008 :-)
Therefore a client MUST NOT do local-part normalization without prior
knowledge of the MTA's normalization method.  IMHO the key discovery
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.

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
URL) is not enough for internationalized domain names: indeed the client
needs to decode each XN-label into an U-label (or vice versa) using the
Punycode algorithm of RFC 3492 (cf. RFC 5890).

-- 
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/20160514/2b867293/attachment.sig>