gnupg-2.2.4: how to deal with failed tests

[Henry]

I finally got gnugp2 built without any fatal errors.
Most of the tests passed, but the following tests failed:
tests/openpgp/issue2346.scm
tests/openpgp/ssh-export.scm
tests/openpgp/export.scm
tests/openpgp/ecc.scm
tests/openpgp/armor.scm

I am not hip on using a binary that fails its tests.
Grateful for any advice on how to configure/build gnupg2 so that
it passes all its tests.

TIA

Henry

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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Dan Kegel]

On Tue, Jan 16, 2018 at 7:37 PM, Robert J. Hansen  wrote:
> * it's not going away in the near future
> * we know people like to use it for servers
> * it's a lot of work to keep two codebases going
> * new crypto, like ECC, will not be backported to 1.4
> * new features will probably not be backported
> * if you need 1.4 support, contact g10 Code GmbH

Thanks.

When I try to use gpg to manipulate secure apt repositories in the
real world, my head explodes.
I'm sure it will all seem reasonable after I figure things out.
I've only been at it off and on for a couple years.
- Dan

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

Re: Will gpg 1.x remain supported for the foreseeable future?

[gnupg]

Robert J. Hansen wrote:

> > Is version 1 going to remain available, I hope?  Version 2 simply
> > seems a poor fit for scripting.
> 
> The game plan has always been to retire 1.4 as soon as practical.  Do
> not rely on it existing in the future.

that's a shame. i hope someone creates a non-gui, non-curses
pinentry program before that happens (that can work inside a
gvim window).

cheers,
raf


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

Re: Will gpg 1.x remain supported for the foreseeable future?

[Robert J. Hansen]

> Is version 1 going to remain available, I hope?  Version 2 simply
> seems a poor fit for scripting.

The game plan has always been to retire 1.4 as soon as practical.  Do
not rely on it existing in the future.

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

Will gpg 1.x remain supported for the foreseeable future?

[Dan Kegel]

Hey all,
I'm starting to suspect that using version 2.x of gnupg is simply not
a good idea when writing shell scripts that have to run unattended
and not touch system keychains or agents.

I worked hard to jump through hoops to use version 2 in such
an environment, but then I ran into the fact that even the latest apt
from debian does not support version 2's keybox format, so I had
to drop back to gpg version 1 anyway.

Is version 1 going to remain available, I hope?  Version 2 simply
seems a poor fit for scripting.

Thanks,
Dan

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

Privacy vs. security

[listo factor via Gnupg-users]

On 01/16/2018 06:05 PM, Andrew Gallagher - andr...@andrewg.com wrote:


Ultimately, the PGP ecosystem prioritises security over privacy. They
are not the same thing, and in some cases they are in conflict.



Somewhat of a generalization, but essentially correct. More
precisely - if I may - it's point of balance between the privacy
and security represents our thinking about the relative importance
of these two categories at the time the system was conceived,
decades ago.

Since that time, our view about the importance of security has
changed very little. Our view about the importance and desirability
of privacy has changed a whole lot.

Consequently, it is time to re-examine the point of balance
between the two.



___
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

DRM

[vedaal]

Robert J. Hansen rjh at sixdemonbag.org wrote on
Tue Jan 16 17:42:29 CET 2018 :
...
>> The mechanism to prove you are the owner of a public key is pretty much
>> in place :-). A mechanism where you can have a signed statement saying
>> "on 2018-01-16, I allow my key to show up on keyservers"

>It is theoretically and practically possible to have a keyserver that
>honors such requests, but what many people want is *enforcement*.  Not
>merely a voluntary system that's trivially circumventable, but some
>mechanism by which their public keys can be actively kept out of
>circulation.

=

It could be done automatically by the keyservers if they wanted to,
and if they made it that *the only way* a Public key can be uploaded to that 
keyserver,
if it were accompanied by a signed statement by that key,  stating " I allow my 
key to show up on keyservers".

Ideally, if this could be done by gnupg by editing the key, much the same as 
editing an e-mail address, it would streamline the process;

i.e. something like this:

gpg --edit-key foo
...
Secret key is available.
...
[ultimate] (1). foo 

gpg> --allow-keyserver-publication

gpg: This requires you to sign that you allow keyserver publication of your 
key, and will be added as a comment to your key.
Do you really want to do this?  Y/N

gpg: Please enter passphrase to sign

gpg;  your key now has a comment  "Keyserver Publication Allowed"

gpg: you may upload this key to any participating keyserver


or something along those lines, assuming that keyservers will abide by this and 
require this 'comment' before accepting a key 


vedaal




___
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: DRM?

[Kristian Fiskerstrand]

On 01/16/2018 10:33 PM, Matthias Mansfeld wrote:
> On 16 Jan 2018 at 20:08, Kristian Fiskerstrand wrote:
> 
>> On 01/16/2018 07:50 PM, Andrew Gallagher wrote:
>>> Agreed. I was thinking more along the lines of having some method of
>>> causing signature vandalism to expire.
>> They don't really constitute an issue either for security or privacy,
>> though. 
> They DO, if unwanted or rashly made signatures on pubkeys disclose 
> connections between people, groups etc..

by "vandalism", I'm taking trollwot cases into account, which doesn't
affect anything to the extent it is DoS-able.

-- 

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

"Happiness in intelligent people is the rarest thing I know."
(Ernest Hemingway)



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

Re: Remove public key from keyserver

[Kristian Fiskerstrand]

On 01/16/2018 11:40 AM, Stefan Claas wrote:
> Am 16.01.2018 um 11:12 schrieb Kristian Fiskerstrand:
> 
>> On 01/15/2018 09:23 PM, Stefan Claas wrote:
>>> No? I for one would like to be sure that i am the only person who
>>> can upload my public key to a key server directory.
>> This seems to be based on a misconception whereby you're attributing
>> properties of a certificate authority to the keyservers. OpenPGP already
>> has a method for certification from CAs, and that is by providing a
>> signature on the appropriate UID on the public keyblock. As long as the
>> signature is propagated on the keyserver network, these roles can be
>> appropriately isolated and the decision of whether or not to trust a
>> specific CA is left to the user performing the trust calculation,
>> incidentally also allowing for signatures from multiple CAs.
>>
> I'm not sure what you are talking about, a language barrier from my
> side,sorry.
> 
> The CA in Germany (Governikus) i have used sends me my certified key
> back to my
> email address and does not publish my pub key on key servers.

I'm not sure how to put it more clearly, but this seems to bring the
discussion into very specific territory. OpenPGP as a specification
handles this nicely, and whether a CA signature is published publicly or
not doesn't change the modus operandus.


-- 

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

"The best way to predict the future is to invent it"
(Alan Kay)



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

Re: Remove public key from keyserver

[Kristian Fiskerstrand]

On 01/16/2018 08:37 PM, Stefan Claas wrote:
>> I know, but keybase.io's goal is (or was, back when I tested it) to
>> use those connections to somehow prove an identity.  It is a neat
>> idea for the facebook generation.  Privacy is something different.
> Agreed. But the word privacy would then also mean to me that
> users who uploaded their public keys on key servers would not
> reveal that they know each other as shown with their signatures,
> which the classical WoT somehow requires, instead of using local sigs. 
> 

A distinction need to be made here, "know each other" actually means
ever having confidence that the public keyblock belongs to that person.
That doesn't imply a very deep relationship except for having met at one
point to exchange information. You don't really attribute anything
except possibly having looked at a governmental issued ID at some point.

But yes, this comes back to security != privacy

-- 

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

qui tacet consentire videtur
He who is silent is taken to agree



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

Re: DRM?

[Matthias Mansfeld]

On 16 Jan 2018 at 20:08, Kristian Fiskerstrand wrote:

> On 01/16/2018 07:50 PM, Andrew Gallagher wrote:
> > Agreed. I was thinking more along the lines of having some method of
> > causing signature vandalism to expire.
> 
> They don't really constitute an issue either for security or privacy,
> though. 

They DO, if unwanted or rashly made signatures on pubkeys disclose 
connections between people, groups etc..

Regards
Matthias
--
OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc
Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF


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

Re: a step in the right direction

