After the key was revoked looking at it in Open Keychain shows the primary key revoked and the encryption subkey is not listed as revoked showing active. In GnuPG list the subkey shows revoked. After hours of trying it seems like GnuPG is unable to issue a subkey revocation properly because I even tried implicitly specifying the subkey ID.
If I understand you right, you revoked a subkey using GnuPG and GnuPG also shows the subkey correctly as revoked. And OpenKeychain shows the entire key as revoked?
As the GnuPG output shows, the revocation was then correct. That may as well be a behavioral difference in OpenKeychain.
Could you please show the output of gpg -k [yourkeyid/email] and a screenshot of OpenKeychain, both possibly with redacted personal data if you’d like.
No. Just re-read what I typed. I typed what it is.
can you write which GnuPG version you are using and on which platform?
(Some GNU/Linux distributions for example add patches that change behaviour, so it is good to know.)
To explicitly ask: Does GnuPG show everything correct?
Your post says (edit: citing @swagner 's conclusion):
GnuPG also shows the subkey correctly as revoked.
(edit, your original phrasing was:)
In GnuPG list the subkey shows revoked.
It may be that GnuPG acts fine and OpenKeychain (based on Bouncy Castle) does not. What makes you think otherwise?
In general: Asking on the gnupg-users mailinglist might give you additional answer. Please include more details like the version number and the output, if you at all can.
Best Regards,
Bernhard
Hi, I agree with @bernhard when he says:
As I understand the OpenPGP specification, revoking a key means revoking the whole key.
Although the revocation packet is only added to the primary, the subkeys are implicitly revoked by this, too. RFC9580 key revocation signature. (LibrePGP sepcs say the same in this regard.)
And you can only revoke a subkey if you did not revoke the whole key already.
I’d recommend to report a bug for OpenKeychain, as they do not show subkeys as revoked, too, if the primary key has a revocation packet.
@bernhard Where are you getting that quote “GnuPG also shows the subkey correctly as revoked.” I am looking at what I typed and it doesn’t say this quote. Revoking the whole key implys subkeys (or in the case of GnuPG should because the term subkey is hierarchical ) The subkeys are not implicitly revoked you are misusing the word. If you can revoke a subkey then until the subkey is revoked it has not been revoked. I didn’t want to teach english but if you implicitly do something like press the power button on your android then it overrides keep screen awake settings because it turns off the screen and implicitly puts the screen to sleep; this is a proper example of an implicit function: it actually does it, it has been implied. Leaving the key not revoke is nothing implicit when you can actually revoke a subkey. So there is English.
No GnuPG may not be acting fine: the evidence shows the opposite. It’s a bug.
@eebb No, OpenKeychain is right and you are wrong. I wouldn’t trust modern RFCs.
The RFC doesn’t even say anything about implicitly revoking a subkey actually it uses questionable wording to say the primary key is bound to the subkey, the subkey should be bound to the primary key however it is likely not and that is why I take the time to look at this because with enough work the subkey could probably be extracted as a standalone key: it is not bound to the primary key. In PGP your key is a keypair and inseparable you would just sign your own more keys if you wanted something like subkey. You would make an RSA keypair and if you needed DSA you would make another key and sign it with your RSA. Now it seems that is the purpose of subkeys however there is an assumption, you were using the word imply where there is no such implication rather you seem to mean users with unfine vulgar understandings are expected to make the assumptions the subkey has been revoked.
Look at what the RFC says:
5.2.1.12. Subkey Revocation Signature (Type ID 0x28)
This signature is calculated directly on the primary key and the subkey being revoked. A revoked subkey is not to be used. Only Revocation Signatures by the top-level signature key that is bound to this subkey, or by a (deprecated) Revocation Key, should be considered valid Revocation Signatures.
If you don’t revoke a subkey yet say the primary is bound to it then the key is not fully revoked. It just seems you made gpg2 more complicated than you can handle more complicated than PGP 1 of which you all don’t seem to understand properly.
Saving the best for last @eebb “As I understand the OpenPGP specification, revoking a key means revoking the whole key.” that is a proper understanding but that is not what the GnuPG software does; it’s a bug that seem’s to be based on an assumption from how the developers read the RFC. That is a 1 up for you; you said 1 thing right.
Further research shows gen-revoke a supplimental program (apparently to fix a GnuPG bug I here report) would be a solution but it does not work. The logic in Michael’s blog is exemplary in explaining the bug. Upon closer look at the RFC it seems maybe the gen-revoke fix no longer works because of the ambiguous (deprecated) about the needed subkey revocation key to be generated. If it was indeed (deprecated) then you have succeeded in elimination of the only found fix to your foundation flaw. Is there any way yet to generate a subket revocation key to actually revoke the subket with a 0x28?
The debian wiki has a very readable explanation on the why and how of subkeys: https://wiki.debian.org/Subkeys . The main point to note in this context: The primary key is not merely the first in a list of subkeys. You can think of it as the key to your key (excuse the pun). Among other things, you can use it to revoke subkeys, and to add new subkeys. So can an attacker who has gained access to the secret part of your primary key.
In other words, if a primary key has been compromised, you cannot trust any subkey associated with it.
1 Like
@tfry Forbidden
You are not allowed to access this!
It could be very readable that doesn’t mean it is right. Why would you trust a user edited wiki of debian downstream of GnuPG the maintainer and they are downstream of a bad RFC editor? I heard Debian all goes to the mayors son with a bitchin camaro tampering with it. You say “the primary key is not merely the first in a list of subkeys. “ When PGP keys are mathematical keypairs that is not true, basically it is the first signing a list of subkeys which are also keypairs having their own private parts. That is just the way they made it look on the screen and GnuPG 2.5.17 has a bug where it falsely reports the subkey revoked while it IS NOT REVOKED, with a 0x28. Other words “if a primary key has been compromised, you cannot trust any subkey associated with it.” Not true, because they are all keypairs the primary could have had the subkey deleted at time of compromise.
This is only how they make it look on the screen and you are regurgitating misleading information.
@tfry I got to take a look at the page and it is not bad. Nothing stood out as wrong, however with the two bugs I have been reporting on the GnuPG ML you can’t perform any of the useful synopsis the debian wiki gives. What the wiki does show is valid usage of subkeys which the GnuPG 2.5.17 bugs block. What stood out was the entertaining theme of how hard it is to keep your private key safe (me smiles). The wiki even highlights the drawbacks of gpg2 automation. I don’t see how you came to your wrong interpretation because the wiki says the same thing I said to correct you.
Gonna wrap this up it is confirmed bug. This bug remains UNSOLVED because apparently the GnuPG maintainers are refusing to accept the bug reports since they confirmed watching my posts on the users ML and refused to give me a bug reporting account and do not reply to take care of the reported bug before I find a second exporting bug and maybe third revocation bug.
GnuPG 2.5.17 Unable to revoke subkey
Regression: T.B.D.
Steps to repro: revoke key, look at revoked key in OpenKeychain and notice the subkeys are not revoked, look at keys in GnuPG see the subkey falsely reported , list packets and no 0x28 revocations are applied under subkeys, attempt to revoke: gnupg does not revoke.
Cause: misconseptions and, misuse and misunderstandings of the English language: they think the word “implied” means not doing something.
The fix: When doing a full key revocation it should have written a 0x28 on every subkey
Workaround: you would have to manually revoke each subkey with a 0x28 before 0x20 because with 0x20 GnuPG 2.5.17 refuses to write the necessary 0x28 . It is too late to do this and nowhere was it documented. This needs to be a documented warning to avoid the bug, pay it forward.
Possible workaround fix: It may be possible to write a 0x28 manually with gpgsplit and apply it with hexedit. More research needed.
note also applying a newly created revocation with different reasons listed reports no change because apparently GnuPG silently refuses to apply it. “already revoked”. Possibly another bug.
Source of problem: misconceptions of developers and community which in regression seems to stem from whenever RFC marked subkey revocation keys deprecated “or by a (deprecated) Revocation Key,”.
Message me in private when you can @tfry
Dear @marqueandreprisal,
the developers and other GnuPG and crypto experts from the community see the issue differently:
They’ve tried to reproduce your situation, and reported what they have found to you with some instructions how to reproduce their results and arguments. (See the gnupg-users mailinglist for details.) Status: it most likely is a minor defect in the display of OpenKeychain which does not matter much as the state of the main key is important.
You are free to disagree or present new arguments, but it does not make sense to state the same arguments again and again.
Also what is considered impolite and unwelcome on this forum is to write something which is not the case, e.g. I explained to you that an account to dev.gnupg.org is not necessary to report a defect - an email to gnupg-users is sufficient. This is independent from the validity of your report. Please do not claim something else.
As community we are open to disagreeing opinions and multiple viewpoints. But, we will not tolerate repeated miss-representations, provocations or postings that aim to be in the way of a constructive and respectful exchange here on the forum. Your post I am replying to does not live up to our standards as explained above.
Please consider what you write or we will be forced to suspend or block your account from posting.
Best Regards,
Bernhard
Misrepresenting us with a false quote is how you opened and yet have not responded to when inquired of your false quote (“Where are you getting that quote “GnuPG also shows the subkey correctly as revoked.” I am looking at what I typed and it doesn’t say this quote.”). I have not misrepresented anything here.
A bug is the best case, if this is not a bug it shall be an intentional lie. Once GnuPG has been notified of it’s fault refusing to address it upgrades it from a possible mistake to an intentional deception, a lie.
No, you are wrong.
Misrepresenting us with a false quote is how you opened and yet have not responded to when inquired of your false quote (“Where are you getting that quote “GnuPG also shows the subkey correctly as revoked.”
I’ve rechecked and you are correct on that point. My original answer quoted a different conclusion without proper indication, which I’ve thought was representing what you wrote. I’ve added a remark to the post above to clarify. Sorry for this!
(Unintentional missunderstandings can happen and it is okay to clarify them.)
I have not misrepresented anything here.
Not on the point of the quote, but on what GnuPG devs have said and the role of the issue tracker account (as explained in my last post).
Once GnuPG has been notified of it’s fault refusing to address it upgrades it from a possible mistake to an intentional deception, a lie.
This one of the unconstructive provocations which does not leave me much choice: I’ve silenced your account for two months on this forum.