Re: [openpgp] Key Superseded signature type

[Aron Wussler <[e-mail]>]

Hi Neal,

> As I commented in the MR, I wonder if a new Reason for Revocation
> type, `Key is superseded by`, which takes a fingerprint and a human
> readable string, would be better than a new signature type.

I think this approach does not play well with legacy implementations, as they would consider the key revoked.

My wish would be to distribute a v4 and a v5 certificate, both valid, so that legacy implementation still use the v4, and newer implementations don't.
A revocation certificate would probably prevent the older implementation to work. (Newer ones would be no issue)

> I also wonder if this should only be respected if there's also a
> backsig similar to how a signing-capable subkey needs a backsig to be
> considered valid.

Good point, this could be made a SHOULD in the spec. I'll take care of this on Monday.

Cheers,
Aron


--
Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930



------- Original Message -------
On Saturday, December 3rd, 2022 at 16:06, Neal H. Walfield <[e-mail]> wrote:


> On Fri, 02 Dec 2022 22:36:01 +0100,
> Aron Wussler wrote:
> 

> > I've got another small proposal for the crypto-refresh, also coming from the OpenPGP summit.
> > 

> > We've been discussing about the options for the v4 -> v5 transition (I guess v6 now?), and I'm a big fan of having multiple independently generated certificates, and allowing a smooth transition between them.
> > 

> > In OpenPGP we don't have a mechanism to signal a superseded or deprecated key, and I fear that if we all wait for v6 keys to be understood from the majority of software and then atomically switch to v6 revoking our old v4 keys we'll wait for a long time. The alternative is to have two cross-signed certificates, and publishing them both, hoping for people to use the newer one.
> > 

> > With this proposal, my objective is to have a standardized way to tackle this, by introducing a new signature type that signals key deprecation with a pointer to the new key.
> > This would automatically extend to future transitions (e.g. PQC), and allow for an easier key rotation (It would be allowed on hard revocation too).
> > 

> > https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/222
> > 

> > All kind of feedback is welcome, whether this means
> > (1) not introducing this feature at all
> > (2) introducing this feature but later
> > (3) introducing this feature now
> 

> 

> I like the idea.
> 

> As I commented in the MR, I wonder if a new Reason for Revocation
> type, `Key is superseded by`, which takes a fingerprint and a human
> readable string, would be better than a new signature type.
> 

> I also wonder if this should only be respected if there's also a
> backsig similar to how a signing-capable subkey needs a backsig to be
> considered valid. Consider: If Alice considers Bob a trusted
> introducer, and Bob creates a new key, Bob', it would be nice if Alice
> didn't have to explicitly designate Bob' as a trusted introducer. If
> Bob and Bob' certify each other in this way, I would have no problem
> considering them to be the same person (the same entity controls both
> keys). If there's no backsig, I'm not sure that this would be safe.
> 

> Neal