Web Key Directory (dealing with subaddressing?)

[Guilhem Moulin]

On Tue, 17 May 2016 at 15:07:37 +0200, Bernhard Reiter wrote:
> More thoughts on
> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git;a=blob;f=misc/id/openpgp-webkey-service/draft.org
> 
> 145 all upper-case ASCII characters in a User ID are mapped to lowercase.
> 146 Non-ASCII characters are not changed.
> 147 
> 148 The so mapped "local-part" is hashed using the SHA-1 algorithm.
> 
> What about the common pattern of subaddressing?
> 
> From https://www.rfc-editor.org/rfc/rfc5233.txt
> 
> | One common way of encoding
> |   'detail' information into the local-part is to add a 'separator
> |   character sequence', such as "+", to form a boundary between the
> |   'user' (original local-part) and 'detail' sub-parts of the address,
> [..]
> |   Typical uses of subaddressing might be:
> |
> |   o  A message addressed to "ken+sieve at example.org" is delivered into a
> |      mailbox called "sieve" belonging to the user "ken".
 
> Because it depends on the server how and if it interprets the local-part,
> I think there is merit in letting the server decide, how to treat it.

Right, the recipient delimiter is a valid character in the RFC 5321
local-part that is not allowed in account names.  Clients shouldn't
assume that messages sent ‘u+e at example.net’ are delivered to
‘u at example.net’.  For instance ‘u+e’ and ‘u’ can very well be two
different account names.

> We could just use the URL to transfer the full address or
> /domain-part/local-part and then have the server decide.

This conflicts with hashing the local part, since the server needs to
reconstruct the original address from the given URL.  I agree with
Werner that it not desirable to have non URL-safe characters in the
local parts (such as ‘/’), but a base32-URL or base64-URL would do.
Furthermore, letting the server interpret the *original* local part
solves the case sensitivity issue I mentioned earlier.

On a related note, should the server ensure that the same key is
delivered for the account itself and its aliases?  (Such as for
login at example.org and full.name at example.org.)  Since messages sent to
either address are routed to the same account, it make sense to use the
same key, but of course a downside is that it exposes the server's alias
database.  All in all I think the decision should be left to the user or
service operator.

-- 
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/20160518/403d32ce/attachment.sig>