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

We can just let aliases and subaddresses be interpreted as additional
"email-identities".

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

Bernhard

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