Web Key Directory (dealing with subaddressing?)

[Bernhard Reiter]

Am Mittwoch, 18. Mai 2016 19:15:43 schrieb Guilhem Moulin:
> 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.

[citation moved further to the top:]
> Furthermore, letting the server interpret the *original* local part
> solves the case sensitivity issue I mentioned earlier.

I take it that you agree that it would be an advantage to let
the server see the original local-part and decide how to handle it.


The next question is
== How to transfer the original local-part?

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

Yes, only using it in the url would be feasable exclusively in the case when 
we do not hash.

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

The goal is to ease implementations on the server and client sides, I assume.
As towards the danger of "non-url-safe" characters:
The server implementations will have to saveguard against malicious requests
anyway. If we define to interpret everything right off  xyz/domain-part/
as being the local-part, I think there is no real danger and usual 
URL percent coding of RFC3986 could be used, aka %2F for '/'.


== email alias names

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

The question also occurred to me. I have not been giving it much thought
so far. One design idea could be that the client will add more user ids
(as a user often also needs to add more "identities" in the client to use
a specific from: address with real name and identify which emails are 
considered "mine".)

Best,
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/20160601/814cf2ad/attachment.sig>