[Duane Whitty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18-01-16 10:54 AM, Robert J. Hansen wrote:
>> (Oh, by the way, usually when I talk about DRM, I'm talking about
>> giving somebody data but restricting the ways in which they can
>> use that data. It's not clear to me how DRM applies when you want
>> to simply not give data at all, to anybody. But this is not
>> really pertinent to the discussion, so never mind.)
> 
> I was the one who brought up DRM.
> 
> What Stefan and Listo want is some mechanism by which, if I have a
> copy of their public key, I can be prohibited from sharing that
> with a keyserver.  How I get to use data in my possession is
> controlled by a third party -- that's DRM.  In this case it's a
> voluntary, half-assed DRM scheme, but it's still in the family of
> DRM schemes.
> 
> 
> 
> 
> ___ Gnupg-users mailing
> list Gnupg-users@gnupg.org 
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
Maybe something akin to patent law here would work better than a
technological solution.  Once you share something it is public unless
you force the the receiving party to sign a non-disclosure document.

Once you share your public key with even one person it is in the
public domain.  If you want to make it painful enough to prevent this
from happening have the receiving party sign a contract of
non-disclosure which stipulates what the penalties will be if the
break the contract.  Just my two cents and I'm sure it doesn't cover
everything.



Best Regards,
Duane

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

iQEcBAEBCAAGBQJaXlCfAAoJEOJfpr8UVxtkwgsH/3V+ZCc839yIENQDgp/Z7/Yj
3TVRRw/ELswj9emAebtIMiY5EYvQp3zhL71sTnXq8+ez0k2oc68ow4oxnwpl+9K1
psQiPVm45ouQlBlS9YJ6O8KBQRFARmP3fDt+JAwQ9a/PJRfqefdk93gVM89T+9VM
V6NzkR9ktyokNmKhKi48oVXIVw2XX2DG2fuspI2QwZLqtt0PxmGdDuyiWmFZKigW
mWU3evTAkzQtslsppVNenJjZjrz7XIqt/xq/CEf/PgfreeY+g7chm+fzpdvSuTMu
9hJWOkXBTx+W40/5GbLyzpSYlKcUyu8evrN8Z9Uo5CtX0E+c30cCQ0auLkPKV8o=
=KRTM
-END PGP SIGNATURE-

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

Re: DRM?

[James R Cutler]

Can anyone explain in the context of this discussion just what “public” in 
“public key” is supposed to mean explicitly and implicitly?

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

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

Re: WKD was Remove public key from keyserver

[Stefan Claas]

On Tue, 16 Jan 2018 19:51:17 +0100, Werner Koch wrote:

> We definitely want to refine some things there but that requires a
> wider deployment.

I will for sure follow the WKD development and hope that also more
mail providers will offer a WKD service.
 
> > i have with posteo's WKD implementation is that their policy is
> > pretty strict, which i personally don't like and i told them so. I
> > would like  
> 
> Posteo does only allows the mail address (addr-spec) and no real name
> in the key for data protection reasons.  Thus a
> 
>  $ wget -O- posteo.de/.well-known/openpgpkey/policy 2>/dev/null
>  # Policy for draft-koch-openpgp-webkey-service-04
>  mailbox-only
>  auth-submit
> 
> shows this policy flag.  If you upload your key using a tool employing
> gpg-wks-client (e.g. Kmail or Enigmail) this policy will be detected
> and if a plain addr-spec only user0id does not exists a new user-id
> will be created and sent to posteo.
> 
> The real problem with Posteo is that they use invalid certificates for
> all but the posteo.de domain.  Thus my posteo.net account does not
> work because they redirect to posteo.de but do not include posteo.net
> in the certificate for the initial access to posteo.net.  Bummer.

Thanks for the information, much appreciated!

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: Remove public key from keyserver

[Stefan Claas]

On Tue, 16 Jan 2018 19:36:30 +0100, Werner Koch wrote:
> On Tue, 16 Jan 2018 16:34, stefan.cl...@posteo.de said:
> 
> > the public key. He / she is not forced to provide any identity via
> > other web sites etc. Doing this is a method they have implemented
> > as sort  
> 
> I know, but keybase.io's goal is (or was, back when I tested it) to
> use those connections to somehow prove an identity.  It is a neat
> idea for the facebook generation.  Privacy is something different.

Agreed. But the word privacy would then also mean to me that
users who uploaded their public keys on key servers would not
reveal that they know each other as shown with their signatures,
which the classical WoT somehow requires, instead of using local sigs. 

> > Why do i prefer keybase.io over the old key server system? Because
> > i am in control of my public key there, so that nobody can do
> > funny  
> 
> They are in control of your key - not you.  You can ask them to do
> something without key but in the end the owners of this service decide
> what they allow you to do and what key they want to publish or stop
> publishing.  Or to shutdown their service.
> 
> Compare that to the keyservers: They have been around for 25 years and
> you can still find all keys ever uploaded there (I am not sure whether
> PGP 2.3 keys are still supported, though).  There is no single entity
> controlling this network.

To me this seems to be the only advantage that the network can't be
controlled. If IMHO key removal by the owner and upload only by the
owner could be implemented in the future than that would pretty
nice.

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: DRM?

[Kristian Fiskerstrand]

On 01/16/2018 07:50 PM, Andrew Gallagher wrote:
> Agreed. I was thinking more along the lines of having some method of
> causing signature vandalism to expire.

They don't really constitute an issue either for security or privacy,
though. If looking at keyserver directly (which you really shouldn't do,
your client will filter unknown keys and actually verify the rest) you
will see all kinds of interesting things like the Christmas present of
["funny sks"] on my keyblock some years ago. But it doesn't constitute
an *issue* when OpenPGP is used correctly.

References:
["funny sks"]
https://sks-keyservers.net/pks/lookup?op=vindex=0x94CBAFDD30345109561835AA0B7F8B60E3EDFAE3
-- 

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

"A committee is a group that keeps minutes and loses hours."
(Milton Berle)



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

Re: DRM?

[Andrew Gallagher]

> On 16 Jan 2018, at 18:15, Kristian Fiskerstrand 
>  wrote:
> 
>> On 01/16/2018 07:12 PM, Andrew Gallagher wrote:
>>> On 16/01/18 17:19, Leo Gaspard wrote:
>>> “on 2018-04-01, please expose only the master key and its revocation
>>> certificate(s) to clients”
>> 
>> IF you wanted to go this route, it would be easier for keyservers to
>> only serve the master key + revocation cert for *all* cases where a
>> revocation cert exists. What does it matter who signed a key that has
>> been revoked, or what IDs it used to be tied to? It's dead, throw it away.
> 
> The important thing would actually be that the data is retained in the
> database, as that wouldn't break sync.

Yes, absolutely. This would be a presentational fix. It would also be a method 
of giving people a way around right to be forgotten - revoke your cert and your 
info becomes more or less unsearchable. 

> this is within the scope of feasibility,
> although wouldn't do anything one way or the other with regards to
> security. Whether it would help privacy is also a questionable matter,
> as the full data store is downloadable, so anyone can download it
> containing the data wanting to be hidden.

Agreed. I was thinking more along the lines of having some method of causing 
signature vandalism to expire.  

A

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

Re: Remove public key from keyserver

[Werner Koch]

On Tue, 16 Jan 2018 16:34, stefan.cl...@posteo.de said:

> the public key. He / she is not forced to provide any identity via other
> web sites etc. Doing this is a method they have implemented as sort

I know, but keybase.io's goal is (or was, back when I tested it) to use
those connections to somehow prove an identity.  It is a neat idea for
the facebook generation.  Privacy is something different.

> Why do i prefer keybase.io over the old key server system? Because
> i am in control of my public key there, so that nobody can do funny

They are in control of your key - not you.  You can ask them to do
something without key but in the end the owners of this service decide
what they allow you to do and what key they want to publish or stop
publishing.  Or to shutdown their service.

Compare that to the keyservers: They have been around for 25 years and
you can still find all keys ever uploaded there (I am not sure whether
PGP 2.3 keys are still supported, though).  There is no single entity
controlling this network.

> Understood, but what speaks against a (syncing) public key server
> system like the old pgp.com key server was, compared to the regular

As Robert already noted: The pgp.com keyserver was a single database
under the control of one entity which did for technical reasons not
syncing with the keyserver network.  IIRC, in the early days Randy
sometimes uploaded keys to the keyserver network but never imported
keys.  


Shalom-Salam,

   Werner

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


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

Re: DRM?

[Kristian Fiskerstrand]

On 01/16/2018 07:17 PM, Leo Gaspard wrote:
> That said, thanks for the link! Just curious, I never saw information
> about this in enigmail, do you know whether it has been implemented yet?

First and foremost you'd have to establish the robot-ca with an API of
some sort. I'm not aware of any production rollout, although I believe a
proof of concept was written based on it for a thesis.

-- 

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

"A government that robs Peter to pay Paul can always depend on the
support of Paul."
(George Bernard Shaw)



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

Re: DRM?

[Kristian Fiskerstrand]

On 01/16/2018 07:12 PM, Andrew Gallagher wrote:
> On 16/01/18 17:19, Leo Gaspard wrote:
>> “on 2018-04-01, please expose only the master key and its revocation
>> certificate(s) to clients”
> 
> IF you wanted to go this route, it would be easier for keyservers to
> only serve the master key + revocation cert for *all* cases where a
> revocation cert exists. What does it matter who signed a key that has
> been revoked, or what IDs it used to be tied to? It's dead, throw it away.

The important thing would actually be that the data is retained in the
database, as that wouldn't break sync. Aside from that the keyservers
would have to implement cryptography and verify that the revocation
certificate is accurate, this is within the scope of feasibility,
although wouldn't do anything one way or the other with regards to
security. Whether it would help privacy is also a questionable matter,
as the full data store is downloadable, so anyone can download it
containing the data wanting to be hidden.

-- 

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

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

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



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

Re: DRM?

[Andrew Gallagher]

On 16/01/18 17:19, Leo Gaspard wrote:
> Well, if such requests were honored, this would fix the OP's answer (ie.
> “how do I hide the fact I mistakenly associated two unrelated UIDs on my
> key”, if I understood correctly), as well as requests pertaining to the
> EU's “right to be forgotten”

