AW: Gnupg-users Digest, Vol 81, Issue 22

Sat Jun 19 13:31:06 CEST 2010

-- Gesendet von meinem Palm Prē
gnupg-users-request at gnupg.org schrieb:

Send Gnupg-users mailing list submissions to

	gnupg-users at gnupg.org

To subscribe or unsubscribe via the World Wide Web, visit

	http://lists.gnupg.org/mailman/listinfo/gnupg-users

or, via email, send a message with subject or body 'help' to

	gnupg-users-request at gnupg.org

You can reach the person managing the list at

	gnupg-users-owner at gnupg.org

When replying, please edit your Subject line so it is more specific

than "Re: Contents of Gnupg-users digest..."

Today's Topics:

   1. Re: Can we use GNUPG with PGP for commercial use

      (Daniel Kahn Gillmor)

   2. Re: Can we use GNUPG with PGP for commercial use (David Smith)

   3. Re: Can we use GNUPG with PGP for commercial use (Joke de Buhr)

   4. Re: Importing public key in OpenGPG - error. MAC OS X (MFPA)

   5. Re: auto refresh-keys (MFPA)

   6. Re: Can we use GNUPG with PGP for commercial use

      (mlb at imparisystems.com)

   7. Re: auto refresh-keys (Hauke Laging)

----------------------------------------------------------------------

Message: 1

Date: Thu, 17 Jun 2010 13:00:21 -0400

From: Daniel Kahn Gillmor &lt;dkg at fifthhorseman.net>

Subject: Re: Can we use GNUPG with PGP for commercial use

To: GnuPG Users &lt;gnupg-users at gnupg.org>

Message-ID: &lt;4C1A54A5.5020206 at fifthhorseman.net>

Content-Type: text/plain; charset="utf-8"

On 06/17/2010 12:45 PM, Joke de Buhr wrote:

> Unlike PGP GnuPG is a non-commercial tool. There is no warranty. You can't sue 

> anyone if GnuPG does not do what it's supposed to do.

If your goal is to be able to sue someone over proprietary software, i

strongly advise you to read the relevant EULA first:

 http://www.pgp.com/products/eula.html

section 9 in particular is illuminating about the scope and duration of

whatever minimal warranty you get from having purchased a license.

> If you need commercial support and liability stick to PGP and pay for it.

If you need commercial support, there is no reason to avoid free

software.  Several companies offer commercial support for GnuPG:

  http://www.gnupg.org/service.en.html

Please don't spread the false idea that only proprietary software is

available with commercial support.

Regards,

	--dkg

-------------- next part --------------

A non-text attachment was scrubbed...

Name: signature.asc

Type: application/pgp-signature

Size: 892 bytes

Desc: OpenPGP digital signature

URL: &lt;/pipermail/attachments/20100617/4201dccd/attachment-0001.pgp>

------------------------------

Message: 2

Date: Thu, 17 Jun 2010 17:15:23 +0100

From: David Smith &lt;Dave.Smith at st.com>

Subject: Re: Can we use GNUPG with PGP for commercial use

To: "Gorugantu, Prakash" &lt;pgorugantu at APUS.EDU>,

	&lt;gnupg-users at gnupg.org>

Message-ID: &lt;4C1A4A1B.9080303 at st.com>

Content-Type: text/plain; charset="ISO-8859-1"

Gorugantu, Prakash wrote:

> Our project has a requirement where we need to pull a file using PGP

> encryption/decryption from one of our clients ftp servers. Please let us

> know if we can use GNUPG to encrypt/decrypt files with PGP.  We read

> somewhere in your licensing agreement that GNUPG for PGP is only for

> non-commercial use and we have to purchase it from PGP Corp. if we have

> to use it.

GnuPG and PGP are different tools.

PGP is a commercial tool, although some versions of it are free for

non-commercial use.

GnuPG is a FOSS (Free, Open Source Software) tool released under the GNU

General Public License (GPL), and it can therefore be used

free-of-charge for both commercial and non-commercial use.

GnuPG and PGP are generally compatible with each other (i.e. a file

encrypted with PGP can be decrypted with GnuPG and vice-versa), as they

both work to a publicly-defined standard.

HTH &amp; HAND.

------------------------------

Message: 3

Date: Thu, 17 Jun 2010 19:51:38 +0200

From: Joke de Buhr &lt;joke at seiken.de>

Subject: Re: Can we use GNUPG with PGP for commercial use

To: GnuPG Users &lt;gnupg-users at gnupg.org>

Message-ID: &lt;201006171951.40684.joke at seiken.de>

Content-Type: text/plain; charset="utf-8"

On Thursday 17 June 2010 19:00:21 Daniel Kahn Gillmor wrote:

> On 06/17/2010 12:45 PM, Joke de Buhr wrote:

