GPG cannot import public key

Thu Apr 24 18:12:23 CEST 2014

Hi, Daniel!

No

Please, re-read:
[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

Key #2 gives me that bizarre error on trying to import it.

I do appreciate your analysis. I hope that a GPG developer can use it to
advance gpg.

On Thu, Apr 24, 2014 at 11:02 AM, Daniel Axtens <daniel at axtens.net> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140424/68dd365d/attachment-0001.html>