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

Hi, Michael.

On 04/05/2026 00:45, Michael Richardson wrote:
> 
> Andrew Gallagher <[email protected]> wrote:
>> 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.

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

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

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

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

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

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

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

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

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

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

It's not exactly a priority! ;-)

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

There are two, I checked already ;-)

>> Is this the bit about detached revocations?
>> 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.

If you mean "when do they upload detached revocations as opposed to 
revoked certificates?" then the answer is "when they're using legacy 
software". In practice, this means "GnuPG"...

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

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

I think it's unlikely that 11372 will ever be used, however the guidance 
for the registry is unclear whether we can get away with this. I'm 
expecting this to come up during IANA review anyway...

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

ISTR the suggestion for keyserver escrow of revocation signatures was 
more concerned with the keyholder losing their secret key material. But 
I agree about there being security and availability tradeoffs.

> 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.
I think such questions may be more appropriate for a separate document. 
HKPv2 provides a flexible submission mechanism for arbitrary objects, so 
we could define an extension mechanism at a later date. The critical 
part IMO is that we capture all the access methods that are foreseeably 
required, so that stale consumers don't become a blocker for rolling out 
such an extension at the generator end.

Thanks,
A

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