> > Unlike PGP GnuPG is a non-commercial tool. There is no warranty. You

> > can't sue anyone if GnuPG does not do what it's supposed to do.

> 

> If your goal is to be able to sue someone over proprietary software, i

> strongly advise you to read the relevant EULA first:

> 

>  http://www.pgp.com/products/eula.html

> 

> section 9 in particular is illuminating about the scope and duration of

> whatever minimal warranty you get from having purchased a license.

As far as I remember the software needs to do mostly what it's supposed to do. 

It should do at least some kind of encryption and start without segfaulting 

And advertised features need to be included and working.

In Germany some court ruled what certain parts of EULAs do not even apply.

And if you're legal region is the USA there might be a possibility you can sue 

PGP if the color of their icons is to bright and you get blinded.

Nevertheless legal departments of companies like to work with over companies 

just to pretend there is someone who can be sued. And project managers like 

know what support hotline to phone if something went wrong.

> > If you need commercial support and liability stick to PGP and pay for it.

> 

> If you need commercial support, there is no reason to avoid free

> software.  Several companies offer commercial support for GnuPG:

> 

>   http://www.gnupg.org/service.en.html

> 

> Please don't spread the false idea that only proprietary software is

> available with commercial support.

> 

> Regards,

> 

> 	--dkg

-------------- next part --------------

A non-text attachment was scrubbed...

Name: not available

Type: application/pgp-signature

Size: 706 bytes

Desc: This is a digitally signed message part.

URL: &lt;/pipermail/attachments/20100617/5e5cebf2/attachment-0001.pgp>

------------------------------

Message: 4

Date: Thu, 17 Jun 2010 19:27:47 +0100

From: MFPA &lt;expires2010 at ymail.com>

Subject: Re: Importing public key in OpenGPG - error. MAC OS X

To: "Asger Larsen on GnuPG-Users" &lt;gnupg-users at gnupg.org>

Message-ID: &lt;1983679122.20100617192747 at my_localhost>

Content-Type: text/plain; charset=iso-8859-15

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA512

Hi

On Thursday 17 June 2010 at 2:23:37 PM, in

&lt;mid:C83FEE79.2F1E%asger at e-advice.dk>, Asger Larsen wrote:

> Hello! Some keys I cannot import, others OK. See

> attachments

I see no attachments. As far as I remember, this list removes

attachments.

> Both sending computer and receiving

> computer use: gpgme: 0.3.14 Thunderbird mail client

> 3.0.4 (enigmail 1.0.1 Add-on) Mac OS X Snowleopard

> 10.6.4

> Typically Public keys which are exported as file are

> OK. If you just rightclick the key and choose: "send as

> e-mail": not possible to import.

> Hope for help! Asger

When you say "not possible to import," do you mean you see some sort

of error message? Providing the details would make it easier for

people to help you. (I do not use any of the software you listed

above.)

- --

Best regards

MFPA                    mailto:expires2010 at ymail.com

An idealist is a person who helps other people to be prosperous

-----BEGIN PGP SIGNATURE-----

iQCVAwUBTBppLaipC46tDG5pAQoxOgQAvCraeBMmaIeHBVa532pthIe8VlwP1/xY

hM1GF/aZF8wblUnGWx6XReqzvEJNgyceOHyHR52FYfnpliDtS2yMduQypO7b72go

V1JnLG21mN7XYRnajYyghSnjRXzN0EmBBczxZdCtY5/w1N1OOEqo9t4qMKB7xIPM

pLyTAB0uyrM=

=PIeW

-----END PGP SIGNATURE-----

------------------------------

Message: 5

Date: Thu, 17 Jun 2010 20:23:40 +0100

From: MFPA &lt;expires2010 at ymail.com>

Subject: Re: auto refresh-keys

To: "Hauke Laging on GnuPG-Users" &lt;gnupg-users at gnupg.org>

Message-ID: &lt;744785252.20100617202340 at my_localhost>

Content-Type: text/plain; charset=iso-8859-15

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA512

Hi

On Wednesday 16 June 2010 at 8:26:11 PM, in

&lt;mid:201006162126.17550.mailinglisten at hauke-laging.de>, Hauke Laging

wrote:

> Am Mittwoch 16 Juni 2010 19:10:17 schrieb Daniel Kahn

> Gillmor:

>> Do you have other suggestions?  We should consider

>> bringing a prioritized form of these to the sks-devel

>> list.

> A different approach might save even more bandwidth:

> Most keys do now change often. It is useless to

> download a key that has not changed.

A key may be sitting on a non-synchronising server that has not been

modified at all recently but contains certifications not on my local

copy. The key has not changed but contains information not in my copy.

Downloading it is not useless.

