GPG cannot import public key

Thu Apr 24 18:02:11 CEST 2014

Hi,

I've had a look at the various keys in a OpenPGP compatible client I'm writing at the moment. All OpenPGP messages (including keys) are represented as a set of packets, and my code has just reached the stage of deserializing the packets and verifying some kinds of signatures, so it's good timing. Here's what I discovered:

-- Key 1 --

Key 1 has the following raw packets:
Public Key Packet: "\EOTQ6V\DC3\ETX\b\NUL\204\175;i\239\167\241\198\156m\189\185\143 F*\DC3\227\NUL2\DLE\167\234\v"... (269 bytes),
User ID Packet: "Concerto Support Key <concerto.s"... (53 bytes),
Signature Packet: "\EOT\DLE\ETX\b\NUL\f\ENQ\STXQ6V\DC3\ENQ\t\ETX\194g\NUL\NUL\n\t\DLE\137~\233\185\132_Q\136\221\&8"... (290 bytes),
Public Subkey Packet: "\EOTQ6V\DC4\STX\b\NUL\209\RSK\214\183\188\162\t6\\Ic\135\174\205\EM\a\147\r\b]thO"... (269 bytes),
Signature Packet: "\EOT\CAN\ETX\b\NUL\f\ENQ\STXQ6V\DC4\ENQ\t\ETX\194g\NUL\NUL\n\t\DLE\137~\233\185\132_Q\136vR"... (290 bytes)

Processing the packets, the public key reads as:
Public Key: Created: Tue Mar  5 20:31:15 UTC 2013, RSA Sign Only, 2048 bits, fingerprint: f6a721e7343193be840fc2ca897ee9b9845f5188

If I load the first signature, I see that it's a Version 4 Generic Certification Signature, made with an RSA Sign Only key having key ID 845f5188, and using a SHA256 hash. This is the signature that binds the user id and the public key, and it's valid, at least as verified by my code. 

Therefore, as far as I can tell, the RSA self-signature binding the UID to the public key is a valid signature.

But that's not the end of the story. If you look at Section 9.1 of the OpenPGP RFC (RFC 4880), you'll see:

"Implementations SHOULD implement RSA keys (1).  RSA
 Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be
 generated, but may be interpreted.  See Section 13.5."

Section 13.5 says:

"There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only
 keys.  These types are deprecated.  The "key flags" subpacket in a
 signature is a much better way to express the same idea, and
 generalizes it to all algorithms.  An implementation SHOULD NOT
 create such a key, but MAY interpret it."

So ultimately, both GPG 2 and the creators of the original key are correct. 
It is a valid key, but it should not have been generated and GPG 2 may legitimately, and in full compliance with the RFC, refuse to recognise it.
I suspect the older version of GPG is more permissive and choses to accept it, although not being familiar with the code of either version, that's just speculation on my part.

-- Key 2 --

Oddly, gpg2 crashes for me when trying to import this key. However, the code I'm writing works fine.

The raw packets are:
Public Key Packet: "\EOTQ6V\DC3\ETX\b\NUL\204\175;i\239\167\241\198\156m\189\185\143 F*\DC3\227\NUL2\DLE\167\234\v"... (269 bytes),
User ID Packet: "Concerto Support Key <concerto.s"... (53 bytes),
Signature Packet: "\EOT\DLE\SOH\b\NULS\ENQ\STXSX\DC4\156\ENQ\t\NUL\NUL\NUL\NUL0\DC4\128\NUL\NUL\NUL\NUL \NUL\apref"... (361 bytes),
User ID Packet: "Josh Miller <josh.miller at impact-"... (39 bytes),
Signature Packet: "\EOT\DLE\SOH\STX\NULS\ENQ\STXSX\DC4\156\ENQ\t\NUL\NUL\NUL\NUL0\DC4\128\NUL\NUL\NUL\NUL \NUL\apref"... (361 bytes),
Public Subkey Packet: "\EOTQ6V\DC4\STX\b\NUL\209\RSK\214\183\188\162\t6\\Ic\135\174\205\EM\a\147\r\b]thO"... (269 bytes),
Signature Packet: "\EOT\CAN\SOH\b\NUL\f\ENQ\STXSX\DC3\251\ENQ\t\NUL\NUL\NUL\NUL\NUL\n\t\DLE\137~\233\185\132_Q\136\177\129"... (290 bytes)

The public key is, oddly, the same - so it's not a new key, just a re-export of the old key:
Public Key: Created: Tue Mar  5 20:31:15 UTC 2013, RSA Sign Only, 2048 bits, fingerprint: f6a721e7343193be840fc2ca897ee9b9845f5188

The user ID (Concerto Support Key) is again bound with a Version 4 Generic Certification Signature. This time the signature claims to be made with RSA *Encrypt Or Sign* key ID 845f5188, and hash algorithm SHA256. You'll notice that's the same key ID as the public key - in other words, the signature simply _claims_ that the key it's made with is an Encrypt or Sign key, even though the Public Key itself claims to be a Sign Only key.

The signature is valid according to my code.

I suspect this is imported fine by your GPG 2 because GPG verifies the signature without checking if the type of key the signature claims it's made by matches the type of key found for that key ID.
(This works out fine in actual usage because RSA keys are all the same anyway - the distinction between Encrypt & Sign/Encrypt Only/Sign Only doesn't exist in the maths, it's added at the application level.)

Interestingly, the key contains a binding between another user (Josh Miller) and the public key. This signature again lies about the type of the issuing key, although this one is made with SHA1 instead of SHA256. Again, the signature seems valid.

-- Further remarks --

I should reiterate that I'm not fluent in GPG's code, so I'm only speculating as to the behaviour of GPG.

You asked if it is possible to 'fix' the first key. As far as I can tell, you should just be able to use the second key: they both publish the same key and the user id <-> key binding you wanted. If you really wanted to, you could delete the second user id and signature after importing the key.

Hope this helps,
Daniel

On 24/04/2014, at 11:15 PM, helices <gpg at mdsresource.net> wrote:

> Thank you, for your response.
> 
> [1] 
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: Encryption Desktop 10.3.0 (Build 8741)
> 
> mQENBFE2VhMDCADMrztp76fxxpxtvbmPIEYqE+MAMhCn6guYS31S9DVZyz/qP1zu
> 9hp+XBj69W5L1P02I+Cvk9kKkuuC3Hz/xkJZQVFOLeHu0s6ipl8TME71STw+ADdq
> Hj+FvxfkhlSwIlpIQAhb8zySbTJptME4kwoM1xASs+IjSWaOVHh/PkjgciV1p0rH
> gSW/xP2P4UH2A+ER93ItQNgp/oGY3u5puwKY1eV8Oy9hbCexlYxWvo7VSTYDumtM
> BqpMLv7yXmJUAe1LN/bIJYo87+Nr0CxVY5A9CCqAIxZy2JEkbTdI6mHLm3zb1Pn6
> FiC42TLskruKlg2Zt8EVxrjeAlapAMbi55OPABEBAAG0NUNvbmNlcnRvIFN1cHBv
> cnQgS2V5IDxjb25jZXJ0by5zdXBwb3J0QGltcGFjdC1wcy5jb20+iQEiBBADCAAM
> BQJRNlYTBQkDwmcAAAoJEIl+6bmEX1GI3TgIAMHQbQA9XKw2e7Fl2IcI/wkG57oQ
> ve0m5/uzMEoruR4vbtwSW12f3Q4/bpokWDp617WqK0cCeec3wvDglsvXLBqHJPlo
> eKE8xp12eiw9qlEIk8oGpQ9BU5Bbxh0ORuu9EBRTo5mmqBZdfzRoeRVKYzMPCqFq
> 8ocBVdJ4NutTvEL0+58XUPFg4FOm1GHgbcRq6D8dMLO3vYj3w7wqloq45TdyRX/t
> I+ftQFsMBF1u4oJpQpErtsn49rVC5nK8rAodQfVY8pDWZM8VjKXk70U9w+e9AqHy
> X06TeKmjT8/fp/5iOUF90wftRnANkJQ4TOHH/neHlh4AVjz/cvvqz62O7ia5AQ0E
> UTZWFAIIANEeS9a3vKIJNlxJY4euzRkHkw0IXXRoT2NvfmC20fyTCrEWIoBGY/Pf
> KIr0WtMnoNem6K69D30nMPvuK7NZIEcf3c5k2KvD/p6GHZZVwnM8da/qvRmW+tFb
> h/W2PlOMBQpZh5Zd0o2Y/XvNmGz/agxOM9qhPj3ZysaKzy/prdx2ncHSUrvImnSH
> L8AtTVc0YtiI6qnhZFTivHpvAexrPUZ0/J2Qi2CL9pXTv/W5Mua1ec0HtCPTmI0g
> QMHcXMAhMdyrg0AQ4jlcS83Rhw6JoUQNEEuJcuuRyo6A/S0kxJuT5iZ1Za8JNoVm
> qOFJtASFz5wAHaAtOTuLJQe6EMaZkVEAEQEAAYkBIgQYAwgADAUCUTZWFAUJA8Jn
> AAAKCRCJfum5hF9RiHZSCADJ19g1ZR6mOCeUS95+NTf9TtGmoqB4ims0s8HqPOPh
> ihRdEEUoX16t+x8Vv6B6gF5zaeAmbMz1Mka41TFXgdgs3Y9HahXsiVKCoXJkrpKj
> LZFz+1fU/txCBZxf3il0JnfqY60qjdfJ5iq7iI0y7ClnjPfIHAE5j8VgrTgM+qIU
> +mpagibiiI7rdXNJF9hk+R5PwQrMLVLnLHq22lYcU3riGJMbRqWqXJJm6eSwxs4K
> Bsf+CKafoSiEKM8NrJGA9Dnd9HyeTCZTtlk92zfRh2zC0e/NCxdTlk2xy12ICoFG
> oeBxDq9N/8+Jbb9tQoFaOg3akr8WBKUaIRySEOky3GQJ
> =3RTl
> -----END PGP PUBLIC KEY BLOCK-----
> 
> [2] Interestingly enough, importing this key with "gpg (GnuPG) 1.4.5" is successful:
> # gpg --import /tmp/imps.asc
> gpg: key 845F5188: public key "Concerto Support Key <concerto.support at impact-ps.com>" imported
> gpg: Total number processed: 1
> gpg:               imported: 1  (RSA: 1)
> 
> [3] After several attempts to export a usable public key, they created a NEW keypair using their Encryption Desktop 10.3.0, which is successful. Of course, since they claim to be using the original without incident with many other vendors, they want to "fix" their original keys.
> 
> [4] Worse, they tried to export it again and we got this error:
> # gpg --import /tmp/imps.asc
> Ohhhh jeeee: ... this is a bug (sexp.c:1259:sexp_sscan)
> Aborted
> 
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: Encryption Desktop 10.3.0 (Build 8741)
> 
> mQENBFE2VhMDCADMrztp76fxxpxtvbmPIEYqE+MAMhCn6guYS31S9DVZyz/qP1zu
> 9hp+XBj69W5L1P02I+Cvk9kKkuuC3Hz/xkJZQVFOLeHu0s6ipl8TME71STw+ADdq
> Hj+FvxfkhlSwIlpIQAhb8zySbTJptME4kwoM1xASs+IjSWaOVHh/PkjgciV1p0rH
> gSW/xP2P4UH2A+ER93ItQNgp/oGY3u5puwKY1eV8Oy9hbCexlYxWvo7VSTYDumtM
> BqpMLv7yXmJUAe1LN/bIJYo87+Nr0CxVY5A9CCqAIxZy2JEkbTdI6mHLm3zb1Pn6
> FiC42TLskruKlg2Zt8EVxrjeAlapAMbi55OPABEBAAG0NUNvbmNlcnRvIFN1cHBv
> cnQgS2V5IDxjb25jZXJ0by5zdXBwb3J0QGltcGFjdC1wcy5jb20+iQFpBBABCABT
> BQJTWBScBQkAAAAAMBSAAAAAACAAB3ByZWZlcnJlZC1lbWFpbC1lbmNvZGluZ0Bw
> Z3AuY29tcGdwbWltZQgLCQgHAwIBCgUeAQAAAAYVCAoJAgMACgkQiX7puYRfUYga
> iQf/ZJ1d7dY2RdRjDzhXfarf7pPXRCFzRG32T8/i0AKL4YUW9hlaQqatrWw5DPe8
> 2LBgCxFptJPgQ8N8nFJBWD6h/FVtUWa7k88we2MM/9oQn7d6v3pRaVxDUKfebCIn
> KqcR0k7ajdUMsGC3X+C6sjMh/Oy1/bI1EDUdFqcLq02kMcMSoDr5B2vpsRm8+tSs
> sSaoMujMmt17v4NkOzIyuOT8oyRPxFbeYszbaLpCjnZsbc1ktmpo3SkgNn8OBckt
> 0A6emPuIgy8tas+rxdmz+N3EWddt9FJz0r5DLCBAo9AUfzDBQnOrnGbvHuJuZH/t
> EFoJZyqTFgBa+RzkVYuPXVEbY7QnSm9zaCBNaWxsZXIgPGpvc2gubWlsbGVyQGlt
> cGFjdC1wcy5jb20+iQFpBBABAgBTBQJTWBScBQkAAAAAMBSAAAAAACAAB3ByZWZl
> cnJlZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQgLCQgHAwIBCgUeAQAA
> AAYVCAoJAgMACgkQiX7puYRfUYid4Af/TzyXyapN59vqiyg7N0ejuQwcnM8Cp7HJ
> DyJtzw/KSK/6xrfEv5vRpW58OtNOy8sjpXGLHfzwh29DBOo/oe0djpz+G/arq6Bj
> JjcAAX9NaYB09rileHN/gw4X3W8FnIR4cZWbO/AwUpesSL75Sc8D/SbQ1i/Gstge
> hzo6d79SDJ6BFRURMDDe4n+kLOZSP3VtK9i3DQ+Bl+8tvzSjLGD+B/78VX+7QR57
> +CzcRjNPQXQgvLdWkWGAYCXHzKZWx/RwTX6aFFFcIjm2s2zxZfunM+ajHt0sGZgT
> gnCtKmfRwTWTF7xlP6t2e1Zt9v+ykRmeMtYO5+IHjlwzjIDy5Ol+VrkBDQRRNlYU
> AggA0R5L1re8ogk2XEljh67NGQeTDQhddGhPY29+YLbR/JMKsRYigEZj898oivRa
> 0yeg16borr0PfScw++4rs1kgRx/dzmTYq8P+noYdllXCczx1r+q9GZb60VuH9bY+
> U4wFClmHll3SjZj9e82YbP9qDE4z2qE+PdnKxorPL+mt3HadwdJSu8iadIcvwC1N
> VzRi2IjqqeFkVOK8em8B7Gs9RnT8nZCLYIv2ldO/9bky5rV5zQe0I9OYjSBAwdxc
> wCEx3KuDQBDiOVxLzdGHDomhRA0QS4ly65HKjoD9LSTEm5PmJnVlrwk2hWao4Um0
> BIXPnAAdoC05O4slB7oQxpmRUQARAQABiQEiBBgBCAAMBQJTWBP7BQkAAAAAAAoJ
> EIl+6bmEX1GIsYEH/2IVbsvGGuSUSLU86sw0HhOxf/q3k8MG2JbrSwpCvdGkJcr4
> jbDXwfUO1taDPx6pESZmB84OASIoJGt0e5KuxWdKa0YmsQA0qERp/Y9RJnGUUNsc
> KPVde6aw6KfR+QAEWH6gRoKBjTfjo101tVD1qCKIpDBDsS6Gg8ucGYTJcNU4AvoV
> +DgTfhzg7q/Whn97idP3biLG9EHyWznRgH00t1wl+yvlaZxY/K3a3X95cTA2zwh4
> 2R0tJy0OzDQDyRjSfe8cT4cfH1k7WIrFb8FdXRAt3M3dtGRMvsHUM+rxxjsLEqGZ
> lN5nnltQiLMHkNdV/tgHCvArBSSaiuVLRYRk5sI=
> =i1to
> -----END PGP PUBLIC KEY BLOCK-----
> 
> [5] As this is a new vendor relationship with my employer, and since we have automated processes for encrypting dozens of files every day, my ultimate goal is to have a public key from this vendor that works automatically, just like the hundreds of others that we have. That is to say, a signed public key that we can sign and to which we can assign trust, and that we can use to automatically encrypt and sign files that will be sent to them on a regular basis.  Secondly, I understand and respect this vendor's desire to use one (1) key pair with all of their vendors.
> 
> Can their original key be "fixed?"  Why does legacy GPG accept that public key?
> 
> I welcome all comments, suggestions and review. Thank you
> 
> ~ helices
> 
> 
> On Wed, Apr 23, 2014 at 10:25 PM, David Shaw <dshaw at jabberwocky.com> wrote:
> On Apr 23, 2014, at 11:14 PM, David Shaw <dshaw at jabberwocky.com> wrote:
> 
> > On Apr 23, 2014, at 3:24 PM, helices <gpg at mdsresource.net> wrote:
> >
> >> No matter how I try, I cannot encrypt a file using that public key, even using --edit-key to assign trust:
> >>
> >> gpg: 845F5188: skipped: Unusable public key
> >>
> >> gpg: /tmp/test.txt: encryption failed: Unusable public key
> >>
> >>
> >> The owner of the public key insists that it is self-signed; but, our GPG cannot find the self-signature
> >
> > It doesn't look like it's self-signed, but without looking at the key itself, I couldn't say for sure.  Is it posted anywhere on the net?
> >
> > In any event, you can override the check for encryption with the same flag you used to override the check on import.  So:
> >
> >  gpg -r 845F5188 --allow-non-selfsigned-uid -e the-file-i-am-encrypting-etc.txt
> 
> I should add, though, that overriding these checks is something you should do with suitable verification of the key.  Don't override the check unless you know what you're doing, and have assured yourself that the key you are encrypting to is really owned by the person/group that you believe it is.  Those checks are there for a reason.
> 
> David
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users