Re: draft-koch-openpgp-webkey-service-21 early Httpdir review

Hi!

It is quite some time since you posted your review with questions and I
apolize for not replying earlier.  So, here are my comments:

On Tue, 17 Feb 2026 17:48, Martin Thomson said:

> * A means of accessing a directory of public keys over HTTP

This is in particular for *PGP keys and not form X.509.  Extending this
to X.509 will is not as easy as some may think.  Actually there are
servers (crypto gateways) which use the Web Key Directory (WKD) for
X.509.  But that is for now out of scope.

> * A predominantly SMTP-based protocol for populating those directories
> * Security-relevant, because getting the wrong key will allow the wrong person
> to read mail

I do not consider this security critical because the *PGP uses other
methods to validate a key.  The WKD however can give a good initial
validity for a key for a not yet used recipient address.

> The protocol defines a special domain name label. 
[..]
> owners is unwise.  I strongly recommend against this practice.  This is more
> the case that the "direct" version seems to be a more practical path anyway. 
> The /.well-known prefix was reserved for exactly this sort of thing.

I fully agree with you here but in the real world there are large mail
service provides who do not full control their own domain.  For example
because the web part might be be sold to an advertising company.  The
German Telekom is one example for such scheme.  Thus for the largest
German MSP is is not possible to put anything below ~/.well-known.  To
address this problem the protocol has been extended to work with the
openpgp domin label.

> the current design forces that service to always include "openpgpkey" in its
> name.  Overall, having the domain in the path always would be more robust.

The assumption of the entire protocol is that for a mail domain a
corresponding web domain with the same name exists.  Thus there is no
need for putting the domain into the path.  With the "openpgpkey."
variant this is different because this may indeed be used to put several
mail domains under one central openpgpkey.example.org domain.  There are
still problems with adding all the served domains to the respective TLS
certificate.

> # Redundant local part
>
> It's not clear to me why the local part of the email address is included

That was on request from Protonmail because they do a diect lookup of
the mailbox.  I think this is a no-brainer because it an imply be
ignored

> multiple times.  The role of SHA-1 here is also pretty questionable (more
> below).  This is something that percent encoding is pretty good at handling. 

Percent encoding would lead to long names, some may be too large to be
used as a file name.  There are also processing advanatages of having a
name with a fixed length.

> The half-hearted attempt at canonicalization used here is a constraint on mail
> operators (who might want t@ and T@ to go to different inboxes) and

We are all Postmaster ;-).  In practise almost all mail systems ignore
the case-sensitivity and *PGP does the same for the web of trust.  t@
and T@ being different is a secuity problem at the UI level.

> insufficient to capture the range of equivalence practices (like
> a.b.c@gmail.com == abc@gmail.com or the common foo+bar@ == foo@).  Better to

This has been discussed at the early stages but it would require a lot
of specila casing or even a syntax to describe the scheme on a per
domain abse.  Can be done but need to be refelcted also in all MUA with
*PGP support when comparing From addresses and *PGP User-Ids.  To
complicated, better add the variants as additional user ids.

> # Case sensitivity

> If you really want to tangle with this particular problem, which includes
> internationalized domain names, the current design doesn't really hold
> up well

There is no no way to correctly handle internationalized domains witout
adding a log of extra complexity and thus attack surface.  Better don't
care about it.  Note also that *PGP User-Ids are not mail addresses but
UTF-8 strings which happen to be similar to mail addresses.  Since PGP-5
we got enough eperience on the problems with that so that this is better
side-stepped bu declaring things are UTF-8 with a smple canonicalization
rue (plain 7-bit ascii is lowercased to address common seen patterns,
everything else used verbatim)

> # Redirects
>
> This doesn't say anything about redirects.  As a practical matter, if you are
> using HTTP, you want to note that following redirects is expected.  This has
> many benefits:
>
> * An operator can delegate responsibility for running the API to another entity.
> * A server can direct requests to equivalent URLs to a single canonical URL.
> * You get consistent implementation of this important feature.  Otherwise, if
> some clients will follow redirects and others don't, you can end up with no
> meaningful interoperability.

A note on this will be considered for the next draft revision.  Actually
ther are subtle things with redirects.  For example the Implementaion in
GnuPG has exceptions to address pecularities of certain domains:

  /* Return true if both URI point to the same host for the purpose of
   * redirection check.  A is the original host and B the host given in
   * the Location header.  As a temporary workaround a fixed list of
   * exceptions is also consulted.  */

The mentioned fixed list is currently for Protonmail (yet another problem
with them ;-)

>> The HTTP GET method MUST return the binary representation of the OpenPGP key
> for the given mail address.
>
> Where is this representation defined?

*PGP: RFC1991, RFC2400, RFC4880, RFC9580, or LibrePGP.

> processing can confidently handle different content.  The same courtesy is not
> extended to HTTP resources.  The specification even recommends the use of
> "application/octet-stream" for this.  As a general rule, that media type is not
> a good idea when defining protocols, where having certainty about formats is
> useful for managing version migration.

The *PGP formats are stable for more than 30 years.  Establishing new
media types to be provided by a general purposes web server has the
problem that the server operators need to agree with that.  This does
not help for fast deployment of the protocol.

> # Policy flags
>
> This format seems under-specified.  Note that while I consider RFC 9309
> insufficiently specified, it is far better defined than this.

It is mainly for future extensibility and only in the scope of the WKD.

> # Security

> * This protocol does a proof of possession for the key.  It's not clear that
> this is a necessary function.  It also appears to do a routeability check for
> the address being claimed, which I believe is necessary.  Is there a security
> analysis, akin to those done for the ACME protocol, that confirms that this
> protocol is not vulnerable to the panoply of attacks that such protocols tend

It is actually the same protocol style as you see with all account
registration schemes which uses mail for confrmation.  The twist here
is that the mail challenge is secured using *PGP.

> * I don't see any effort made to ensure that the operator of the HTTP server is
> authorized to operate as an authority for information about the mail
> infrastructure.  Other efforts in this domain use DNS records for this purpose.

DNS would be good but we run into the usual problems with browsers and
missing support for SRV records etc.

> * SHA-1 appears to play a significant role here.  Given that it has been shown
> to have collision attacks and this protocol (as specified) would appear to
> depend on collision resistance, that seems like a genuine problem.  If I
> request keys for an address with a collision, how can I be sure that I'm
> getting the keys I intended?  (Above, I suggested that hashing might not even

SHA1 is just use to map a name to another identifier and has no security
function.  Obvioulsy the clients needs to check that the received key
has the requested user-id.  Yes, this requirement should be put into the
security consideration.

> low entropy of local parts.)  What measures, if any, can be put in place to
> protect the privacy of addresses from crawling and scraping?

Obviously you can try all comman mail addresses in the same way you can
do this with mail.  However, a public key is public and if you don't
want to have it public, don't upload it to a server - but this in
general only recommended in very special cases,

> # Nits
>
> What is "hu"?

Hashed Userid

> I see a few places where references are in the form "as specified below". 
> Please add section references instead.

Okay.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein