Import Key fails: Mainkey has identical subkey (Totemo software)

[Alaric84]

A public key can not be imported.

Key can be imported by other implementations (APG, Mailvelope, ...)

German Errorlog:
[START] Importiere öffentlichen Schlüsselbund 0xef90cb4583876c37
[START] Öffentlicher Schlüsselbund 0xef90cb4583876c37 wird in vorschriftsmäßiges Format gebracht
[DEBUG] Hauptschlüssel wird verarbeitet
[ERROR] Unterschlüssel 0xef90cb4583876c37 kommt zweimal im Schlüsselbund vor. Schlüsselbund ist fehlerhaft und wird nicht importiert!

Possible Solution

None known

Steps to Reproduce (for bugs)

1. Try to import Key
   Thomas Amrhein.asc.txt

• Android Version: 7.1.1
• Device Model: Sony E5823
• OpenKeychain Version: 4.8.1 (48002)
• From Google Play

[dschuermann]

Which software has been used to generate this key? We consider it a bug, when a key like this has been generated. 0xef90cb4583876c37 works as a unique identifier to the key and if it is used twice it is no longer unique.

[Valodim]

Phew, oh man.

So, the short version is that this key has a questionable structure, and we believe we are doing the right thing not importing it.

Technically, the issue is that this key is a primary key with a subkey, and both of those keys are the same. There was only one key generated, and that key was used as a primary key and bound to itself as a subkey.

This is a completely unreasonable thing to do, it suggests that the people writing the software generating it ("Totemo") didn't really know what they were doing with their OpenPGP or at least slipped up really bad here, and I'm a bit disappointed that other implementations would accept such a key.

[dschuermann]

Ah, I see https://www.totemo.com

[Alaric84]

Thanks for your replies!

open-keychain is in fact the only implementation which has problems with this key.
Is there any workaround for this? Since this key is not mine... it's hard to change it.

[Valodim]

Actually, there is a second thing in the key that makes no sense: Neither the primary key, nor the subkey have flags that say which operations they are supposed to be used for... which is valid (though deprecated), it just doesn't really make sense in this constellation. However it's uh, possible to make use of that other weirdness to workaround the first weirdness.

I'd like to point out that this is questionable security practice, but it should fix your problem:

thomas_amrhein.pub.asc.txt

[dkg]

please see https://bugs.debian.org/888841 -- hokey lint now considers this configuration (subkey same as primary key) to be something worth warning the user about.

[Alaric84]

Thanks guys for helping!

Maybe this kind of key is somethin worth WARNING - but not for an error?

[Valodim]

I realize this is unfortunate for users who are at the receiving end of that stick, but I think this happens rarely enough that we can actually eliminate this problem if all implementations reject such keys. A warning doesn't do that.

[HeikoStamer]

I proactive added a warning on such a key structure in DKGPG, however, it should never trigger due to further restrictions on primary key (i.e. DSA) and subkeys (i.e. ElGamal) there.