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

Michael Richardson <[email protected]> Sun, 03 May 2026 16:21:50 -0400
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
I have reviewed openpgp-hkp-10.
I have no objection to adopting it, probably overdue.

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.

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.

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

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

The /v1 probably needds to be described, at least to the extent that client
authors might need help moving to /v2, and server operators might need advice
how much, if any, of /v1 they need to continue to support.  Oh. Section 6
calls it the "Legacy API", but does not say "v1" anywhere... so maybe it
needs a forward reference in section 4.1, and it should say, "Legacy v1 API"

I'm especially enthusiastic about being able to "support" this API via static
files.  This is a win for many entities who want to self-host.

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)
Maybe RFC3339 is replaced with RFC9557?

The Security Considerations should probably mention the Third Party Signature
spam attack mentioned in section 8.
If key servers always return "sequence of one or more Transfereable Public
Keys, (section 9), is "public keyring" the correct qualified term?

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

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.

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?

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.

--
Michael Richardson <[email protected]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

**       My working hours and your working hours may be different.         **
** Please do not feel obligated to reply outside your normal working hours **

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 487 B)