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

Hi Werner,

Just a quick few notes about reviews and a few more things inline.

As a general rule, questions reviewers have are things that fresh implementers might also have.  My goal in asking questions in a review is to highlight areas where the specification was unclear to me.  So, as much as possible, it is best to have the specification answer the questions, not your email.  (Yes, that's a lot harder; writing good specifications is not easy.)  To that end, as a reviewer, I'm very happy to be pointed at where I missed answers in the specification.

In this case, it looks like you have some work to do to ensure that these questions have good answers in the document.

I'll trim this response down to focus on a few points.  Don't assume anything about the stuff I cut.

On Sun, Apr 5, 2026, at 09:26, Werner Koch wrote:
>> 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.

Yeah, that was all in the subtext.  Not particularly convincing though.  If anything, the special name serves *less* of a purpose for the case where you are operating a directory for others.  Indeed, you don't even need the .well-known part for that either, because you are now no longer operating under the assumed constraint where the mail domain is the same as the web domain.  So https://irunaserver.example/for/pgpkeys/{domain}/... would be a perfectly fine starting point.

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

If *PGP has that constraint, it's one that could be noted.  I'd be curious how that helps with adoption.  My experience is that you need to be more permissive than an upstream specification (email) rather than more restrictive.  It's tempting to try to "fix" the problems of the upstream thing, but that sort of hubris tends not to aid adoption.

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

This is an area where redirects would help.  That is, you don't solve the problem, but let the server operator redirect to a canonical resource.   I can only say that the following is not a recipe for 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 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.

All of them?  Sounds like a great opportunity to clarify which representation is expected, or, if many are possible, how to use content negotiation to get the one you want/need.

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

What you have sits in the worst possible place then.  It's specified enough for someone to maybe believe that it might be interoperable, so they might be tempted to implement something.  Of course, it won't interoperate if they try.

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

That's not a particularly satisfactory answer.  If you have a security goal, then you should state what the goal is and then show that the mechanism you design achieves that goal.

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

I ask about this question because the security goals are not clear.  If your goal is to demonstrate that the server operator also controls the mail infrastructure, then that is one thing.  But this is not consistent with what you are saying about how PGP works (web of trust and all that).  It would help to be clearer about what your goals are in this regard.

Received on Sunday, 12 April 2026 13:41:52 UTC