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

[Andrew Gallagher <[e-mail]>]

On 19 Apr 2024, at 22:47, Daniel Kahn Gillmor <[e-mail]> wrote:
> 
> 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.

You’re using “transition document” to mean the document that asks people to *sign* the new key, not the one that tells people to *use* the new key. I see the transition process as starting with scenario 2 (original key not revoked) and migrating to scenario 1 (revoked) over time. While this proposal would not be able to automate the process of gathering third-party signatures, it does represent the relationship between the old and new keys in a standard form.

> 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

If “intent to expire” means “I intend to expire this key at some point in favour of another key”, then this is equivalent to scenario 2 above - but we have to create the new key first so we can include its fingerprint in the replacement key subpacket.

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

This document would need to be signed by the old key (at least), and include both certs (including the replacement key subpacket). Is there a standard format?

> 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

We shouldn't wait until this stage to publish the replacement-key indirection, it should be done at step 2 above. The replacement-key subpacket on the self-sig is sufficient for both purposes - it won’t be publicly available and/or verifiable until step 6, so in general clients shouldn’t be using it before then.

> 8. configure local tooling to not use old cert for signing
> 9. revoke old cert

At this point we move to scenario 1.

> 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

The order of these parts are flexible, and well outside the scope here :-)

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

Up until the point that the old key is revoked, the indirection can be rolled back by making a new self-sig that lacks the RK subpacket.

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

Potentially yes, but I’m wary of turning this draft into a HOWTO document… :-)

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

Which peer is this? If you mean the certifying peer, then it might be better dealt with elsewhere - key signing best practices are a whole other set of processes and questions. If you mean an arbitrary correspondent, then their software should be able to update automatically.

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

Key distribution methods that carry implicit trust (such as Autocrypt and WKD) do not strictly require a key replacement mechanism, however implementations that perform TOFU should(!) normally warn if they see that a key has changed. In such a scenario the key replacement subpacket could suppress the TOFU key-change warning.

Distributing the sig with the replacement key subpacket would be an interesting challenge though - for example WKD does not allow for both the old and new keys to be served simultaneously. GnuPG’s WKD implementation does allow for martian sigs to be appended to the served key, and reattached to the correct key on receipt. IMO this is kludgy and should be properly specified in the WKD draft using a more robust mechanism. Autocrypt would probably support the inclusion of two keys in principle, although space constraints may be a concern.

A