Re: [openpgp] Call for adoption of draft-gallagher-openpgp-replacementkey

[Daniel Kahn Gillmor <[e-mail]>]

My comments below are as an implementer and a user, not wearing any
chair hat.

On Fri 2024-04-19 11:59:52 +0100, Andrew Gallagher wrote:
> On 19 Apr 2024, at 08:30, Simon Josefsson wrote:
>> Two rough outlines of problem statements:
>> 
>>   1) replace human written key transition documents
>> 
>>   2) enable automatic non-interactive upgrades to PQ keys

[…]

> I don’t believe that use cases 1 and 2 are in conflict, I think they
> are clearly distinguished by whether the old key remains valid or is
> expired/revoked.

fwiw, i don't expect an OpenPGP tranition document (case 1) to require
that the old key be expired/revoked.  Common practice for a transition
document for Alice seems to be that Alice leaves her old certificate
valid while she gathers certifications on her new certificate.

There may well be multiple stages to a transition.  From the perspective
of the keyholder, here's an exhaustive list of the possible steps i can
think of, roughly in the order that it seems reasonable to take them:

1. publish intent-to-expire on old cert
2. create new cert
3. configure local tooling to use new cert as well as old for decryption
4. distribute new cert to gather 3rd-party certifications ("transition document")
5. configure local tooling to use new cert as well as old for signing
6. publish new cert (with 3rd-party certifications) in standard(?) channels
7. add replacement information to old cert, re-publish old cert
8. configure local tooling to not use old cert for signing
9. revoke old cert
10. destroy signing-capable secret key material from old cert
11. publish revoked old cert
12. harvest and retain session keys for encrypted data deemed worth keeping
13. destroy decryption-capable secret key material from old cert

Depending on the properties of the transition, maybe some of these steps
aren't necessary.  And there might be months or years between some of
these steps.

And, depending on the outcome of some of these steps, you might want to
roll the process back somehow.

Do you think the use cases section (in the pending MR) of the draft
could be a place to work through these steps, from the keyholder side?

It would be useful to think through the interactions between the
keyholder's steps and the steps taken by the peer, who is relying on the
certificate(s) as well.

> A receiving implementation that first validates both keys and then
> orders them according to the replacement key indirection will behave
> sensibly in either case.

I think teasing that apart a bit more could be useful.

In practice, it isn't uncommon for people use OpenPGP in a sort of TOFU
(or YOLO) fashion, where "meh, it's better than cleartext, we'll see
whether it works" seems to be the operating principle.

It's not clear what "validates both keys" means for this mode of
operation.  That is, the first certfificate has already been "validated"
(by the user saying "sure, ok by me"), but of course the new certificate
has not yet been through this process.

I think it would be useful for the draft to at least try to address what
it means for this mode of operation instead of completely waving it
away.

When certificate validation is automated and invisible (like X.509),
saying "do the same thing for both certs and only use the new one if (a)
you know how to use it, and (b) it validates silently and correctly for
the relevant User ID" make sense.  But what are the impacts on the user
experience if the user has to interact during the validation process?

           --dkg