> 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. > Ah, sorry - I misunderstood your earlier email.
I'm trying to compile a local version of GnuPG to poke around at it, but I'm having some trouble. I'll let you know if I make any further progress. Daniel > 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 <dan...@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@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 <g...@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.supp...@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 <ds...@jabberwocky.com> wrote: > > On Apr 23, 2014, at 11:14 PM, David Shaw <ds...@jabberwocky.com> wrote: > > > > > On Apr 23, 2014, at 3:24 PM, helices <g...@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@gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