The right to be forgotten is not absolute. For example, it does not
require that published news be unpublished, although it does sometimes
ask that published news not show up in search results. It also does not
require that search engine operators scrub their internal databases.

It is technically difficult to prevent keys from being propagated
because altering or deleting data packets breaks the assumptions upon
which the reconciliation algorithm is founded. But there is nothing to
stop individual servers from scrubbing search results of keys that have
a valid "nopublish cert" (however this may be technically implemented).
This would not affect SKS reconciliation and would reduce the
computational overhead.

IF something like this were to be implemented, then only searches for
IDs should be stripped. Searches on fingerprints should always return
data, in order to ensure that revocation certificates are still
distributed. "Nopublish" certs could also be used by well-behaved
clients as a guard against accidental disclosure, even if preventing
malicious disclosure is technically impossible.

If we were worried about the *legal* implications of right to be
forgotten, then this could be a defensible fallback position. But it is
not a solution to many of the *practical* problems in privacy protection.

Ultimately, the PGP ecosystem prioritises security over privacy. They
are not the same thing, and in some cases they are in conflict.

-- 
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: DRM?

[Kristian Fiskerstrand]

On 01/16/2018 06:19 PM, Leo Gaspard wrote:
> Also, there are flaws with this approach (like after a private key
> compromise, it would allow to prevent dissemination of the revocation
> certificate) [1], but fixes like allowing the statement to be “on
> 2018-04-01, please expose only the master key and its revocation
> certificate(s) to clients” would likely handle this particular issue.
> 
> All I'm saying is that a system like this one is not a silver bullet
> solution, but may handle a few of the current complaints against the SKS
> network?

Not really (and that is ignoring disagreement with the complaints to
begin with).

One issue with the first statement "please allow to be on keyserver" is
that it doesn't provide any verification that the email in UID (or just
the name) is accurate, so most of the complains regarding occurrence of
multiple matches for a search would not be honored, as you could anyways
create multiple keyblocks with this property.

To answer that request for feature, you need to make the keyserver a
de-facto CA instead of separating the roles, and performing some ID
verification at upload point, for email this might be a simple
robot-signing, but email addresses changes over time, and a key might be
relevant even after changing email providers to verify historical
signatures etc.

But for OpenPGP this isn't an issue to begin with. No keyblock should be
used without first verifying the material, which historically is mostly
done through fingerprint exchanges / key signing parties. If wanting to
introduce a CA in the system, nothing is stopping you, and you will find
some discussion on robo-signers etc e.g at [0], but it doesn't require
any changes on the keyserver side, exactly because that is just a data
store and distribution point without any other responsibility.

Obviously the same goes for a TOFU model and WKD, which still can use
the keyserver network as distribution point for updates of
expirations/revocations/etc...


References:
[0]
https://wiki.gnupg.org/OpenPGPEmailSummit201512/EmailValidation?action=AttachFile=get=EmailValidation20151207.pdf
-- 

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

Aut dosce, aut disce, aut discede
Either teach, or study, or leave



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

Re: DRM?

[Leo Gaspard]

On 01/16/2018 05:42 PM, Robert J. Hansen wrote:
>> The mechanism to prove you are the owner of a public key is pretty much
>> in place :-). A mechanism where you can have a signed statement saying
>> "on 2018-01-16, I allow my key to show up on keyservers"
> 
> It is theoretically and practically possible to have a keyserver that
> honors such requests, but what many people want is *enforcement*.  Not
> merely a voluntary system that's trivially circumventable, but some
> mechanism by which their public keys can be actively kept out of
> circulation.

Well, if such requests were honored, this would fix the OP's answer (ie.
“how do I hide the fact I mistakenly associated two unrelated UIDs on my
key”, if I understood correctly), as well as requests pertaining to the
EU's “right to be forgotten” (modulo people who would have lost their
private key and still claim this right, but I guess the extraordinary
measures taken for the last time it was invoked would still be possible).

So that's at least a good part of the current problem solved, I think --
though obviously nothing close to the nightmare scenario or people
wanting to DRM their keys.

Also, there are flaws with this approach (like after a private key
compromise, it would allow to prevent dissemination of the revocation
certificate) [1], but fixes like allowing the statement to be “on
2018-04-01, please expose only the master key and its revocation
certificate(s) to clients” would likely handle this particular issue.

All I'm saying is that a system like this one is not a silver bullet
solution, but may handle a few of the current complaints against the SKS
network?


[1] It looks like Kristian has written more about it during my typing
this mail if I can guess from Peter's answer, though Kristian's mail
didn't land in my mailbox yet.

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

Re: DRM?

[Peter Lebbing]

On 16/01/18 17:42, Robert J. Hansen wrote:
> [...] what many people want is *enforcement*.

Now, /that/ would be DRM, I agree. I just considered "what
well-configured keyservers in the keyserver pool should do" as the
boundary of the problem statement. Just like a well-configured webserver
will not change their homepage when a random person on the internet asks
for it.

Cheers,

Peter.

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



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

Re: DRM?

[Peter Lebbing]

On 16/01/18 17:47, Kristian Fiskerstrand wrote:
> I'm somewhat interested in hearing how this scheme would work in the
> case of a compromised private key. Mainly;

I was merely using the description of the basics of it as a means to
show how it would be access control rather than DRM. All the thorny
extra issues I never even seriously considered is part of why I also
said "I'm not saying this is the way to go."

> (iii) iff (ii)(a) and (ii)(b) differ; how would you handle a sync
> conflict of said data?

Sounds really, really difficult to solve. Perhaps impossible? Since I'm
not advocating implementing this in the first case, I'm not spending
many computation cycles on the issue either :-). It might be there is an
imperfect but acceptable solution, though. The problem with that is
again litigation: "What do you mean, you can't remove me? You have a
removal feature! See you in court!"

