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

Simon Josefsson <[email protected]> Mon, 04 May 2026 09:48:37 +0200
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
Michael Richardson <[email protected]> writes:

> I have reviewed openpgp-hkp-10.
> I have no objection to adopting it, probably overdue.

+1

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

This was also my main concern when browsing the current document.

There is a difference between 1) documenting reality, and 2) proposing
something new for future implementations.

It is hard to tell where the split is in this document.  The document
seems to want to do both, which makes things unclear.

I realize that splitting up the document is boring and time-consuming,
and maybe even infeasible.  So maybe just focus on the v2 part that you
want future implementations to actually implement?  And don't claim that
the legacy/v1 description in the document is a proper and complete
specification of the legacy protocol.  The v1 part should be
Informational, the v2 could be Standards-Track if there is wide
deployment interest.  It is fine if all deployed v2 implementations ALSO
supports the informal v1 protocol.  It doesn't have to be described in a
v2 standards-track document.

/Simon

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

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