[openpgp] Re: Call for adoption: draft-gallagher-openpgp-h kp-10 (Ends 2026-05-14)

Hi, Michael.

On 03/05/2026 21:21, Michael Richardson wrote:
> 
> I have reviewed openpgp-hkp-10.
> I have no objection to adopting it, probably overdue.

Thank you.

> IETF tradition is that protocols that we can not change, because the vendor
> controls them, and/or because they are effectively already deployed, should
> be written up as Informational v1.0 RFCs, with a second, Standards Track v2.0
> that describes extensions/revisions that *are* mutable by the IETF.

Are you suggesting that this document be split? If we hadn't already 
started work on HKPv2, I would seriously consider it. But since HKPv2 is 
already wire stable (and in the process of implementation), this seems 
like overkill to me. I'll defer to the chairs on matters of procedure.

> Section 4.x mentions URI schemes hkp and khps, but they were never
> registered.  I see IANA Considerations to do that.   I don't understand
> changing the Contact *to* D. Shaw.  (I see the subtle change in name)
> I think it should be the OpenPGP WG, not a person now.

In the service names registry, WGs are not used as contacts. Established 
practice is to register under the name of one of the RFC authors, or an 
organisation. On rare occasions a service is registered under "IETF 
Chair", but this is clearly an exceptional practice.

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

> Section 4.1 speaks about /pks/v2, and that will elicit a question about /pks/v1.
> A changelog entry says it was /v1, so maybe this is anticipating the change
> of control. 

The original plan was for "Legacy HKP" to be treated as "version 0" and 
for the new API to be "version 1" - but at IETF 122 it was generally 
agreed that this was even more confusing, and that we should go directly 
from "Legacy" to "v2" instead.

> We probably need to justify why we don't use /.well-known,
> which is because hkp:// is a bespoke server.

The /pks prefix has been in established use for keyservers since before 
/.well-known was specified (in RFC5785). It makes sense to continue to 
use it so that reverse proxies and application firewalls do not require 
modification to support HKPv2.

It is permitted for alternative URL schemes to use arbitrary fixed 
paths. It's also worth noting that the Well Known URIs RFC recommends 
against granting user write access to files under /.well-known for 
security reasons.

https://datatracker.ietf.org/doc/html/rfc8615#section-4.1

> khps probably needs to say that it does DNS-ID matching (RFC9525).
> Some might be annoyed to need PKIX stuff when doing OpenPGP :-)

Hm, I wasn't aware of RFC9525. At first glance, it feels somewhat 
trivial, in that it's what most clients would be expected to do by 
default. But I'll have a better read of it later to see if it's useful. 
Thanks.

> The /v1 probably needds to be described, at least to the extent that client
> authors might need help moving to /v2

There was never a "/v1" - but the legacy API is described later in the 
document.
> Please consider documenting the JSON API replies (section 7) with CDDL.
> I think that each type/object reply here probably needs a clear, program
> compatible name. (V2_INDEX)

CDDL is mainly a CBOR thing - would it not be more appropriate to use 
JSON-LD? We already reference JSON-LD (via Structured Mail) in this draft.

Alternatively, there was a proposal at the last openpgp email summit to 
draw up a common JSON representation of arbitrary OpenPGP structures 
(you could call it `application/pgp+json`) which might be more 
appropriate as a reference in the long term. I don't want to hold up the 
HKP specification waiting for it though, because it will not be ready 
any time soon.

> Maybe RFC3339 is replaced with RFC9557?

RFC9557 doesn't apply, because all the references to RFC3339 in the HKP 
draft hardcode UTC.

> The Security Considerations should probably mention the Third Party Signature
> spam attack mentioned in section 8.

Agreed.

> If key servers always return "sequence of one or more Transfereable Public
> Keys, (section 9), is "public keyring" the correct qualified term?

It's historically been the most common term that avoids ambiguity. Any 
terminology in PGP that uses the three letters K-E-Y is unfortunately a 
minefield... :-)

> I found the Revocation discussion unclear.
> Maybe we need a model for client<->server key lifecycle interaction?

Is this the bit about detached revocations? What do you feel is unclear?

> I was confused by the lack of port number in section 12.2 for openpgpkey.
> I think that's because _openpgpkey is just a SRV RR thing.

Correct. It's `_openpgpkey._https.<domain>`, so port 443 for HTTPS 
follows automatically.

> Can Section 10.3 also include  case where the server is hkps:// on port
> 11372?   Is it still https:??  Are SRV used here?
> BTW, I find hkps scheme with port 443 confusing here, but then I went back to
> section 4, which explained that hkp runs over 11371, and hkps uses port 443.
> So, is 11372 ever used?  Should it be tried?
> Will it confuse HTTP Proxies?

By the time HTTPS was becoming widespread, the use of arbitrary ports 
for public web services had already become difficult due to network 
perimeters blocking outgoing connections to unknown remote port numbers. 
Keyserver operators had begun to serve plaintext HKP on port 80 in 
addition to the official port 11371, so when HKPS was introduced it was 
easier to serve it on port 443. This does mean however that HKPS doesn't 
have a reserved port number of its own, which is an unusual corner case. 
There's an issue open for this in the tracker:

https://gitlab.com/andrewgdotcom/draft-gallagher-openpgp-hkp/-/work_items/14

> Somewhere there was a long debate about key servers that flood filled keys,
> and how this was incompatible with GDPR and Right to be Forgotten, because
> revocation information was needed to be able to remove keys.
> 
> This document says nothing about that, as far as I can see.
> I think that flood filling between key servers is not specified by this
> document, and I'm fine with that, but I think it should be mentioned as not
> just out of scope, but in fact undesireable.

It's definitely out of scope for this document. Different keystores will 
have different policies about what to serve and how to treat changes. 
For example, some keystores may not allow external submission of any 
kind. The hockeypuck keyservers (which I work on) are making continuous 
improvements to compat spam and vandalism, and I wouldn't want to be 
prescriptive in this document.

Thanks,
A

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]