Cheers,

Peter.

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



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

Re: DRM?

[Robert J. Hansen]

> The mechanism to prove you are the owner of a public key is pretty much
> in place :-). A mechanism where you can have a signed statement saying
> "on 2018-01-16, I allow my key to show up on keyservers"

It is theoretically and practically possible to have a keyserver that
honors such requests, but what many people want is *enforcement*.  Not
merely a voluntary system that's trivially circumventable, but some
mechanism by which their public keys can be actively kept out of
circulation.



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

Re: a step in the right direction

[Robert J. Hansen]

> while i agree with rjh that destruction of the current SKS-based
> keyserver network (either by technical or legal means) would today be a
> net loss, this statement goes too far.

I welcome the correction, but I stand by my statement.  Many users,
particularly in corporate environments, roll their own packages and rely
on the keyservers to propagate those signing keys worldwide.  I know
I've seen RHEL corporate networks doing this; I _believe_ I've seen
Ubuntu-based corporate networks doing this.  (Back in 2016 I wound up
doing just this task for an RHEL network, while my officemate handled
the Ubuntu machines -- I have no hands-on experience with the Ubuntu
side of things, just recollections of hearing my officemate talk about
them.)

It is correct, though, to say official Debian packages would have
minimal disruption.  Thank you.  :)



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

Re: a step in the right direction

[Daniel Kahn Gillmor]

On Mon 2018-01-15 17:45:49 -0500, Robert J. Hansen wrote:
> _Literally every major FOSS package manager breaks.  Updates become
> impossible._

while i agree with rjh that destruction of the current SKS-based
keyserver network (either by technical or legal means) would today be a
net loss, this statement goes too far.

the debian package manager does not directly use the keyserver network,
and debian archive signing keys are themselves distributed as debian
packages.

the keyservers can occasionally be used as a way to find updated keys
for a system that has been offline for years, to "re-bootstrap" the
package manager, but dpkg and apt are certainly not reliant on the
keyserver network to do their thing.

Third-party repositories also do not need the keyservers to function
properly, if they're configured in a sensible way:

https://wiki.debian.org/DebianRepository/UseThirdParty

Regards,

--dkg


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

Re: Remove public key from keyserver

[Robert J. Hansen]

> Understood, but what speaks against a (syncing) public key server
> system like the old pgp.com key server was, compared to the regular
> key servers, which don't allow deletion of a key, by the owner and if
> i remember correctly also only upload by the owner.

The pgp.com keyserver had some serious problems.  When I was at PGP
Security there were at least three engineers on the floor -- myself, Len
Sassaman, and Randy Harmon (the keyserver admin!) -- who thought the
keyserver was a pretty marginal idea specifically because we could be
compelled by governments to do unpleasant things.  None of us used that
keyserver in our own personal lives.

The pgp.com keyserver is also a *standalone* server.  It does not sync
with the keyserver network.  (Search for 0xB44427C7, for instance.  My
cert has been in the SKS network for years, but as of this writing isn't
in the pgp.com keyserver.)  That's important for several reasons.  It
means it's very easy for governments to blackhole, for instance.  And it
also means it's possible to drop certificates.

One of the other reasons SKS doesn't allow dropping information is
because it lets two disagreeing keyservers figure out very easily what
the canonical and correct data is: it is the union of the disparate
data.  As soon as you change this to allow for discarding data, suddenly
each certificate needs to bear with it some way to prove to other
keyservers that it's the most recent record and thus correct.  Now you
get into needing trusted timestamps, certifications of changes, adding
crypto code into SKS, and ... things get out of hand quickly.

If you like the PGP Global Directory, go for it.  Use it!  It still exists.

But please, understand why SKS works the way it does before telling
people to change it.

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

Re: "right to be forgotten" nonsense

[Phil Susi]

On 1/15/2018 10:24 PM, listo factor via Gnupg-users wrote:
> If there is merit to the principle that an Internet server operator
> can not keep publicly serving private data over the objections of
> the owner (the same as today, after many battles, he can no longer

There isn't merit.  It became public, not private, the moment you
published it.  I have the right to free speech, the EU be damned.  Are
these numbnuts going to demand that libraries black out newspaper
articles on microfilm because they mention someone that doesn't like the
coverage of themselves?  Sure, I molested children 5 years ago, but I
have the "right to be forgotten" so when anyone searches for my name on
the Internet they won't find out.  Give me a break.


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

WKD was Remove public key from keyserver

[Stefan Claas]

On Tue, 16 Jan 2018 08:52:44 +0100, Werner Koch wrote:
> On Mon, 15 Jan 2018 20:21, stefan.cl...@posteo.de said:
> 
> > O.k. Werner invented WKD which solves those problems, if i'm not
> > mistaken, but is it besides keybase.io widely deployed?  
> 
> Nope.  The Web Key Directory solves exactly one problem: How to
> initially map a mail address to a key.  This directory is hosted by
> the provider of the mail address because that is the only entity which
> controls the mail address.  

O.k. thanks for the clarification!

> Once this mail address has been mapped  keyservers can be used to get
> revocations and updates of the key.

This part i do not understand... i send the rev cert or my updated key
again to WKD and then i can search a regular key server for the updated
key?

> Unfortunately it is not yet widely supported; you can help to make it
> better known.

Well, i really would like to promote WKD at other places. The problem
i have with posteo's WKD implementation is that their policy is pretty
strict, which i personally don't like and i told them so. I would like
to see a mail provider using WKD which allows the user to use his
certified key.

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: Remove public key from keyserver

[Robert J. Hansen]

> O.K. than it is a feature request. You also triggered something in me
> with the words "which you think belongs to you".

That's because you think information *does* belong to you.  But
information doesn't belong to anyone: the nature of information is that
it has no owners.  You can place restrictions on what people do with
information -- maybe -- but you can't make information into a possession
any more than you can declare you own mathematics.

The fact an EU committee has declared otherwise strikes me as like the
legend of King Canute.  When his advisers told him his power was without
limit, Canute took them to the ocean and let them watch as he ordered
the tide to not come in.  The tide came in anyway, thus proving Canute's
point to his advisers -- just because they say it's so doesn't mean it's so.

None of this is to say you have no privacy interest in your data, nor
that our laws shouldn't facilitate you having some control over your
private data.  But our laws also shouldn't be written in such a way as
to lead people to think they can *own* information.

> If i am not mistaken you have also a keybase account

Yep.

> How about this; let's make "your" public key the ideal canditate for a
> global trollwot session, were every GnuPG Linux user can participate
> and add some funny things to "your" public key.

You seem to be under the belief I don't see this as a problem.  As a
quick check in the archives will show you, I've been talking about this
problem for at least eight years.  And I know Werner's been dealing with
this problem for even longer.

Just because I think you understand neither the problem nor the deeply
problematic aspects of your proposed fixes, does not mean I disagree
there's a problem.

> This would imho give you and people you talk to in conferences etc.
> also a better view what i am talking about.

I already know exactly what you're concerned about.  I share in those
concerns.  I do not believe you're contributing to finding an answer to
these problems.

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

Re: Remove public key from keyserver

[Stefan Claas]

On Tue, 16 Jan 2018 08:52:44 +0100, Werner Koch wrote:

> I wonder why you seem to suggest the US based keybase.io as a better
> solution.  After all keybase.io is a service which connects private
> data to private data of other sites and that all in the public.  I
> would consider this a real privacy problem compared to a public mail
> address on a keyserver with no other associated private data.

(sorry for the late reply, i did not see this message this morning)

Well, it is up to the user what he / she publishes on keybase.io besides
the public key. He / she is not forced to provide any identity via other
web sites etc. Doing this is a method they have implemented as sort
of another way of a web of trust, so to speak.

Why do i prefer keybase.io over the old key server system? Because
i am in control of my public key there, so that nobody can do funny
things with my key, like it is possible with the old key servers. If
people would like to sign my key they would have to provide me
my signed key so that i can upload it to keybase and not like the
other way the old key servers let people do, without my approval
first.

> The mail address is a technical necessity to send mail; mapping the
> mail address to a key is a technical necessity to send encrypted
> mail.  So what keyservers do is to provide a directory of public keys
> - in the same way as white pages of the phone systems.  Nobody
> requires you to enter you phone number / public key into a
> directory.  But if you want to receive phone calls / encrypted mails
> you need to somehow publish this data.  You can't remove your name
> from white pages either - they used to be printed in sometimes
> millions of copies.

Understood, but what speaks against a (syncing) public key server
system like the old pgp.com key server was, compared to the regular
key servers, which don't allow deletion of a key, by the owner and if
i remember correctly also only upload by the owner.

As it is of now with SKS and Co. i think in 2018 such a key server
model does not help for a clean database, which everybody can
look up, nor does it help users to protect their keys nor deleting
their keys, in case they like to do so.

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: a step in the right direction

[Robert J. Hansen]

> (Oh, by the way, usually when I talk about DRM, I'm talking about giving
> somebody data but restricting the ways in which they can use that data.
> It's not clear to me how DRM applies when you want to simply not give
> data at all, to anybody. But this is not really pertinent to the
> discussion, so never mind.)

I was the one who brought up DRM.

What Stefan and Listo want is some mechanism by which, if I have a copy
of their public key, I can be prohibited from sharing that with a
keyserver.  How I get to use data in my possession is controlled by a
third party -- that's DRM.  In this case it's a voluntary, half-assed
DRM scheme, but it's still in the family of DRM schemes.




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

My MISTAKE! not a bug Re: BUG report gnupg-2.2.4 (or npth)

[Henry]

I'm very, very sorry to have wasted people's time.
The problem was that I configured GNUpth incorrectly.
I used "enable-pthread option when I should have done the
opposite, disable.

Many apologies,

Henry

2018-01-15 10:47 GMT+09:00 NIIBE Yutaka :
> Hello,
>
> I think that you have some different Pthread library in /usr/local.
>
> Henry  wrote:
>> /usr/local/include/pthread.h:357:18: error: conflicting types for
>   ^^^
>
> I wonder if you have installed GNU Pth.  Please try without Pth.
> --

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

Re: a step in the right direction

[Stefan Claas]

Am 16.01.2018 um 13:38 schrieb Andrew Gallagher:


On 16/01/18 12:34, Stefan Claas wrote:

I don't know if such software already exists but how about using key
servers
as message storing/retrival system, so that people can avoid the classic
smtp
route for their PGP encrypted messages. Well, just a thought...

Isn't that called USENET?
Yes, something like Usenet's alt.anonymous.messages, for people who 
don't know

or have Usenet access.

Regards
Stefan


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

Re: a step in the right direction

[Andrew Gallagher]

On 16/01/18 12:34, Stefan Claas wrote:
> I don't know if such software already exists but how about using key
> servers
> as message storing/retrival system, so that people can avoid the classic
> smtp
> route for their PGP encrypted messages. Well, just a thought...

Isn't that called USENET?

-- 
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: a step in the right direction

[Stefan Claas]

Am 16.01.2018 um 12:51 schrieb Andrew Gallagher:



So we have to distinguish between what is available if one is
sufficiently motivated to go and look, and what is shown to the majority
of users. The vandalism problem is solved by clients not displaying
unverified content. Whereas the "nightmare scenario" happens entirely
out of view of the average user, but has more serious consequences.
Let's not mix them up.

There might be also another problem in the future, not for GnuPG users, but
for key servers.

I don't know if such software already exists but how about using key servers
as message storing/retrival system, so that people can avoid the classic 
smtp

route for their PGP encrypted messages. Well, just a thought...

Regards
Stefan


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

Re: a step in the right direction

[Andrew Gallagher]

On 16/01/18 10:57, Stefan Claas wrote:
> And do people always look into blockchain data, when using their wallet to
> do transactions? With public WWW key servers it is imho different.

This is an important distinction.

Ordinary users should not be browsing the raw data. They should be using
tools such as Enigmail that filter out unverified data from their
default views. Sure, if you want to go looking for all the junk
signatures on people's keys you can, but it shouldn't be displayed as a
matter of course.

Now, for various reasons a lot of us on this list have spent far too
much of our lives looking at the raw keyserver data. And similarly, I
have no doubt that a lot of early Bitcoin adopters have looked at the
raw blockchain data.

So we have to distinguish between what is available if one is
sufficiently motivated to go and look, and what is shown to the majority
of users. The vandalism problem is solved by clients not displaying
unverified content. Whereas the "nightmare scenario" happens entirely
out of view of the average user, but has more serious consequences.
Let's not mix them up.

-- 
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: a step in the right direction

[Stefan Claas]

Am 16.01.2018 um 11:35 schrieb Peter Lebbing:


On 16/01/18 04:24, listo factor via Gnupg-users wrote:

Considering the possibility that this particular system will
be forced to conform to a more contemporary (and I would argue
more enlightened) legislative framework in respect to the right to
privacy (cf., https://en.wikipedia.org/wiki/Right_to_be_forgotten)

So how about I insert some private information of somebody into the
"more contemporary" Bitcoin blockchain. Would you advocate that
everybody removes copies of the blockchain? Wouldn't that mean an end to
Bitcoin?



The blockchain is not anonymous and the origin can be traced back, right?
And do people always look into blockchain data, when using their wallet to
do transactions? With public WWW key servers it is imho different.

Regards
Stefan

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

Re: Remove public key from keyserver

[Stefan Claas]

Am 16.01.2018 um 11:12 schrieb Kristian Fiskerstrand:


On 01/15/2018 09:23 PM, Stefan Claas wrote:

No? I for one would like to be sure that i am the only person who
can upload my public key to a key server directory.

This seems to be based on a misconception whereby you're attributing
properties of a certificate authority to the keyservers. OpenPGP already
has a method for certification from CAs, and that is by providing a
signature on the appropriate UID on the public keyblock. As long as the
signature is propagated on the keyserver network, these roles can be
appropriately isolated and the decision of whether or not to trust a
specific CA is left to the user performing the trust calculation,
incidentally also allowing for signatures from multiple CAs.

I'm not sure what you are talking about, a language barrier from my 
side,sorry.


The CA in Germany (Governikus) i have used sends me my certified key 
back to my

email address and does not publish my pub key on key servers.

Regards
Stefan

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

Re: a step in the right direction

[Peter Lebbing]

On 16/01/18 04:24, listo factor via Gnupg-users wrote:
> Considering the possibility that this particular system will
> be forced to conform to a more contemporary (and I would argue
> more enlightened) legislative framework in respect to the right to
> privacy (cf., https://en.wikipedia.org/wiki/Right_to_be_forgotten)

So how about I insert some private information of somebody into the
"more contemporary" Bitcoin blockchain. Would you advocate that
everybody removes copies of the blockchain? Wouldn't that mean an end to
Bitcoin?

Or do you consider blockchains to be outmoded technology from a
different era? Just kidding :-).

> then it is not unreasonable to assume that most enlightened
> jurisdictions will sooner or later enact such legislation. Yes, it
> is DRM, but in my view ethically much more justifiable than DRM over
> the data of commercial value.

What about those enlightened jurisdictions where anything not conforming
to a strict interpretation of the local major religion is forbidden?
Should country A get to forbid anything that is not directly conforming
to religion 1 and country B forbid anything not conforming to religion
2, and this world-wide? Perhaps then we can use all those high-bandwidth
links to exchange nothing but kitten pictures... provided there isn't a
religion forbidding the depiction of animals.

Why would you honour the EU's request to purge unwanted information from
the internet world-wide, but not honour country A and B? Who decides
what is "ethically justifiable" and what not? Do we need a world-wide
vote on which commission is the most enlightened to decide this? Would
such a vote require a majority, a large majority or be unanimous? And
who decides these parameters anyway? And when there's a radical regime
change somewhere in the world, do we go back to the drawing board?

(Oh, by the way, usually when I talk about DRM, I'm talking about giving
somebody data but restricting the ways in which they can use that data.
It's not clear to me how DRM applies when you want to simply not give
data at all, to anybody. But this is not really pertinent to the
discussion, so never mind.)

Peter.

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



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

Re: Remove public key from keyserver

[Kristian Fiskerstrand]

On 01/15/2018 09:23 PM, Stefan Claas wrote:
> No? I for one would like to be sure that i am the only person who
> can upload my public key to a key server directory.

This seems to be based on a misconception whereby you're attributing
properties of a certificate authority to the keyservers. OpenPGP already
has a method for certification from CAs, and that is by providing a
signature on the appropriate UID on the public keyblock. As long as the
signature is propagated on the keyserver network, these roles can be
appropriately isolated and the decision of whether or not to trust a
specific CA is left to the user performing the trust calculation,
incidentally also allowing for signatures from multiple CAs.

-- 

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

Fabricando fit faber
Practice makes perfect



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

Re: Remove public key from keyserver

[Stefan Claas]

Am 16.01.2018 um 10:18 schrieb Werner Koch:


On Tue, 16 Jan 2018 09:46, stefan.cl...@posteo.de said:


and add some funny things to "your" public key. This would be
also interesting to see how many signatures a public key can bear.

You may look at my key to see funny things and thousands of key
signatures from made up users.  They print a messges if viewed in a
keyserver listing.

Right, these key signatures allow for a DoS and eventually we should do
something about them.  As of now I resort to

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

to keep my _local_ copy of the key at a reasonable size.

I have read also once on Wikipedia about that a DoS is possible,
but the Wiki Artikel gives no figures on how much Signatures are
needed to carry out such an attack.

And what would be your proposal to eventually circumwent this?

Regards
Stefan

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

Re: Remove public key from keyserver

[Werner Koch]

On Tue, 16 Jan 2018 09:46, stefan.cl...@posteo.de said:

> and add some funny things to "your" public key. This would be
> also interesting to see how many signatures a public key can bear.

You may look at my key to see funny things and thousands of key
signatures from made up users.  They print a messges if viewed in a
keyserver listing.

Right, these key signatures allow for a DoS and eventually we should do
something about them.  As of now I resort to

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

to keep my _local_ copy of the key at a reasonable size.



Salam-Shalom,

   Werner

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


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

Re: a step in the right direction

[Leo Gaspard]

On 01/16/2018 09:20 AM, Robert J. Hansen wrote:>> should not be viewed
as "discussing a [...] nightmare scenario",
> 
> I am darkly amused at someone who has not done the research into what
> the nightmare scenario *is* telling me that it's not a nightmare scenario.
> 
> The nightmare scenario is malcontents realize the keyserver network is a
> multijurisdictional, redundant, distributed database from which data
> cannot be deleted... and decide this makes it an ideal way to distribute
> child porn.  The moment that happens, the keyserver network goes down
> hard as every keyserver operator everywhere gets exposed to massive
> criminal liability.
> 
> We've known about it for several years.  We've been thinking about how
> to counter it for several years.  It turns out that countering it is a
> *really hard job*.  If you make it possible to delete records from a
> keyserver, you open the door to all kinds of shenanigans that
> governments could force keyserver operators to do on their behalf.

I think this may be the reason why others than you are much more
optimistic than you about all this: I don't think we are considering
this scenario, only the much more restricted case of “I want to remove
information associated with my private key”. In which case there is no
need of trusted introducers who would be allowed to moderate data, or
anything like this: the owner of the key could just sign the deletion
token with the said key.

Handling network-wide censorship of information published is a much
harder scenario, as the network was designed to be censorship-resistent.
And it looks like a nice property we would want to keep at network-level
in my opinion, though in order to accomodate local jurisdictions
keyserver operators could maybe want not to store eg. photo IDs or the
like -- just like if I understand correctly the case of someone sueing
to get his key removed from keyservers lead to the addition of an option
for keyserver operators to refuse syncing certain keys.

That said, I did read your “To implement this would require a completely
new keyserver implementation, […]” ; this message was just to maybe cast
some light on why some people look much more optimistic about this than
you are.

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

Re: Remove public key from keyserver

[Stefan Claas]

Am 16.01.2018 um 00:32 schrieb Robert J. Hansen:


(Responding here because Stefan's message hasn't hit my mail server yet)

My previous message to you and the list was bounced from your mail server.



It's from 2003.  It doesn't need modernization.

No? I for one would like to be sure that i am the only person who can
upload my public key to a key server directory.

Which is not a modernization issue.  It's a feature request, and the
feature you're asking for is DRM.  Literally.  You're asking that the
keyserver network be rewritten to give you the ability to manage how
information, which you think belongs to you, gets shared: that's DRM.
DRM schemes are awful and they don't work.

O.K. than it is a feature request. You also triggered something in me 
with the

words " which you think belongs to you".

If i am not mistaken you have also a keybase account, if not i applogize.
How about this; let's make "your" public key the ideal canditate for a
global trollwot session, were every GnuPG Linux user can participate
and add some funny things to "your" public key. This would be
also interesting to see how many signatures a public key can bear.

Maybe people can do also other things with "your" pub key and post
the used techniques here, like i did in the past with Erika Mustermann's
pub key and the added fake sig from Werner.

This would imho give you and people you talk to in conferences etc.
also a better view what i am talking about.

Best regards
Stefan






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

Re: a step in the right direction

[Robert J. Hansen]

> I'd suggest speaking up over at sks-de...@gnu.org, where people have

Correction: sks-de...@nongnu.org

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

Re: a step in the right direction

[Robert J. Hansen]

(I originally composed this on a mobile device and it was held for
moderation.  Re-sending it from my laptop.)

=

(Apologies for the terseness: on a mobile device)

> should not be viewed as "discussing a [...] nightmare scenario",

I am darkly amused at someone who has not done the research into what
the nightmare scenario *is* telling me that it's not a nightmare scenario.

The nightmare scenario is malcontents realize the keyserver network is a
multijurisdictional, redundant, distributed database from which data
cannot be deleted... and decide this makes it an ideal way to distribute
child porn.  The moment that happens, the keyserver network goes down
hard as every keyserver operator everywhere gets exposed to massive
criminal liability.

We've known about it for several years.  We've been thinking about how
to counter it for several years.  It turns out that countering it is a
*really hard job*.  If you make it possible to delete records from a
keyserver, you open the door to all kinds of shenanigans that
governments could force keyserver operators to do on their behalf.

How do you make it possible to delete records from a keyserver, while at
the same time keeping the keyserver resistant to malicious tampering
from adversaries?

This is an incredibly hard question to address.  And frankly, you're not
adding a single iota to the discussion.  But if you want to continue it,
I'd suggest speaking up over at sks-de...@gnu.org, where people have
been having this discussion off and on for years.

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

Re: Remove public key from keyserver

[Werner Koch]

On Mon, 15 Jan 2018 20:21, stefan.cl...@posteo.de said:

> O.k. Werner invented WKD which solves those problems, if i'm not
> mistaken, but is it besides keybase.io widely deployed?

Nope.  The Web Key Directory solves exactly one problem: How to
initially map a mail address to a key.  This directory is hosted by the
provider of the mail address because that is the only entity which
controls the mail address.  Once this mail address has been mapped
keyservers can be used to get revocations and updates of the key.

Unfortunately it is not yet widely supported; you can help to make it
better known.

I wonder why you seem to suggest the US based keybase.io as a better
solution.  After all keybase.io is a service which connects private data
to private data of other sites and that all in the public.  I would
consider this a real privacy problem compared to a public mail address
on a keyserver with no other associated private data.

The mail address is a technical necessity to send mail; mapping the mail
address to a key is a technical necessity to send encrypted mail.  So
what keyservers do is to provide a directory of public keys - in the
same way as white pages of the phone systems.  Nobody requires you to
enter you phone number / public key into a directory.  But if you want
to receive phone calls / encrypted mails you need to somehow publish
this data.  You can't remove your name from white pages either - they
used to be printed in sometimes millions of copies.


Shalom-Salam,

   Werner


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


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