[solved] Re: Web Key Directory (dealing with subaddressing?)

Bernhard Reiter bernhard at intevation.de
Mon Jun 27 17:49:20 CEST 2016

Am Mittwoch, 1. Juni 2016 09:52:16 schrieb Bernhard Reiter:
> > > What about the common pattern of subaddressing?
> >
> > Still part of the local-part thus it does not matter.  It is an open
> > question on how to handle such sub-addressing.  I discussed this in
> > detail with Neal while thinking about TOFU; our conclusion was that it
> > is to early to settle for a standard on how to canonicalize such
> > addresses. If that makes sense at all.
> The server must know, as it will do the email routing.
> This is why me (and I believe  Guilhem, too) think that
> transfering the original localpart to the server and let the
> server do the decisions about an and if to handle this
> maybe be a good idea to consider further.

Last week Werner and Andre (that I had the pleasure to meet in person)
convinced me that doing the canonicalisation and hasing on client side
is a good approach.

What convinced me is, that the client also will have to "interpret" the 
local-part, when it compares the user-id of the returning
pubkey to the email-address it wants to encrypt and send email to. 
Thus it makes sense to use a common interpretation on client-side anyway. And 
if we do that, why not hash right away to make the server implementations 

We can just let aliases and subaddresses be interpreted as additional

As for case-insensitivity in the local part, I believe it is okay to ignore 
rarely used RFC parts in order to get a system up and running for the common 


www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160627/3dc92e1a/attachment.sig>

More information about the Gnupg-devel mailing list