Re: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem]

[Stefan Claas]

On Thu, 28 Sep 2017 14:58:05 +0100, Andrew Gallagher wrote:
> On 28/09/17 14:18, Peter Lebbing wrote:
> > Are you sure you had the Governikus key in your keyring? I am
> > seeing the same as Stefan: the signature is bad. It says sig-3, the
> > dash indicates failure. It should have been sig!3 for a good
> > signature.  
> 
> Apologies, you are right. Importing the governikus key gives me the
> same result.

I just mailed Governikus. Let's see what they say, or what Werner says.

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem]

[Andrew Gallagher]

On 28/09/17 14:18, Peter Lebbing wrote:
> Are you sure you had the Governikus key in your keyring? I am seeing the
> same as Stefan: the signature is bad. It says sig-3, the dash indicates
> failure. It should have been sig!3 for a good signature.

Apologies, you are right. Importing the governikus key gives me the same
result.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem]

[Andrew Gallagher]

On 28/09/17 12:59, Stefan Claas wrote:
> When long time ago Facebook's pub key received it's vanity sigs i was
> upset and decided
> to no longer support traditional key servers and added this text to my key.

As I argued above, vanity signatures *shouldn't* be an issue - the
problem comes when client software blindly regurgitates vanity
signatures without any consideration of their usefulness.

But back to the point at hand. I wasn't referring to you putting
plaintext in your ID (lots of people do that), but because you split the
plaintext over multiple IDs it becomes scrambled because IDs don't have
an intrinsic order.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem]

[Peter Lebbing]

Okay, I made a boo boo regarding text wrapping. Let me repaste the debug 
output:

--8<---cut here---start->8---
gpg: DBG: rsa_verify 
data:+01ff \
gpg: DBG:  
 \
gpg: DBG:  
 \
gpg: DBG:  
 \
gpg: DBG:  
 \
gpg: DBG:  
 \
gpg: DBG:  
 \
gpg: DBG:  
 \
gpg: DBG:  
 \
gpg: DBG:  
 \
gpg: DBG:  
 \
gpg: DBG:  
 \
gpg: DBG:  
 \
gpg: DBG:  
 \
gpg: DBG:  
ff003031300d0609608648016503040201050004208f \
gpg: DBG:  
a83f9358156973aa13d8bec76f29f960a5ef0baf4f9ecb63df7a0296ea1f46
gpg: DBG: rsa_verify  
sig:+7c0d84121a51ae5f5e99d131fc0e0e1e9157b03375b65bfd706aef1b42776ccd \
gpg: DBG:  
c5ef1d4c7a4a77733af8f49648000e2c779e176e4874609ca3d22a88beac09c4 \
gpg: DBG:  
f4556a9a25636ac6acc33e366356fb71f7c702771a622773ab55fe00cb4d3f71 \
gpg: DBG:  
6d291871302dc35e0ecd9a37cf60887d9b65e2f751172eb9c81e5c9bb76d3b07 \
gpg: DBG:  
f2589f29196761f39d9786956ba8d20a2a4df6f0157861bc49a972d923567135 \
gpg: DBG:  
a45bcaf8bded2a55edcdadd7109fef620b533fabb0a29bcf4a254a2a6043be46 \
gpg: DBG:  
be8606d0e21075a1b1927f3a3c846a21abb52d64c3260c451a7a9688ff290caf \
gpg: DBG:  
9be60639618cd547dd6ad5beed0dd0167ba01fafbcf0b8650b02bd47166d5705 \
gpg: DBG:  
2b30fd7314625b925b4638469524b54d084f1e4bec5fd3ed19b576fc25fffe27 \
gpg: DBG:  
cf71b534be9cf865f4db030bf99f2617f4520c6c47bf94593af2fe91800cc838 \
gpg: DBG:  
8e43c86864d5338b53ef88d65657b5ba241072cdc4b1744b44bd01ccbf9e8124 \
gpg: DBG:  
83fb23c00e94900bd94c3070c0dfbfd85a8244e07b22f275376dd9ba8b8af16b \
gpg: DBG:  
6f79ed424330e4b4611478863ad67819a1a12fe86ec6bb466d8823d5982c462a \
gpg: DBG:  
4a2f35a8369092487d66d12f75e7701205e2d3b6b5932e01a98d66e2ac61243a \
gpg: DBG:  
d97d8f5c46d7d965d27e1dbaee09af1c2787121845d11a73c8a3b5b6dc66d44b \
gpg: DBG:  
d849cd96decb42ad8d4d7df80da7aa9ddc072c37fea1cf68c349d7c3a4909e2a
gpg: DBG: rsa_verify
n:+ac04bff70099263c05a8a3be359f82648d18b3b0e5b7fd15994c438683ba175b \
gpg: DBG:  
7d6763f59f8778f01957fa82a3edcc94896de20f1fe8b0e4d214db863f18013f \
gpg: DBG:  
8e4ab9b4d16e4381cca8b877db3399a99aa8475c6ba9b6e04143e5e55ac8c438 \
gpg: DBG:  
323e5365abef50c0468dc8afeb03cd0e15846393d5a52aaa7b60ade16b834214 \
gpg: DBG:  
d8be2000ac9550327215c2e8da95cd8e5ba60dbf2846f139ffd44e1e3a1dd366 \
gpg: DBG:  
e3e7c0a7c1dd8924501e8f93bfb18020fbae5c3f942a0e8b0c61f5561ee9b17d \
gpg: DBG:  
23521cabc4c26213236720824a0356c34af4e22ee1da9dde2d151e1b0b0e04d6 \
gpg: DBG:  
a63df7817aadaa43964bd57de7c1c4d0092ba132a9e5bd8bb05335d5e195a5b4 \
gpg: DBG:  
c47d121004021f3648a13da771edf0a48601fc047b9aa54d4f58fba2f53b680e \
gpg: DBG:  
29e2e8c6101f050fc5035f08f38300b1c799e6631efff5eb78c1d8898c6862cf \
gpg: DBG:  
3cc167e371817499afff072f5b3f8e150a4c836580911d17f47fc460ae8d6547 \
gpg: DBG:  
ca4b067811cae95590e294e89610af96aeb834697d9525d86ce74129e432dc7c \
gpg: DBG:  
4380807b1eb6fd5dfc5604ab3d050bf9f1ba589979f914717e11807b02787681 \
gpg: DBG:  
66b729babd216b2e85beb3565d2583fc1fff7c69a6ec91226b40b2fe0aead4f9 \
gpg: DBG:  
7625d05eb251e3ab8a85f16981c85ec03d745db81dee38ca948e4aa5aff14529 \
gpg: DBG:  
f6ae044278dec55f50ccb7c918d7f9b41443df640ddebc7d1632bf90d47dc9cf
gpg: DBG: rsa_verifye:+010001
--8<---cut here---end--->8---

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

Re: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem]

[Peter Lebbing]

On 28/09/17 13:30, Andrew Gallagher wrote:
> What specific error are you getting? I don't see any errors using
> --check-sigs on that key, but then I don't trust Governikus so I'm not
> performing the same test that you are.

Are you sure you had the Governikus key in your keyring? I am seeing the
same as Stefan: the signature is bad. It says sig-3, the dash indicates
failure. It should have been sig!3 for a good signature.

For reference, this is the Governikus signature in --list-packets format:

:signature packet: algo 1, keyid 5E5CCCB4A4BF43D7
version 4, created 1506196241, md5len 0, sigclass 0x13
digest algo 8, begin of digest 6b 6e
hashed subpkt 2 len 4 (sig created 2017-09-23)
hashed subpkt 5 len 2 (trust signature of depth 1, value 60)
subpkt 16 len 8 (issuer key ID 5E5CCCB4A4BF43D7)
data: [4095 bits]

