Keys which can be revoked by another key are not supported

[ghost]

When trying to import a key that has an authorized revoker Mailvelope fails because openpgpjs doesn't support this, What is the reasoning of not supporting this?

[twiss]

Hey 👋 The reasoning was that, if a key can be revoked by another key, we have no way to know whether it's revoked (because we don't currently have a way of getting this other key, nor a feature to pass it). If there is a revocation signature, we have no way to verify it.

We also don't have a way to warn the user about this. In GnuPG, if this happens, it warns that the key is revoked by a key that you don't have. However, since we're a library and not an application, we can't show a warning to the user. We could add a feature to return warnings to the application, but they'll most likely be ignored.

However, note that we only reject the signature that mentions the revocation key, not the entire key. So if it's included on a separate direct-key signature, the key can still be used, because the user could remove that signature anyway without invalidating the key.

RFC4880bis Section 5.2.3.16. Revocation Key explicitly mentions:

This is only found on a direct-key self-signature (type 0x1f). The use on other types of self-signatures is unspecified.

Although admittedly, RFC4880 doesn't mention this. However, if that is followed, we support the key.

[Mikaela]

I encountered this same issue with Mailevelope trying to verify signatures of NCSC-FI CERT keys in one of their newsletters. Is there some workaround to get the key accepted by openpgpjs/mailevelope?

[N8Fear]

I also need a key with a designated revoker and people can't contact me die to mailvelope bailing out.
This is very frustrating.
Any chance to get Back Support for this?

[jotoho]

Multiple of my keys including my main email key are also affected by this limitation. I have a setup where I have one master key stored securely on a YubiKey (53B1B68B5081F3AEC906709E4C6E404513ED90C9) that I use to sign my other OpenPGP keys, which are stored less securely. In order to have a way to properly revoke those lesser keys and not just the signature if I lose my access to the private keys or revocation certificates (like through harddrive failure for example), I have specified the master key as a designated revoker in some of my older keys until stopping when I learned that a lot of software fails to use those keys due to missing support in this library.

I have last used the designated revoker feature only a few days ago when I found an old key on public keyservers that I had lost the private key and rev-cert for but was thankfully able to kill using the master key. This places me in an odd position where I have to choose between doing what I think is best for my use-case going forward (marking my lesser keys as revocable by master key) and a large part of OpenPGP compatible software. Those shouldn't be mutually exclusive.

[twiss]

Multiple of my keys including my main email key are also affected by this limitation. I have a setup where I have one master key stored securely on a YubiKey (53B1B68B5081F3AEC906709E4C6E404513ED90C9) that I use to sign my other OpenPGP keys, which are stored less securely. In order to have a way to properly revoke those lesser keys and not just the signature if I lose my access to the private keys or revocation certificates (like through harddrive failure for example), I have specified the master key as a designated revoker in some of my older keys (...)

This seems reasonable, however, please consider what the application needs to do when you revoke the key in this way. The OpenPGP implementation needs to verify the revocation signature (otherwise anyone could revoke your key), and thus it needs to have the revocation key in its "keyring" (OpenPGP.js has no concept of a keyring, but never mind, we could add a mechanism for the application to pass this key - but where is it supposed to get it from?). And what if it doesn't have the revocation key? Should it reject the key? (Then we're back to anyone being able to revoke your key.) Should it accept it? (Then revocation is useless.) Should it warn the user? (OpenPGP.js has no warning mechanism at the moment, though we could add one, but this warning would not be very actionable, and users might ignore it, or the application might not even display it in the first place.)

There was a proposal for a "designated revoker" subpacket (which stores the public key packet) to replace the "revocation key" subpacket (which stores only the fingerprint, with no indication of where to get the key from). This would solve all of the above issues, but is not in scope for the current charter for the next version of the OpenPGP spec, which is a crypto refresh. (It may be considered after that is done.)

For now, your best bet is to store a revocation certificate in a secure location. (It doesn't even have to be extremely private, since compromise of the revocation certificate doesn't compromise security, it merely might force you to generate a new key. The most important part is that you don't lose it.)

[jotoho]

@twiss While I take a look at OpenPGP WG discussions from time to time, I've never read the current or crypto refresh specification and my knowledge of OpenPGP implementations outside of advanced GnuPG usage approaches zero.

The only thing I can think of would be requiring the designated revoker key to be imported/read together with the key that is claimed to have been revoked for verification. With ascii-armored key files it would be easy to put a (minimized) copy of the designated revokers pubkey into the same file/string as the lesser key but I could imagine that to be more complicated or impossible with binary key exports. I would also guess that this approach would likely require extensive changes to OpenPGPJS and possibly some of the software using it.

I'm in no position to provide concrete suggestions or estimate the effort and chances of something like this working so I'll just stick with revocation certificates and maybe sensitive designated revokers for now.

[ToBeHH]

Any updates on this topic? This blocks me from using OpenPGP.js in production.