[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