It is a SHA256 trust signature issued by an RSA key. I think it's odd
they issue a level 1 partial trust signature, but I'd guess they think
they're doing their users a service by making it possible to
automatically assign partial trust to all keys signed by them, if you
want to. Don't worry, this won't happen unless you issue at least a
level 2 trust signature to Governikus. At least, I'm fairly sure it's
not enough to simply assign full ownertrust to Governikus, ownertrust
and trust signatures don't interact, right?

I don't see anything yet that stands out to me as "this must be why it's
a bad signature".

But we can always dig deeper. Using gpg's debugging output, it is clear
that the RSA signature is well-formed, but the hash doesn't match. If I
read it right, GnuPG wants the hash to be:
8fa83f9358156973aa13d8bec76f29f960a5ef0baf4f9ecb63df7a0296ea1f46
But the Governikus signature hash is:
6b6e7c7823d29203332faae25a3abb18a7e36689a77e5f32feb57c73e7e0ec48

I didn't actually parse the ASN.1, though, I simply used common sense:
the signature packet indicates the Governikus hash starts with 6b 6e,
and the length is correct for a SHA-256 hash, so it makes sense that the
ASN.1 ends with the pure hash. Haven't thought about endianness.

I don't know what could cause this. This is as far as I can go. Perhaps
a developer recognises the situation.

Here's the debugging output:
--8<---cut here---start->8---
gpg: DBG: rsa_verify
data:+01ff \
gpg: DBG:
 \
gpg: DBG:
 \
gpg: DBG:
 \
gpg: DBG:
 \
gpg: DBG:
 \
gpg: DBG:
 \
gpg: DBG:
 \
gpg: DBG:
 \
gpg: DBG:
 \
gpg: DBG:
 \
gpg: DBG:
 \
gpg: DBG:
 \
gpg: DBG:
 \
gpg: DBG:
ff003031300d0609608648016503040201050004208f \
gpg: DBG:
a83f9358156973aa13d8bec76f29f960a5ef0baf4f9ecb63df7a0296ea1f46
gpg: DBG: rsa_verify
sig:+7c0d84121a51ae5f5e99d131fc0e0e1e9157b03375b65bfd706aef1b42776ccd \
gpg: DBG:
c5ef1d4c7a4a77733af8f49648000e2c779e176e4874609ca3d22a88beac09c4 \
gpg: DBG:
f4556a9a25636ac6acc33e366356fb71f7c702771a622773ab55fe00cb4d3f71 \
gpg: DBG:
6d291871302dc35e0ecd9a37cf60887d9b65e2f751172eb9c81e5c9bb76d3b07 \
gpg: DBG:
f2589f29196761f39d9786956ba8d20a2a4df6f0157861bc49a972d923567135 \
gpg: DBG:
a45bcaf8bded2a55edcdadd7109fef620b533fabb0a29bcf4a254a2a6043be46 \
gpg: DBG:
be8606d0e21075a1b1927f3a3c846a21abb52d64c3260c451a7a9688ff290caf \
gpg: DBG:
9be60639618cd547dd6ad5beed0dd0167ba01fafbcf0b8650b02bd47166d5705 \
gpg: DBG:
2b30fd7314625b925b4638469524b54d084f1e4bec5fd3ed19b576fc25fffe27 \
gpg: DBG:
cf71b534be9cf865f4db030bf99f2617f4520c6c47bf94593af2fe91800cc838 \
gpg: DBG:
8e43c86864d5338b53ef88d65657b5ba241072cdc4b1744b44bd01ccbf9e8124 \
gpg: DBG:
83fb23c00e94900bd94c3070c0dfbfd85a8244e07b22f275376dd9ba8b8af16b \
gpg: DBG:
6f79ed424330e4b4611478863ad67819a1a12fe86ec6bb466d8823d5982c462a \
gpg: DBG:
4a2f35a8369092487d66d12f75e7701205e2d3b6b5932e01a98d66e2ac61243a \
gpg: DBG:
d97d8f5c46d7d965d27e1dbaee09af1c2787121845d11a73c8a3b5b6dc66d44b \
gpg: DBG:
d849cd96decb42ad8d4d7df80da7aa9ddc072c37fea1cf68c349d7c3a4909e2a
gpg: DBG: rsa_verify
n:+ac04bff70099263c05a8a3be359f82648d18b3b0e5b7fd15994c438683ba175b \
gpg: DBG:
7d6763f59f8778f01957fa82a3edcc94896de20f1fe8b0e4d214db863f18013f \
gpg: DBG:

Re: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem]

[Stefan Claas]

Am 28.09.2017 um 13:30 schrieb Andrew Gallagher:


On 2017/09/28 10:57, Stefan Claas wrote:

Now i have a problem lol... with my new pub key and --check-sigs.

My new pub key 3BB27531899F06EA4582B2E9D68B6EAC6ECF3AB6 was signed
by Governikus 864E8B951ECFC04AF2BB233E5E5CCCB4A4BF43D7 and when doing
a --check-sigs i get an error...under Windows 7 and gpg4win GnuPG 2.2.1,
which i just
downloaded... Therfore i checked other users, which have a Governikus
sig3 and
the error persists. Any ideas gentlemen?

What specific error are you getting? I don't see any errors using
--check-sigs on that key, but then I don't trust Governikus so I'm not
performing the same test that you are.

Well, i installed today at work gpg4win (GnuPG 2.2.1) and it tells me when
downloading my pub key 1 bad signature in German. when doing a --check-sigs
it tells me in German:

gpg: 5 korrekte Signaturen
gpg: 1 falsche Beglaubigung

the good signatures are shown with gpg in cmd.exe as sig!3 and the bad 
signature is
shown as sig-3. Same applies when i do gpg --recv-keys/--check-sigs from 
other keys

signed by Governikus.


BTW, your usage of key IDs to contain arbitrary text produces some weird
results:


When long time ago Facebook's pub key received it's vanity sigs i was 
upset and decided

to no longer support traditional key servers and added this text to my key.

Regards
Stefan


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem]

[Andrew Gallagher]

On 2017/09/28 10:57, Stefan Claas wrote:
> 
> Now i have a problem lol... with my new pub key and --check-sigs.
> 
> My new pub key 3BB27531899F06EA4582B2E9D68B6EAC6ECF3AB6 was signed
> by Governikus 864E8B951ECFC04AF2BB233E5E5CCCB4A4BF43D7 and when doing
> a --check-sigs i get an error...under Windows 7 and gpg4win GnuPG 2.2.1,
> which i just
> downloaded... Therfore i checked other users, which have a Governikus
> sig3 and
> the error persists. Any ideas gentlemen?

What specific error are you getting? I don't see any errors using
--check-sigs on that key, but then I don't trust Governikus so I'm not
performing the same test that you are.

BTW, your usage of key IDs to contain arbitrary text produces some weird
results:

```
galactica:~ andrewg$ gpg --search-keys stefan.cl...@posteo.de
gpg: searching for "stefan.cl...@posteo.de" from hkps server
hkps.pool.sks-keyservers.net
(1) supersedes 0x981EB7C382EC52B4
Stefan Claas 
  2048 bit RSA key 0xD68B6EAC6ECF3AB6, created: 2017-09-23, expires:
2022-09-22
(2) Stefan Claas (ECC Test Key - do not use) 
  256 bit unknown key 0x2C5F53E23FC75D86, created: 2017-07-15 (revoked)
(3) Stefan Claas 
  2048 bit RSA key 0x981EB7C382EC52B4, created: 2017-05-26, expires:
2021-05-26
(4) Stefan Claas
Stefan Claas 
Stefan Claas 
at https://keybase.io/stefan_claas
Stefan Claas 
Stefan Claas 
Stefan Claas 
servers. A valid copy of this key can be found
because i no longer support standard public key
This key is revoked for public key server usage,
  2048 bit RSA key 0xAAD2E08D4A3C2C49, created: 2013-11-27 (revoked)
Keys 1-4 of 4 for "stefan.cl...@posteo.de".  Enter number(s), N)ext, or
Q)uit > 1
```