> Thus the client could send a list of all keys it wants

> to check and the server could respond with a list of

> fingerprints and modification timestamps.

In the case of a key flagged with a preferred keyserver-URL, the

"keyserver-url" may just point to a key file. Does the client just

receive the file, or can it see the last modification date and

terminate the connection without downloading the file?

> If the server wants to do its job (without TLS)

> especially well then it signs this list and solves a

> today unsolved problem by that.

Please expand.

> This way you could even

> check whether a key update of yourself has reached a

> (non-TLS) key server.

Why/does the keyserver signing its list make a difference to that?

> It would have to be decided whether this key server

> time stamp refers to the newest time stamp of a

> signature in the respective key

This would be a security problem in the event that somebody uploads to

the servers a revocation certificate they had prepared in advance;

this revocation would be overlooked if the latest modification date of

the key were taken to be newest time stamp of a signature.

> (then the time stamp

> would be the same from all key servers and the client

> could check the local key to find out whether it has

> the current key)

Assuming all the servers the user ever checks against are

synchronised. Also assuming the certification to be uploaded most

recently to the servers always equates the one containing the latest

time-stamp.

> or to the timestamp of the last update

> on the key server (which would require the client to

> store the timestamp of the last key download for every

> key server).

If the client could reliably tell from the server's response that it

synchronised with a particular group-ID of keyservers, the client

would need only the timestamp for the last time that key was

downloaded from a member of that group. Probably easier to store the

info per synchronising group-ID than per individual keyserver, but

still a major undertaking if you are storing it for all the keys on a

large keyring. (Maybe the file of which servers synchronise with which

others should be a local file rather than relying on what the servers

tell you.)

- --

Best regards

MFPA                    mailto:expires2010 at ymail.com

Oven mitt: A partially charred grease stain that fits over the hand.

-----BEGIN PGP SIGNATURE-----

iQCVAwUBTBp2RKipC46tDG5pAQoq0AP/VkqhnPRzaPc8pzTCCSLFOnBi4PUGhuJf

sPZqTeyUzXAhhkmjx7kpqdU0wuIV7dXAGiJmyQIJfx8lK7Slgg0G7ZlDBVrboCOe

cBm/xnwOsKW2Tk6duZ5ojvzuQaUQ3g7SbarJVmhwGc0lJc5UeBxDdB63et+M9gBx

iYsnoKD6swk=

=/MYK

-----END PGP SIGNATURE-----

------------------------------

Message: 6

Date: Thu, 17 Jun 2010 13:07:49 -0600

From: &lt;mlb at imparisystems.com>

Subject: Re: Can we use GNUPG with PGP for commercial use

To: Joke de Buhr &lt;joke at seiken.de>

Cc: GnuPG Users &lt;gnupg-users at gnupg.org>

Message-ID: &lt;0ab2ae1c340bb73fdbcebef806bbd4d2 at imparisystems.com>

Content-Type: text/plain; charset=UTF-8

On Thu, 17 Jun 2010 19:51:38 +0200, Joke de Buhr &lt;joke at seiken.de> wrote:

> On Thursday 17 June 2010 19:00:21 Daniel Kahn Gillmor wrote:

>> On 06/17/2010 12:45 PM, Joke de Buhr wrote:

>> > Unlike PGP GnuPG is a non-commercial tool. There is no warranty. You

>> > can't sue anyone if GnuPG does not do what it's supposed to do.

>> 

>> If your goal is to be able to sue someone over proprietary software, i

>> strongly advise you to read the relevant EULA first:

>> 

>>  http://www.pgp.com/products/eula.html

>> 

>> section 9 in particular is illuminating about the scope and duration of

>> whatever minimal warranty you get from having purchased a license.

> 

> As far as I remember the software needs to do mostly what it's supposed

to

> do. 

> It should do at least some kind of encryption and start without

> segfaulting. 

> And advertised features need to be included and working.

> 

> In Germany some court ruled what certain parts of EULAs do not even

apply.

> And if you're legal region is the USA there might be a possibility you

can

> sue 

> PGP if the color of their icons is to bright and you get blinded.

> 

> Nevertheless legal departments of companies like to work with over

> companies 

> just to pretend there is someone who can be sued. And project managers

> like 

> know what support hotline to phone if something went wrong.

>  

I've bought software at companies like MCI, IBM and a couple of others. 

They just care if there's a contract and the contract is legal - meaning

"I'm paying for software "X" and you're going to deliver it this way" or

"You're going to come and install this software and it's going to work as

you advertised or you will refund our money".  I'm working for more and

more companies that are getting open source software - not just OS's, but

things like KnowledgeTree, Alfresco and Pentaho.

I work and live in the United States and I'm not going to even guess about

any other country and their laws.

