Endpoint Encryption

GPG version trying to import: gpg (GnuPG) 2.0.14

Header from shared armored public key: Version: Encryption Desktop 10.3.0 (Build 8741)

GPG error on import:

# gpg --import /tmp/imps.asc

gpg: key 845F5188: no valid user IDs

gpg: this may be caused by a missing self-signature

gpg: Total number processed: 1

gpg:           w/o user IDs: 1

Other GPG import:

# gpg --allow-non-selfsigned-uid --import /tmp/imps.asc

gpg: key 845F5188: accepted non self-signed user ID "Concerto Support Key <concerto.support@impact-ps.com>"

gpg: key 845F5188: public key "Concerto Support Key <concerto.support@impact-ps.com>" imported

gpg: Total number processed: 1

gpg:               imported: 1  (RSA: 1)

Then:

# gpg --list-keys 845F5188

pub      0s/845F5188 2013-03-05

uid                  Concerto Support Key <concerto.support@impact-ps.com>

# gpg --edit-key 845F5188

gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc.

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

pub     0s/845F5188  created: 2013-03-05  expires: never       usage: SC

                     trust: unknown       validity: unknown

[ unknown] (1). Concerto Support Key <concerto.support@impact-ps.com>

Command> sign

User ID "Concerto Support Key <concerto.support@impact-ps.com>" is not self-signed.  Unable to sign.

Nothing to sign with key 31A070A8

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

What am I missing?

Please, advise. Thank you

Wow! How could this get any worse?

They tried exporting a public key in a different way and now, on import, we get this bizarre error:

# gpg --import /tmp/imps.asc

Ohhhh jeeee: ... this is a bug (sexp.c:1259:sexp_sscan)

Aborted

I'm not kidding -- that's the real error ?!?!

Please, advise. Thank you

Well I think the writing is right there.  Appears to be a bug within GPG.  You could attach  the public key so we can test using PGP Desktop, but if GPG can't import it, then it can't import it.

Is it possible to get the user to send you the key so it isnt armoured perhaps?  Or get the actual pgp key body, create a new file from it and saveas ?

NOTE: There is an interesting thread on gnupg-users (http://lists.gnupg.org/pipermail/gnupg-users/2014-April/049472.html ,) which begs a couple questions that bear answering in our time of eroding privacy:

1. Under what circumstances does Encryption Desktop generate deprecated content for an existing key; while generating fully acceptable content for a new key pair?
2. How long ought GPG to accept deprecated code (RFC 4880, November 2007 ?)

=========================

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

Hi 1helices,

If they check the Key properties and then expand Subkeys, they have no usage associated with it.
Dumping the packets with command line you can see that they have a "Subkey Binding Signature(0x18)", but lack a "Primary Key Binding Signature(0x18)".

I haven't tested this, but they might be able to be solved this by following the post in this thread: https://www-secure.symantec.com/connect/forums/modifying-key-usage-flags-existing-adks-universal-server-environment.
They will need to test it in an standalone client.

HTH,
dcats