A



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem]

[Stefan Claas]

Am 27.09.2017 um 20:24 schrieb Daniel Kahn Gillmor:


On Wed 2017-09-27 10:10:54 +0100, Andrew Gallagher wrote:

On 26/09/17 20:39, Werner Koch wrote:

Unfortunately the man pages describes --list-sigs in detail and only in
the next paragraph --check-sigs is explained in terms of --list-sigs.
it might be better to merge them into one description with a focus on
--check-sigs.

Or just describe --check-sigs and have --list-sigs tucked away in an
"experts only, beware" section.

I've noted this as https://dev.gnupg.org/T3430

  --dkg


Now i have a problem lol... with my new pub key and --check-sigs.

My new pub key 3BB27531899F06EA4582B2E9D68B6EAC6ECF3AB6 was signed
by Governikus 864E8B951ECFC04AF2BB233E5E5CCCB4A4BF43D7 and when doing
a --check-sigs i get an error...under Windows 7 and gpg4win GnuPG 2.2.1, 
which i just
downloaded... Therfore i checked other users, which have a Governikus 
sig3 and

the error persists. Any ideas gentlemen?

Regards
Stefan



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

preferring --check-sigs over --list-sigs [was: Re: Houston, we have a problem]

[Daniel Kahn Gillmor]

On Wed 2017-09-27 10:10:54 +0100, Andrew Gallagher wrote:
> On 26/09/17 20:39, Werner Koch wrote:
>> Unfortunately the man pages describes --list-sigs in detail and only in
>> the next paragraph --check-sigs is explained in terms of --list-sigs.
>> it might be better to merge them into one description with a focus on
>> --check-sigs.
>
> Or just describe --check-sigs and have --list-sigs tucked away in an
> "experts only, beware" section.

I've noted this as https://dev.gnupg.org/T3430

 --dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Werner Koch]

On Tue, 26 Sep 2017 13:07, andr...@andrewg.com said:

> The gpg command itself should cryptographically verify signatures when
> performing --list-sigs, so that at least it can throw a warning when an

Actually --list-sigs is more of a debug command than a command users
should use to verify a key.  The real command is --check-sigs and it
does what you suggested. 

Unfortunately the man pages describes --list-sigs in detail and only in
the next paragraph --check-sigs is explained in terms of --list-sigs.
it might be better to merge them into one description with a focus on
--check-sigs.

Anyway, it is easy to create keys just for signatures and --check-sigs
would not make a difference.  Look at my key for all those vanity
signature.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpRq4IaKv732.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Tue, 26 Sep 2017 15:14:38 +0200, Kristian Fiskerstrand wrote:
> On 09/26/2017 03:05 PM, Stefan Claas wrote:
> > I'm no expert like all you guys, but my dream would be if Werner
> > and his team could
> > work together with the keybase team, so that we could have WKD
> > support for keybase.  
> 
> WKD is a good step in providing a mechanism for key discovery, but if
> automatically considering such keys valid (either directly or through
> TOFU-model) you reduce the security to security of X.509 root
> certificate PKIX, which many users trusts implicitly already so it is
> a good simplification in many cases. That said I fail to see where
> keybase comes into the picture, maybe you can elaborate a bit on that?
> 
Well, i can't fetch keys from keybase with GnuPG in the command line
like i can do with traditional key servers. On keybase i am in full
control of my pub key, so that nobody can add there unwanted
signatures or a fake "sig3" to my pub key. I could not test WKD yet,
but believe that the same rule applies there too, with protecting
my pub key. If both, WKD and keybase could work as one unit
GnuPG power users could fetch keys via CLI, as usual, or via their
client software and users had the ability too to check also the keybase
Web Interface for additional infos about a user, if they like to do so.

keybase current stats:

Keys: 763,642
Humans: 180,431
Teams: 8,652 (new!)

The figures should not be underestimated imho because i believe
that keybase helps also the grow of GnuPG and is a nice addition for
GnuPG users, me thinks.

Regards
Stefan




-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Kristian Fiskerstrand]

On 09/26/2017 03:51 PM, Andrew Gallagher wrote:
> Not getting into an OS flame war here, but not everyone uses Android. 

That doesn't mean it doesn't exist, it just means different user
preferences as represented by the weigths in the decision matrix when
purchasing a new device.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"Expect the best. Prepare for the worst. Capitalize on what comes."
(Zig Ziglar)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Andrew Gallagher]

On 26/09/17 14:39, Kristian Fiskerstrand wrote:
> On 09/26/2017 03:38 PM, Andrew Gallagher wrote:
>> Yes. Unfortunately it's tricky to implement that on a smartphone. We
>> don't have card+phone working in gnupg yet either. We *barely* have
>> gnupg working on phones at all. But that's for another day.
> 
> Sure we do, youbikey 3 neo on NFC works quite well with K9Mail from
> OpenKeychain.. Not that it should be used too much, a smartphone is one
> of the least secure devices around.

Not getting into an OS flame war here, but not everyone uses Android. ;-)

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Kristian Fiskerstrand]

On 09/26/2017 03:38 PM, Andrew Gallagher wrote:
> Yes. Unfortunately it's tricky to implement that on a smartphone. We
> don't have card+phone working in gnupg yet either. We *barely* have
> gnupg working on phones at all. But that's for another day.


Sure we do, youbikey 3 neo on NFC works quite well with K9Mail from
OpenKeychain.. Not that it should be used too much, a smartphone is one
of the least secure devices around.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Credo quia absurdum
I believe it because it is absurd



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Andrew Gallagher]

On 26/09/17 13:49, Kristian Fiskerstrand wrote:
> 
> The users shoudn't browse keyservers at all, so it shouldn't really be
> an issue. Linking to get operation to get the public keyblock is just a
> convenience.

Users shouldn't do it. And yet they still do it, precisely because it is
a convenience.

>> WhatsApp gets the UX *very nearly* right. And since everyone and his dog
>> now uses it that's the new baseline. If it's easier to do it wrong than
> 
> No, that actually is broken by design

It's broken, but it's usable. They've prioritised usability over
security, absolutely. People don't care. They should, but they don't.
We're not going to get them to embrace something technically better if
it's harder to use.

> as it doesn't open up for proper operational security controls, > in 
> particular lack of private key
> separation on smartcard and airgapped computer.

Yes. Unfortunately it's tricky to implement that on a smartphone. We
don't have card+phone working in gnupg yet either. We *barely* have
gnupg working on phones at all. But that's for another day.

> the name of the primary UID of a signature is irrelevant; if we follow
> this argument; (i) until it is verified everything is untrustworthy, so
> (ii) the signature itself shouldn't be shown, nor should any of the UIDs
> for the public keyblock itself, as the self-signature isn't verified

I wouldn't go that far. The signature itself is not a signature by "John
Doe " - it's a signature by some (sub)key "0x123456...".
The fact that it may or may not be a (sub)key bound to "John Doe" is
rightly stored elsewhere. My argument is that displaying an unverified
comment that *implies* there is a binding *somewhere else* identifying
this key with a particular ID may be a convenience, but is a)
unnecessary and b) a source of confusion. We can't perform any
verification without downloading the full key of the owner anyway, and
that's done with the fingerprint.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Duane Whitty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 17-09-26 09:15 AM, Andrew Gallagher wrote:
> On 26/09/17 12:30, Kristian Fiskerstrand wrote:
>> On 09/26/2017 01:07 PM, Andrew Gallagher wrote:
>>> So SKS should just say "unverified signature from 
>>> ". It should not repeat the purported user ID, nor
>>> provide a search link that returns completely unrelated keys
>>> that happen to have the same purported ID.
>> 
>> No, that is also wrong, as it implies that anything is trusted 
>> unless otherwise stated. A malicious actor can claim it is 
>> verified all he/she wants (simply removing the disclaimer).
> 
> Um, did you reply to the wrong paragraph? I did mention
> disclaimers elsewhere, but only in passing (and tongue in cheek).
> My argument is that we shouldn't be displaying unverified
> information at all.
> 
>> The user's default position NEEDS to be that nothing is verified
>>  until it is done locally or by an explicitly trusted third 
>> party.
> 
> Absolutely. None of this is an argument against users having to do 
> things right. But the way to get users to do things right is to 
> train them to do things right from the start - and you do that by 
> railroading them down the straight and narrow and not even have the
> option to do it any other way. That way, if the opportunity to do
> it wrong arises in the future their first instinct will be "this
> isn't how it's supposed to happen". If you can't train people
> personally, you have to write your software so that the software
> trains them.
> 
Why?  Ultimately are we not all responsible for our own actions?
People should be required to make some effort.

> WhatsApp gets the UX *very nearly* right. And since everyone and 
> his dog now uses it that's the new baseline. If it's easier to do 
> it wrong than in WhatsApp, it's broken. If it's harder to 
> understand than WhatsApp, it's broken. If you have to read more 
> instructions than WhatsApp, it's broken.
> 
WhatsApp controls the key material.  *Seems* safe so far but who
knows.  I personally would never put anything truly confidential over
WhatsApp.  And actually people are supposed to verify that they are
messaging who they think they are messaging by doing a comparison of
fingerprints or ids or whatever they are called.  I only message one
person with it so it's been a while since I've had to do it.  But I am
willing to bet lots of users don't do that verification step.  It's a
good UX but not perfect.  Same goes for GPG in my opinion.  It's good
but not perfect.  It never will be and I don't believe any (security)
software will ever have a perfect mix of features for all users and
use cases out of the "box"

> It's no good implementing something correctly if it can be applied 
> incorrectly. Murphy's Law applies.
> 
I don't want my software or its developers acting like my big brother!

>> being able to browse the keyserver directly is too useful for 
>> debugging to completely remove
> 
> Indeed, but is it necessary to display the untrustworthy user-ID
> on signatures? The fingerprint should be sufficient.
> 
> 
> 
> ___ Gnupg-users mailing
> list Gnupg-users@gnupg.org 
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

Best Regards,
Duane

- -- 
Duane Whitty
du...@nofroth.com
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJZykjZAAoJEOJfpr8UVxtkeY4IAKL6A0KqGm85yzSrEh6Stj5z
sC86fbEtP/xXkrbYdUDVfkEYuj3AqkNL+E4AaJXO0xT8limk4COMRwl8346V9J7O
dzNIjdHAXU0iGrIBxj+CWILyY4qxTnmDar9ef+7lKxFAbJ8pUBJVxzeh0Ci2Al2L
hYXhWBrCyjqHqbMmAB/JaUBJy4BTCHNAFy704rblB2ZbqKAqbQpaTP+Jx14HWCQG
saSZn8qZwbiAnVcX4vUzssOi5Ls81eEU4W5GPGOqw7u5CvyadgXuJB8578B3qjHH
I9JQAIom6xrw3V8USwqsBCO4W9v3+C3fcT1WXivOJsZbKqJDRodjtBrxvKuI1/k=
=oYMp
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Kristian Fiskerstrand]

On 09/26/2017 02:15 PM, Andrew Gallagher wrote:
> Absolutely. None of this is an argument against users having to do
> things right. But the way to get users to do things right is to train
> them to do things right from the start - and you do that by railroading
> them down the straight and narrow and not even have the option to do it
> any other way. That way, if the opportunity to do it wrong arises in the
> future their first instinct will be "this isn't how it's supposed to
> happen". If you can't train people personally, you have to write your
> software so that the software trains them.

The users shoudn't browse keyservers at all, so it shouldn't really be
an issue. Linking to get operation to get the public keyblock is just a
convenience.

> 
> WhatsApp gets the UX *very nearly* right. And since everyone and his dog
> now uses it that's the new baseline. If it's easier to do it wrong than


No, that actually is broken by design as it doesn't open up for proper
operational security controls, in particular lack of private key
separation on smartcard and airgapped computer.

> 
>> being able to browse the
>> keyserver directly is too useful for debugging to completely remove
> Indeed, but is it necessary to display the untrustworthy user-ID on
> signatures? The fingerprint should be sufficient.

the name of the primary UID of a signature is irrelevant; if we follow
this argument; (i) until it is verified everything is untrustworthy, so
(ii) the signature itself shouldn't be shown, nor should any of the UIDs
for the public keyblock itself, as the self-signature isn't verified,
and (iii) and the keyserver can't verify it as it isn't a trusted part
of the infrastructure so the user can't know that it isn't a malicious
operator running the specific server.

The only logical consequence from (i)-(iii) is to remove keyservers from
the mix and let users do bilateral exchanges (good luck with revocation
distribution), for the simple reason that SOME users can't do things
right, it has to destroy any chance of a proper security for others.
Which incidentally is similar to a lot of other over-simplification and
interconnections throughout the world, but that is a separate
discussion. Finding the least common denominator and simplify everything
to the absurd, no matter the consequences.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"Great things are not accomplished by those who yield to trends and fads
and popular opinion."
(Jack Kerouac)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Andrew Gallagher]

On 26/09/17 12:30, Kristian Fiskerstrand wrote:
> On 09/26/2017 01:07 PM, Andrew Gallagher wrote:
>> So SKS should just say "unverified signature from ". It
>> should not repeat the purported user ID, nor provide a search link that
>> returns completely unrelated keys that happen to have the same purported ID.
> 
> No, that is also wrong, as it implies that anything is trusted unless
> otherwise stated. A malicious actor can claim it is verified all he/she
> wants (simply removing the disclaimer).

Um, did you reply to the wrong paragraph? I did mention disclaimers
elsewhere, but only in passing (and tongue in cheek). My argument is
that we shouldn't be displaying unverified information at all.

> The user's default position
> NEEDS to be that nothing is verified until it is done locally or by an
> explicitly trusted third party.

Absolutely. None of this is an argument against users having to do
things right. But the way to get users to do things right is to train
them to do things right from the start - and you do that by railroading
them down the straight and narrow and not even have the option to do it
any other way. That way, if the opportunity to do it wrong arises in the
future their first instinct will be "this isn't how it's supposed to
happen". If you can't train people personally, you have to write your
software so that the software trains them.

WhatsApp gets the UX *very nearly* right. And since everyone and his dog
now uses it that's the new baseline. If it's easier to do it wrong than
in WhatsApp, it's broken. If it's harder to understand than WhatsApp,
it's broken. If you have to read more instructions than WhatsApp, it's
broken.

It's no good implementing something correctly if it can be applied
incorrectly. Murphy's Law applies.

> being able to browse the
> keyserver directly is too useful for debugging to completely remove

Indeed, but is it necessary to display the untrustworthy user-ID on
signatures? The fingerprint should be sufficient.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Kristian Fiskerstrand]

On 09/26/2017 01:07 PM, Andrew Gallagher wrote:
> So SKS should just say "unverified signature from ". It
> should not repeat the purported user ID, nor provide a search link that
> returns completely unrelated keys that happen to have the same purported ID.

No, that is also wrong, as it implies that anything is trusted unless
otherwise stated. A malicious actor can claim it is verified all he/she
wants (simply removing the disclaimer). The user's default position
NEEDS to be that nothing is verified until it is done locally or by an
explicitly trusted third party.

Any kind of disclaimer is actually doing the user a dis-service and
supporting a subset of the user base that lacks sufficient
experience/knowledge to do anything securely to begin with, which is the
root cause of the issue; the solution isn't a disclaimer it is more
education.

Fwiw I don't recommend anyone to directly link to vindex etc on
keyservers, you'll notice that https://sks-keyservers.net only links to
get operations for similar purposes (if you find a (v)index link it is a
bug and you should report it separately), but being able to browse the
keyserver directly is too useful for debugging to completely remove. It
is a reason it is done on port 11371 for hkp and I would encourage only
accessing it through a local client, but other than that it isn't much
to do on the keyserver side.

But the lesson here is that in order to avoid misuse by an unexperience
userbase the protocol has to be a binary obfuscated mess instead of
trying to re-use well-established protocols in text form, just in case
the user walks into the maze for some reason.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"If you don't drive your business, you will be driven out of business"
(B. C. Forbes)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Fri, 22 Sep 2017 20:29:07 +0200, Werner Koch wrote:

> You may use the latest Enigmail or Kmail to automate the upload but
> you can also use Posteo's Web interface to upload the key.  But take
> care: Posteo does not allow a Name in the user id, only the mail
> address (addr-spec) is allowed.  Thus you need to add a second user
> id with just your mailaddress and use gpg's filter stuff to export
> only that UID. GnuPG 2.2.1 automates that tasks and creates another
> user if needed.

I just created a new key pair made a second UID with only containing
my email address and now i don't know how to filter for an export...
Also i have let certified my pub key again by Governikus.

Then i checked posteo's FAQ and now i see (under Point 4.) this:

Diese Kriterien muss Ihr öffentlicher OpenPGP-Schlüssel erfüllen, um
ihn bei Posteo hinterlegen zu können. 

1. Das Namensfeld muss leer sein oder lediglich Ihre E-Mail-Adresse
enthalten. 

2. Der öffentliche Schlüssel darf nur eine E-Mail-Adresse
enthalten. Unterschlüssel (Subkeys) oder mehrere E-Mail-Adressen sind
nicht zulässig. 

3. Ihr Schlüssel muss Ihre Posteo-E-Mail-Adresse oder eine
Ihrer Alias-Adressen enthalten. 

4. Der Schlüssel darf nicht von anderen unterschrieben oder signiert
sein. 

5. Der Schlüssel darf kein Foto oder andere persönliche Daten
enthalten.

If i need email privacy with GnuPG i would use Mixmaster Remailers
with a nym account or Bitmessage and not a german based email
provider, where i have to pay for their service... :-)

So it seem that while it's a good idea with WKD, posteo is no
option for me, when it comes to submitting my pub key there.

Best regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Guilhem Moulin]

On Fri, 22 Sep 2017 at 22:32:37 +0200, Kristian Fiskerstrand wrote:
> And what happens if you do gpg --import-options import-clean --recv-key
> ? is the bad MPI value sigs removed or still there in that case?

Should be `gpg --keyserver-options import-clean --recv-key $keyid`; or
alternatively, `gpg --edit-key $keyid clean save` if you want to do it
offline.  Both commands removes these “Bad MPI value” sigs here (2.2.1),
and `--check-sigs` reports that all remaining signatures are indeed
valid.

-- 
Guilhem.


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Fri, 22 Sep 2017 23:16:55 +0200, Guilhem Moulin wrote:
> On Fri, 22 Sep 2017 at 22:32:37 +0200, Kristian Fiskerstrand wrote:
> > And what happens if you do gpg --import-options import-clean
> > --recv-key ? is the bad MPI value sigs removed or still there in
> > that case?  
> 
> Should be `gpg --keyserver-options import-clean --recv-key $keyid`; or
> alternatively, `gpg --edit-key $keyid clean save` if you want to do it
> offline.  Both commands removes these “Bad MPI value” sigs here
> (2.2.1), and `--check-sigs` reports that all remaining signatures are
> indeed valid.

That did the trick. Thanks a lot! :-)

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Fri, 22 Sep 2017 22:52:13 +0200, Kristian Fiskerstrand wrote:
> On 09/22/2017 10:48 PM, Stefan Claas wrote:
> > On Fri, 22 Sep 2017 22:32:37 +0200, Kristian Fiskerstrand wrote:  
> 
> 
> >>> And in place of the fake sigs it says erroneous MPI value. :-)
> >>
> >> And what happens if you do gpg --import-options import-clean
> >> --recv-key ? is the bad MPI value sigs removed or still there in
> >> that case?  
> > 
> > Unfortunately still there.  
> 
> Well, it doesn't really do anything, as the signature will be checked
> when calculating the trust database for the web of trust, but indeed,
> need to use --check-sigs explicitly in your use case then.

O.k. and thanks a lot for your help!

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Kristian Fiskerstrand]

On 09/22/2017 10:48 PM, Stefan Claas wrote:
> On Fri, 22 Sep 2017 22:32:37 +0200, Kristian Fiskerstrand wrote:


>>> And in place of the fake sigs it says erroneous MPI value. :-)  
>>
>> And what happens if you do gpg --import-options import-clean
>> --recv-key ? is the bad MPI value sigs removed or still there in that
>> case?
> 
> Unfortunately still there.

Well, it doesn't really do anything, as the signature will be checked
when calculating the trust database for the web of trust, but indeed,
need to use --check-sigs explicitly in your use case then.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Potius sero quam numquam
Better late then never



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Fri, 22 Sep 2017 22:32:37 +0200, Kristian Fiskerstrand wrote:
> On 09/22/2017 10:29 PM, Stefan Claas wrote:
> > On Fri, 22 Sep 2017 22:17:17 +0200, Kristian Fiskerstrand wrote:  
> >> On 09/22/2017 10:08 PM, Stefan Claas wrote:
> >>> Thanks for the information! Can you tell me please how to import
> >>> a pub key with a local client, so that invalid data get's removed
> >>> automatically? When doing a gpg --receive-key key-id the fake data
> >>> is not removed.  
> >>
> >> What does gpg --check-sigs  report?
> > 
> > Ah... it reports (in german) 3 correct sigs and 2 not checked
> > because of errors.
> > 
> > And in place of the fake sigs it says erroneous MPI value. :-)  
> 
> And what happens if you do gpg --import-options import-clean
> --recv-key ? is the bad MPI value sigs removed or still there in that
> case?

Unfortunately still there.

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Kristian Fiskerstrand]

On 09/22/2017 10:29 PM, Stefan Claas wrote:
> On Fri, 22 Sep 2017 22:17:17 +0200, Kristian Fiskerstrand wrote:
>> On 09/22/2017 10:08 PM, Stefan Claas wrote:  
>>> Thanks for the information! Can you tell me please how to import
>>> a pub key with a local client, so that invalid data get's removed
>>> automatically? When doing a gpg --receive-key key-id the fake data
>>> is not removed.
>>
>> What does gpg --check-sigs  report?  
> 
> Ah... it reports (in german) 3 correct sigs and 2 not checked because of
> errors.
> 
> And in place of the fake sigs it says erroneous MPI value. :-)

And what happens if you do gpg --import-options import-clean --recv-key
? is the bad MPI value sigs removed or still there in that case?


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Veni, vidi, vacatum
I came , I saw, I left



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Houston, we have a problem

[Stefan Claas]

On Fri, 22 Sep 2017 22:17:17 +0200, Kristian Fiskerstrand wrote:
> On 09/22/2017 10:08 PM, Stefan Claas wrote:  
> > Thanks for the information! Can you tell me please how to import
> > a pub key with a local client, so that invalid data get's removed
> > automatically? When doing a gpg --receive-key key-id the fake data
> > is not removed.
> 
> What does gpg --check-sigs  report?  

Ah... it reports (in german) 3 correct sigs and 2 not checked because of
errors.

And in place of the fake sigs it says erroneous MPI value. :-)

Regards
Stefan 

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Kristian Fiskerstrand]

On 09/22/2017 10:08 PM, Stefan Claas wrote:
> Thanks for the information! Can you tell me please how to import
> a pub key with a local client, so that invalid data get's removed
> automatically? When doing a gpg --receive-key key-id the fake data
> is not removed.

What does gpg --check-sigs  report?

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Primum ego, tum ego, deinde ego
First I, then I, thereafter I.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Fri, 22 Sep 2017 21:40:41 +0200, Kristian Fiskerstrand wrote:
> On 09/22/2017 09:34 PM, Stefan Claas wrote:
> >>> O.k. i just tested a bit and this is a bug int the Web Interface
> >>> and in GnuPG's CLI Interface. 
> >> I don't see a bug here.  
> > Now i am a bit confused... Then maybe a "funny" design flaw? I mean
> > what should users unfamiliar with the whole WoT procedure may
> > think when seeing a fake "sig3" (which they may not spot) and then
> > clicking on the key-id in question, which then links to the original
> > key?
> >   
> 
> No, its not a design flaw, it is valid design. OpenPGP keyblock
> information is based on an object based security model where packets
> are added, but don't carry any meaning until the signature has been
> verified. The public keyserver network is by design not a trusted
> third party, and can not be, so keyblock needs to be imported using a
> local client at which point invalid data, including invalid
> signatures, results in discarding of the data, which would filter out
> the signature in this case.
> 
> So all is as it is supposed to be

Thanks for the information! Can you tell me please how to import
a pub key with a local client, so that invalid data get's removed
automatically? When doing a gpg --receive-key key-id the fake data
is not removed.

Regards
Stefan


-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Kristian Fiskerstrand]

On 09/22/2017 09:40 PM, Kristian Fiskerstrand wrote:
> So all is as it is supposed to be

Just to add, the alternative if not considering WoT is a direct
validation structure, a user in this case should only (locally) sign
keyblock information of communication peers after a direct fingerprint
exchange in person, that removes any need for adding ownertrust to keys
not your own and simplifies the model.

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Nunc aut numquam
Now or never



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Kristian Fiskerstrand]

On 09/22/2017 09:34 PM, Stefan Claas wrote:
>>> O.k. i just tested a bit and this is a bug int the Web Interface
>>> and in GnuPG's CLI Interface.   
>> I don't see a bug here.
> Now i am a bit confused... Then maybe a "funny" design flaw? I mean
> what should users unfamiliar with the whole WoT procedure may
> think when seeing a fake "sig3" (which they may not spot) and then
> clicking on the key-id in question, which then links to the original
> key?
> 

No, its not a design flaw, it is valid design. OpenPGP keyblock
information is based on an object based security model where packets are
added, but don't carry any meaning until the signature has been
verified. The public keyserver network is by design not a trusted third
party, and can not be, so keyblock needs to be imported using a local
client at which point invalid data, including invalid signatures,
results in discarding of the data, which would filter out the signature
in this case.

So all is as it is supposed to be

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"By three methods we may learn wisdom: First, by reflection, which is
noblest; Second, by imitation, which is easiest; and third by
experience, which is the bitterest."
(Confucius)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Fri, 22 Sep 2017 20:29:07 +0200, Werner Koch wrote:
> On Fri, 22 Sep 2017 19:23, stefan.cl...@posteo.de said:
> 
> > O.k. i just tested a bit and this is a bug int the Web Interface
> > and in GnuPG's CLI Interface.   
> 
> I don't see a bug here.

Now i am a bit confused... Then maybe a "funny" design flaw? I mean
what should users unfamiliar with the whole WoT procedure may
think when seeing a fake "sig3" (which they may not spot) and then
clicking on the key-id in question, which then links to the original
key?

> However, given that you use Posteo, you are in the good position to
> use the Web Key Directory feature.  This requires 2.2.1 because we
> had to add some workaround for key upload due to changes at Posteo
> which we didn't caught earlier.  So people sending mail to you using
> a GnuPG 2.2 would find your key instantly.  It is not there right now:
> 
>   /usr/local/libexec/gpg-wks-client -v --check stefan.claas at posteo
> de gpg-wks-client: public key for 'stefan.cl...@posteo.de' NOT found
> via WKD

Well, as i mentioned previously i have have no longer access to my key,
due to my stupidness. I may consider to create a new one for posteo
usage, but this may take a while.
 
> You may use the latest Enigmail or Kmail to automate the upload but
> you can also use Posteo's Web interface to upload the key.  But take
> care: Posteo does not allow a Name in the user id, only the mail
> address (addr-spec) is allowed.  Thus you need to add a second user
> id with just your mailaddress and use gpg's filter stuff to export
> only that UID. GnuPG 2.2.1 automates that tasks and creates another
> user if needed.
> 
> If you want to test this feature you may send a mail to clara.chefin
> at posteo de, which is a test account of us.  (You can also write to
> the owner of Posteo to ask him why they still have an invalid
> certificate for posteo.net addresses ;-).

O.k thanks for the info. When time permits i will check this out.

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Werner Koch]

On Fri, 22 Sep 2017 19:23, stefan.cl...@posteo.de said:

> O.k. i just tested a bit and this is a bug int the Web Interface and in
> GnuPG's CLI Interface. 

I don't see a bug here.

However, given that you use Posteo, you are in the good position to use
the Web Key Directory feature.  This requires 2.2.1 because we had to
add some workaround for key upload due to changes at Posteo which we
didn't caught earlier.  So people sending mail to you using a GnuPG 2.2
would find your key instantly.  It is not there right now:

  /usr/local/libexec/gpg-wks-client -v --check stefan.claas at posteo de
  gpg-wks-client: public key for 'stefan.cl...@posteo.de' NOT found via WKD

You may use the latest Enigmail or Kmail to automate the upload but you
can also use Posteo's Web interface to upload the key.  But take care:
Posteo does not allow a Name in the user id, only the mail address
(addr-spec) is allowed.  Thus you need to add a second user id with just
your mailaddress and use gpg's filter stuff to export only that UID.
GnuPG 2.2.1 automates that tasks and creates another user if needed.

If you want to test this feature you may send a mail to clara.chefin at
posteo de, which is a test account of us.  (You can also write to the
owner of Posteo to ask him why they still have an invalid certificate
for posteo.net addresses ;-).

>
> Regards
> Stefan

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpsSZYqr6WSF.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Thu, 21 Sep 2017 16:44:57 +0200, Stefan Claas wrote:
> Hi all,
> 
> http://pgp.zdv.uni-mainz.de:11371/pks/lookup?op=vindex=Erika+Mustermann
> 
> Question for the experts, how can a casual or new GnuPG user, like
> Alice and Bob, detect a Signature forgery on a pub key, when using
> Web based key servers?
> 
> Note for native English speakers, Erika Mustermann is well known among
> german users, same as Jon Doe.

O.k. i just tested a bit and this is a bug int the Web Interface and in
GnuPG's CLI Interface. 

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

Am 22.09.2017 um 02:37 schrieb Ángel:

On 2017-09-21 at 23:37 +0200, Stefan Claas wrote:

Long ago when we had a discussion here on the Mailing List on
how to prevent unwanted signatures i made a proposal that
signing someone's public key should work similar to revocation
certificates. If you would like to sign my pub key you had to
send me a, let's call it, Signature Request Certificate, if i accept
it i enter my passphrase and then the Software would extract
the needed signature bits from the request cert and add those
bits to my pub key. Like i said i'm no programmer and can't
therefore test if such a feature proposal would work.

Regards
Stefan


Nope. This would solve the case of «Key of legitimate user signed by
fake user»¹ but not «Fake user signed by another fake user», which is
the problem.


¹ Assuming the legitimate one would notice and not allow his key to be
signed by the evil one, which is no problem, actually.


The proposal would be technically feasible (invalidating all existing
signatures, and probably conflicting with local sigs, but feasible).
However, it wouldn't solve the underlying problem.



Thanks for your insights, much appreciated!

Regards
Stefan


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Ángel]

On 2017-09-21 at 23:37 +0200, Stefan Claas wrote:
> Long ago when we had a discussion here on the Mailing List on
> how to prevent unwanted signatures i made a proposal that
> signing someone's public key should work similar to revocation
> certificates. If you would like to sign my pub key you had to
> send me a, let's call it, Signature Request Certificate, if i accept
> it i enter my passphrase and then the Software would extract
> the needed signature bits from the request cert and add those
> bits to my pub key. Like i said i'm no programmer and can't
> therefore test if such a feature proposal would work.
> 
> Regards
> Stefan


Nope. This would solve the case of «Key of legitimate user signed by
fake user»¹ but not «Fake user signed by another fake user», which is
the problem.


¹ Assuming the legitimate one would notice and not allow his key to be
signed by the evil one, which is no problem, actually.


The proposal would be technically feasible (invalidating all existing
signatures, and probably conflicting with local sigs, but feasible).
However, it wouldn't solve the underlying problem.

Best




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Thu, 21 Sep 2017 17:05:35 -0400, Daniel Kahn Gillmor wrote:

> If by "key-id" you mean the 32-bit long thing like "D21739E9", then
> there's no way to cryptographically secure that -- it's just too
> low-entropy.  I've written elsewhere about why key ids are bad:
> 
> https://debian-administration.org/users/dkg/weblog/105
> 
> Hope this helps to clear things up,

Yes, i was referring to those bits and thanks for your other
detailed explanation.

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Thu, 21 Sep 2017 23:11:23 +0200, Ralph Seichter wrote:
> On 21.09.17 22:37, Stefan Claas wrote:
> 
> > If i would be a programmer of software like GnuPG, my software would
> > not allow to receive unwanted signatures on my pub key, nor would it
> > allow that someone else can fake a sig on someone else's pub key
> > with my key-id.  
> 
> If you can solve the design problem of having a decentralised key
> infrastucture, the ability for everyone to create and sign keys
> without third party involvement, and the detection/prevention of
> "fake" sigs (whatever fake may mean), I'm sure we all would be
> interested. ;-)

Long ago when we had a discussion here on the Mailing List on
how to prevent unwanted signatures i made a proposal that
signing someone's public key should work similar to revocation
certificates. If you would like to sign my pub key you had to
send me a, let's call it, Signature Request Certificate, if i accept
it i enter my passphrase and then the Software would extract
the needed signature bits from the request cert and add those
bits to my pub key. Like i said i'm no programmer and can't
therefore test if such a feature proposal would work.

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Thu, 21 Sep 2017 17:06:18 -0400, Robert J. Hansen wrote:
> > Do i understand you right, i validate Werner's pub key and when
> > i get a signed email from Erika Mustermann the sig should be then
> > o.k. from her, because i signed Werner's key?  
> 
> No.  When you see something claiming to be Werner's sig on Erika's
> certificate, ask yourself:
> 
>   * Is it correct?
>   * Does the signing cert really belong to Werner?
>   * Do you trust Werner?
> 
> If you can positively answer all three questions 'yes', then you
> should trust it.  Otherwise, you shouldn't.

I can only say now i don't know if i should ever "trust" signatures
again on someone else's pub key, because in the past i have had only
communicated with people i did not know personally. And with
Erika's key example while trusting Werner's key i don't like the
idea when clicking in the Web interface on Werner's key-id that
it leads to Werner's key. That's all what i can say now. I better
should start now using my class3 S/MIME certificate...

Regards
Stefan


-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Daniel Kahn Gillmor]

On Thu 2017-09-21 22:37:38 +0200, Stefan Claas wrote:
> I'm sorry! Let me say one last word. If i would be a programmer of
> software like GnuPG, my software would not allow to receive unwanted
> signatures on my pub key

The way the universe works is that once data is public, other data might
refer to that public data, and even the person who created the first bit
of data can't prevent it.

An OpenPGP certificate is, at minimum:

 * a public primary key K
 * a User ID U
 * a signature from K that binds U to K

Once this data is published, anyone with a different key X can make a
new certification, which also claims that U is correctly bound to K.
This is what "signing a key" means.

Your choice of software implementation can't prevent those third-party
certifications from being produced, nor from being published, nor can it
prevent other people's software from discovering them and making
inferences based on them.

There are some good (and some bad) arguments that software capable of
interpreting OpenPGP certificates should only accept third-party
certifications that the first-party (the party being certified) has
explicitly endorsed, which might come close to meeting your requirement
here.  But no one has spec'ed out exactly how to do that or written such
a constraint, and existing OpenPGP software will continue to exist even
if new (improved) software is developed and distributed.

> nor would it allow that someone else can fake a sig on someone else's
> pub key with my key-id.

If by "key-id" you mean your actual public key, then the cryptography
behind OpenPGP does actually enforce this already.  It's not believed to
be possible to forge an OpenPGP signature from any reasonably strong
modern OpenPGP key.

If by "key-id" you mean the 32-bit long thing like "D21739E9", then
there's no way to cryptographically secure that -- it's just too
low-entropy.  I've written elsewhere about why key ids are bad:

https://debian-administration.org/users/dkg/weblog/105

Hope this helps to clear things up,

 --dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Ralph Seichter]

On 21.09.17 22:37, Stefan Claas wrote:

> If i would be a programmer of software like GnuPG, my software would
> not allow to receive unwanted signatures on my pub key, nor would it
> allow that someone else can fake a sig on someone else's pub key with
> my key-id.

If you can solve the design problem of having a decentralised key
infrastucture, the ability for everyone to create and sign keys without
third party involvement, and the detection/prevention of "fake" sigs
(whatever fake may mean), I'm sure we all would be interested. ;-)

-Ralph

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Robert J. Hansen]

> Do i understand you right, i validate Werner's pub key and when
> i get a signed email from Erika Mustermann the sig should be then
> o.k. from her, because i signed Werner's key?

No.  When you see something claiming to be Werner's sig on Erika's
certificate, ask yourself:

* Is it correct?
* Does the signing cert really belong to Werner?
* Do you trust Werner?

If you can positively answer all three questions 'yes', then you should
trust it.  Otherwise, you shouldn't.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Ralph Seichter]

On 21.09.17 22:13, Robert J. Hansen wrote:

> About 25 years ago I first saw the suggestion that signatures from
> unvalidated certificates should simply not be visible to the end-user
> [...]

Yeah, that would be one way to make these sigs less obvious. Of course
it does not solve the underlying issue, but for the layman it might be
an improvement.

-Ralph

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Thu, 21 Sep 2017 22:38:06 +0200, Ralph Seichter wrote:
> On 21.09.17 22:11, Stefan Claas wrote:
> 
> > > You can only ever be certain of a signature if you have personally
> > > verified the signing key and the signer's identity.  
> >
> > Well, call me a stupid Mac dummie, but how in the world could GnuPG
> > users , living in different areas verify that?  
> 
> They can't. That's one of the reasons the "web of trust" is a tricky
> concept. Among all of the people I know to use PGP, I trust only two
> to verify both key fingerprints and identities as thoroughly as I do.
> That means I usually have to jump through hoops to verify stuff
> myself, and that only works for people I have personally met (and
> checked their Personalausweis or what have you). My web of trust is
> almost non-existent. Yours might be extensive. It all depends on what
> you verify yourself and who else you trust to verify. As Robert
> wrote, you seem to keep rehashing the same issue, and an old one at
> that.

Thank you for your detailed point of view.

> > https://pgp.governikus-eid.de/pgp/  
> 
> You mean there are people who actually use Online-PA, and trust the
> BSI on top of that? You're kidding, right? ;-) I neither care nor
> trust what Governikus signs. I've been providing IT security services
> for decades, and find it extremely hard to trust others in this
> field, based on my own experience.

Well, i used once their service to obtain a sig3. I think under normal
circumstances this would be a better idea to check if a Personalausweis
is valid or fake, assuming GnuPG Signatures could be used in the future
for online business, because then "carefully" crafted WoT signatures
would have imho no weight in the business world.

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Ralph Seichter]

On 21.09.17 22:11, Stefan Claas wrote:

> > You can only ever be certain of a signature if you have personally
> > verified the signing key and the signer's identity.
>
> Well, call me a stupid Mac dummie, but how in the world could GnuPG
> users , living in different areas verify that?

They can't. That's one of the reasons the "web of trust" is a tricky
concept. Among all of the people I know to use PGP, I trust only two to
verify both key fingerprints and identities as thoroughly as I do. That
means I usually have to jump through hoops to verify stuff myself, and
that only works for people I have personally met (and checked their
Personalausweis or what have you). My web of trust is almost non-existent.
Yours might be extensive. It all depends on what you verify yourself and
who else you trust to verify. As Robert wrote, you seem to keep rehashing
the same issue, and an old one at that.

> https://pgp.governikus-eid.de/pgp/

You mean there are people who actually use Online-PA, and trust the BSI
on top of that? You're kidding, right? ;-) I neither care nor trust what
Governikus signs. I've been providing IT security services for decades,
and find it extremely hard to trust others in this field, based on my
own experience.

-Ralph


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Thu, 21 Sep 2017 16:16:12 -0400, Robert J. Hansen wrote:
> > If someone would issue a fake sig3 from Governikus to someone
> > else how could you, for example, verify that the sig3 is from
> > Governikus?  
> 
> By validating Governikus's certificate.

Do i understand you right, i validate Werner's pub key and when
i get a signed email from Erika Mustermann the sig should be then
o.k. from her, because i signed Werner's key?
 
> You seem to be asking the same question (and getting the same answer)
> over and over again.  Perhaps try a different phrasing?  Or is it that
> the answer isn't clear?

I'm sorry! Let me say one last word. If i would be a programmer of
software like GnuPG, my software would not allow to receive unwanted
signatures on my pub key, nor would it allow that someone else can
fake a sig on someone else's pub key with my key-id.

Good night and best regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Robert J. Hansen]

> If someone would issue a fake sig3 from Governikus to someone
> else how could you, for example, verify that the sig3 is from
> Governikus?

By validating Governikus's certificate.

You seem to be asking the same question (and getting the same answer)
over and over again.  Perhaps try a different phrasing?  Or is it that
the answer isn't clear?


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Robert J. Hansen]

> I'm not certain what problem you see that has not been around for as
> long as PGP/GPG exists? You can only ever be certain of a signature if
> you have personally verified the signing key and the signer's identity.
> That's why the default owner trust level is "unknown" (not trusted).

About 25 years ago I first saw the suggestion that signatures from
unvalidated certificates should simply not be visible to the end-user,
as a signature from an unvalidated certificate is meaningless and the
risk of people believing "oh, Frank (or whoever) signed this!" is so high.

(A command of --list-all-sigs would need to be added, to force display
of signatures from unvalidated certificates.)

I've thought it was a good idea ever since I first saw it.  I have
always been in a distinct minority, though...

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Thu, 21 Sep 2017 21:59:26 +0200, Ralph Seichter wrote:
> On 21.09.17 21:38, Stefan Claas wrote:
> 
> > The thing is someone could issue a fake sig3 from Heise's CA key to
> > someone else's pub key, without that that customers would detect it,
> > nor Heise would know it, until of course they would see the keys in
> > question.  
> 
> I'm not certain what problem you see that has not been around for as
> long as PGP/GPG exists? You can only ever be certain of a signature if
> you have personally verified the signing key and the signer's
> identity. That's why the default owner trust level is "unknown" (not
> trusted).

Well, call me a stupid Mac dummie, but how in the world could GnuPG
users , living in different areas verify that? As one more example i
give name here  Governikus CA.

If someone would issue a fake sig3 from Governikus to someone
else how could you, for example, verify that the sig3 is from
Governikus?

https://pgp.governikus-eid.de/pgp/

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Thu, 21 Sep 2017 21:11:17 +0200, Ralph Seichter wrote:
> On 21.09.17 20:49, Stefan Claas wrote:
> 
> > How could customers, not pros like all you guys here on the list,
> > could verify that we both are the persons the keys/signatures are
> > claiming?  
> 
> Legal identification is required. Since you are German, you can use
> https://www.heise.de/security/dienste/Wie-kann-ich-mitmachen-474837.html
> as a reference for how this can be done.

Hi Ralph,

i am well aware of Heise's CA, because an old pub key of mine bears a
sig3 from them. The thing is someone could issue a fake sig3 from
Heise's CA key to someone else's pub key, without that that customers
would detect it, nor Heise would know it, until of course they would
see the keys in question. I don't know if CA's here in Germany scan
key servers for their issued signatures.

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Ralph Seichter]

On 21.09.17 20:49, Stefan Claas wrote:

> How could customers, not pros like all you guys here on the list,
> could verify that we both are the persons the keys/signatures are
> claiming?

Legal identification is required. Since you are German, you can use
https://www.heise.de/security/dienste/Wie-kann-ich-mitmachen-474837.html
as a reference for how this can be done.

-Ralph

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Stefan Claas]

On Thu, 21 Sep 2017 10:55:26 -0400, Robert J. Hansen wrote:
> > Question for the experts, how can a casual or new GnuPG user, like
> > Alice and Bob, detect a Signature forgery on a pub key, when using
> > Web based key servers?  
> 
> By remembering that anyone can create a key claiming to be anyone, and
> that seeing a signature allegedly from Werner (or anyone) means
> absolutely nothing until and unless you've verified the signing
> certificate actually belongs to him.
> 
> Key validation -- ensuring a key really belongs to who it says -- is
> an important step.  It cannot be skipped.  It is not optional.

Thanks for your reply. Let's assume the following: You would be also
a german national, we both are friends and would have bad things in
mind...

I issue now fake signatures (from a german CA) to our fake keys* and
then we would start some bad business on the Internet. How could
customers, not pros like all you guys here on the list, could verify
that we both are the persons the keys/signatures are claiming?

* Due to my stupidness i no longer have access to my passphrase
nor can i find my rev cert, in case someone would use my key,
which i used here for signing previous post from me.

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Houston, we have a problem

[Robert J. Hansen]

> Question for the experts, how can a casual or new GnuPG user, like Alice
> and Bob, detect a Signature forgery on a pub key, when using Web based
> key servers?

By remembering that anyone can create a key claiming to be anyone, and
that seeing a signature allegedly from Werner (or anyone) means
absolutely nothing until and unless you've verified the signing
certificate actually belongs to him.

Key validation -- ensuring a key really belongs to who it says -- is an
important step.  It cannot be skipped.  It is not optional.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Houston, we have a problem

[Stefan Claas]

Hi all,

http://pgp.zdv.uni-mainz.de:11371/pks/lookup?op=vindex=Erika+Mustermann

Question for the experts, how can a casual or new GnuPG user, like Alice
and Bob, detect a Signature forgery on a pub key, when using Web based
key servers?

Note for native English speakers, Erika Mustermann is well known among
german users, same as Jon Doe.

Regards
Stefan


-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users