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

Michael Richardson <[email protected]> Sun, 03 May 2026 19:45:23 -0400
Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>
Andrew Gallagher <[email protected]> wrote:
    > 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.

I don't know, it may be enough to more clearly document that the Legacy API
is non-normative, informational.

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

Is that really the practice for that registry for a WG document.  Surprising to me.

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

fair enough, just let's put those words in the document :-)

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

I can buy that, but reviewers won't know.  That's why we have to explain it.

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

I suppose that applies to operating the "API" as a set of static files.

    >> 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 rules for *HTTPS* are well known.
The rules for HKPS:// would need to be established.
RFC9525 DNS-ID matching is probably just fine.
Just needs to be said, I think.

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

Yes, there was never a /v1 by the name /pks/v1, it's at /pks !

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

CDDL can describe both JSON and CBOR objects.
JSON-LD is considered much (cognitively) heavier by some, and historically
has been hard to cite for RFCs.  That's supposed to change, I'm told.
Not a hill I will die on; I suggest just doing something.

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

Sounds like make word to me :-)

    >> Maybe RFC3339 is replaced with RFC9557?

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

okay, but probably need to check all the 3339 references.

    >> 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 also agree.  I also hate those three letters, and I seek another noun for the
word public to qualify... ideally one that doesn't need qualification, and
is never confused with the private version :-(

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

    > Is this the bit about detached revocations?

Yes.

    > What do you feel is unclear?

All of it...  When do do clients upload detached revocations?
That's why I'm saying that we need a lifecycle model.

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

Going *forward*, will we ever use 11372 then?
If not, then let's say that.

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

I think that one possible conclusion from that old argument was that clients
might need to provide revocation signatures to key servers, to be embargoed
against some time where the key server has to forget the key.
This has different security issues that were discussed at the time.
(The key server now has stuff that can be abused)

I am not saying we have to solve the problem here, but I'm saying that we
need to think about what tools/APIs a key server might need to provide.
This is WG work; post-adoption.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [
]       My working hours and your working hours may be different.            [
]  Please do not feel obligated to reply outside your normal working hours   [



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