Certainly, if you work for someone who doesn't like open source - you'll

get every kind of excuse from Monday and their arguments are all about as

reasonable as a schizophrenic homeless person could offer up.

Basically, companies are all about making money and at some point somebody

will realize that they can get Pentaho BI or Talend up and running for

about 1/10th the price of some Oracle solution and they'll take the risk

for the cash.

My humble opinion....

>> > If you need commercial support and liability stick to PGP and pay for

>> > it.

>> 

>> If you need commercial support, there is no reason to avoid free

>> software.  Several companies offer commercial support for GnuPG:

>> 

>>   http://www.gnupg.org/service.en.html

>> 

>> Please don't spread the false idea that only proprietary software is

>> available with commercial support.

>> 

>> Regards,

>> 

>> 	--dkg

------------------------------

Message: 7

Date: Thu, 17 Jun 2010 22:14:55 +0200

From: Hauke Laging &lt;mailinglisten at hauke-laging.de>

Subject: Re: auto refresh-keys

To: gnupg-users at gnupg.org

Message-ID: &lt;201006172215.01214.mailinglisten at hauke-laging.de>

Content-Type: text/plain; charset="iso-8859-15"

Am Donnerstag 17 Juni 2010 21:23:40 schrieb MFPA:

> > A different approach might save even more bandwidth:

> > Most keys do now change often. It is useless to

> > download a key that has not changed.

> 

> A key may be sitting on a non-synchronising server that has not been

> modified at all recently but contains certifications not on my local

> copy. The key has not changed but contains information not in my copy.

> Downloading it is not useless.

My aim was not to prevent the first unnecessary download but the others. 

Download it once from every keyserver and store the timestamp for every 

server.

Something I forgot: The keyserver should not update the timestamp for a key 

just because of a new upload. The timestamp should be modified only if the key 

is modified somehow.

> In the case of a key flagged with a preferred keyserver-URL, the

> "keyserver-url" may just point to a key file. Does the client just

> receive the file, or can it see the last modification date and

> terminate the connection without downloading the file?

As I was talking about a keyserver feature I just don't care about non-

keyserver scenarios. In general it might be possible to create similar 

optimizations for other transport (application) protocols.

If it's an http URL then gpg might store the etag or timestamp and use If-

None-Match or If-Modified-Since in the request. But isn't this a rather exotic 

case? How many keys are configured that way? Are their owners to be freed from 

unnecessary traffic...?

I would advise to care about the keyservers first.

> > If the server wants to do its job (without TLS)

> > especially well then it signs this list and solves a

> > today unsolved problem by that.

> 

> Please expand.

If your keyservers don't support TLS (I have no idea whether the important 

ones use it) then you are open to a MitM attack when checking them. If the 

response is signed then you are not (if you are sure about the signing key 

:-) ).

One more advantage: The signed response could be distributed among several 

systems of the same user or several users with similar keyrings. This would 

result in omitted or smaller requests (containing just those IDs not covered 

by the response). Several users might even combine their ID wishlist so that 

only one of them has to ask the keyserver.

> > This way you could even

> > check whether a key update of yourself has reached a

> > (non-TLS) key server.

> 

> Why/does the keyserver signing its list make a difference to that?

MitM again. If you upload a changed key you cannot be sure (without TLS) 

whether it has arrived at the keyserver or just at one of the bad guys.

> > It would have to be decided whether this key server

> > time stamp refers to the newest time stamp of a

> > signature in the respective key

> 

> This would be a security problem in the event that somebody uploads to

> the servers a revocation certificate they had prepared in advance;

> this revocation would be overlooked if the latest modification date of

> the key were taken to be newest time stamp of a signature.

Right. So the keyserver would use the timestamp of the latest change at it

> If the client could reliably tell from the server's response that it

> synchronised with a particular group-ID of keyservers, the client

> would need only the timestamp for the last time that key was

> downloaded from a member of that group. Probably easier to store the

> info per synchronising group-ID than per individual keyserver, but

> still a major undertaking if you are storing it for all the keys on a

> large keyring.

Look at it the other way round: The more keys there are in the keyring the 

more bandwith is saved. I am convinced that users with large keyrings have 

enough local storage for that...

Hauke

-- 

PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814

-------------- next part --------------

A non-text attachment was scrubbed...

Name: not available

Type: application/pgp-signature

Size: 555 bytes

Desc: This is a digitally signed message part.

URL: &lt;/pipermail/attachments/20100617/f89121f8/attachment.pgp>

------------------------------

_______________________________________________

Gnupg-users mailing list

Gnupg-users at gnupg.org

http://lists.gnupg.org/mailman/listinfo/gnupg-users

End of Gnupg-users Digest, Vol 81, Issue 22

*******************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100619/1670079e/attachment-0001.htm>