On Wed, 7 Nov 2018 20:49,
ijackson(_at_)chiark(_dot_)greenend(_dot_)org(_dot_)uk said:
1. SHA-1 is obsolete.
| The use of SHA-1 for the mapping of the local-part to a fixed string
| is not a security feature but merely used to map the local-part to a
| fixed-sized string made from a well defined set of characters. It is
| not intended to conceal information about a mail address.
2. The use of a cryptographic hash here makes it harder for a server
to conduct an appropriate lookup. For example, if a server defines
that all email addresses
alice+<something>@example.com
are owned by Alice, and Alice tells the server `please advertise
my one OpenPGP key for all my email addresses', it is not clear how
the server could implement that.
The problem here is that the client needs to know how the server handles
this. This is because the client should filter the returned key for a
matching mail-addresses. Actually we have had a discussion about this
recently in Brussels with the outcome that for experiments we now
appened "?l=joe.hacker" to the request. Currently implemented servers
will just ignore these parameters.
2a. The cryptographic hash does not, however, provide any significant
degree of useful obfuscation since a search will usually be able to
reverse it.
See above
2b. The cryptographic hash is not needed for space reasons since URLs
can easily be as long as email addresses.
Right. A constant length can make implementations easier. YMMV.
Further there is no limit on the length of the local part of the
addrspec. It may well exceed the max. length of file names.
3. Supposing the hash were to be retained, choice of base-32 rather
than base-64 is unusual and needs to be justified.
Easy: The standard Base-64 includes a slash and thus the has can't be
used as a file name.
4. The lowercasing of the email address is contrary to the Internet
mail specifications, where case-sensitivity of the email address
is up to the mail domain in question. If the email address were
not obfuscated by hashing it would be easy for the webserver to
handle case-sensitivity by URL remapping.
See my reply to Brian and above.
Suggested modification: Replace this part of the URL with the
URL-encoded email address.
Nope: That breaks existing implementations and would not allow to serve
the data from static files.
II. URL domain name part
The mail system for some domain, and its web server, are not
necessarily on the same host or under the same practical
administration. Often webservers are outsourced.
That is rarely the case but given that I know a pretty large provider
which has this problem, SRV records are used to overcome this problem.
Suggested modification: the domain name part should have a fixed
string prepended.
This is an open question but for a different reason: Current web
browsers have no way to lookup SRV records.
III. Normative status of this document
| Internet-Drafts are draft documents valid for a maximum of six months
| and may be updated, replaced, or obsoleted by other documents at any
| time. It is inappropriate to use Internet-Drafts as reference
| material or to cite them other than as "work in progress."
OTOH, it is a standard practise that RFCs are based on existing
implementations and we have that implemented in in GnUPG 2.1.12 (May
2016) and thus for example also in Debian Stretch
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgpk2n5oDrauX.pgp
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp