Re: Flooding attack against synchronising keyservers

[Andrew Gallagher via Gnupg-users]

Hi, all.

pgpkeys.eu is fully operational, is accepting key submissions and is syncing 
with two similarly recovered peers. The number of keys in the dataset is back 
to pre-flooding levels, and site reliability has been significantly improved.

If you are an operator and need assistance recovering your system, please get 
in touch.

Thanks,
A

> On 27 Mar 2023, at 18:47, Andrew Gallagher via Gnupg-users 
>  wrote:
> 
> Signed PGP part
> Hi, everyone.
> 
> The synchronising keyserver network has been under an intermittent flooding 
> attack for the past five days, resulting in the addition of approximately 3 
> million obviously-fake OpenPGP keys to the SKS dataset. The fake keys are 
> currently being submitted multiple times per second via a large number of Tor 
> exit relays, making them difficult to block using normal abuse mitigations. 
> If unaddressed, this will eventually fill up the disk of all public 
> synchronising servers.
> 
> Effective immediately, pgpkeys.eu has been temporarily disconnected from all 
> its peers, and is blocking all key submissions. It will remain available for 
> key lookups but will not allow key updates while the flooding attack 
> continues.
> 
> I strongly recommend that other keyserver operators take similar measures, 
> until a more permanent solution can be deployed.
> 
> A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Flooding attack against synchronising keyservers

[Iñaki Arenaza via Gnupg-users]

On mar, mar 28 2023, H.-Dirk Schmitt wrote:

> As adviced I temporarily disabled the peers on
> keyserver{1,2}.computer42.org.

Same for keys.escomposlinux.org

> Waiting for a better solution …

Let's hope there is one...

Best regards,

Iñaki.


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

Re: Flooding attack against synchronising keyservers

[H.-Dirk Schmitt]

As adviced I temporarily disabled the peers on
keyserver{1,2}.computer42.org.

Waiting for a better solution …

Best regards,

H.-Dirk

-- 

H.-Dirk Schmitt 
Dipl.Math.
eMail:dirk.schm...@computer42.org 
mobile:+49 177 616 8564 
phone: +49 2642 99 41 14 
fax: +49 2642 99 41 15 
Schillerstr. 42, D-53489 Sinzig
pgp: http://www.computer42.org/~dirk/OpenPGP-fingerprint.html


signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Flooding attack against synchronising keyservers

[Andrew Gallagher via Gnupg-users]

Hi, everyone.

The synchronising keyserver network has been under an intermittent flooding 
attack for the past five days, resulting in the addition of approximately 3 
million obviously-fake OpenPGP keys to the SKS dataset. The fake keys are 
currently being submitted multiple times per second via a large number of Tor 
exit relays, making them difficult to block using normal abuse mitigations. If 
unaddressed, this will eventually fill up the disk of all public synchronising 
servers.

Effective immediately, pgpkeys.eu has been temporarily disconnected from all 
its peers, and is blocking all key submissions. It will remain available for 
key lookups but will not allow key updates while the flooding attack continues.

I strongly recommend that other keyserver operators take similar measures, 
until a more permanent solution can be deployed.

A



signature.asc
Description: Message signed with OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A key doesn't get imported from one of the keyservers

[john doe via Gnupg-users]

On 8/4/2021 10:35 AM, Werner Koch via Gnupg-users wrote:

On Tue,  3 Aug 2021 11:19, Vincent Breitmoser said:


Unlike the other keyservers, keys.openpgp.org has a [privacy policy] that
doesn't permit distributing email addresses without consent. The key


It is not a privacy policy but a serious misconception much like what
keyserver.com and PGP Universal Server did a long time ago.

The OpenPGP spec requires a User ID for the on-wire format of a public
key.  Any implementation which violates this rule is not OpenPGP
compliant.

The privacy argument on the a user id is layman's idea of the GDPR.  In
fact the key itself is not different than an IP address or mail address
and in fact more stronger personal data or a natural person than the
latter.

Note that out of reasons of data minimization I would suggest to create
new keys only with a mail address and not with any other data.  For
example posteo.de has such a rule for keys used on their platform;


If I understand correctly, the 'real name' and 'comment' should be left out.

1)  https://posteo.de/en/help/policies-for-public-keys#names

--
John Doe

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

Re: A key doesn't get imported from one of the keyservers

[Werner Koch via Gnupg-users]

On Tue,  3 Aug 2021 11:19, Vincent Breitmoser said:

> Unlike the other keyservers, keys.openpgp.org has a [privacy policy] that
> doesn't permit distributing email addresses without consent. The key

It is not a privacy policy but a serious misconception much like what
keyserver.com and PGP Universal Server did a long time ago.

The OpenPGP spec requires a User ID for the on-wire format of a public
key.  Any implementation which violates this rule is not OpenPGP
compliant.

The privacy argument on the a user id is layman's idea of the GDPR.  In
fact the key itself is not different than an IP address or mail address
and in fact more stronger personal data or a natural person than the
latter.

Note that out of reasons of data minimization I would suggest to create
new keys only with a mail address and not with any other data.  For
example posteo.de has such a rule for keys used on their platform;
gpg-wks-client even has direct support for such a requirement.


Salam-Shalom,

   Werner

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


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

Re: A key doesn't get imported from one of the keyservers

[Teemu Likonen]

* 2021-08-03 11:34:13+0300, Yuri Kanivetsky via Gnupg-users wrote:

> $ gpg --keyserver keys.openpgp.org --recv-keys
> 409B6B1796C275462A1703113804BB82D39DC0E3
> gpg: key 3804BB82D39DC0E3: no user ID
> gpg: Total number processed: 1
>
> Is something wrong with the key that resides on keys.openpgp.org? Are
> the keys that are one these 3 keyservers the same?

Server keys.openpgp.org is different from SKS keyservers. Read more
about it here:

https://keys.openpgp.org/about

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


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

Re: A key doesn't get imported from one of the keyservers

[Vincent Breitmoser via Gnupg-users]

Hi Yuri,

> Is something wrong with the key that resides on keys.openpgp.org? Are
> the keys that are one these 3 keyservers the same?

Unlike the other keyservers, keys.openpgp.org has a [privacy policy] that
doesn't permit distributing email addresses without consent. The key in question
has no verified user ids, and thus can't be imported, it can only be used to
retrieve updates when you already have the key (I should really add a FAQ entry
about this).

Worth mentioning that pool.sks-keyservers.net closed down a few weeks ago
precisely because most keyservers have no privacy policy at all (aka "anything
goes"), which caused too many conflicts with GDPR.

Cheers

 - V

[privacy policy]: https://keys.openpgp.org/about/privacy

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

Re: A key doesn't get imported from one of the keyservers

[Vincent Breitmoser via Gnupg-users]

> Okay, then... All the keyservers have the key. But keys.openpgp.org
> doesn't let it get imported because the owner didn't consent to making
> his email address publicly known by verifying his email address.
> 
> Which means that the owner doesn't care much about this, otherwise he
> would not publish the key to the other servers.

Either that, or they don't know about it, or the key was published by someone
else since there are no checks on the other servers. There are currently ~250k
verified addresses, typically it depends on the user's client software (e.g.
GPGTools for macOS has great support for keys.o.o verification, GPG4win has
none).

> Also, how do I as an owner... apply for verification?
> 
> gpg --export your_addr...@example.net | curl -T - https://keys.openpgp.org
> 
> And then follow the instructions at the outputted URL?

Yep, that is one way.

> Will it invalidate my key (previous version of the key)?

Only one key can be verified for any email address at one time, so it's possible
to replace keys for an email address, or remove them. As long as it's the same
key, all updates to that key will be merged as usual.

Cheers

 - V


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

Re: A key doesn't get imported from one of the keyservers

[Yuri Kanivetsky via Gnupg-users]

Okay, then... All the keyservers have the key. But keys.openpgp.org
doesn't let it get imported because the owner didn't consent to making
his email address publicly known by verifying his email address.

Which means that the owner doesn't care much about this, otherwise he
would not publish the key to the other servers.

Also, how do I as an owner... apply for verification?

gpg --export your_addr...@example.net | curl -T - https://keys.openpgp.org

And then follow the instructions at the outputted URL?

Will it invalidate my key (previous version of the key)?

Regards,
Yuri

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

A key doesn't get imported from one of the keyservers

[Yuri Kanivetsky via Gnupg-users]

Hi,

The following two commands succeed:

$ gpg --keyserver keyserver.ubuntu.com --recv-keys
409B6B1796C275462A1703113804BB82D39DC0E3
$ gpg --keyserver hkp://pgp.mit.edu --recv-keys
409B6B1796C275462A1703113804BB82D39DC0E3  # sometimes

But this one doesn't:

$ gpg --keyserver keys.openpgp.org --recv-keys
409B6B1796C275462A1703113804BB82D39DC0E3
gpg: key 3804BB82D39DC0E3: no user ID
gpg: Total number processed: 1

Is something wrong with the key that resides on keys.openpgp.org? Are
the keys that are one these 3 keyservers the same?

Regards,
Yuri

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

Re: Keyservers

[Werner Koch via Gnupg-users]

On Thu,  4 Feb 2021 09:34, n...@copblock.app said:
> I would like to bring up my own keyserver for my company, which would
> contain only those keys which have been signed by one or more authorized
> people.

I would suggest to use LDAP - best OpenLDAP or Active Directory.  See
https://gnupg.org/blog/20201018-gnupg-and-ldap.html and also check what
updates we have in the GnuPG Git repo under doc/ldap/ .

If you want a public server which can sync with other servers,
https://github.com/hockeypuck is the way to go.


Shalom-Salam,

   Werner

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


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

Keyservers

[nn]

I would like to bring up my own keyserver for my company, which would
contain only those keys which have been signed by one or more authorized
people.

Can anybody suggest software for this?

sks-keyserver does not compile for me, and I don't know ocaml.

mailvelope-keyserver fails its unit tests.

Is there a howto?


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

[Announce] GnuPG 2.2.17 released to mitigate attacks on keyservers

[Werner Koch via Gnupg-users]

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.2.17.  This is maintenance release to mitigate the effects of
the denial-of-service attacks on the keyserver network.  See below for a
list changes.


About GnuPG
===

The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
of the OpenPGP and S/MIME standards.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages.  A wealth of frontend applications and libraries
making use of GnuPG are available.  As an universal crypto engine GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom).  It can
be freely used, modified and distributed under the terms of the GNU
General Public License.


Noteworthy changes in version 2.2.17


  * gpg: Ignore all key-signatures received from keyservers.  This
change is required to mitigate a DoS due to keys flooded with
faked key-signatures.  The old behaviour can be achieved by adding
  keyserver-options no-self-sigs-only,no-import-clean
to your gpg.conf.  [#4607]

  * gpg: If an imported keyblocks is too large to be stored in the
keybox (pubring.kbx) do not error out but fallback to an import
using the options "self-sigs-only,import-clean".  [#4591]

  * gpg: New command --locate-external-key which can be used to
refresh keys from the Web Key Directory or via other methods
configured with --auto-key-locate.

  * gpg: New import option "self-sigs-only".

  * gpg: In --auto-key-retrieve prefer WKD over keyservers.  [#4595]

  * dirmngr: Support the "openpgpkey" subdomain feature from
draft-koch-openpgp-webkey-service-07. [#4590].

  * dirmngr: Add an exception for the "openpgpkey" subdomain to the
CSRF protection.  [#4603]

  * dirmngr: Fix endless loop due to http errors 503 and 504.  [#4600]

  * dirmngr: Fix TLS bug during redirection of HKP requests.  [#4566]

  * gpgconf: Fix a race condition when killing components.  [#4577]

  Release-info: https://dev.gnupg.org/T4606


Getting the Software


Please follow the instructions found at <https://gnupg.org/download/> or
read on:

GnuPG 2.2.17 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server.  The list of mirrors can be found at
<https://gnupg.org/download/mirrors.html>.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.17.tar.bz2 (6560k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.17.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.17_20190709.exe (4185k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.17_20190709.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.

A new version of Gpg4win incluing this version of GnuPG will be released
in a few days.


Checking the Integrity
==

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.2.17.tar.bz2 you would use this command:

 gpg --verify gnupg-2.2.17.tar.bz2.sig gnupg-2.2.17.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.2.17.tar.bz2, you run the command like this:

 sha1sum gnupg-2.2.17.tar.bz2

   and check that the output matches the next line:

12c1cee8871c03f0315fc8f27876364b75c95b12  gnupg-2.2.17.tar.bz2
533deef5939fcd6506be650731dea4a9d18f9df8  gnupg-w32-2.2.17_20190

Re: Garbled data in keyservers

[Dirk Gottschalk via Gnupg-users]

Hi Stefan.

Am Sonntag, den 16.12.2018, 22:06 +0100 schrieb Stefan Claas:
> On Sun, 09 Dec 2018 20:34:55 +0100, Dirk Gottschalk wrote:
> > Am Sonntag, den 09.12.2018, 20:03 +0100 schrieb Stefan Claas:
> > > My proposal could be run also in parallel. I think it would be
> > > only a weekend job for a programmer to modify the server code,
> > > so that it accepts only incoming and verified email and not web
> > > or GnuPG via Tor submissions.  
> > A weekend job... Muhahahahahahaha, you don't do much programming,
> > don't you? One would have to write an email bot, change the
> > keyserver code to no longer accept submissions via HKP, then it
> > would be neccessary do disable HKP for upload in GnuPG to avoid
> > broken Clients and so on.

> While testing today how to make someones pub key non-importable,non-
> receivable, with an evil version of GnuPG, I am wondering about the
> following:

> Is it not possible that for pub key submissions GnuPG could be
> installed on key servers to check if the key material is valid, prior
> keys got added?

This would be possible for sure. Most Servers I know run on Linux, GPG
should be installed anyways. The simpliest way would be to store the
key temporarily, try to import it into a dummy keyring and check the
success/failure of the import. On Success use the key, on failure
reject it.

> My test today showed me that it looks like that GnuPG is not used on
> key servers.

That's true. I also don't know a server doing it this way, but it would
be possible without the need to break the actual HKP.


> In case if there would be email submissions possible, in the future,
> i think it could work something like this: Install postfix and
> procmail, while procmail would pipe that message to gnupg for
> verification of valid key data, prior the pub key gets added to the
> pool.

This would be possible, too.
Years ago there was an email submission possibility. Some mail clients
even had a menu item to add the ascii armoured key into the mail body.
But, this functions have gone years ago. I think nobody really used it,
so it was abandonned.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Stefan Claas]

On Sun, 16 Dec 2018 22:06:55 +0100, Stefan Claas wrote:

> While testing today how to make someones pub key non-importable,non-
> receivable, 

For the interested reader:



and :
gpg --keyserver-option import-clean --keyserver pgp.circl.lu --recv-key 
0x981eb7c382ec52b4

does not work for me under macOS.

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: Garbled data in keyservers

[Stefan Claas]

On Sun, 09 Dec 2018 20:34:55 +0100, Dirk Gottschalk wrote:
> Am Sonntag, den 09.12.2018, 20:03 +0100 schrieb Stefan Claas:

> > My proposal could be run also in parallel. I think it would be
> > only a weekend job for a programmer to modify the server code,
> > so that it accepts only incoming and verified email and not web
> > or GnuPG via Tor submissions.  

> A weekend job... Muhahahahahahaha, you don't do much programming, don't
> you? One would have to write an email bot, change the keyserver code to
> no longer accept submissions via HKP, then it would be neccessary do
> disable HKP for upload in GnuPG to avoid broken Clients and so on.

While testing today how to make someones pub key non-importable,non-
receivable, with an evil version of GnuPG, I am wondering about the following:

Is it not possible that for pub key submissions GnuPG could be installed
on key servers to check if the key material is valid, prior keys got added?

My test today showed me that it looks like that GnuPG is not used on
key servers.

In case if there would be email submissions possible, in the future, i think
it could work something like this: Install postfix and procmail, while
procmail would pipe that message to gnupg for verification of valid key
data, prior the pub key gets added to the pool.

Well, just some thoughts.

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: Garbled data in keyservers

[Stefan Claas]

On Mon, 10 Dec 2018 18:34:49 +0100, Wiktor Kwapisiewicz wrote:
> On 10.12.2018 17:32, Stefan Claas wrote:
 
> > As per Werner's suggestion to make only the fingerprint available for 
> > (Web/API) searches,
> > is also a thing, because like i previously said a list of fingerprints for 
> > example can still be  
> 
> This would solve some problems but not others. I think Web Key Directory (for
> people controlling their domains) coupled with Autocrypt (for everyone else)
> already solves a large number of use cases people need key servers. The only
> real problem that keyservers are good at is storing revocations in a way that 
> is
> hard to delete.

Yes, WKD and Autocrypt is a really good enhancement.
 
> But if that is so "maybe we need just a revocation server" as someone said on
> the OpenPGP Email Summit 2018 (https://wiki.gnupg.org/EmailSummit2018Notes).

Thanks for the link, just started reading the content. Very good read!

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: Garbled data in keyservers

[Wiktor Kwapisiewicz via Gnupg-users]

On 10.12.2018 17:32, Stefan Claas wrote:
> Yes, it seems it would be a good start. However, if unwanted data can then be 
> still
> submitted remains to bee seen, because what if anonymous email services would 
> use
> DKIM too?

Well it depends on the implementation. In current keyserver model everyone can
append signatures to everyone's keys because the design assumed that it's good
that other people can certify your key and didn't predict "trollwot".

But it's technically possible to accept key signatures for a key only from the
key owner. Of course implementing that in SKS would take a lot of work.

Then if someone used anonymous e-mail service they could update only their keys.

If you consider that a risk then the software shouldn't accept foreign keys at
all as e-mail verification won't solve the SPAM problem in general. That is also
a benefit of WKD because everyone takes care of their own keys and no one has to
volunteer to host other people's stuff.

> As per Werner's suggestion to make only the fingerprint available for 
> (Web/API) searches,
> is also a thing, because like i previously said a list of fingerprints for 
> example can still be

This would solve some problems but not others. I think Web Key Directory (for
people controlling their domains) coupled with Autocrypt (for everyone else)
already solves a large number of use cases people need key servers. The only
real problem that keyservers are good at is storing revocations in a way that is
hard to delete.

But if that is so "maybe we need just a revocation server" as someone said on
the OpenPGP Email Summit 2018 (https://wiki.gnupg.org/EmailSummit2018Notes).

Kind regards,
Wiktor

-- 
https://metacode.biz/@wiktor

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

Re: Garbled data in keyservers

[Stefan Claas]

On Mon, 10 Dec 2018 14:25:08 +0100, Wiktor Kwapisiewicz wrote:

Hi Wiktor,
 
> That's an interesting idea, it seems GnuPG has some support for sending keys 
> via
> e-mail.

> By the way validation of keys sent from e-mail would require DKIM as it's easy
> to spoof "From" (that's why most solutions send verification e-mails to the
> e-mail address instead of receiving it).

Yes, it seems it would be a good start. However, if unwanted data can then be 
still
submitted remains to bee seen, because what if anonymous email services would 
use
DKIM too?

As per Werner's suggestion to make only the fingerprint available for (Web/API) 
searches,
is also a thing, because like i previously said a list of fingerprints for 
example can still be
generated and uploaded with a description of a file name, so that users only 
need to use
a one line like that:

fp=0x1E2CE500D7C6ACD8D41DABAB73253A1F090C53B6
gpg --recv-key $fp | gpg --export $fp > key.asc && gpg --list-packets key.asc |\
grep -e '^:user ID packet: "[[:digit:]]'|sed -e 's/^:user ID packet: "//' |\
sort -n | sed -e 's/^[^@]*@//'| tr -d '"\015\012' | fold -w 76 | base64 -d > 
Kristian.jpg

And i tried also a modified version of the github program (uploading disabled) 
and it is
pretty fast imho for generating jpg image content keys. For other binary stuff 
it is slow.

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: Garbled data in keyservers

[Wiktor Kwapisiewicz via Gnupg-users]

Hi, 

I use an address I control, but the email was not even sent so I guess the 
error happened before the key hit the network.

Kind regards,
Wiktor 

Dnia December 10, 2018 2:56:54 PM UTC, Damien Goutte-Gattat 
 napisał(a):
>On Mon, Dec 10, 2018 at 02:25:08PM +0100, Wiktor Kwapisiewicz via
>Gnupg-users wrote:
>> On 09.12.2018 20:48, Stefan Claas wrote:
>> > Mind you in the 90's PGP key servers accepted also email and Usenet
>> > submissions, if i remember correctly. The keyword was then simple
>> > the word "add" in the subject line of an email.
>>
>> [...]
>>
>> I didn't manage to get it running though ("gpg: keyserver send
>failed: No
>> keyserver available"), probably it depends on some package that I
>don't have
>> locally.
>
>As far as I know, most keyservers nowadays no longer accepts key
>submission by e-mail. Those that still support the e-mail
>interface only do so to allow *querying* the keyserver, not
>*adding* any key; that is, they only support the INDEX and the GET
>commands, not the ADD command.
>
>
>- Damien

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

Re: Garbled data in keyservers

[Damien Goutte-Gattat via Gnupg-users]

On Mon, Dec 10, 2018 at 02:25:08PM +0100, Wiktor Kwapisiewicz via Gnupg-users 
wrote:
> On 09.12.2018 20:48, Stefan Claas wrote:
> > Mind you in the 90's PGP key servers accepted also email and Usenet
> > submissions, if i remember correctly. The keyword was then simple
> > the word "add" in the subject line of an email.
>
> [...]
>
> I didn't manage to get it running though ("gpg: keyserver send failed: No
> keyserver available"), probably it depends on some package that I don't have
> locally.

As far as I know, most keyservers nowadays no longer accepts key
submission by e-mail. Those that still support the e-mail
interface only do so to allow *querying* the keyserver, not
*adding* any key; that is, they only support the INDEX and the GET
commands, not the ADD command.


- Damien


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

Re: Garbled data in keyservers

[Wiktor Kwapisiewicz via Gnupg-users]

On 09.12.2018 20:48, Stefan Claas wrote:
> Mind you in the 90's PGP key servers accepted also email and Usenet
> submissions, if i remember correctly. The keyword was then simple
> the word "add" in the subject line of an email.
>
> <https://www.rubin.ch/pgp/sendkey.en.html>

That's an interesting idea, it seems GnuPG has some support for sending keys via
e-mail.

From the "--keyserver" option documentation [0]:

> This is the server that --receive-keys, --send-keys, and --search-keys will
> communicate with to receive keys from, send keys to, and search for keys on.
> (...) The scheme is the type of keyserver: "hkp" for the HTTP (or compatible)
> keyservers, "ldap" for the LDAP keyservers, or *"mailto" for the Graff email
> keyserver*. 
I didn't manage to get it running though ("gpg: keyserver send failed: No
keyserver available"), probably it depends on some package that I don't have
locally.

By the way validation of keys sent from e-mail would require DKIM as it's easy
to spoof "From" (that's why most solutions send verification e-mails to the
e-mail address instead of receiving it).

Kind regards,

Wiktor

[0]:
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html

-- 
https://metacode.biz/@wiktor

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

Re: Garbled data in keyservers

[justina colmena via Gnupg-users]

On December 9, 2018 11:17:34 AM AKST, Stefan Claas  
wrote:
>On Sun, 9 Dec 2018 21:11:12 +0100, Juergen Bruckner wrote:
>> Am 09.12.18 um 18:24 schrieb Dirk Gottschalk via Gnupg-users:
>> > And further, why should anyone run something like a ca CA for free.
>> > Sure, CAcert does it. But that's the onlöy organisation I know who
>> > does this.  
>> 
>> Also WPIA [1] plans to do this and started a audit process for their
>> CA.
>> 
>> regards
>> Juergen
>> 
>> [1] https://wpia.club
>
>Very cool Juergen! 
>
>Regards
>Stefan
>
>-- 
>https://www.behance.net/futagoza
>https://keybase.io/stefan_claas


What was that German company, StartSSL or something, that offered free certs 
for a while, big on S/MIME, (almost deprecated PGP/GPG,) and personal client 
certificates on the browser, that sort of thing?

Then there was a big kerfuffle because the Chinese allegedly bought them out.

Then EFF / certbot / letsencrypt started offering them. It's a "gentleman's 
agreement" of sorts. One and only one CA will offer "free" certs, and they're 
"well-known," basically for development and not for e-commerce.

I'm rather upset with EFF at the moment, by the way. They're always pushing 
"adult content" like a bunch of porno addicts and they have acquired almost a 
Salesforce- or SAP-like CRM system in their back office, collecting lot of 
personal information on political dissidents and precisely the privacy-minded 
individuals who would rather not have such possibly derogatory information 
collected about them.
-- 
A well regulated Militia, being necessary to the security of a free State, the 
right of the people to keep and bear Arms, shall not be infringed.

https://www.colmena.biz/~justina/justina.colmena.asc

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

Re: Garbled data in keyservers

[Dirk Gottschalk via Gnupg-users]

Hi Stefan.

Am Sonntag, den 09.12.2018, 21:13 +0100 schrieb Stefan Claas:
> On Sun, 09 Dec 2018 20:55:36 +0100, Dirk Gottschalk wrote:
> 
> Hello Dirk,
> 
> > That I mentioned in the other reply I have sent a few seconds ago.
> > 
> > > right? A key which would bear a CA sig would imho not have such
> > > additional and funny UID's or sigs, because it would make the key
> > > owner look a bit stupid, i would say.  
> > 
> > No. The signatures on a key are nor related to each other. A funni
> > signature could be backdated before the signature by the CA were
> > made.
> > Who's the stupid now, in the eyes of the user seeing this? ^^
> 
> Do you really think a user with a CA sig would do that, with my
> proposals i have made?

Yes, for sure. With a backdated signature the CA could be blamed in the
eyes of some not so firm users. Even if it's only for this purpose.

First the UID problem should be fixed and then a similar mechanism for
the signatures could be introduces. This would fix the well known
problems and no CA would be needed. That is unrelated to the CA's for
"assurance" which are not a really bad idea, but it has nothing to do
with the flaws in the key servers and even wouÄt be a fix for this.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Stefan Claas]

On Sun, 9 Dec 2018 21:11:12 +0100, Juergen Bruckner wrote:
> Am 09.12.18 um 18:24 schrieb Dirk Gottschalk via Gnupg-users:
> > And further, why should anyone run something like a ca CA for free.
> > Sure, CAcert does it. But that's the onlöy organisation I know who
> > does this.  
> 
> Also WPIA [1] plans to do this and started a audit process for their
> CA.
> 
> regards
> Juergen
> 
> [1] https://wpia.club

Very cool Juergen! 

Regards
Stefan

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


pgp6pxZYqTVvQ.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Stefan Claas]

On Sun, 09 Dec 2018 20:55:36 +0100, Dirk Gottschalk wrote:

Hello Dirk,

> That I mentioned in the other reply I have sent a few seconds ago.
> 
> > right? A key which would bear a CA sig would imho not have such
> > additional and funny UID's or sigs, because it would make the key
> > owner look a bit stupid, i would say.  
> 
> No. The signatures on a key are nor related to each other. A funni
> signature could be backdated before the signature by the CA were made.
> Who's the stupid now, in the eyes of the user seeing this? ^^

Do you really think a user with a CA sig would do that, with my
proposals i have made?

Regards
Stefan

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


pgpkpHR6TFiSG.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Juergen Bruckner]

Am 09.12.18 um 18:24 schrieb Dirk Gottschalk via Gnupg-users:
> And further, why should anyone run something like a ca CA for free.
> Sure, CAcert does it. But that's the onlöy organisation I know who does
> this.

Also WPIA [1] plans to do this and started a audit process for their CA.

regards
Juergen

[1] https://wpia.club
-- 
Juergen Bruckner
juer...@bruckner.tk



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Stefan Claas]

On Sun, 09 Dec 2018 20:34:55 +0100, Dirk Gottschalk wrote:
> Am Sonntag, den 09.12.2018, 20:03 +0100 schrieb Stefan Claas:

Hi Dirk,

> A weekend job... Muhahahahahahaha, you don't do much programming,
> don't you? One would have to write an email bot, change the keyserver
> code to no longer accept submissions via HKP, then it would be
> neccessary do disable HKP for upload in GnuPG to avoid broken Clients
> and so on.

Mind you in the 90's PGP key servers accepted also email and Usenet
submissions, if i remember correctly. The keyword was then simple
the word "add" in the subject line of an email.

<https://www.rubin.ch/pgp/sendkey.en.html>

> > People can then still use the old key servers (until they may become
> > obsolete...) or use keybase.  
> 
> Keybase is an option, yes., And the Keyservers could be fixed. HKP for
> retrieval is very comfortable and there is no need to disable also the
> retrieval.

The retrieval is of course good and it did not say something about it. 

Regards
Stefan

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


pgpZKviWys3gW.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Wiktor Kwapisiewicz via Gnupg-users]

On 09.12.2018 20:03, Stefan Claas wrote:
> To bad that Werner's WKD is not widely adopted from email
> service providers...

Just for the record but it is adopted by e-mail service providers that are
interested in OpenPGP (like ProtonMail and Posteo.de, see
https://wiki.gnupg.org/WKD).

As for "e-mail service providers" like Gmail or Yahoo that obviously is not
going to happen (unless one uses Google Suite with custom domain, etc.)

Kind regards,

Wiktor

-- 
https://metacode.biz/@wiktor


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

Re: Garbled data in keyservers

[Dirk Gottschalk via Gnupg-users]

Hello Stefan.

Am Sonntag, den 09.12.2018, 19:38 +0100 schrieb Stefan Claas:
> On Sun, 09 Dec 2018 08:23:03 -0900, justina colmena via Gnupg-users
> wrote:
> > On December 9, 2018 7:54:01 AM EST, Stefan Claas
> >  wrote::
> > > Get a sig from a CA and then upload your key via email.
> > >  
> > That's a bit steep, and was never the original goal of PGP or GPG.

> No, in 2018 i think it is not. CA's can be run by non-profit
> organizations like EFF etc., which i believe a lot of people trust.

> Then don't forget all the worldwide assurers from CAcert.org.

> > If the goal is to eliminate the bulk of bad keys and junk from key
> > servers, an account creation with basic email verification for
> > adding or removing keys should suffice.

> I don't think so. Create an anon account at ProtonMail via Tor for
> example and then do "funny stuff" with those keys.

There is always a way to abuse things. And a plausibility check on UIDs
would remove the possibility for abusive data encoding in these. I
think that would be a starting point.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Fw: Garbled data in keyservers

[Stefan Claas]

Beginn der weitergeleiteten Nachricht:

Datum: Sun, 9 Dec 2018 20:35:41 +0100
Von: Stefan Claas 
An: Dirk Gottschalk 
Betreff: Re: Garbled data in keyservers


On Sun, 09 Dec 2018 20:26:21 +0100, Dirk Gottschalk wrote:

Hi Dirk,

> > I don't think so. Create an anon account at ProtonMail via Tor for
> > example and then do "funny stuff" with those keys.
> 
> Nah, the server code has just to be modified, then a plausibility
> check could be established if the UID is a valid one, or an abusive.
> This would disable abusive UIDs with malicious data.  

Well, if one creates a valid UID for ProtonMail, for example, the
the Server needs then also to check additional UID's or "funny" sigs,
right? A key which would bear a CA sig would imho not have such
additional and funny UID's or sigs, because it would make the key owner
look a bit stupid, i would say.

Regards
Stefan

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


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


pgpgfPnA5EOsp.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Dirk Gottschalk via Gnupg-users]

Am Sonntag, den 09.12.2018, 20:03 +0100 schrieb Stefan Claas:
> On Sun, 9 Dec 2018 19:38:31 +0100, Stefan Claas wrote:
> > On Sun, 09 Dec 2018 08:23:03 -0900, justina colmena via Gnupg-users
> > wrote:
> > > On December 9, 2018 7:54:01 AM EST, Stefan Claas
> > >  wrote::  
> > > > Get a sig from a CA and then upload your key via email.
> > > >
> > > That's a bit steep, and was never the original goal of PGP or
> > > GPG.  

> > No, in 2018 i think it is not. CA's can be run by non-profit
> > organizations like EFF etc., which i believe a lot of people trust.

> > Then don't forget all the worldwide assurers from CAcert.org.

> > > If the goal is to eliminate the bulk of bad keys and junk from
> > > key
> > > servers, an account creation with basic email verification for
> > > adding or removing keys should suffice.  

> > I don't think so. Create an anon account at ProtonMail via Tor for
> > example and then do "funny stuff" with those keys.

> My proposal could be run also in parallel. I think it would be
> only a weekend job for a programmer to modify the server code,
> so that it accepts only incoming and verified email and not web
> or GnuPG via Tor submissions.

That's also what GPG is made for. Privacy. So TOR usage is quite okay.
The Idea with an email bot instead of a HKP for upload is something
that could be taken into consideration to validate sender and key, I
agree.

A weekend job... Muhahahahahahaha, you don't do much programming, don't
you? One would have to write an email bot, change the keyserver code to
no longer accept submissions via HKP, then it would be neccessary do
disable HKP for upload in GnuPG to avoid broken Clients and so on.

> People can then still use the old key servers (until they may become
> obsolete...) or use keybase.

Keybase is an option, yes., And the Keyservers could be fixed. HKP for
retrieval is very comfortable and there is no need to disable also the
retrieval.

> To bad that Werner's WKD is not widely adopted from email
> service providers...

WKD is a good thing, but has not yet widely spread. I think one oif the
problems is the small amount of users demanding it.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Dirk Gottschalk via Gnupg-users]

Hi Stefan.

Am Sonntag, den 09.12.2018, 19:38 +0100 schrieb Stefan Claas:
> On Sun, 09 Dec 2018 08:23:03 -0900, justina colmena via Gnupg-users
> wrote:
> > On December 9, 2018 7:54:01 AM EST, Stefan Claas
> >  wrote::
> > > Get a sig from a CA and then upload your key via email.
> > >  
> > That's a bit steep, and was never the original goal of PGP or GPG.

> No, in 2018 i think it is not. CA's can be run by non-profit
> organizations like EFF etc., which i believe a lot of people trust.

> Then don't forget all the worldwide assurers from CAcert.org.
> 
> > If the goal is to eliminate the bulk of bad keys and junk from key
> > servers, an account creation with basic email verification for
> > adding
> > or removing keys should suffice.

> I don't think so. Create an anon account at ProtonMail via Tor for
> example and then do "funny stuff" with those keys.

Nah, the server code has just to be modified, then a plausibility check
could be established if the UID is a valid one, or an abusive. This
would disable abusive UIDs with malicious data.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Dirk Gottschalk via Gnupg-users]

Am Sonntag, den 09.12.2018, 19:54 +0100 schrieb Stefan Claas:
> On Sun, 9 Dec 2018 19:51:37 +0100, Stefan Claas wrote:
> > On Sun, 09 Dec 2018 18:24:38 +0100, Dirk Gottschalk wrote:
>  
> Hi Dirk,
> > > Get a sig from a CA and then upload your key via email.
> > > Then the key servers do something like a gpg --check-sigs
> > > to see if a key bears a valid CA sig and if it is found in their
> > > index the key will be added to the network, once the submitted
> > > UID matches with the email address header. So no cryptographic
> > > verification is imho needed. This would also eliminate, i think,
> > > > that someone else can upload someone else's pub key.
> > > 
> > > And who decides which CA ist trustworthy and which is not? The
> > > problem ist, like in the X.509 land, that it depends on an
> > > initial
> > > trust to one or more central authorities. Who decides whom one
> > > can
> > > trust.  

> If trusted organizations like EFF etc. would run a CA...

> > > And further, why should anyone run something like a ca CA for
> > > free.  
 
> Nobody said that it should be free.

That's a point one would have to discuss. A small one time fee would be
okay, but not to much, ore we are at the same point like in X.509 land
and nobody wants to invest, except for real good reasons.


> > > And then again the question, who decides who get's the nedded
> > > trust?  

> I have learned in the past the phrase "trust nobody" when it comes
> to IoT. That means also I don't have to trust GnuPG users, for
> example... ;-)

Exactly this is the point where the key signatures get in place. You
can decide whom you trust, or not, and how far your trust goes.
Than you can see, if somebody you don't know yet is trusted by a user
you trust. Then the trustdb comes into place. Exactly this is how PGP
works. PGP is not a replacement for the X.509 infrastructure like it is
used in companies or other organizations. And even there often PGP is
enough, at least for Email signature or encryption.

I'm still not sure what you're trying to achieve. A Replacement for
X.509?

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Stefan Claas]

On Sun, 9 Dec 2018 19:38:31 +0100, Stefan Claas wrote:
> On Sun, 09 Dec 2018 08:23:03 -0900, justina colmena via Gnupg-users
> wrote:
> > On December 9, 2018 7:54:01 AM EST, Stefan Claas
> >  wrote::  
> > >
> > >Get a sig from a CA and then upload your key via email.
> > >
> > That's a bit steep, and was never the original goal of PGP or GPG.  
> 
> No, in 2018 i think it is not. CA's can be run by non-profit
> organizations like EFF etc., which i believe a lot of people trust.
> 
> Then don't forget all the worldwide assurers from CAcert.org.
> 
> > If the goal is to eliminate the bulk of bad keys and junk from key
> > servers, an account creation with basic email verification for
> > adding or removing keys should suffice.  
> 
> I don't think so. Create an anon account at ProtonMail via Tor for
> example and then do "funny stuff" with those keys.

My proposal could be run also in parallel. I think it would be
only a weekend job for a programmer to modify the server code,
so that it accepts only incoming and verified email and not web
or GnuPG via Tor submissions.

People can then still use the old key servers (until they may become
obsolete...) or use keybase.

To bad that Werner's WKD is not widely adopted from email
service providers...

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: Garbled data in keyservers

[Stefan Claas]

On Sun, 9 Dec 2018 19:51:37 +0100, Stefan Claas wrote:
> On Sun, 09 Dec 2018 18:24:38 +0100, Dirk Gottschalk wrote:
 
Hi Dirk,
> 
> > Get a sig from a CA and then upload your key via email.
> > Then the key servers do something like a gpg --check-sigs
> > to see if a key bears a valid CA sig and if it is found in their
> > index the key will be added to the network, once the submitted
> > UID matches with the email address header. So no cryptographic
> > verification is imho needed. This would also eliminate, i think,
> > > that someone else can upload someone else's pub key.
> > 
> > And who decides which CA ist trustworthy and which is not? The
> > problem ist, like in the X.509 land, that it depends on an initial
> > trust to one or more central authorities. Who decides whom one can
> > trust.  

If trusted organizations like EFF etc. would run a CA...

> > And further, why should anyone run something like a ca CA for
> > free.  
 
Nobody said that it should be free.

> > And then again the question, who decides who get's the nedded
> > trust?  

I have learned in the past the phrase "trust nobody" when it comes
to IoT. That means also I don't have to trust GnuPG users, for
example... ;-)

Regards
Stefan


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


pgpg3JPGCayJz.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Stefan Claas]

On Sun, 09 Dec 2018 08:23:03 -0900, justina colmena via Gnupg-users
wrote:
> On December 9, 2018 7:54:01 AM EST, Stefan Claas
>  wrote::
> >
> >Get a sig from a CA and then upload your key via email.
> >  
> That's a bit steep, and was never the original goal of PGP or GPG.

No, in 2018 i think it is not. CA's can be run by non-profit
organizations like EFF etc., which i believe a lot of people trust.

Then don't forget all the worldwide assurers from CAcert.org.

> If the goal is to eliminate the bulk of bad keys and junk from key
> servers, an account creation with basic email verification for adding
> or removing keys should suffice.

I don't think so. Create an anon account at ProtonMail via Tor for
example and then do "funny stuff" with those keys.

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: Garbled data in keyservers

[Dirk Gottschalk via Gnupg-users]

Hello Justina

Am Sonntag, den 09.12.2018, 08:23 -0900 schrieb justina colmena via
Gnupg-users:
> On December 9, 2018 7:54:01 AM EST, Stefan Claas <
> stefan.cl...@posteo.de> wrote::
> > Get a sig from a CA and then upload your key via email.
> > 
> That's a bit steep, and was never the original goal of PGP or GPG.

Correct.


> If the goal is to eliminate the bulk of bad keys and junk from key
> servers, an account creation with basic email verification for adding
> or removing keys should suffice.

That's something I thought about, too.


> Let's be honest: no one really wants an infrastructure of legally
> valid or enforceable GPG signatures, either. It's a technical
> verification that something is very unlikely to be altered if the
> signature is valid. Any particular overriding legal significance
> beyond that is unnecessary.

Legal significcance is one point and it's to complicated in many
countries.


> Don't overdo it, please. PGP key servers are not supposed to be
> "authoritative." They are a convenience to extend an informal web of
> trust. Let's resist that German urge toward authoritarianism and
> absolutism, shall we?

Yeah, RIGHT! As a German I say, this urge in Germany and even in Europe
is totally silly at all. They are making an A 380 out of a duck, so to
say. Or like we call it in germany: "eine Mücke zu einem Elefanten
machen".


> Bosses and bullies do not help with privacy, personal digital
> signatures, or cryptography for personal use. The CA stuff is mostly
> for business, not personal. The adversaries in that case are
> pickpockets and credit card skimmers, not major governments and
> political enemies.

Right, but, to be honest, in some cases a GPG signature should be even
enough to prove the origin in a legal way. Some countries accept this
already, but not in silly old europe. Okay, EU sucks, but that's
another topic.

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Dirk Gottschalk via Gnupg-users]

Hi.

Am Sonntag, den 09.12.2018, 13:54 +0100 schrieb Stefan Claas:
> On Thu, 06 Dec 2018 15:22:14 +0100, Werner Koch wrote:
> 
> > > That's right, but my thought is / was someone can (ab)use key
> > > servers as data storage / retrieval system and then only provides
> > > the key id  
> > 
> > As it has been commeted, there are easier ways to do that.

> I have read also the threads at sks devel ML and my suggestions
> would be that we need more international CA's to get rid of all
> the problems, the key server network has.

> People should think about the following:

> Get a sig from a CA and then upload your key via email.
> Then the key servers do something like a gpg --check-sigs
> to see if a key bears a valid CA sig and if it is found in their
> index the key will be added to the network, once the submitted
> UID matches with the email address header. So no cryptographic
> verification is imho needed. This would also eliminate, i think,
> that someone else can upload someone else's pub key.

And who decides which CA ist trustworthy and which is not? The problem
ist, like in the X.509 land, that it depends on an initial trust to one
or more central authorities. Who decides whom one can trust.

And further, why should anyone run something like a ca CA for free.
Sure, CAcert does it. But that's the onlöy organisation I know who does
this.

And then again the question, who decides who get's the nedded trust?

Regards,
Dirk

-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen, Germany

GPG: DDCB AF8E 0132 AA54 20AB  B864 4081 0B18 1ED8 E838
Keybase.io: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac



signature.asc
Description: This is a digitally signed message part
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[justina colmena via Gnupg-users]

On December 9, 2018 7:54:01 AM EST, Stefan Claas  
wrote::
>
>Get a sig from a CA and then upload your key via email.
>
That's a bit steep, and was never the original goal of PGP or GPG.

If the goal is to eliminate the bulk of bad keys and junk from key servers, an 
account creation with basic email verification for adding or removing keys 
should suffice.

Let's be honest: no one really wants an infrastructure of legally valid or 
enforceable GPG signatures, either. It's a technical verification that 
something is very unlikely to be altered if the signature is valid. Any 
particular overriding legal significance beyond that is unnecessary.

Don't overdo it, please. PGP key servers are not supposed to be 
"authoritative." They are a convenience to extend an informal web of trust. 
Let's resist that German urge toward authoritarianism and absolutism, shall we?

Bosses and bullies do not help with privacy, personal digital signatures, or 
cryptography for personal use. The CA stuff is mostly for business, not 
personal. The adversaries in that case are pickpockets and credit card 
skimmers, not major governments and political enemies.

-- 
A well regulated Militia, being necessary to the security of a free State, the 
right of the people to keep and bear Arms, shall not be infringed.

https://www.colmena.biz/~justina/justina.colmena.asc

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

Re: Garbled data in keyservers

[Stefan Claas]

On Thu, 06 Dec 2018 15:22:14 +0100, Werner Koch wrote:

> > That's right, but my thought is / was someone can (ab)use key
> > servers as data storage / retrieval system and then only provides
> > the key id  
> 
> As it has been commeted, there are easier ways to do that.

I have read also the threads at sks devel ML and my suggestions
would be that we need more international CA's to get rid of all
the problems, the key server network has.

People should think about the following:

Get a sig from a CA and then upload your key via email.
Then the key servers do something like a gpg --check-sigs
to see if a key bears a valid CA sig and if it is found in their
index the key will be added to the network, once the submitted
UID matches with the email address header. So no cryptographic
verification is imho needed. This would also eliminate, i think,
that someone else can upload someone else's pub key.

Regards
Stefan

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


pgpTpHQdhDMRZ.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Werner Koch]

On Thu,  6 Dec 2018 14:05, stefan.cl...@posteo.de said:

> Understood. Please check this example, a key with with plenty of data,
> which only needs to be extracted.
>
> https://pgp.circl.lu/pks/lookup?op=get=0x73253A1F090C53B6

Surely you can put arbitrary data into into a user-id. 

> That's right, but my thought is / was someone can (ab)use key servers
> as data storage / retrieval system and then only provides the key id

As it has been commeted, there are easier ways to do that.


Salam-Shalom,

   Werner

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


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

Re: Garbled data in keyservers

[Stefan Claas]

On Thu, 6 Dec 2018 14:05:37 +0100, Stefan Claas wrote:
> On Thu, 06 Dec 2018 11:42:32 +0100, Werner Koch wrote:
> > On Thu,  6 Dec 2018 10:22, stefan.cl...@posteo.de said:
> >   
> > > As long as we have the option to add additional UID's  to a key
> > > my
> > 
> > You can't add an UID to a key without having a signature from the
> > primary key.  If the keyservers accept that any OpenPGP
> > implementation will simply skip such an UID.  
> 
> Understood. Please check this example, a key with with plenty of data,
> which only needs to be extracted.
> 
> https://pgp.circl.lu/pks/lookup?op=get=0x73253A1F090C53B6

O.k. curious how i am, i extracted the data and it shows an image of
Kristian, size 1178x1439 pixels, 96 dpi.. :-D

Regards
Stefan

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


pgp2q5EV9yyd4.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Stefan Claas]

On Thu, 06 Dec 2018 11:42:32 +0100, Werner Koch wrote:
> On Thu,  6 Dec 2018 10:22, stefan.cl...@posteo.de said:
> 
> > As long as we have the option to add additional UID's  to a key my  
> 
> You can't add an UID to a key without having a signature from the
> primary key.  If the keyservers accept that any OpenPGP implementation
> will simply skip such an UID.

Understood. Please check this example, a key with with plenty of data,
which only needs to be extracted.

https://pgp.circl.lu/pks/lookup?op=get=0x73253A1F090C53B6

> > People then would only need a little program to dearmor and
> > extract the data from that key UID's.  
> 
> But they can't search for it on public servers.  Thus there is no gain
> here.  If you require a dedicated program anyway, that program can
> anyway consult one of the Tor hidden servers.  But no search engine
> will show it.

That's right, but my thought is / was someone can (ab)use key servers
as data storage / retrieval system and then only provides the key id
in a link.

Regards
Stefan

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


pgpkE2MhpQjUR.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Stefan Claas]

On Thu, 6 Dec 2018 11:09:04 +0100, Wiktor Kwapisiewicz wrote:
> >> But that "little program" would have to download the entire dump
> >> and provide search feature itself, making it non-trivial for most
> >> users.  
> > I don't think so...
> >
> > https://github.com/yakamok/keyserver-fs  
> 
> Yes:
> 
> > WARNING: this may break easily and is intended for use only on
> > linux  
> 
> > *Notice:* This Program is very slow to add data to the gpg pubkey
> > so dont plan  
> on super large files.
> 
> I don't think a lot of users use this or would use this. It's more
> convenient and easier to store data somewhere else (pastebins?).

At least the cat is out of the bag and i could imagine if only one
person would misuse this technique operators could face problems
in the future.

Regards
Stefan

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


pgpEcRx7EPmxx.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Wiktor Kwapisiewicz via Gnupg-users]

>> But that "little program" would have to download the entire dump and
>> provide search feature itself, making it non-trivial for most users.
> I don't think so...
>
> https://github.com/yakamok/keyserver-fs

Yes:

> WARNING: this may break easily and is intended for use only on linux

> *Notice:* This Program is very slow to add data to the gpg pubkey so dont plan
on super large files.

I don't think a lot of users use this or would use this. It's more convenient
and easier to store data somewhere else (pastebins?).

Also, storing blobs is not a unique problem of keyservers, one can store it in
Certificate Transparency logs by issuing certs from Let's Encrypt or in Bitcoin
blockchain or even X.509 timestamping services. It would be slow and
inefficient, that's why practically no-one misuses it.

Kind regards,

Wiktor

-- 
https://metacode.biz/@wiktor

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

Re: Garbled data in keyservers

[Stefan Claas]

On Thu, 6 Dec 2018 10:39:24 +0100, Wiktor Kwapisiewicz wrote:

Hi Wiktor,

> On 06.12.2018 10:24, Stefan Claas wrote:
> > As long as we have the option to add additional UID's  to a key my
> > thinking was, after reading the links from Yegor, that one appends
> > arbitrary data to a key and provides a link, at some other place, to
> > that key, in the form of URL://keyserver/keyid_or_fp.
> >
> > People then would only need a little program to dearmor and
> > extract the data from that key UID's.  
> 
> But that "little program" would have to download the entire dump and
> provide search feature itself, making it non-trivial for most users.

I don't think so...

https://github.com/yakamok/keyserver-fs

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


pgpDBFg6FO94n.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Wiktor Kwapisiewicz via Gnupg-users]

On 06.12.2018 10:24, Stefan Claas wrote:
> As long as we have the option to add additional UID's  to a key my
> thinking was, after reading the links from Yegor, that one appends
> arbitrary data to a key and provides a link, at some other place, to
> that key, in the form of URL://keyserver/keyid_or_fp.
>
> People then would only need a little program to dearmor and
> extract the data from that key UID's.

But that "little program" would have to download the entire dump and provide
search feature itself, making it non-trivial for most users.

Sometimes raising a bar a little would solve most of the problem.

(And then there are talks about removing UIDs from key servers, but that's a
different matter).

Kind regards,

Wiktor

-- 
https://metacode.biz/@wiktor


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

Re: Garbled data in keyservers

[Stefan Claas]

On Thu, 06 Dec 2018 09:03:32 +0100, Werner Koch wrote:
> On Wed,  5 Dec 2018 19:56, stefan.cl...@posteo.de said:
> 
> > Well, my understanding would be that a least one (search) criteria
> > would be needed to fetch a key, right? And if so i could also
> > imagine  
> 
> Right, the fingerprint.  And maybe the long keyid for a transitional
> period because not all software already includes the fingerprint in
> the signature.

O.k.

> > that this one criteria could be abused as well, in form of a given
> > link to that resource, as long as it can be fetched via the web.  
> 
> Being able to search for a fingerprint does not allow you to search
> for the latest blockbuster movie to get a torrent link.  Thus there
> is no incentive to use the keyservers as an index and running a
> keyserver will be safer for most operators.

Well, i am not familiar how the current warez etc. scene works,
but my assumption was the following (o.k. i am no programmer...):

As long as we have the option to add additional UID's  to a key my
thinking was, after reading the links from Yegor, that one appends
arbitrary data to a key and provides a link, at some other place, to
that key, in the form of URL://keyserver/keyid_or_fp.

People then would only need a little program to dearmor and
extract the data from that key UID's.

Regards
Stefan

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


pgpaJFRDsGbGS.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Werner Koch]

On Wed,  5 Dec 2018 19:56, stefan.cl...@posteo.de said:

> Well, my understanding would be that a least one (search) criteria
> would be needed to fetch a key, right? And if so i could also imagine

Right, the fingerprint.  And maybe the long keyid for a transitional
period because not all software already includes the fingerprint in the
signature.

> that this one criteria could be abused as well, in form of a given
> link to that resource, as long as it can be fetched via the web.

Being able to search for a fingerprint does not allow you to search for
the latest blockbuster movie to get a torrent link.  Thus there is no
incentive to use the keyservers as an index and running a keyserver will
be safer for most operators.


Salam-Shalom,

   Werner

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


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

Re: Garbled data in keyservers

[Stefan Claas]

On Wed, 05 Dec 2018 11:24:10 -0900, justina colmena via Gnupg-users
wrote:
> A keyserver is a convenience. Of course it's not magic. Right now I
> am using K-9 Mail and OpenKeychain on Android. When I received the
> above message from the list, K-9 Mail informed me that it was signed
> with a key with fingerprint "0xff80ae9d1dec358d", and referred me to
> the OpenKeychain app, which searched keyservers and found a matching
> public key, which I was allowed to import to verify the signature,
> which I did so successfully.

Sure, thats the way it works. If Werner and you for example had an
implementation of Autocrypt installed then you would not need
a key server. ;-)

But what we are pointing out here are the problems the current key
server network has, or might face in the future.

Regards
Stefan

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


pgpohDTzZmoLb.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[justina colmena via Gnupg-users]

A keyserver is a convenience. Of course it's not magic. Right now I am using 
K-9 Mail and OpenKeychain on Android. When I received the above message from 
the list, K-9 Mail informed me that it was signed with a key with fingerprint 
"0xff80ae9d1dec358d", and referred me to the OpenKeychain app, which searched 
keyservers and found a matching public key, which I was allowed to import to 
verify the signature, which I did so successfully.

The fingerprints are some collision-resistant secure hashes, and in theory it 
is extraordinarily difficult to create another public key with the same 
fingerprint.

I have never met "Werner Koch" personally, but I am about as certain as I can 
be (under the present scheme of things) that that is the key fingerprint of the 
person from GnuPG.org who posts to the mailing list, and that there would be 
quite a bit of noise on the list in case of a mistaken identity.

There is a certain "reputation effect" with a public key which in theory 
obviates the need for in-person verification and secret handshakes.

The major difficulties and points of weakness to the whole scheme, in my 
opinion, are, (a) retaining possession of the private key, and (b) denying 
others illicit access to the private key.

Point (b) is a long-term, seemingly irremediable, problem. The long key 
lifetimes and the general lack of *Perfect Forward Secrecy* greatly aggravate 
the risk of a catastrophic total compromise of all data signed with or 
encrypted to the private key.

-- 
A well regulated Militia, being necessary to the security of a free State, the 
right of the people to keep and bear Arms, shall not be infringed.

https://www.colmena.biz/~justina/justina.colmena.asc

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

Re: Garbled data in keyservers

[Stefan Claas]

On Wed, 05 Dec 2018 18:53:20 +0100, Werner Koch wrote:
> On Wed,  5 Dec 2018 17:34, stefan.cl...@posteo.de said:
> 
> > Can you give more details about the security aspect?  
> 
> People believe that the keyservers magically return a matching key
> for a mail address.  There is no guarantee for this.  In fact all
> people from the strong had meanwhile expired faked key on the
> servers, which was not easy to detect given that they were also
> signed by faked keys from the strong set.
> 
> Thus if you have the capability to sniff mail you would upload a faked
> key and hope that future senders pick up that faked key and encrypt to
> it.  You can now intercept that mail, read it, encrypt to the real key
> and send on.  Even if you can't mount such an active MitM you can
> simply send on the newly encrypted mail with an additional line
> "sorry, I encrypted to the wrong key".
> 
> Right the Web of Trust would stop this attack, but most people are not
> part of the WoT.  Simple methods for initial /key discovery/ are
> required.  Even autocrypt is better than keyservers and with the Web
> Key Directory you can get an even better assurance that it is the
> correct key.

Agreed.

> > run their own key server and analyze the data. So what purpose
> > should your suggestion serve?  
> 
> The additional benefit is that this would take away the load from the
> servers and allow that we can get back the large mesh of keyservers.
> Without being able to search user-ids it does not anymore make sense
> to use keyservers as search engines for magnet links to Bittorrent
> distributed data.

Well, my understanding would be that a least one (search) criteria
would be needed to fetch a key, right? And if so i could also imagine
that this one criteria could be abused as well, in form of a given
link to that resource, as long as it can be fetched via the web.

Regards
Stefan

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


pgpdwKd_BguB5.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Werner Koch]

On Wed,  5 Dec 2018 17:34, stefan.cl...@posteo.de said:

> Can you give more details about the security aspect?

People believe that the keyservers magically return a matching key for a
mail address.  There is no guarantee for this.  In fact all people from
the strong had meanwhile expired faked key on the servers, which was not
easy to detect given that they were also signed by faked keys from the
strong set.

Thus if you have the capability to sniff mail you would upload a faked
key and hope that future senders pick up that faked key and encrypt to
it.  You can now intercept that mail, read it, encrypt to the real key
and send on.  Even if you can't mount such an active MitM you can
simply send on the newly encrypted mail with an additional line "sorry, I
encrypted to the wrong key".

Right the Web of Trust would stop this attack, but most people are not
part of the WoT.  Simple methods for initial /key discovery/ are
required.  Even autocrypt is better than keyservers and with the Web Key
Directory you can get an even better assurance that it is the correct
key.

> run their own key server and analyze the data. So what purpose should
> your suggestion serve?

The additional benefit is that this would take away the load from the
servers and allow that we can get back the large mesh of keyservers.
Without being able to search user-ids it does not anymore make sense to
use keyservers as search engines for magnet links to Bittorrent
distributed data.


Shalom-Salam,

   Werner


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


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

Re: Garbled data in keyservers

[Stefan Claas]

On Wed, 05 Dec 2018 13:28:50 +0100, Werner Koch wrote:

> A better way of using keyservers would be to entire disable their
> search by name or mail address capabilities.  Not only in the web
> interface but also in their API.  Of course that will be a radical
> change but I consider it better for security: 

Can you give more details about the security aspect?

Currently users can still search sks key servers by names, with
Lynx... :-) As understood key server operators can still give a whole
dump to 3rd parties, which like to analyze the data, or third parties
run their own key server and analyze the data. So what purpose should
your suggestion serve?

If you are talking about GDPR issues, those keys server operators
are not "licensed" by governmental institutions and run their servers
according to some strict regulations.

Regards
Stefan

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


pgpe5FPFllMEL.pgp
Description: Digitale Signatur von OpenPGP
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Garbled data in keyservers

[Werner Koch]

On Wed,  5 Dec 2018 10:31, c...@cod-web.net said:

> On pool.sks-keyservers.net eveything works well while on other
> keyservers I get 47Mb of garbled data from Yegor Timoshenko key, which I
> never signed and I don't know exactly why it's included in search

There are several problem with the keyservers due to their policy of
being a plain data store.  Actually this policy is a Good Thing because
it allows to sync with other servers and their is no need for a central
authority.

The problem is that the keyservers are abused as data store and, worse,
as a public search engine for such data.  The latter point can be
mitigated by not having a web interface which displays everything.

Restricting user-ids and such does not help because there are other ways
to store arbitrary data in a OpenPGP keyblock.  Even keyservers which
would checking the signatures won't help because key signatures can be
made using an arbitrary amount of new keys.

A better way of using keyservers would be to entire disable their search
by name or mail address capabilities.  Not only in the web interface but
also in their API.  Of course that will be a radical change but I
consider it better for security: Too many users assume that the
keyservers return a correct key; which they don't.  In fact their is no
way to get a key for a given mail address from a web server.  It used to
work just out of luck and because all keyserver users used to be fair
netizens.

The keyserver would then be used for getting the keys to verify a
signature (because the lookup is by fingerprint) and to distribute
revocations.  That is still a useful thing to have.  Further the
keyservers should stop to accept key signature; for Web of Trust things
signed keys should be mailed directly instead (caff already does that).

FWIW, I have the problem of a garbled key for quite some time which I
can fix for me using things like

import-filter drop-sig=   sig_created_d=2015-12-24
import-filter drop-sig=|| sig_created_d=2016-03-16

in my gpg.conf.  But that is just a stopgap. 


Shalom-Salam,

   Werner



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


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

Re: Garbled data in keyservers

[Claudio Canavese]

Thank you.

Fun fact:
https://bitbucket.org/skskeyserver/sks-keyserver/issues/57
> https://bitbucket.org/skskeyserver/sks-keyserver/issues/60
> 
were opened by Yegor Timoshenko himself ^__^


Thank you again for your quick and sharp answer!


--
CoD


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

Re: Garbled data in keyservers

[Wiktor Kwapisiewicz via Gnupg-users]

Hi Claudio,

You may find these SKS issues relevant:

https://bitbucket.org/skskeyserver/sks-keyserver/issues/41
https://bitbucket.org/skskeyserver/sks-keyserver/issues/57
https://bitbucket.org/skskeyserver/sks-keyserver/issues/60

I'm not able to comment on the specifics of search implementation in SKS 
though...

Kind regards,
Wiktor

On 05.12.2018 10:31, Claudio Canavese wrote:
> Hi everyone,
> I'm experiencing a strange behavior when looking for my email address on
> many keyserver web interfaces: I get al lot of garbled output from a key
> of someone else.
>
> I can't find and answer in this mailing list archives, so I decided to
> ask directly. Forgive me if it's a silly question.
>
> How to test this:
> 1) pick any keyserver, I tried  https://pgp.mit.edu/ ,
> https://keyserver.ubuntu.com/ , http://pool.sks-keyservers.net
> 2) search any key but mine by email: works? Well, so it was for me
> 3) now try with this email address
>
> On pool.sks-keyservers.net eveything works well while on other
> keyservers I get 47Mb of garbled data from Yegor Timoshenko key, which I
> never signed and I don't know exactly why it's included in search
> results. I had to use wget to download the web page since any browser
> will crash.
>
> Is this a bug I should submit somewhere? 
> Can a key break the html output of a keyserver?
>
>
> Thanks you for your time ;-)
>
>
> --
> CoD
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


-- 
https://metacode.biz/@wiktor


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

Garbled data in keyservers

[Claudio Canavese]

Hi everyone,
I'm experiencing a strange behavior when looking for my email address on
many keyserver web interfaces: I get al lot of garbled output from a key
of someone else.

I can't find and answer in this mailing list archives, so I decided to
ask directly. Forgive me if it's a silly question.

How to test this:
1) pick any keyserver, I tried  https://pgp.mit.edu/ ,
https://keyserver.ubuntu.com/ , http://pool.sks-keyservers.net
2) search any key but mine by email: works? Well, so it was for me
3) now try with this email address

On pool.sks-keyservers.net eveything works well while on other
keyservers I get 47Mb of garbled data from Yegor Timoshenko key, which I
never signed and I don't know exactly why it's included in search
results. I had to use wget to download the web page since any browser
will crash.

Is this a bug I should submit somewhere? 
Can a key break the html output of a keyserver?


Thanks you for your time ;-)


--
CoD


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

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Andrew Gallagher]

On 13/06/18 14:43, Daniel Kahn Gillmor wrote:
> the proposed revocation distribution network wouldn't allow any user IDs
> or third-party certifications, so most of the "trollwot" would not be
> relevant.

As I see it, the keyservers perform two related but distinct functions -
finding unknown keys by UID, and finding updates to known keys by
fingerprint.

All the current issues are related to the first function, but the first
function has several alternative solutions available (DNS, WKD, Keybase,
attaching pubkeys to every email...). If this first function were to
fail overnight, it would be an inconvenience but not a disaster.

But there is no known alternative to the second function, which is the
distribution of key updates, including revocations. Therefore I believe
the immediate priority should be to protect update distribution.

How to prevent abuse of a distributed, unauthenticated store of
arbitrary data remains an unsolved problem (see: usenet). If the
keyservers are to remain unauthenticated and distributed, then the only
option is to prohibit arbitrary data. That means no arbitrary data
fields (i.e. no UIDs) and no arbitrary data in structured data fields
(i.e. validity checks on self-sigs). This will shrink the size of the
database significantly, but impose some processing cost.

There are two ways forward: a new network of key-material-only servers,
or restricting the existing network to key material only. In the first
case, we would still need a means to propagate keys between the old and
new networks during the transition. And in the second case, we would
need to handle an intermediate state where only some servers have been
upgraded to the new version.

So no matter what we do, we will still need to have some method of doing
fake recon with legacy sks instances. The question is how to arrive at
this state most efficiently. I would suggest that since recon is at the
root of the problems, we should concentrate on the recon process itself.
If uploading a bad key takes down one server then fine, we can lose one
server. But the badness must not infect other servers automatically.

-- 
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: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Daniel Kahn Gillmor]

On Wed 2018-01-17 08:57:12 +0100, Kristian Fiskerstrand wrote:
> On 01/17/2018 01:20 AM, Daniel Kahn Gillmor wrote:
>> On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote:
>>> thanks for this post Daniel, my primary question would be what advantage
>>> is gained by this verification being done by an arbitrary third party
>>> rather by a trusted client running locally, which is the current modus
>>> operandus. Any keyserver action doing this would just shift
>>> responsibilities to a third party for something better served (and
>>> already happens) locally.
>> 
>> the advantage is spam-abatement -- the keyservers have to keep track of
>> what is attached to each blob they transport/persist.  if all signatures
>> that they transport for a given blob are cryptographically certified,
>> then only the original uploader of that blob can make assertions about
>> it; other people can't spam the blob to make it untransportable.
>
> All the certificates used in trollwot are technically correct. You can
> still use the same mechanisms as you control the other key material, and
> can use intentionally weak key material if wanting to speed things up.

sorry for the blast from the past here, but in re-reading this thread, i
thought i'd follow up on this.

the proposed revocation distribution network wouldn't allow any user IDs
or third-party certifications, so most of the "trollwot" would not be
relevant.

if someone wants to upload their own key and make it unfetchable by
appending garbage to it, that's probably OK (at least, it's a strict
improvement than the current situation, which is that they can append
garbage to *any* key).  and if they use weak key material (or publish
the secret someplace), then sure it's a noisy blob that anyone can
append to.  But no one will care, because they aren't likely to be
relying on that key.

does that make sense as to why this proposal is potentially useful?

--dkg


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

Re: GnuPG 2.2.4 on Windows - problems accessing some HKPS keyservers

[David Gray via Gnupg-users]

Thanks, Phil - 

I appreciate your help and your response.

Thanks,

Dave

Sent from my iPhone

> On Jan 23, 2018, at 9:51 PM, Phil Pennock  wrote:
> 
> Looks to me like a GnuPG bug.  In fact, it looks very much like
> https://dev.gnupg.org/T1447 which has been marked resolved.
> 
> The hostname there is a CNAME to Amazon DNS, and my dirmngr logfile
> records:
> 
> 2018-01-23 21:28:10 dirmngr[70787.6] TLS verification of peer failed: 
> hostname does not match
> 2018-01-23 21:28:10 dirmngr[70787.6] DBG: expected hostname: 
> keyserver-prod.v3jierkpjv.eu-west-1.elasticbeanstalk.com
> 
> The untrusted name retrieved from DNS resolution of the CNAME record is
> being used as the name for validation.
> 
> The patches to address the issue seem to focus on SRV records, so
> repaired one way in which the problem manifested, but either didn't fix
> the underlying issue, or there's been a regression.
> 
> I've opened a new ticket for the maintainers to track this.
> https://dev.gnupg.org/T3755
> 
> -Phil


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

Re: GnuPG 2.2.4 on Windows - problems accessing some HKPS keyservers

[Phil Pennock]

On 2018-01-22 at 20:12 -0500, David Gray via Gnupg-users wrote:
> I'm running GnuPG 2.2.4 on Windows.  I'm able to successfully query the SKS
> keyserver pool via HKPS (hkps://hkps.pool.sks-keyservers.net) with no
> problems.  I'm trying to query the hkps://keys.mailvelope.com keyserver, and
> I'm not having any luck.

Looks to me like a GnuPG bug.  In fact, it looks very much like
https://dev.gnupg.org/T1447 which has been marked resolved.

The hostname there is a CNAME to Amazon DNS, and my dirmngr logfile
records:

2018-01-23 21:28:10 dirmngr[70787.6] TLS verification of peer failed: hostname 
does not match
2018-01-23 21:28:10 dirmngr[70787.6] DBG: expected hostname: 
keyserver-prod.v3jierkpjv.eu-west-1.elasticbeanstalk.com

The untrusted name retrieved from DNS resolution of the CNAME record is
being used as the name for validation.

The patches to address the issue seem to focus on SRV records, so
repaired one way in which the problem manifested, but either didn't fix
the underlying issue, or there's been a regression.

I've opened a new ticket for the maintainers to track this.
https://dev.gnupg.org/T3755

-Phil

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

GnuPG 2.2.4 on Windows - problems accessing some HKPS keyservers

[David Gray via Gnupg-users]

Good Evening -

 

I'm running GnuPG 2.2.4 on Windows.  I'm able to successfully query the SKS
keyserver pool via HKPS (hkps://hkps.pool.sks-keyservers.net) with no
problems.  I'm trying to query the hkps://keys.mailvelope.com keyserver, and
I'm not having any luck.  I suspect I don't have the appropriate hkp-cacert
referenced in the dirmngr, but I got the certificate by browsing to
https://keys.mailserver.com, exporting the root cert in the certification
path as a Base-64 encoded X.509 file (with .pem extension) and copying it to
my gnupg home directory, and the hkp-cacert line in dirmngr.conf references
that .PEM file.  The cert thumbprint shows:
ad7e1c28b064ef8f6003402014c3d0e3370eb58a in windows certmgr, and the full
contents of that .pem file appear at the bottom of this message for
reference.

 

I'm hoping someone may be able to point me in the right direction to
troubleshoot this a bit further - I suspect I've done something wrong but
I'm not sure how to identify exactly what it is.

 

Details below - Thanks!

 

Dave

 

This is what I get when I attempt to lookup the key for patr...@enigmail.com
  at hkps://keys.mailvelope.com:

 

C:\Users\dave>gpg --debug-all -vvv --search-keys patr...@enigmail.com

gpg: reading options from 'C:/Users/dave/AppData/Roaming/gnupg/gpg.conf'

gpg: using character set 'CP437'

gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache
memstat trust hashing ipc clock lookup extprog

gpg: DBG: [not enabled in the source] start

gpg: DBG: chan_0x0180 <- # Home: C:/Users/dave/AppData/Roaming/gnupg

gpg: DBG: chan_0x0180 <- # Config:
C:/Users/dave/AppData/Roaming/gnupg/dirmngr.conf

gpg: DBG: chan_0x0180 <- OK Dirmngr 2.2.4 at your service

gpg: DBG: connection to the dirmngr established

gpg: DBG: chan_0x0180 -> GETINFO version

gpg: DBG: chan_0x0180 <- D 2.2.4

gpg: DBG: chan_0x0180 <- OK

gpg: DBG: chan_0x0180 -> KEYSERVER --clear hkps://keys.mailvelope.com/

gpg: DBG: chan_0x0180 <- OK

gpg: DBG: chan_0x0180 -> KS_SEARCH -- patr...@enigmail.com

gpg: DBG: chan_0x0180 <- ERR 285212985 Wrong name 

gpg: error searching keyserver: Wrong name

gpg: keyserver search failed: Wrong name

gpg: DBG: chan_0x0180 -> BYE

gpg: DBG: [not enabled in the source] stop

gpg: keydb: handles=0 locks=0 parse=0 get=0

gpg:build=0 update=0 insert=0 delete=0

gpg:reset=0 found=0 not=0 cache=0 not=0

gpg: kid_not_found_cache: count=0 peak=0 flushes=0

gpg: sig_cache: total=0 cached=0 good=0 bad=0

gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0

  outmix=0 getlvl1=0/0 getlvl2=0/0

gpg: rndjent stat: collector=0x calls=0 bytes=0

gpg: secmem usage: 0/32768 bytes in 0 blocks

 

The corresponding logs from dirmngr show:

 

2018-01-22 19:40:43 dirmngr[1664] handler for fd 864 started

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> # Home:
C:/Users/dave/AppData/Roaming/gnupg

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> # Config:
C:/Users/dave/AppData/Roaming/gnupg/dirmngr.conf

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> OK Dirmngr 2.2.4
at your service

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 <- GETINFO version

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> D 2.2.4

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> OK

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 <- KEYSERVER --clear
hkps://keys.mailvelope.com/

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> OK

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 <- KS_SEARCH --
patr...@enigmail.com

2018-01-22 19:40:43 dirmngr[1664] TLS handshake failed: Wrong name 

2018-01-22 19:40:43 dirmngr[1664] error connecting to
'https://52.50.100.145:443': Wrong name

2018-01-22 19:40:43 dirmngr[1664] command 'KS_SEARCH' failed: Wrong name


2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> ERR 285212985
Wrong name 

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 <- BYE

2018-01-22 19:40:43 dirmngr[1664] DBG: chan_0x0360 -> OK closing
connection

2018-01-22 19:40:43 dirmngr[1664] handler for fd 864 terminated

 

 

By contrast, this is what I get when I query the SKS pool for the same key
via HKPS:

 

C:\Users\dave>gpg --debug-all -vvv --keyserver
hkps://hkps.pool.sks-keyservers.net --search-keys patr...@enigmail.com

gpg: reading options from 'C:/Users/dave/AppData/Roaming/gnupg/gpg.conf'

gpg: using character set 'CP437'

gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache
memstat trust hashing ipc clock lookup extprog

gpg: DBG: [not enabled in the source] start

gpg: DBG: chan_0x0190 <- # Home: C:/Users/dave/AppData/Roaming/gnupg

gpg: DBG: chan_0x0190 <- # Config:
C:/Users/dave/AppData/Roaming/gnupg/dirmngr.conf

gpg: DBG: chan_0x0190 <- OK Dirmngr 2.2.4 at your service

gpg: DBG: connection to the dirmngr established

gpg: DBG: chan_0x0190 -> GETINFO version

Re: key distribution/verification/update mechanisms other than keyservers

[Andrew Gallagher]

On 17/01/18 15:32, Daniel Kahn Gillmor wrote:
> i don't think you need an extension to OpenPGP at all to do this -- you
> just need policy.  The policy could be (for example):

The main technical question is where should this policy be applied?

1. At upload stage - easy to implement, but requires all keyservers to
cooperate. It also means starting from an empty set, effectively
building a parallel keyserver network from scratch.

2. At replication stage - this would be effective, but to the best of
our knowledge would cripple the algorithm.

3. At search/display stage - almost as easy as 1, although more
computationally intensive as it would need to be calculated per download
(caching may help). Can be retrofitted to existing keyservers.

-- 
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: key distribution/verification/update mechanisms other than keyservers

[Daniel Kahn Gillmor]

On Wed 2018-01-17 09:58:21 +0100, Werner Koch wrote:
> On Tue, 16 Jan 2018 22:56, kristian.fiskerstr...@sumptuouscapital.com
> said:
>
>>>  (c) rejected all third-party certifications -- so data attached to a
>>>  given primary key is only accepted when certified by that primary
>>>  key.
>>> 
>>
>> thanks for this post Daniel, my primary question would be what advantage
>> is gained by this verification being done by an arbitrary third party
>
> This can help to avoid DoS attacks.  I would love to see that to get my
> key down to a reasonable size. 
>
> OpenPGP specifies Key Server Preferences (5.2.3.17) with just one flag:
>
>First octet: 0x80 = No-modify the key holder requests that this key
>only be modified or updated by the key holder or an administrator of
>the key server.
>
> By default GnuPG sets this flag but unfortunately it has no effect
> because it is not defined on how the keyserver can check this condition.

please see also the thread on sks-devel from december 2016 with the
subject "nokeyserver annotation" -- if we're designing a new, parallel,
more narrowly-focused keyserver network we should make sure to include
that as well.

> A way to implement this without requiring an external protocol would be
> an extension to OpenPGP to either allow an Embedded Signature (5.2.3.26)
> in a key signature.  With ECC this would not increase the size of a key
> signature too much.  It puts a burden on the keyservers to check this
> signature during an upload, though.

I think you're describing a way to permit such a narrowly-scoped
keyserver to be slightly more broad -- to allow third-party
certifications to be published.

i don't think you need an extension to OpenPGP at all to do this -- you
just need policy.  The policy could be (for example):

 * if a third-party certification is present, discard it unless all of
   the following are true:

   a) it has the "issuer fingerprint" subpacket in the hashed subpackets
   
   b) the issuing key is itself is known to the keyserver
   
   c) the certification is cryptographically correct

   d) there is an Embedded Signature subpacket in the unhashed
  subpackets from the primary key, over the existing signature
  *with unhashed subpackets discarded*

   e) the embedded signature is cryptographically valid

but the simplest thing would be to start without third-party
certifications at all -- making this strictly for self-certification
updates (expiry, revocation, key-rotation).

wdyt?

--dkg


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

Re: key distribution/verification/update mechanisms other than keyservers

[Teemu Likonen]

Werner Koch [2018-01-17 09:58:21+01] wrote:

>>>  (c) rejected all third-party certifications -- so data attached to
>>>  a given primary key is only accepted when certified by that primary
>>>  key.

> This can help to avoid DoS attacks. I would love to see that to get my
> key down to a reasonable size.

Not quite related but... I tend to think that on client side it would be
good idea to "clean" by default. (I like to do that.)

keyserver-options import-clean,export-clean

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


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

Re: key distribution/verification/update mechanisms other than keyservers

[Werner Koch]

On Tue, 16 Jan 2018 22:56, kristian.fiskerstr...@sumptuouscapital.com
said:

>>  (c) rejected all third-party certifications -- so data attached to a
>>  given primary key is only accepted when certified by that primary
>>  key.
>> 
>
> thanks for this post Daniel, my primary question would be what advantage
> is gained by this verification being done by an arbitrary third party

This can help to avoid DoS attacks.  I would love to see that to get my
key down to a reasonable size. 

OpenPGP specifies Key Server Preferences (5.2.3.17) with just one flag:

   First octet: 0x80 = No-modify the key holder requests that this key
   only be modified or updated by the key holder or an administrator of
   the key server.

By default GnuPG sets this flag but unfortunately it has no effect
because it is not defined on how the keyserver can check this condition.

A way to implement this without requiring an external protocol would be
an extension to OpenPGP to either allow an Embedded Signature (5.2.3.26)
in a key signature.  With ECC this would not increase the size of a key
signature too much.  It puts a burden on the keyservers to check this
signature during an upload, though.


Salam-Shalom,

   Werner

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


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

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Kristian Fiskerstrand]

On 01/17/2018 01:20 AM, Daniel Kahn Gillmor wrote:
> On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote:
>> thanks for this post Daniel, my primary question would be what advantage
>> is gained by this verification being done by an arbitrary third party
>> rather by a trusted client running locally, which is the current modus
>> operandus. Any keyserver action doing this would just shift
>> responsibilities to a third party for something better served (and
>> already happens) locally.
> 
> the advantage is spam-abatement -- the keyservers have to keep track of
> what is attached to each blob they transport/persist.  if all signatures
> that they transport for a given blob are cryptographically certified,
> then only the original uploader of that blob can make assertions about
> it; other people can't spam the blob to make it untransportable.

All the certificates used in trollwot are technically correct. You can
still use the same mechanisms as you control the other key material, and
can use intentionally weak key material if wanting to speed things up.


-- 

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

"We all die. The goal isn't to live forever, the goal is to create
something that will."
(Chuck Palahniuk)



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

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Daniel Kahn Gillmor]

On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote:
> thanks for this post Daniel, my primary question would be what advantage
> is gained by this verification being done by an arbitrary third party
> rather by a trusted client running locally, which is the current modus
> operandus. Any keyserver action doing this would just shift
> responsibilities to a third party for something better served (and
> already happens) locally.

the advantage is spam-abatement -- the keyservers have to keep track of
what is attached to each blob they transport/persist.  if all signatures
that they transport for a given blob are cryptographically certified,
then only the original uploader of that blob can make assertions about
it; other people can't spam the blob to make it untransportable.

--dkg

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

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Andrew Gallagher]

> On 16 Jan 2018, at 22:26, Leo Gaspard  wrote:
> 
> It could also help limit the impact of the nightmare scenario RJH has
> described, by making sure all the data is “cryptographically valid and
> matching”, thus making it harder to just propagate arbitrary data down
> the network.

It would make it *very* slightly more computationally expensive to pull off, 
but would not limit the impact one bit. 

A

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

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Leo Gaspard]

On 01/16/2018 10:56 PM, Kristian Fiskerstrand wrote:
> On 01/16/2018 07:40 PM, Daniel Kahn Gillmor wrote:
> 
>> The keyserver network (or some future variant of it) can of course play
>> a role in parallel to any or all of these.  for example, keyservers are
>> particularly well-situated to offer key revocation, updates to expiry,
>> and subkey rotation, none of which would necessarily involve names or
>> e-mail addresses.
>>
>> It would be interesting to see a network of keyserver operators that:
>>
>>  (a) did cryptographic verification, and rejected packets that could not
>>  be verified (also: required cryptographic verifications of
>>  cross-signatures for signing-capable subkeys)
>>
>>  (b) rejected all User IDs and User Attributes and certifications over
>>  those components
>>
>>  (c) rejected all third-party certifications -- so data attached to a
>>  given primary key is only accepted when certified by that primary
>>  key.
>>
> 
> thanks for this post Daniel, my primary question would be what advantage
> is gained by this verification being done by an arbitrary third party
> rather by a trusted client running locally, which is the current modus
> operandus. Any keyserver action doing this would just shift
> responsibilities to a third party for something better served (and
> already happens) locally.

I guess one argument could be “when lazy people use the keyserver
network, they likely get not-too-bad data”.

I seem to remember that when a keyserver returned multiple keys to
GnuPG, GnuPG imported both, even when searching for a fingerprint and
the fingerprint didn't match, at some point in the last few years? If
even GnuPG can fail at properly sanitizing the data received by
keyservers (and I hope I'm not mistaken in this memory), I guess having
such keyservers only serve curated data when used in their “nominal” use
could help a bit.

It could also help limit the impact of the nightmare scenario RJH has
described, by making sure all the data is “cryptographically valid and
matching”, thus making it harder to just propagate arbitrary data down
the network. Then I don't have the structure of an OpenPGP key in mind,
so maybe this would not work due to fields in the key that could be set
to arbitrary data anyways

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

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Kristian Fiskerstrand]

On 01/16/2018 07:40 PM, Daniel Kahn Gillmor wrote:

> The keyserver network (or some future variant of it) can of course play
> a role in parallel to any or all of these.  for example, keyservers are
> particularly well-situated to offer key revocation, updates to expiry,
> and subkey rotation, none of which would necessarily involve names or
> e-mail addresses.
> 
> It would be interesting to see a network of keyserver operators that:
> 
>  (a) did cryptographic verification, and rejected packets that could not
>  be verified (also: required cryptographic verifications of
>  cross-signatures for signing-capable subkeys)
> 
>  (b) rejected all User IDs and User Attributes and certifications over
>  those components
> 
>  (c) rejected all third-party certifications -- so data attached to a
>  given primary key is only accepted when certified by that primary
>  key.
> 

thanks for this post Daniel, my primary question would be what advantage
is gained by this verification being done by an arbitrary third party
rather by a trusted client running locally, which is the current modus
operandus. Any keyserver action doing this would just shift
responsibilities to a third party for something better served (and
already happens) locally.


-- 

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

Bene diagnoscitur, bene curatur
Something that is well diagnosed can be cured well



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

key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Daniel Kahn Gillmor]

On Tue 2018-01-16 01:02:11 +, listo factor via Gnupg-users wrote:
> Burning it down is not what I was advocating. I am advocating orderly
> evacuation and replacement of a system that has clearly outlived its
> usefulnesses. If it is not replaced in time, it will, at some point,
> burn ignited by forces we have no control over. ~Then~ it will have
> to be abandoned in rather more painful manner - just as you are
> alluding to.

While i think we disagree on "has outlived its usefulnesses", i would
agree that planning and preparing for catastrophic keyserver network
failure is a good idea.  What i haven't seen in this thread is a list of
the variety of proposals for OpenPGP key distribution that do *not*
require the global append-only keyserver network.

So in the hopes of making this a productive discussion, i'll list a
few.  Already briefly mentioned are:

 * Web Key Directory (WKD)
 Mail provider publishes public keys of users via https to a
 well-known location.

 https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-05

 * Keybase
 social media and other avenues for key publication, identification,
 and corroboration.

 https://keybase.io

A few other approaches are:

 * DNS OPENPGPKEY records
 DNS lookups of public keys (or hashes of public keys for
 confirmation)
 
 https://tools.ietf.org/html/rfc7929

 * Autocrypt
 In-band key exchange (in every e-mail message) removes the need for
 external distribution mechanisms for all messages but the first.
 
 https://autocrypt.org/

 * VVV
 DNS (SRV) discovery of HKP service operated by the mail provider.

 https://keys4all.de/media/beschreibung-vvv-loesung.pdf

I'm sure i've missed some other distribution/verification/update
mechanism, and would be happy to see constructive pointers.

Of the above, i'm most leaning toward Autocrypt today, because it does
not require involvement of any third party -- as long as both sides of
the e-mail use an autocrypt-capable client, there is no additional
information leakage.

Note that the different schemes have different properties in terms of:

 * information leakage
 * cryptographic verification
 * third-party control
 * censorship
 * ...

The keyserver network (or some future variant of it) can of course play
a role in parallel to any or all of these.  for example, keyservers are
particularly well-situated to offer key revocation, updates to expiry,
and subkey rotation, none of which would necessarily involve names or
e-mail addresses.

It would be interesting to see a network of keyserver operators that:

 (a) did cryptographic verification, and rejected packets that could not
 be verified (also: required cryptographic verifications of
 cross-signatures for signing-capable subkeys)

 (b) rejected all User IDs and User Attributes and certifications over
 those components

 (c) rejected all third-party certifications -- so data attached to a
 given primary key is only accepted when certified by that primary
 key.

This would basically be a network that facilitates
update/revocation/key-rotation, without exposing any names or e-mail
addresses to the public by default; it could be run in parallel with the
existing keyserver network.  i don't know how well we could bridge the
two networks, though and it'd be a shame to have to upload updated
keys to both networks manually. :/

anyway, hopefully this gives some concrete, positive next steps that
folks who want the keyserver network to go away can take, rather than
trying to burn it all down :)

   --dkg


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

Re: Dirmngr fails to communicate with keyservers (W32 binaries for GnuPG 2.1.22)

[Kosuke Kaizuka]

On Mon, 31 Jul 2017 10:35:24 +0200, Andre Heinecke wrote:
> Hi,
> 
> On Sunday, July 30, 2017 11:41:01 AM CEST Kosuke Kaizuka wrote:
>> On Sat, 29 Jul 2017 14:58:09 +0100, MFPA wrote:>
>>> I have installed the W32 package for GnuPG 2.1.22 and I find keys
>>> cannot be sent to keyservers, or fetched/refreshed. The operation
>>> fails with the message "keyserver send failed: Resource temporarily
>>> unavailable".
>>>
>>> In the event the dirmngr from 2.1.21 is already running, the operation
>>> succeeds.
> 
> Yes, slipped our testing. We are working on it:
> 
> https://dev.gnupg.org/T3318

The problem seems to have been fixed in gnupg-w32-2.1.22_20170731.

-- 
Kosuke Kaizuka <cai.0...@gmail.com>



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

Re: Dirmngr fails to communicate with keyservers (W32 binaries for GnuPG 2.1.22)

[Andre Heinecke]

Hi,

On Sunday, July 30, 2017 11:41:01 AM CEST Kosuke Kaizuka wrote:
> On Sat, 29 Jul 2017 14:58:09 +0100, MFPA wrote:>
> > I have installed the W32 package for GnuPG 2.1.22 and I find keys
> > cannot be sent to keyservers, or fetched/refreshed. The operation
> > fails with the message "keyserver send failed: Resource temporarily
> > unavailable".
> > 
> > In the event the dirmngr from 2.1.21 is already running, the operation
> > succeeds.

Yes, slipped our testing. We are working on it:

https://dev.gnupg.org/T3318

Regards,
Andre
-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Dirmngr fails to communicate with keyservers (W32 binaries for GnuPG 2.1.22)

[Kosuke Kaizuka]

On Sat, 29 Jul 2017 14:58:09 +0100, MFPA wrote:>
> I have installed the W32 package for GnuPG 2.1.22 and I find keys
> cannot be sent to keyservers, or fetched/refreshed. The operation
> fails with the message "keyserver send failed: Resource temporarily
> unavailable".
> 
> In the event the dirmngr from 2.1.21 is already running, the operation
> succeeds.
> 
> 
> 
> [path_to]\GnuPG_2_1_22\bin>gpg --send-key 0xF5AECE1EF251BFAB
> gpg: using character set 'utf-8'
> gpg: no running Dirmngr - starting
> '[path_to]\GnuPG_2_1_22\bin\dirmngr.exe'
> 
> gpg: waiting for the dirmngr to come up ... (5s)
> gpg: waiting for the dirmngr to come up ... (4s)
> gpg: connection to the dirmngr established
> gpg: Invalid key 0xF5AECE1EF251BFAB made valid by
> --allow-non-selfsigned-uid
> 
> gpg: sending key 0xF5AECE1EF251BFAB to hkp://pool.sks-keyservers.net
> gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked
> gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked
> gpg: keyserver send failed: Resource temporarily unavailable
> gpg: keyserver send failed: Resource temporarily unavailable
> 
> 
> 
> 
> 
> Compare with:
> 
> [path_to]\GnuPG_2_1_22\bin>gpg --send-key 0xF5AECE1EF251BFAB
> gpg: using character set 'utf-8'
> gpg: WARNING: server 'dirmngr' is older than us (2.1.21 < 2.1.22)
> gpg: Invalid key 0xF5AECE1EF251BFAB made valid by
> --allow-non-selfsigned-uid
> 
> gpg: sending key 0xF5AECE1EF251BFAB to hkp://pool.sks-keyservers.net
> gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked
> gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked

Same issue with gpg 2.1.22 on Win7 x64.

I've tried search, send-keys and recv-keys commands but all failed with
"Resource temporarily unavailable" messages.

gpg 2.1.21 works fine.

-- 
Kosuke Kaizuka <cai.0...@gmail.com>



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

Dirmngr fails to communicate with keyservers (W32 binaries for GnuPG 2.1.22)

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


I have installed the W32 package for GnuPG 2.1.22 and I find keys
cannot be sent to keyservers, or fetched/refreshed. The operation
fails with the message "keyserver send failed: Resource temporarily
unavailable".

In the event the dirmngr from 2.1.21 is already running, the operation
succeeds.



[path_to]\GnuPG_2_1_22\bin>gpg --send-key 0xF5AECE1EF251BFAB
gpg: using character set 'utf-8'
gpg: no running Dirmngr - starting
'[path_to]\GnuPG_2_1_22\bin\dirmngr.exe'

gpg: waiting for the dirmngr to come up ... (5s)
gpg: waiting for the dirmngr to come up ... (4s)
gpg: connection to the dirmngr established
gpg: Invalid key 0xF5AECE1EF251BFAB made valid by
- --allow-non-selfsigned-uid

gpg: sending key 0xF5AECE1EF251BFAB to hkp://pool.sks-keyservers.net
gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked
gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked
gpg: keyserver send failed: Resource temporarily unavailable
gpg: keyserver send failed: Resource temporarily unavailable





Compare with:

[path_to]\GnuPG_2_1_22\bin>gpg --send-key 0xF5AECE1EF251BFAB
gpg: using character set 'utf-8'
gpg: WARNING: server 'dirmngr' is older than us (2.1.21 < 2.1.22)
gpg: Invalid key 0xF5AECE1EF251BFAB made valid by
- --allow-non-selfsigned-uid

gpg: sending key 0xF5AECE1EF251BFAB to hkp://pool.sks-keyservers.net
gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked
gpg: Note: signature key 0xF5AECE1EF251BFAB has been revoked




- --
Best regards

MFPA  <mailto:2014-667rhzu3dc-lists-gro...@riseup.net>

It's not hard to meet expenses, they're everywhere.
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWXyUeV8UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5MMNAQC4QqhxRYa/L8rMfoyfcYDixQOr6uskMoN/bDwdBmPCwwEAtlNVH+dlE5h/
xLesXjjiB8+rU1KK+mSJnhGgFPEFVAqJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWXyUkV8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8FC0CADAWYNuxXCeEdVIc1L8HC6WZHG/
oUYEyGnPIgFfczjzLgU+fHbpJnzk4PdJZVEhlTqYb3rg+5Wr55UcTStskbmP6tcR
xBBKx+8hk7s9pIH4iCZgbN9DF9oT9ENdFV/ODSBgpI8IVDiE+02DHXaZLQCTjIP2
YOvInshDJheKAq+ZnL4T9BBma3NCvvzoCD61Z+35VuUcxSq8uCjw6vEnMAHGoCdG
sCCSa6X0Ch+becbsWJmkeSoOL7eDE/TVuLBpy85F+O3xlRrcqGxzERAqsXKP34t/
OVt2Q+HUFVfObPnHxG4DUk3nYA3ja+yS1QvwD8z3Bz/WnYb4hGJpikBKuXkT
=yPGQ
-END PGP SIGNATURE-


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

Re: HTTPS keyservers (with SSL-keys recording)

[Miroslav Rovis]

On 170315-16:46+0100, Werner Koch wrote:
> On Wed, 15 Mar 2017 10:14, miro.ro...@croatiafidelis.hr said:
> 
> > keyserver hkps.pool.sks-keyservers.net:443
> 
> I guess we should better default to hkps:// if a scheme is not given.
which is, IIUC, HTTPS key protocol, like hkp:// is HTTP key protocol.

> I have not checked whether this is already the case.
No, it's not implemented, or if it is, it's not by default in my Gentoo.
But if it's local configuration, I'm not an expert to know what to
configure to get it implemented.
 
> > I record SSL-keys all the time, and I believe every communication
> > in/with my machine must be permitted by me, and open to my inspection,
> 
> I didn't understand the need for recording session keys - in general we
> try hard not to leave any trace of session keys.
How do you solve issues that arise then? How do you guard your system if
you don't have an option to inspect what it happening in your system?
There's no defence generally without knowing what happens on your turf,
not really, ever!

> BTW, we should not use the term SSL anymore.
BTW, my original title to that Youtube-dl issue contained SSL-key, not
TLS-key recording, the maintainer there changed that title...

It's very hard for me to contradict someone of your format, Werner, but
other smart people say the name change has been purely political,
without any technical merit to it... So allow me to point to you others
that contradict to you, and IMO rebellion against senseless practices is a
good thing(TM):

https://wiki.wireshark.org/SSL
and if you try:
https://wiki.wireshark.org/TLS
you get "This page does not exist yet."

> 
> Shalom-Salam,
Peace!

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

Deutch schreiben, lesen und schprechen I möchte lernen... Aber kein
zeit für jetzt...
( I like German, and German-speaking nations, culture and way of life a
lot. )

Sincere respect and regards to you and your team!
-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr


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

Re: HTTPS keyservers (with SSL-keys recording)

[Werner Koch]

On Wed, 15 Mar 2017 10:14, miro.ro...@croatiafidelis.hr said:

> keyserver hkps.pool.sks-keyservers.net:443

I guess we should better default to hkps:// if a scheme is not given.  I
have not checked whether this is already the case.

> I record SSL-keys all the time, and I believe every communication
> in/with my machine must be permitted by me, and open to my inspection,

I didn't understand the need for recording session keys - in general we
try hard not to leave any trace of session keys.

BTW, we should not use the term SSL anymore.


Shalom-Salam,

   Werner

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


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

HTTPS keyservers (with SSL-keys recording), WAS: help

[Miroslav Rovis]

My reply is really to one issue of all, but the discussion is
noteworthy, and also it took place 2 1/2 weeks ago, so I leave the whole
email quoted.

On 170228-00:35+0100, Damien Goutte-Gattat wrote:
> Hi,
> 
> On 02/27/2017 04:07 PM, r...@riseup.net wrote:
> > I'll use my master key offline. Following this guidelines:
> > https://incenp.org/notes/2015/using-an-offline-gnupg-master-key.html
> >
> > I also implemented the Appelbaum's config.(Riseup Best Practices) Will
> > it work properly if the Master Key isn't on my machine?
> 
> It should.
> 
> Note, however, that Riseup's Best Practices [1] and proposed 
> configuration file [2] are partially obsolete, *especially* if you are 
> using GnuPG 2.1. Many of the proposed options and advices are not needed 
> anymore, as GnuPG already does The Right Thing.
> 
> 
> > And the following faults are coming:
> >  gpg: keyserver option 'ca-cert-file' is obsolete; please use
> > 'hkp-cacert' in dirmngr.conf
> 
> If you're using the sks-keyservers.net pool you no longer need to 
> provide GnuPG with the CA certificate file, as it is now bundled with 
> GnuPG (>= 2.1.11) and automatically used when needed. (And with GnuPG >= 
> 2.1.16 you will no longer even need to explicity set the keyserver 
> option, as hkps.pool.sks-keyservers.net is already the default.)
> 
> 
> > gpg: keyserver option 'no-try-dns-srv' is unknown
> 
> This option no longer exists, but I *think* that if you really want to, 
> you can disable SRV lookups by explicitly specifying a port number when 
> setting the keyserver, as in:
> 
>keyserver hkps.pool.sks-keyservers.net:443

Nope! The port is 11371. I just tried apply your suggestion (because I'd
very much like two things, see below), and I added to my:

~/.gnupg/dirmngr.conf

the line:

keyserver hkps.pool.sks-keyservers.net:443

but this are the HTTP Requests full uri that I found in my traces:

125 
http://pool.sks-keyservers.net:11371/pks/lookup?op=get=mr=0x3F533109A9509B14
153 
http://pool.sks-keyservers.net:11371/pks/lookup?op=get=mr=0xCBB15A68EF3AC804875D5C4E153FE398821C8394
234 
http://pool.sks-keyservers.net:11371/pks/lookup?op=get=mr=0xB34135EC5C5D05CF0FBCC8D583864DFC21ABA4A6
1046
http://pool.sks-keyservers.net:11371/pks/lookup?op=get=mr=0x19419825DE14BEA8
1076
http://pool.sks-keyservers.net:11371/pks/lookup?op=get=mr=0x9011A67E3A73CDF575FA841C7BCC5A972762EBA1
1110
http://pool.sks-keyservers.net:11371/pks/lookup?op=get=mr=0x8EB8BFEFAA18B872

-- those were just some keys from the public mailing lists, I think I
used Mutt ML this time --

( gotten with the unfinished, but mostly working, script of mine:
https://github.com/miroR/tshark-hosts-conv , the number in front is the
packet the request it appears in )
 
> --
> [1] https://riseup.net/en/security/message-security/openpgp/best-practices
> [2] 
> https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf
> 

And the two things that I would very much like to see (in not too
distant future), is,

1) of course, HKP in secure conversation client-server, not in
plaintext, over the internet

2) secure HKP decryptable for end user, at his configuration and
request. Pls. see this youtube-dl issue:

Write TLS session keys to $SSLKEYLOGFILE #11614
https://github.com/rg3/youtube-dl/issues/11614
(of course devs will find real read in the links therefrom, but I'm not
one, I give what I can follow)

and know that Wget program has implemented that decryptability for end
user (just like some big browsers do if you set up $SSLKEYLOGFILE...)

I record SSL-keys all the time, and I believe every communication
in/with my machine must be permitted by me, and open to my inspection,
else, it's getting very close to doing/allowing things to be done behind
my back... A very good example of things possibly being done, allowed to
be done behind my back is dbus, the core of all big Desktop
Environments, the best and sine qua non friend of SystemDestruction or
systemd...

Just look it up, and apparently, that's the normal communication setup
by dbus (see below about that too):

Re: How to avoid stealth installation of systemd?
http://forums.debian.net/viewtopic.php?f=20=116770=45#p552566

where find:

$ ps aux | grep ssh
root  2184  0.0  0.0  54976  1004 ?Ss   Sep06   0:00 /usr/sbin/sshd
mr2447  0.0  0.0  1059232 ?Ss   Sep06   0:00 
/usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager
mr   15141  0.0  0.0  19980  1796 pts/9S+   21:48   0:00 grep ssh
$

I really hope GnuPG will go the SSL way for getting the keys, and the
decryptable-for-user way, to get it all open, at user's
request/configuration (not by default! nobody does it by default any
more, can be hijacked from non-advanced users).

I learned that recently from people at secure-os that this way is how
dbus regularly works! Quoting: 

> Both ssh-agent and dbus must be wrapped around X11 in order to do
> their job, and that is just what that 

Re: Using LDAP keyservers with gpg 2.1.11

[Philip Colmer]

OK ... I've done some more digging.

The command

KEYSERVER --clear

was failing because it doesn't like the embedded username and
password, i.e. it only works if the configuration just specifies
ldaps://login.linaro.org.

So, stripping the username and password out gets *that* bit of the
code to work but ultimately fails when the code tries to send the key
because it no longer has any authentication information.

How/where am I supposed to specify the username and password? I've
tried specifying:

keyserver-options binddn="uid=user1,ou=PGP Keys,dc=EXAMPLE,dc=ORG"
keyserver-options bindpw=PASSWORD

which is what https://wiki.gnupg.org/LDAPKeyserver suggests, but the
software complains they are unrecognised; I suspect that gnupg 2.1
removed those but it isn't clear if they got replaced by something
else.

Thanks.

Philip


On 8 April 2016 at 12:19, Philip Colmer  wrote:
> On 8 April 2016 at 11:55, Kristian Fiskerstrand
>  wrote:
 is ldap listed as a schema when doing KEYSERVER --help ? you can
 also check if ldd /usr/bin/dirmngr shows a linkage to libldap
>
> Thanks for this suggestion. dirmngr wasn't listing ldap, so I've
> installed the extra bits, rebuilt and now it is.
>
> However, unfortunately, now --send-key breaks earlier than it was :(
>
> gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache
> memstat trust hashing cardio ipc clock lookup extprog
> gpg: DBG: [not enabled in the source] start
> gpg: DBG: chan_3 <- # Home: /home/ubuntu/.gnupg
> gpg: DBG: chan_3 <- # Config: /home/ubuntu/.gnupg/dirmngr.conf
> gpg: DBG: chan_3 <- OK Dirmngr 2.1.11 at your service
> gpg: DBG: connection to the dirmngr established
> gpg: DBG: chan_3 -> GETINFO version
> gpg: DBG: chan_3 <- D 2.1.11
> gpg: DBG: chan_3 <- OK
> gpg: DBG: chan_3 -> KEYSERVER --clear
> ldaps://:@login.linaro.org?dc=linaro,dc=org
> gpg: DBG: chan_3 <- ERR 167772161 General error 
> gpg: no keyserver known
> gpg: keyserver send failed: No keyserver available
> gpg: DBG: chan_3 -> BYE
> gpg: DBG: [not enabled in the source] stop
>
> This used to be the output ...
>
> gpg: DBG: [not enabled in the source] start
> gpg: DBG: chan_3 <- # Home: /home/ubuntu/.gnupg
> gpg: DBG: chan_3 <- # Config: /home/ubuntu/.gnupg/dirmngr.conf
> gpg: DBG: chan_3 <- OK Dirmngr 2.1.11 at your service
> gpg: DBG: chan_4 <- # Home: /home/ubuntu/.gnupg
> gpg: DBG: chan_4 <- # Config: /home/ubuntu/.gnupg/dirmngr.conf
> gpg: DBG: chan_4 <- OK Dirmngr 2.1.11 at your service
> gpg: DBG: connection to the dirmngr established
> gpg: DBG: chan_4 -> GETINFO version
> gpg: DBG: chan_4 <- D 2.1.11
> gpg: DBG: chan_4 <- OK
> gpg: DBG: chan_4 -> KEYSERVER --clear ldaps://:@login.linaro.org
> gpg: DBG: chan_4 <- OK
> gpg: DBG: chan_4 -> KEYSERVER
> gpg: DBG: chan_4 <- S KEYSERVER ldaps://uid=:@login.linaro.org
> gpg: DBG: chan_4 <- OK
> gpg: DBG: [not enabled in the source] keydb_new
> gpg: DBG: [not enabled in the source] keydb_search enter
>
> Regards
>
> Philip

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

Re: Using LDAP keyservers with gpg 2.1.11

[Philip Colmer]

On 7 April 2016 at 17:03, Kristian Fiskerstrand
 wrote:
> is ldap listed as a schema when doing KEYSERVER --help ? you can also
> check if ldd /usr/bin/dirmngr shows a linkage to libldap

Sorry - how do I check the schema? I'm not sure what command you are
asking me to run.

With regards to the ldd command, no, there is no linkage to libldap. I
have the libldap package installed, so do I need to do something to
get gnupg to link to it when I build it?

Regards

Philip

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

Re: Using LDAP keyservers with gpg 2.1.11

[Philip Colmer]

On 8 April 2016 at 11:55, Kristian Fiskerstrand
 wrote:
>>> is ldap listed as a schema when doing KEYSERVER --help ? you can
>>> also check if ldd /usr/bin/dirmngr shows a linkage to libldap

Thanks for this suggestion. dirmngr wasn't listing ldap, so I've
installed the extra bits, rebuilt and now it is.

However, unfortunately, now --send-key breaks earlier than it was :(

gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache
memstat trust hashing cardio ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/ubuntu/.gnupg
gpg: DBG: chan_3 <- # Config: /home/ubuntu/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.1.11 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.1.11
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear
ldaps://:@login.linaro.org?dc=linaro,dc=org
gpg: DBG: chan_3 <- ERR 167772161 General error 
gpg: no keyserver known
gpg: keyserver send failed: No keyserver available
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop

This used to be the output ...

gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/ubuntu/.gnupg
gpg: DBG: chan_3 <- # Config: /home/ubuntu/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.1.11 at your service
gpg: DBG: chan_4 <- # Home: /home/ubuntu/.gnupg
gpg: DBG: chan_4 <- # Config: /home/ubuntu/.gnupg/dirmngr.conf
gpg: DBG: chan_4 <- OK Dirmngr 2.1.11 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_4 -> GETINFO version
gpg: DBG: chan_4 <- D 2.1.11
gpg: DBG: chan_4 <- OK
gpg: DBG: chan_4 -> KEYSERVER --clear ldaps://:@login.linaro.org
gpg: DBG: chan_4 <- OK
gpg: DBG: chan_4 -> KEYSERVER
gpg: DBG: chan_4 <- S KEYSERVER ldaps://uid=:@login.linaro.org
gpg: DBG: chan_4 <- OK
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter

Regards

Philip

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

Re: Using LDAP keyservers with gpg 2.1.11

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/08/2016 12:38 PM, Philip Colmer wrote:
> On 7 April 2016 at 17:03, Kristian Fiskerstrand 
>  wrote:
>> is ldap listed as a schema when doing KEYSERVER --help ? you can 
>> also check if ldd /usr/bin/dirmngr shows a linkage to libldap
> 
> Sorry - how do I check the schema? I'm not sure what command you 
> are asking me to run.

$ dirmngr
OK Dirmngr 2.1.11 at your service
KEYSERVER --help
S # Known schemata:
S #   hkp
S #   hkps
S #   http
S #   finger
S #   kdns
S #   ldap
S # (Use an URL for engine specific help.)
OK


> 
> With regards to the ldd command, no, there is no linkage to 
> libldap. I have the libldap package installed, so do I need to do 
> something to get gnupg to link to it when I build it?
> 


you need the appropriate header files for the library (-dev packages
as well) and for good measure I specify --with-ldap in the gnupg build

- -- 
- 
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
- 
Public OpenPGP key at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
Aquila non capit muscas
The eagle does not hunt flies
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJXB443AAoJECULev7WN52FO2wIAMbGQp92GrEtCwF0wXZ6PJTA
otCRJC37Wvcsk+2zcW1Tkfe+zauSDblsTAy6GkrYTvWGdzR/Bt+vSFU8A8qzTe/Q
QBPtYU6I5ErPdj3VGpPZ7ruboH/R3pRT6DREd4Ag/FqqaHoEPA9+ePvpzgXOZiS6
9DktTodvqZDhxhI7xjbGVeGnq8YfrXTshjEyAThpIjOHQBFheMvdmHc9yvvFWnFn
jpnXRJK2XiGiorvigsAtBhXwoGzwdFjyEsXL3ljSEUUQRWDlvEnwUPCThGu1FwiU
eK/6wS3XZ67gWUE0bY5nZQNDrf1hYTqrlBHZq9PuuRwSY8oW2O83VhAi381AFwE=
=tAhY
-END PGP SIGNATURE-

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

Re: Using LDAP keyservers with gpg 2.1.11

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/07/2016 04:58 PM, Philip Colmer wrote:
> On 7 April 2016 at 15:40, Werner Koch  wrote:
>> On Wed,  6 Apr 2016 17:33, philip.col...@linaro.org said:
>> 
>>> However, with version 2.1.11, it isn't working. Enabling debug
>>> options where I can find them gives me this output:
>> 
>> Please enable debugging for dirmngr and restart dirmngr.  All
>> network access is done via the dirmngr daemon which is started
>> when needed.
> 
> I've configured debugging for dirmngr in dirmngr.conf as follows:
> 
> debug-level guru debug-all
> 
> dirmngr is running with its homedir set to the directory
> containing that conf file.
> 
> If I should be doing something different to get more debugging
> info out of dirmngr, please clarify. At the moment, the only
> information I seem to be getting is:
> 
> gpg: DBG: chan_4 <- ERR 167772346 No keyserver available 

is ldap listed as a schema when doing KEYSERVER --help ? you can also
check if ldd /usr/bin/dirmngr shows a linkage to libldap


- -- 
- 
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
- 
Public OpenPGP key at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
Aquila non capit muscas
The eagle does not hunt flies
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJXBoTrAAoJECULev7WN52F3MkH/iR6xVI49aBItDWtP+AShovp
6bnQ1E2iEA0FXo04LdKw4ab/REnsGXsOqVvtyjndqIO32lFzw4dw73wwJUq0m12N
xqQuNJASMs+Gu/jzQh/JiYmorilZgt+S7QgElIIureeD1oH3gKAvFalrATxex03e
0nG0bQQE/WJnpRITP8qW9pP0XWR8bqUiOd9bIAmeHntuZj1RJif87a4ntcWPc7xt
X3cLRphIL+AxGk2kL8g0Y4ojbZ0GQfyYHlg6X6cYXIIu7Pv4cdmzCUGjoMuex70K
+uFv1TP+TNV30oJwDea72zegty04H8QvreCx6dGAni+PNwcF96J8csi0RX7UGqM=
=U3Uh
-END PGP SIGNATURE-

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

Re: Using LDAP keyservers with gpg 2.1.11

[Philip Colmer]

On 7 April 2016 at 15:40, Werner Koch  wrote:
> On Wed,  6 Apr 2016 17:33, philip.col...@linaro.org said:
>
>> However, with version 2.1.11, it isn't working. Enabling debug options
>> where I can find them gives me this output:
>
> Please enable debugging for dirmngr and restart dirmngr.  All network
> access is done via the dirmngr daemon which is started when needed.

I've configured debugging for dirmngr in dirmngr.conf as follows:

debug-level guru
debug-all

dirmngr is running with its homedir set to the directory containing
that conf file.

If I should be doing something different to get more debugging info
out of dirmngr, please clarify. At the moment, the only information I
seem to be getting is:

gpg: DBG: chan_4 <- ERR 167772346 No keyserver available 

Which doesn't really tell me much, and I cannot figure out where in
the source code this is happening.

Regards

Philip

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

Re: Using LDAP keyservers with gpg 2.1.11

[Werner Koch]

On Wed,  6 Apr 2016 17:33, philip.col...@linaro.org said:

> However, with version 2.1.11, it isn't working. Enabling debug options
> where I can find them gives me this output:

Please enable debugging for dirmngr and restart dirmngr.  All network
access is done via the dirmngr daemon which is started when needed.


Salam-Shalom,

   Werner

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


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

Using LDAP keyservers with gpg 2.1.11

[Philip Colmer]

I've configured our LDAP server to act as a keyserver for use with
GnuPG. In testing, with version 1.x and 2.0, sending keys to the
keyserver works.

However, with version 2.1.11, it isn't working. Enabling debug options
where I can find them gives me this output:

gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache
memstat trust hashing cardio ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/ubuntu/.gnupg
gpg: DBG: chan_3 <- # Config: /home/ubuntu/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.1.11 at your service
gpg: DBG: chan_4 <- # Home: /home/ubuntu/.gnupg
gpg: DBG: chan_4 <- # Config: /home/ubuntu/.gnupg/dirmngr.conf
gpg: DBG: chan_4 <- OK Dirmngr 2.1.11 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_4 -> GETINFO version
gpg: DBG: chan_4 <- D 2.1.11
gpg: DBG: chan_4 <- OK
gpg: DBG: chan_4 -> KEYSERVER --clear ldaps://:@login.linaro.org
gpg: DBG: chan_4 <- OK
gpg: DBG: chan_4 -> KEYSERVER
gpg: DBG: chan_4 <- S KEYSERVER ldaps://uid=:@login.linaro.org
gpg: DBG: chan_4 <- OK
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: SHORT_KID: 'DC6F3C29'
gpg: DBG: keydb_search: searching keyring (resource 0 of 1)
gpg: DBG: keyring_search: need_uid = 0; need_words = 0; need_keyid =
1; need_fpr = 0; any_skip = 0
gpg: DBG: fd_cache_open (/home/ubuntu/.gnupg/pubring.gpg) not cached
gpg: DBG: iobuf-2.0: open '/home/ubuntu/.gnupg/pubring.gpg'
desc=file_filter(fd) fd=5
gpg: DBG: keyring_search: initializing offset table. (need_keyid: 1 => 1)
gpg: DBG: keyring_search: searching from start of resource.
gpg: DBG: iobuf-2.0: underflow: buffer size: 8192; still buffered: 0
=> space for 8192 bytes
gpg: DBG: iobuf-2.0: underflow: A->FILTER (8192 bytes)
gpg: DBG: iobuf-2.0: A->FILTER() returned rc=0 (ok), read 1211 bytes
gpg: DBG: parse_packet(iob=2): type=6 length=269 (search.keyring.c.1115)
gpg: DBG: keyring_search: packet starting at offset 0 matched descriptor 0
gpg: DBG: keyring_search: returning success
gpg: DBG: free_packet() type=6
gpg: DBG: keydb_search: searched keyring (resource 0 of 1) => Success
gpg: DBG: [not enabled in the source] keydb_search leave (found)
gpg: DBG: [not enabled in the source] keydb_get_keybock enter
gpg: DBG: fd_cache_open (/home/ubuntu/.gnupg/pubring.gpg) not cached
gpg: DBG: iobuf-3.0: open '/home/ubuntu/.gnupg/pubring.gpg'
desc=file_filter(fd) fd=6
gpg: DBG: iobuf-3.0: underflow: buffer size: 8192; still buffered: 0
=> space for 8192 bytes
gpg: DBG: iobuf-3.0: underflow: A->FILTER (8192 bytes)
gpg: DBG: iobuf-3.0: A->FILTER() returned rc=0 (ok), read 1211 bytes
gpg: DBG: parse_packet(iob=3): type=6 length=269 (parse.keyring.c.414)
gpg: DBG: parse_packet(iob=3): type=13 length=40 (parse.keyring.c.414)
gpg: DBG: parse_packet(iob=3): type=2 length=318 (parse.keyring.c.414)
gpg: DBG: parse_packet(iob=3): type=12 length=2 (parse.keyring.c.414)
gpg: DBG: free_packet() type=12
gpg: DBG: parse_packet(iob=3): type=14 length=269 (parse.keyring.c.414)
gpg: DBG: parse_packet(iob=3): type=2 length=293 (parse.keyring.c.414)
gpg: DBG: parse_packet(iob=3): type=12 length=2 (parse.keyring.c.414)
gpg: DBG: free_packet() type=12
gpg: DBG: iobuf-3.0: underflow: buffer size: 8192; still buffered: 0
=> space for 8192 bytes
gpg: DBG: iobuf-3.0: underflow: A->FILTER (8192 bytes)
gpg: DBG: iobuf-3.0: A->FILTER() returned rc=-1 (EOF), read 0 bytes
gpg: DBG: /home/ubuntu/.gnupg/pubring.gpg: close fd/handle 6
gpg: DBG: fd_cache_close (/home/ubuntu/.gnupg/pubring.gpg) new slot created
gpg: DBG: iobuf-3.0: close '?'
gpg: DBG: [not enabled in the source] keydb_get_keyblock leave
gpg: DBG: build_packet() type=6
gpg: DBG: iobuf-4.0: close '?'
gpg: DBG: build_packet() type=13
gpg: DBG: build_packet() type=2
gpg: DBG: iobuf-5.0: close '?'
gpg: DBG: build_packet() type=14
gpg: DBG: iobuf-6.0: close '?'
gpg: DBG: build_packet() type=2
gpg: DBG: iobuf-7.0: close '?'
gpg: DBG: iobuf-2.0: close 'file_filter(fd)'
gpg: DBG: /home/ubuntu/.gnupg/pubring.gpg: close fd/handle 5
gpg: DBG: fd_cache_close (/home/ubuntu/.gnupg/pubring.gpg) new slot created
gpg: DBG: iobuf-1.0: close '?'
gpg: sending key DC6F3C29 to ldaps://:@login.linaro.org
gpg: DBG: chan_4 -> KS_PUT
gpg: DBG: chan_4 <- INQUIRE KEYBLOCK
gpg: DBG: chan_4 -> [ 44 20 99 01 25 30 44 04 56 fe 8f d2 01 08 00 c2
...(982 byte(s) skipped) ]
gpg: DBG: chan_4 -> [ 44 20 20 4f ad 28 53 1c 95 8a ae 0f 57 5f 35 fc
...(231 byte(s) skipped) ]
gpg: DBG: chan_4 -> END
gpg: DBG: chan_4 <- INQUIRE KEYBLOCK_INFO
gpg: DBG: chan_4 -> D
pub::2048:1:4625A9B1DC6F3C29:1459523538:1460128338::%0Auid:1459523538Philip
Colmer 
:::%0Asig4625A9B1DC6F3C29:1459523538:::%0Asub::2048:1:87E613C66F047E92:1459523538:1460128338::%0A
gpg: DBG: chan_4 -> END
gpg: DBG: chan_4 <- ERR 167772346 No keyserver 

Re: Remove photos from OpenPGP key in the keyservers

[Andrew Gallagher]

On 09/03/16 18:47, Anthony Papillion wrote:
> So am I
> correct in this thinking: if I attach a picture to my key and upload
> it to a keyserver then remove the picture and upload that 'version' of
> my key to the server, the key on the server STILL HAS my picture and
> the clients choose to ignore it at that point?

Not only do the servers still have your picture, but clients cannot know
to ignore it unless you explicitly revoke the picture and upload the
revocation. But all this does is mark the picture as invalid. Clients
have to download the picture before they find out it has been revoked -
so other people will still be able to see it.

A



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

Re: Remove photos from OpenPGP key in the keyservers

[Anthony Papillion]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 03/08/2016 10:47 AM, Robert J. Hansen wrote:
>> I'm pretty sure that, if you just send your modified key to the 
>> keyserver again, it will replace the one that's there.
> 
> This is not correct.

Apparently not. Thanks for the correction. I made an incorrect
assumption due to not thinking things through properly.


-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJW4HA2AAoJEAKK33RTsEsV130P/2g8GV/Eh3Qn0tEEEnOrf0u4
PaNwhUmN5XM1mmatTBgLL6dWHGpsrl7DO9bOEedRkZDifFbKqjYTKiNLdOQBBEO2
8Qf4pQacgpjclcJYdmMThztSMZWyn06/V6Q406hXbdFaOD/AiNLoVfuOXXdZ3XS/
1J53XF8RCERfn6/Cg5WeLmwTaTAxe+nJ8oAkEYRq1LUjBcj+g52Zg8rz4aq6orQ8
t/7FW49pdvu1rQlZNpSTp0evXROjoTIWlJjPjWnlEIW2dmewfF8biXNLbSqQ8gyL
R3n4byBJwNobJn7VByzjPpUDfPsHk3Gn8InpNy1YJekt1OG/DlpV+/dl253Nq9vA
8U0q5/fn6qmfS6RIS+GDv4aQ1KrZ88xlnZBrQ9U4bKhKwat87jfZQ0mxq2ilUpSf
OO2IuKlHre/b9nRBrUgdkoO3XNi1aBR6OnxMqVM5tDZlO+9LbS8eLYfpAXdDLe1h
8Oj6Fy5mURLmMA+my0WnPYEZBqN+7DepjzugDqo6eCROZLMlUEWyBjSMTT95d7u5
n2CX3DHzdn0QMgNSK44kMVUVDAnTSUiTDdXbuW446Q3Q1ouIRSMBXy8PDYpOMMYA
pd3Nzw5Vj+32HWN3gOwXiTa2grY+XnE3SuSksCPvIVkTF0n/yjptcst3fwmMlm/Q
r0DseVPj0eFUngMtnhZV
=JXTO
-END PGP SIGNATURE-


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

Re: Remove photos from OpenPGP key in the keyservers

[Anthony Papillion]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


On 03/08/2016 11:24 AM, Andrew Gallagher wrote:
> On 08/03/16 16:08, Anthony Papillion wrote:
>> 
>> I'm pretty sure that, if you just send your modified key to the 
>> keyserver again, it will replace the one that's there.
> 
> You shouldn't think of a PGP key as a single file that is
> overwritten - it's more like a logbook that is progressively
> filled. Your primary key is the first entry, and each "fact" that
> is associated with the primary key (id, certification, subkey,
> photo) gets appended to the bottom. You can upload a new fact to
> the keyservers, including a fact that repudiates a previous fact,
> but it all just gets appended to the log and it's the client's job
> to sort through it and decide what bits are still relevant.

Thank you, Andrew, for the clarification. I suppose I've never thought
of it that way but, as you explained it, it makes sense. So am I
correct in this thinking: if I attach a picture to my key and upload
it to a keyserver then remove the picture and upload that 'version' of
my key to the server, the key on the server STILL HAS my picture and
the clients choose to ignore it at that point?


-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJW4G/BAAoJEAKK33RTsEsVlAIP/3UfE2WiynAb4igUXWdPdGK1
GobpOLlFXVX2P7XhGUioQWKytARAgMZNY+rNaqY/sG0o8Nmc0I0v/Na81mkp2bDV
y5ykgsiI3h1MkPbacszQTaB9SJTY36GM8QplUR5HfC70rFFZU64rrc6cYGZpms+c
O0oHCiUONKpqu8nPtx2jlBcZVneRj2MCYNr6mLGgGi562Cklws5WHmRckQPYubdI
Pk3Qx8hdmVqHtbvNhk8lDifxd7QumHds56JYHwyBGT4TjIj8bkSp+YqyKLjmr10g
1FTZzW3FP7Hyhy7qg/m45PTuOG7jximiGLngV4F/SspzsEzQPzxKQBu2mstku3AA
V3Rq7bJgw/JyL72G4T6MBtDuN1y1c1agDO7r1MZM6kQz/ndXXLC/NHSYkiy9trjh
NcS/0CKzSq70YgIFe/2AxXGsDYtvCIft5sznSOsreKJh79zdMmF7ILBYlTFTM9jP
26/ipBxEKz1J9e7Tm+ijK+WYA/EKrjhiU3RtWM8sQTlMNZyjwoWTSJiCBz17CwzR
fa+pyyvdyYNm6TMfTEBgpa3yQV88RMdRRlqj62+06x+lwCNOB6+iG+M5NQNdOJ4C
e2sNzXdgcZIYsc5rBIIrEho+z8KUMVcUKO2xDTiWrsHrzORUspomSxi0XyXN8Oy8
ulV2P9Rz8kpTc9KskI2j
=TIee
-END PGP SIGNATURE-


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

Re: Remove photos from OpenPGP key in the keyservers

[Brian Minton]

On 03/08/2016 11:08 AM, Anthony Papillion wrote:
>
> I'm pretty sure that, if you just send your modified key to the
> keyserver again, it will replace the one that's there.
>

I tried it, deleting some subkeys locally, and adding others.  I
submitted it to the keyservers, but now all the keys, old and new, are
on the servers.  GnuPG (and probably other products) will use the newest
subkey for a given purpose (encryption, signing, etc.) if it is usable.
 For instance, I have a key with some ECC keys and some DSA and El Gamal
keys.  GnuPG version 1 will automatically use the newest El Gamal key
for encrypting to my public key.  GnuPG version 2 uses the newest ECC
keys for encrypting to my key (because I created them later).  After
receiving the key from the keyservers (which I did in an isolated
environment), now both gpg 1 and gpg2 use the most recent usable key for
encryption, which is the El Gamal one.

I say all that to say, the keyservers won't replace your existing key,
they only merge.



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

Re: Remove photos from OpenPGP key in the keyservers

[Robert J. Hansen]

> How do keyservers manage DMCA claims?

They go down.

A few years ago Peter Pramberger, a keyserver operator in Austria, had a
request from someone who had uploaded a certificate but was now
asserting their right under EU data privacy directives to have their
personal information removed.  After consulting with legal counsel,
Peter realized the only step he could take would be to shut down his
keyserver.  Otherwise, he'd be hit with large per-day fines for failure
to comply with the user's demand.


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

Re: Remove photos from OpenPGP key in the keyservers

[Andrew Gallagher]

On 08/03/16 16:08, Anthony Papillion wrote:
> 
> I'm pretty sure that, if you just send your modified key to the
> keyserver again, it will replace the one that's there.

You shouldn't think of a PGP key as a single file that is overwritten -
it's more like a logbook that is progressively filled. Your primary key
is the first entry, and each "fact" that is associated with the primary
key (id, certification, subkey, photo) gets appended to the bottom. You
can upload a new fact to the keyservers, including a fact that
repudiates a previous fact, but it all just gets appended to the log and
it's the client's job to sort through it and decide what bits are still
relevant.

A



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

Re: Remove photos from OpenPGP key in the keyservers

[Francesco Ariis]

On Tue, Mar 08, 2016 at 06:00:30PM +0100, Viktor Dick wrote:
> I always wondered what would happen if someone uploaded something to the
> keyservers where he has no permission to do so.

An interesting presentation on the subjest is "Trolling the Web of
Trust" [1] by Micah Lee.

[1] https://github.com/micahflee/trollwot/blob/master/trollwot.pdf

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

Re: Remove photos from OpenPGP key in the keyservers

[Viktor Dick]

On 08.03.2016 16:33, Daniel Kahn Gillmor wrote:
> Sorry, but no.  The keyservers are globally-synced and append-only.  you
> will not be able to remove stuff once it's posted there.

I always wondered what would happen if someone uploaded something to the
keyservers where he has no permission to do so. Maybe some revealing
photograph of someone. It might also be possible to somehow use the
keyservers for file sharing, although it might be difficult to do so
since they probably have a file size limitation. How do keyservers
manage DMCA claims?

Regards,
Viktor



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

Re: Remove photos from OpenPGP key in the keyservers

[Robert J. Hansen]

> I'm pretty sure that, if you just send your modified key to the
> keyserver again, it will replace the one that's there.

This is not correct.


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

Re: Remove photos from OpenPGP key in the keyservers

[Anthony Papillion]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 03/08/2016 05:54 AM, Marco A.G.Pinto wrote:
> Hello!
> 
> I have made the mistake of adding the same photo with different
> file sizes using Enigmail and export it to the servers.
> 
> I have already deleted two of the three photos using the CLI, but
> the key in the server still has three photos and a size of 70 kB.
> 
> Is there anyone I could contact to export this attached public key
> which only has one photo?

I'm pretty sure that, if you just send your modified key to the
keyserver again, it will replace the one that's there.

HTH,
Anthony


-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJW3vjgAAoJEAKK33RTsEsVzFUP/iDugmLIYW4kpFsqnBBvpgBp
uAxywtakdaM6Dzw0IlDBc/ETrlzSPcCqp9KmogbPRPI66WfGW8zHMg9mSe3LD3R3
ZK3bwPEGIDUumFLvTH6d6YRHFq9KVORQGfGBvksWCeD7/TudR11eQRP/freSJOfj
jhIzN10+3b0YAVX+VcrmrGU9vNonK9of67qzpX+WiTCTxQIS1SYfNzJWMCQiy2xX
mVn4IW63AdtGSm1V99Y7RIFmFxr4NfOdXumkHtOEOL5F89XC5kmHfyycSNhiQDZ2
ZFdxRuRLGTXWDOjE+GVI/qCz4CJOvuljBumzYi5RN/PF+gbC0XW9hcp3ia70PBpt
VvGZj9juid1L4Ci3IP8Lwil2jVpHn1k+GHl+8St2ghIlaVJhdZbVGU/0WkwJS9j4
aY+2uLoYnL00RI9eNZoJeQf/cHUXGPq5QTworx1pMQzQIXRsfgsRlYjsqwIiQFPq
JkEvQkguVDfHGTNqEdoeLZXGfAbh6jHdGEVlwVSt9hlJewdakUURrtZXhHAmKUq3
lbAeiMUnTJUV2Cvs0ymaDh1hfonf1zXz4OzWzfdqd9YnIYTh++JMxxenXLYh11EP
PaWuECF2xO0Ryxl/s04koHOYlqUAHitIifHouvdxkl6LBB2HSTx9NcNT4TO1QuBJ
c393PzoAb3yQreKiwoC8
=Zw23
-END PGP SIGNATURE-


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