From etiquettesg at gmail.com Wed Jun 1 06:53:35 2011
From: etiquettesg at gmail.com (Foo Lum)
Date: Wed, 1 Jun 2011 14:23:35 +0930
Subject: Using output from gpg --list-packets on a key to get the mpi values
to generate s-expressions
Message-ID:
Hey guys,
I am trying to use gpg generated public keys to do encryption using
libgcrypt. I used the list packets command on the key to get me the contents
of the key and parsed the mpi values into an s-expression. So when I try to
encode my session key with my public key I get the error "Odd hexadecimal
numbers in S-expression"? I think list packets is maybe giving me hex
numbers without the leading zero? If so what do I need to do to get me mpi
values that I can use in libgcrypt?
Thanks in advance,
Foo
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From wanda.sprowl at newcomlink.com Wed Jun 1 16:29:58 2011
From: wanda.sprowl at newcomlink.com (wanda.sprowl at newcomlink.com)
Date: Wed, 01 Jun 2011 07:29:58 -0700
Subject: extractin a gpg file
Message-ID: <20110601072958.87adf5a748cd2208c18add6e2abb3efd.54535417b5.wbe@email00.secureserver.net>
An HTML attachment was scrubbed...
URL:
From dpmcgee at gmail.com Thu Jun 2 00:41:13 2011
From: dpmcgee at gmail.com (Dan McGee)
Date: Wed, 1 Jun 2011 17:41:13 -0500
Subject: Working with a system-shared keyring
Message-ID:
We're trying to get a full implementation of package and database
signing going for Arch Linux using gpgme/gpg, and have run into a few
small hiccups. The goal was to actually use the web of trust features
rather than relying on gpgv and trusting everything in a given
keyring, as it seems every other distro using singing has done.
However, gpg is very particular about permissions, locking, and
ownership, and when layering gpgme on top of this, it becomes even
harder to work within the bounds of what is available.
A quick console session is shown below. Basically the idea is the
system GPG homedir used by the package manager is located at
/etc/pacman.d/gnupg/, and is world readable, as are all the files
within. There will never be private key information in this location.
So my questions are:
1. Does anyone else have experience with a shared among users keyring?
2. What is best/secure practice when it comes to this? Outside of
--lock-never, yum does something that seems silly, but works- make a
user-owned copy of the entire keyring directory and then uses that.
3. gpgme doesn't allow us to bypass the trustdb.gpg locking; is there
any possibility of allowing gpgme to run with --lock-never in a
read-only mode?
Any feedback is welcome, thanks in advance!
-Dan
$ sudo gpg --homedir /etc/pacman.d/gnupg --verify
/home/makepkg/packages/libmysqlclient-5.5.12-1-x86_64.pkg.tar.xz.sig
gpg: WARNING: unsafe permissions on homedir `/etc/pacman.d/gnupg'
gpg: Signature made Tue 17 May 2011 09:13:06 AM CDT using DSA key ID F53A76ED
gpg: Good signature from "Dan McGee "
gpg: aka "Dan McGee (Developer) "
gpg: aka "Dan McGee (Jabber) "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: A5CA 9D55 15DC 2CA7 3DF7 48CA 5C2E 46A0 F53A 76ED
$ gpg --homedir /etc/pacman.d/gnupg --verify
/home/makepkg/packages/libmysqlclient-5.5.12-1-x86_64.pkg.tar.xz.sig
gpg: WARNING: unsafe ownership on homedir `/etc/pacman.d/gnupg'
gpg: Signature made Tue 17 May 2011 09:13:06 AM CDT using DSA key ID F53A76ED
gpg: failed to create temporary file
`/etc/pacman.d/gnupg/.#lk0x149f680.galway.5260': Permission denied
gpg: fatal: can't create lock for `/etc/pacman.d/gnupg/trustdb.gpg'
secmem usage: 1408/1408 bytes in 2/2 blocks of pool 1408/32768
$ gpg --lock-never --homedir /etc/pacman.d/gnupg --verify
/home/makepkg/packages/libmysqlclient-5.5.12-1-x86_64.pkg.tar.xz.sig
gpg: WARNING: unsafe ownership on homedir `/etc/pacman.d/gnupg'
gpg: Signature made Tue 17 May 2011 09:13:06 AM CDT using DSA key ID F53A76ED
gpg: NOTE: trustdb not writable
gpg: Good signature from "Dan McGee "
gpg: aka "Dan McGee (Developer) "
gpg: aka "Dan McGee (Jabber) "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: A5CA 9D55 15DC 2CA7 3DF7 48CA 5C2E 46A0 F53A 76ED
From aheinlein at gmx.com Thu Jun 2 11:57:30 2011
From: aheinlein at gmx.com (Andreas Heinlein)
Date: Thu, 02 Jun 2011 11:57:30 +0200
Subject: Working with a system-shared keyring
In-Reply-To:
References:
Message-ID: <4DE75E8A.40206@gmx.com>
Am 02.06.2011 00:41, schrieb Dan McGee:
> So my questions are:
> 1. Does anyone else have experience with a shared among users keyring?
> 2. What is best/secure practice when it comes to this? Outside of
> --lock-never, yum does something that seems silly, but works- make a
> user-owned copy of the entire keyring directory and then uses that.
> 3. gpgme doesn't allow us to bypass the trustdb.gpg locking; is there
> any possibility of allowing gpgme to run with --lock-never in a
> read-only mode?
>
I'd try not relocating the homedir, but only the keyring location. If
you have a means of distributing a gpg.conf to everyone's home
directory, you could insert
no-default-keyring
keyring /etc/pacman.d/gnupg
Not sure about the secret keyring, though. It should not try to use
~/.gnupg/secring.gpg, so trying to import a secret key or generate a new
one should give an error. I assume that's what you intend.
A home directory with wrong permissions and/or read-only is granted to
give problems with various applications.
Bye,
Andreas
From wmsprowl at austin.rr.com Thu Jun 2 15:14:15 2011
From: wmsprowl at austin.rr.com (Wanda Sprowl)
Date: Thu, 2 Jun 2011 08:14:15 -0500
Subject: problem getting gpg to work
Message-ID:
I have a zipped file that I un zipped and then notice the file types are
gpg.
I installed the gpg and un tarred it in a different location where the zip
folder is, does that matter?
Also, what command do I use to unzip the gpg file ?
When I ungpg or gz the file I need to be a txt file for importing into
access.
Many thanks
Mary
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From lopaki at gmail.com Thu Jun 2 20:23:27 2011
From: lopaki at gmail.com (Scott Lambdin)
Date: Thu, 2 Jun 2011 14:23:27 -0400
Subject: problem getting gpg to work
In-Reply-To:
References:
Message-ID:
It sounds like you already know how to unzip them. Are you asking how to
decrypt them?
Do you have any reason to believe the files were encrypted for a key that
you have in your possession?
gpg --list-packets
will tell you the key that was used to encrypt. If you do not have the
private key for it, you are out of luck.
--Scott
On Thu, Jun 2, 2011 at 9:14 AM, Wanda Sprowl wrote:
> I have a zipped file that I un zipped and then notice the file types are
> gpg.
>
> I installed the gpg and un tarred it in a different location where the zip
> folder is, does that matter?
>
>
>
> Also, what command do I use to unzip the gpg file ?
>
> When I ungpg or gz the file I need to be a txt file for importing into
> access.
>
>
>
>
>
> Many thanks
>
> Mary
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
--
?Until we have the courage to recognize cruelty for what it is?whether its
victim is human or animal ?we cannot expect things to be much better in this
world. We cannot have peace among men whose hearts delight in killing any
living creature.??Rachel Carson, Silent Spring
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jerome at jeromebaum.com Thu Jun 2 21:01:42 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Thu, 2 Jun 2011 21:01:42 +0200
Subject: problem getting gpg to work
In-Reply-To:
References:
Message-ID:
On Thu, Jun 2, 2011 at 15:14, Wanda Sprowl wrote:
> Also, what command do I use to unzip the gpg file ?
>
> When I ungpg or gz the file I need to be a txt file for importing into
> access.
gpg files are usually encrypted, which means you need a key to get at
the contents. If you haven't used gpg or PGP before, then your
correspondent probably didn't encrypt the file to a public key. They
will have used a password. You need to know that password to access
the file.
I suggest you contact the person who sent you this file. They should
be able to help out.
--
Jerome Baum
tel +49-1578-8434336
email?jerome at jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From jerome at jeromebaum.com Thu Jun 2 23:16:45 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Thu, 2 Jun 2011 23:16:45 +0200
Subject: problem with gpg
In-Reply-To: <20110602140840.87adf5a748cd2208c18add6e2abb3efd.0df6d27948.wbe@email00.secureserver.net>
References: <20110602140840.87adf5a748cd2208c18add6e2abb3efd.0df6d27948.wbe@email00.secureserver.net>
Message-ID:
On Thu, Jun 2, 2011 at 23:08, wrote:
> Yes I have the password and I was given a script that actually calls the
> file and inserts password but I have to do it for every single file I can't
> just run the script for all and have it decrypt all by running the script?
>
>
> I also don?t' know where to put the script it was given to me in note pad
> does it have to go in a path or file that the actual files are in ?
Could you provide the script? (Make sure to remove any sensitive
contents -- replace paths, filenames, passwords, and any other private
information with e.g. ***REDACTED***)
--
Jerome Baum
tel +49-1578-8434336
email?jerome at jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From wk at gnupg.org Fri Jun 3 09:19:21 2011
From: wk at gnupg.org (Werner Koch)
Date: Fri, 03 Jun 2011 09:19:21 +0200
Subject: Working with a system-shared keyring
In-Reply-To: (Dan McGee's
message of "Wed, 1 Jun 2011 17:41:13 -0500")
References:
Message-ID: <877h93z8jq.fsf@vigenere.g10code.de>
On Thu, 2 Jun 2011 00:41, dpmcgee at gmail.com said:
> 1. Does anyone else have experience with a shared among users keyring?
Be warned that future gpg versions may not support the use of multiple
keyrings. It is not easy to define the semantics for this as it is
similar to a translucent filesystem.
What we currently do is to write changes to the first writable keyring.
This may lead to a situation were we have 2 copies of the keys; one
updated and one not updated.
> 2. What is best/secure practice when it comes to this? Outside of
> --lock-never, yum does something that seems silly, but works- make a
> user-owned copy of the entire keyring directory and then uses that.
Importing all the keys is the safest strategy.
Disable locking for a shared resource requires at least to check that no
write bits are set for the file. I am not sure whetehr such checks are
justified given the above mentioned problems with shared keyrings.
> 3. gpgme doesn't allow us to bypass the trustdb.gpg locking; is there
> any possibility of allowing gpgme to run with --lock-never in a
> read-only mode?
You may specify a different home directory with gpgme and in that
home directory you put the option lock-never into gpg.conf.
You can change the configuration of a backend engine, and thus change
the executable program and configuration directory to be used. You can
make these changes the default or set them for some contexts
individually.
-- Function: gpgme_error_t gpgme_set_engine_info
(gpgme_protocol_t PROTO, const char *FILE_NAME,
const char *HOME_DIR)
The function `gpgme_set_engine_info' changes the default
configuration of the crypto engine implementing the protocol PROTO.
FILE_NAME is the file name of the executable program implementing
this protocol, and HOME_DIR is the directory name of the
configuration directory for this crypto engine. If HOME_DIR is
`NULL', the engine's default will be used.
The new defaults are not applied to already created GPGME contexts.
This function returns the error code `GPG_ERR_NO_ERROR' if
successful, or an eror code on failure.
The functions `gpgme_ctx_get_engine_info' and
`gpgme_ctx_set_engine_info' can be used to change the engine
configuration per context. *Note Crypto Engine::.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From ian.m.fields at lmco.com Thu Jun 2 18:18:55 2011
From: ian.m.fields at lmco.com (Fields, Ian M)
Date: Thu, 02 Jun 2011 12:18:55 -0400
Subject: uninstall problems
Message-ID: <68C254EED7170D4E929A77F472A26A26084D9D64FF@HVXMSP7.us.lmco.com>
Good afternoon,
I was attempting to uninstall gnupg-w32cli-1.4.11 from my machine. I was successful, but upon attempting to reinstall it and checking the version I am seeing that version 1.4.9 is installed. So I basically have 2 problems.
1) I can't remove the application
2) I can't reinstall it and get to version 1.4.11 anymore.
After the application says that it has been successfully removed I can still run gpg commands. I am running a Win7 OS (64 and 32 bit).
Any help you could provide will be great.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From wk at gnupg.org Fri Jun 3 13:49:50 2011
From: wk at gnupg.org (Werner Koch)
Date: Fri, 03 Jun 2011 13:49:50 +0200
Subject: uninstall problems
In-Reply-To: <68C254EED7170D4E929A77F472A26A26084D9D64FF@HVXMSP7.us.lmco.com>
(Ian M. Fields's message of "Thu, 02 Jun 2011 12:18:55 -0400")
References: <68C254EED7170D4E929A77F472A26A26084D9D64FF@HVXMSP7.us.lmco.com>
Message-ID: <8739jrxhgh.fsf@vigenere.g10code.de>
On Thu, 2 Jun 2011 18:18, ian.m.fields at lmco.com said:
> I was attempting to uninstall gnupg-w32cli-1.4.11 from my machine. I
That is quite possible; I have not tested the uninstall featuire for
years. 1.4.x is not recommended for Windows; you better use gpg4win
which feature GnuPG 2.0. Unfortunately we had a ling to the 1.4 version
on the download page and I was made aware of it only a few weeks ago.
> 2) I can't reinstall it and get to version 1.4.11 anymore.
Answer the "Install anyway" (os similar) question with yes. Unless
youare currently using gpg, this should always succeed.
Also check that there is no other GnuPG version installed.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From dpmcgee at gmail.com Fri Jun 3 17:10:15 2011
From: dpmcgee at gmail.com (Dan McGee)
Date: Fri, 3 Jun 2011 10:10:15 -0500
Subject: Working with a system-shared keyring
In-Reply-To: <877h93z8jq.fsf@vigenere.g10code.de>
References:
<877h93z8jq.fsf@vigenere.g10code.de>
Message-ID:
On Fri, Jun 3, 2011 at 2:19 AM, Werner Koch wrote:
> On Thu, ?2 Jun 2011 00:41, dpmcgee at gmail.com said:
>
>> 1. Does anyone else have experience with a shared among users keyring?
>
> Be warned that future gpg versions may not support the use of multiple
> keyrings. ?It is not easy to define the semantics for this as it is
> similar to a translucent filesystem.
Perhaps I phrased this bad- I more meant "accessible to multiple
users". When using this keyring, no other keyring will ever come into
play, as $GNUPGHOME is set to this shared directory
(/etc/pacman.d/gnupg/).
>> 2. What is best/secure practice when it comes to this? Outside of
>> --lock-never, yum does something that seems silly, but works- make a
>> user-owned copy of the entire keyring directory and then uses that.
>
> Importing all the keys is the safest strategy.
Importing to where, and trust levels as well? The idea here is we are
using this keyring for one purpose only- the system-defined keyring
and trust levels used to verify downloaded and to-be-installed
packages and metadata. Having user-specific keyrings/trustdbs for this
stuff doesn't seem to make much sense unless I'm overlooking
something.
> Disable locking for a shared resource requires at least to check that no
> write bits are set for the file. ?I am not sure whetehr such checks are
> justified given the above mentioned problems with shared keyrings.
>
>
>> 3. gpgme doesn't allow us to bypass the trustdb.gpg locking; is there
>> any possibility of allowing gpgme to run with --lock-never in a
>> read-only mode?
>
> You may specify a different home directory with gpgme and in that
> home directory you put the option lock-never into gpg.conf.
Aha, didn't think about this, but it makes sense- thanks. Of course if
the user that does have write permissions on these files (root) runs
gpg, then the --lock-never would be unwanted but maybe we have to live
with that.
> ?You can change the configuration of a backend engine, and thus change
> ?the executable program and configuration directory to be used. ?You can
> ?make these changes the default or set them for some contexts
> ?individually.
>
> ? -- Function: gpgme_error_t gpgme_set_engine_info
Yes, we are doing this already and are setting the home directory to
/etc/pacman.d/gnupg/.
-Dan
From amanoc at dizum.nl Fri Jun 3 21:32:59 2011
From: amanoc at dizum.nl (Amano Corunga)
Date: Fri, 3 Jun 2011 21:32:59 +0200 (CEST)
Subject: Problem with faked-system-time option
Message-ID: <20110603193259.4C19B8C069@nym.dizum.nl>
In doc\gpg.man of my gnupg 1.4.11 I found
--faked-system-time epoch
This option is only useful for testing; it sets the system time
back or forth to epoch which is the number of seconds elapsed
since the year 1970. Alternatively epoch may be given as a full
ISO time string (e.g. "20070924T154812").
a real goody, as nobody has to know at what (night-)time I create keys
or work off (and sign) my mail. But I can't get it working:
| Microsoft Windows [Version 6.1.7600]
| Copyright (c) 2009 Microsoft Corporation. All rights reserved.
|
| e:\portapps\GnuPG>gpg --homedir .\data
| --faked-system-time 20110501T120000
| --gen-key
| gpg: Invalid option "--faked-system-time"
Transferring a number instead of the time string and putting it in
quotation marks doesn't help either.
Any hint appreciated.
Amano
From wk at gnupg.org Sun Jun 5 10:32:13 2011
From: wk at gnupg.org (Werner Koch)
Date: Sun, 05 Jun 2011 10:32:13 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <20110603193259.4C19B8C069@nym.dizum.nl> (Amano Corunga's message
of "Fri, 3 Jun 2011 21:32:59 +0200 (CEST)")
References: <20110603193259.4C19B8C069@nym.dizum.nl>
Message-ID: <87tyc4wueq.fsf@vigenere.g10code.de>
On Fri, 3 Jun 2011 21:32, amanoc at dizum.nl said:
> In doc\gpg.man of my gnupg 1.4.11 I found
>
> --faked-system-time epoch
> This option is only useful for testing; it sets the system time
You need to use GnuPG-2, Gpg4win installs gpg2 under the name gpg but
older instalaltions don't. The installer is availabale at gpg4win.org.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From amanoc at dizum.nl Sun Jun 5 21:15:04 2011
From: amanoc at dizum.nl (Amano Corunga)
Date: Sun, 5 Jun 2011 21:15:04 +0200 (CEST)
Subject: Problem with faked-system-time option
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<87tyc4wueq.fsf@vigenere.g10code.de>
Message-ID: <20110605191504.54EB58C06D@nym.dizum.nl>
On Sun, 05 Jun 2011 10:32:13 +0200, Werner Koch wrote:
>On Fri, 3 Jun 2011 21:32, amanoc at dizum.nl said:
>
>> In doc\gpg.man of my gnupg 1.4.11 I found
>>
>> --faked-system-time epoch
>> This option is only useful for testing; it sets the system time
>
>You need to use GnuPG-2, Gpg4win installs gpg2 under the name gpg but
>older instalaltions don't. The installer is availabale at gpg4win.org.
Werner, thanks for that hint. I installed the naked GPG part of
Gpg4Win but didn't get it working.
To begin with, I wonder whether I have to drag along all those 25 MB
for using GnuPG-2 compared with less than 2 MB with GnuPG-1 (gpg.exe +
iconv.dll). Is there a chance to slim it down in case I only need to
create / delete keys and encrypt / sign / verify messages?
And are there instructions available on how to perform those tasks
without altering the host system. I have GPG1 with all its data
stored on a removable device and use it on several computers, no local
installation required. That's a perfect portable application, which
shouldn't be dismissed without an adequate replacement at hand.
Last but not least, do I have to start the gpg-agent background task
for each command line gpg call if I don't want to risk data corruption
when inadvertently removing that USB device?
Those are a lot of questions, but I'm still highly sceptical towards
that GPG2 monster and would prefer to stay with my more manageable
GPG1, if it only had that faked-system-time option. Is there room for
hope to get it enhanced that way?
Thanks again
Amano
From dkg at fifthhorseman.net Mon Jun 6 00:15:29 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 05 Jun 2011 18:15:29 -0400
Subject: Problem with faked-system-time option
In-Reply-To: <20110605191504.54EB58C06D@nym.dizum.nl>
References: <20110603193259.4C19B8C069@nym.dizum.nl> <87tyc4wueq.fsf@vigenere.g10code.de>
<20110605191504.54EB58C06D@nym.dizum.nl>
Message-ID: <4DEC0001.4030803@fifthhorseman.net>
On 06/05/2011 03:15 PM, Amano Corunga wrote:
> Those are a lot of questions, but I'm still highly sceptical towards
> that GPG2 monster and would prefer to stay with my more manageable
> GPG1, if it only had that faked-system-time option. Is there room for
> hope to get it enhanced that way?
If you're using debian or a debian-derived operating system (e.g.
ubuntu), you have a choice of faketime or datefudge; both of these
packages can fake the system clock for any dynamically-linked executable.
for example:
0 dkg at pip:~$ date
Sun Jun 5 18:13:19 EDT 2011
0 dkg at pip:~$ faketime 2010-03-05 date
Fri Mar 5 00:00:00 EST 2010
0 dkg at pip:~$
hth,
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL:
From wk at gnupg.org Tue Jun 7 10:18:40 2011
From: wk at gnupg.org (Werner Koch)
Date: Tue, 07 Jun 2011 10:18:40 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <20110605191504.54EB58C06D@nym.dizum.nl> (Amano Corunga's message
of "Sun, 5 Jun 2011 21:15:04 +0200 (CEST)")
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<87tyc4wueq.fsf@vigenere.g10code.de>
<20110605191504.54EB58C06D@nym.dizum.nl>
Message-ID: <8762oivyu7.fsf@vigenere.g10code.de>
On Sun, 5 Jun 2011 21:15, amanoc at dizum.nl said:
> To begin with, I wonder whether I have to drag along all those 25 MB
The light installer is 15MB.
> iconv.dll). Is there a chance to slim it down in case I only need to
> create / delete keys and encrypt / sign / verify messages?
Yes, in theory but it is a lot of work to distribute and maintain 3
installers. Even convincing my co-hackers to keep the light installer
was not easy.
You may build your own installer of course. The installer is a meta
package and using a decent Debian OS a new installer is easy to build.
> without altering the host system. I have GPG1 with all its data
> stored on a removable device and use it on several computers, no local
> installation required. That's a perfect portable application, which
> shouldn't be dismissed without an adequate replacement at hand.
The installer can't do that out of the box.
> Last but not least, do I have to start the gpg-agent background task
> for each command line gpg call if I don't want to risk data corruption
> when inadvertently removing that USB device?
If the gpg-agent fails it gfails and it won't corrupt any data.
> Those are a lot of questions, but I'm still highly sceptical towards
> that GPG2 monster and would prefer to stay with my more manageable
It is not a moster; rthe installer is only that larger becuase it
includes the GTK+ libraries a full mail client and GPA.
> GPG1, if it only had that faked-system-time option. Is there room for
> hope to get it enhanced that way?
The faked-system-time option is a debug option we need to run the
regression tests. If you merely want to create your keys with an other
creation date you may use a parameter file:
@item Ceation-Date: @var{iso-date}
Set the creation date of the key as stored in the key information and
which is also part of the fingerprint calculation. Either a date like
"1986-04-26" or a full timestamp like "19860426T042640" may be used.
The time is considered to be UTC. If it is not given the current time
is used.
The batch key generation and that parameter is supported by all
versions.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From laurent.jumet at skynet.be Wed Jun 8 13:01:40 2011
From: laurent.jumet at skynet.be (Laurent Jumet)
Date: Wed, 08 Jun 2011 13:01:40 +0200
Subject: Manual...
Message-ID:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Hello !
Here you can download the manual digest for GnuPG 1.4.11 in a 11 pages
convenient mode for printing:
In PDF: http://www.pointdechat.net/MyMan_GnuPG-1411.pdf
In .DOC: http://www.pointdechat.net/MyMan_GnuPG-1411.doc
- --
Laurent Jumet
KeyID: 0xCFAF704C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
iHEEAREDADEFAk3vV5cqGGh0dHA6Ly93d3cucG9pbnRkZWNoYXQubmV0LzB4Q0ZB
RjcwNEMuYXNjAAoJEPUdbaDPr3BMAdYAoOClVDb7KmTTdIYQv3BwjvqmNbE3AKCP
e4hEx4tU0A3UdCTiB+Zah/FT7A==
=qIdw
-----END PGP SIGNATURE-----
From aaron.toponce at gmail.com Wed Jun 8 15:07:12 2011
From: aaron.toponce at gmail.com (Aaron Toponce)
Date: Wed, 8 Jun 2011 07:07:12 -0600
Subject: Manual...
In-Reply-To:
References:
Message-ID: <20110608130712.GC2812@poseidon.cocyt.us>
On Wed, Jun 08, 2011 at 01:01:40PM +0200, Laurent Jumet wrote:
> Here you can download the manual digest for GnuPG 1.4.11 in a 11 pages
> convenient mode for printing:
>
> In PDF: http://www.pointdechat.net/MyMan_GnuPG-1411.pdf
> In .DOC: http://www.pointdechat.net/MyMan_GnuPG-1411.doc
Cool (for the PDF's sake, not the DOC's)! How did you create the document?
did you use some tool for automatically doing so, ro copy and paste
manually?
--
. o . o . o . . o o . . . o .
. . o . o o o . o . o o . . o
o o o . o . . o o o o . o o o
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 527 bytes
Desc: Digital signature
URL:
From amanoc at dizum.nl Wed Jun 8 17:36:52 2011
From: amanoc at dizum.nl (Amano Corunga)
Date: Wed, 8 Jun 2011 17:36:52 +0200 (CEST)
Subject: Problem with faked-system-time option
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<87tyc4wueq.fsf@vigenere.g10code.de>
<20110605191504.54EB58C06D@nym.dizum.nl>
<8762oivyu7.fsf@vigenere.g10code.de>
Message-ID: <20110608153652.4F1508C074@nym.dizum.nl>
On Tue, 07 Jun 2011 10:18:40 +0200, Werner Koch wrote:
>On Sun, 5 Jun 2011 21:15, amanoc at dizum.nl said:
>
>> To begin with, I wonder whether I have to drag along all those 25 MB
>
>The light installer is 15MB.
I subsumed all the files I found in the GnuPG folder of a fresh
Gpg4Win installation, which may approximate those 15 MB packed.
>> iconv.dll). Is there a chance to slim it down in case I only need to
>> create / delete keys and encrypt / sign / verify messages?
>
>Yes, in theory but it is a lot of work to distribute and maintain 3
>installers. Even convincing my co-hackers to keep the light installer
>was not easy.
>
>You may build your own installer of course. The installer is a meta
>package and using a decent Debian OS a new installer is easy to build.
>
>> without altering the host system. I have GPG1 with all its data
>> stored on a removable device and use it on several computers, no local
>> installation required. That's a perfect portable application, which
>> shouldn't be dismissed without an adequate replacement at hand.
>
>The installer can't do that out of the box.
But is it technically possible to use GPG2 like GPG1 as a portable
application which leaves no traces on the host system?
And, though I don't require an installer, without further information
I'm not capable of locating the files that aren't required for basic
tasks?
>> Last but not least, do I have to start the gpg-agent background task
>> for each command line gpg call if I don't want to risk data corruption
>> when inadvertently removing that USB device?
>
>If the gpg-agent fails it gfails and it won't corrupt any data.
I'm relieved to hear that.
>> GPG1, if it only had that faked-system-time option. Is there room for
>> hope to get it enhanced that way?
>
>The faked-system-time option is a debug option we need to run the
>regression tests. If you merely want to create your keys with an other
>creation date you may use a parameter file:
>
> @item Ceation-Date: @var{iso-date}
> Set the creation date of the key as stored in the key information and
> which is also part of the fingerprint calculation. Either a date like
> "1986-04-26" or a full timestamp like "19860426T042640" may be used.
> The time is considered to be UTC. If it is not given the current time
> is used.
>
>The batch key generation and that parameter is supported by all
>versions.
I gladly confirm it really works - Great! GPG1 key creation problem
solved.
But is there an equivalent for determining signature timestamps?
It's fair to say that GnuPG is one of the most important privacy tools
out there. It protects data from unauthorized access, with
'throw-keyids' the recipient's identity is hidden, but why in the
world do I involuntarily have to allow others to gain sensitive
information about my time management with each mail I sign? I don't
quite understand why that's of minor importance to others. If OTOH
you're aiming at a signature with a trusted timestamp in no way
whatsoever the local computer's system clock can replace a validated
time stamp service. So why not allow everybody to specify signatures'
timestamps directly instead of making that option accessible only to
those who are permitted to change their Windows computer's system time
(thanks Daniel for your Linux advice) and tolerant against all the
adverse side effects arising from that manipulation?
Thanks
Amano
From Sethukumar.R at sungard.com Thu Jun 9 10:36:55 2011
From: Sethukumar.R at sungard.com (Sethukumar.R at sungard.com)
Date: Thu, 9 Jun 2011 09:36:55 +0100
Subject: GPG encryption and decryption in windows
Message-ID:
Hi,
I'm trying to use GPG on windows to encrypt and decrypt some XML
messages. ON windows I'm able to encrypt with the passphrase of the
message sender passed as below:
gpg --passphrase $passphrase$ --no-secmem-warning -e -u
$senderUserName$ -r $receiverUserName$ $xmlFileName$
The text inbetween any two '$' symbols are placeholders whose values are
replaced at runtime.
On windows platform this works and the source XML file is encrypted
without prompting for the passphrase of the sender.
On the otherhand, when I try to decrypt the encrypted file, using a
similar syntax to pass the passphrase, it prompts for the passphrase of
the receiver at runtime (a small pop up window is open).
gpg --passphrase $passphrase$ --no-tty --status-fd 2 -d
-o $targetFileName$ $encryptedFileName$
The passphrase passed here is that of the receiver for decryption.
I'm executing these commands through a java program as:
Runtime.getRuntime().exec(command) where command is the
string form of the above command.
My question is how to get rid of the passphrase prompt during runtime in
windows platform?
Thanks
Sethukumar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From lopaki at gmail.com Thu Jun 9 18:05:28 2011
From: lopaki at gmail.com (Scott Lambdin)
Date: Thu, 9 Jun 2011 12:05:28 -0400
Subject: GPG encryption and decryption in windows
In-Reply-To:
References:
Message-ID:
On Thu, Jun 9, 2011 at 4:36 AM, wrote:
> Hi,
>
>
>
> I?m trying to use GPG on windows to encrypt and decrypt some XML messages.
> ON windows I?m able to encrypt with the passphrase of the message sender
> passed as below:
>
> gpg --passphrase $passphrase$ --no-secmem-warning -e -u
> $senderUserName$ -r $receiverUserName$ $xmlFileName$
>
>
>
> The text inbetween any two ?$? symbols are placeholders whose values are
> replaced at runtime.
>
> On windows platform this works and the source XML file is encrypted without
> prompting for the passphrase of the sender.
>
>
>
> On the otherhand, when I try to decrypt the encrypted file, using a similar
> syntax to pass the passphrase, it prompts for the passphrase of the receiver
> at runtime (a small pop up window is open).
>
> gpg --passphrase $passphrase$ --no-tty --status-fd 2 -d -o
> $targetFileName$ $encryptedFileName$
>
> The passphrase passed here is that of the receiver for decryption.
>
>
>
> I?m executing these commands through a java program as:
>
> Runtime.getRuntime().exec(command) where command is the
> string form of the above command.
>
>
>
>
>
> My question is how to get rid of the passphrase prompt during runtime in
> windows platform?
>
I don't think the passphrase is needed for the encrypt command, since you
are not signing? If you add --sign, do you get the pop up?
Does your pass phrase have double quotes around it? Maybe more of the
command is being seen as part of the pass phrase than you expect?
>
>
>
>
> Thanks
>
> Sethukumar
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
--
?Until we have the courage to recognize cruelty for what it is?whether its
victim is human or animal ?we cannot expect things to be much better in this
world. We cannot have peace among men whose hearts delight in killing any
living creature.??Rachel Carson, Silent Spring
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From lists at meumonus.com Thu Jun 9 20:51:54 2011
From: lists at meumonus.com (Devin Fisher)
Date: Thu, 9 Jun 2011 18:51:54 +0000
Subject: Assuan processing failed
Message-ID: <1124743696-1307645515-cardhu_decombobulator_blackberry.rim.net-227799414-@b1.c27.bise6.blackberry>
Hi,
I'm running GnuPG 1.4.9 on Windows. I'm trying to cache a passphrase using gpg-preset-passphrase so I can batch decrypt a couple hundred files. I've successfully decrypted the by manually entering the passphrase. However I'd like to cache the passphrase so that I can script the decryption.
I started gpg-agent as a daemon and get the following output:
Set GPG_AGENT_INFO=C:\Documents and Settings\user\Application Data\gnupg\S.gpg-agent;948;1
The log file shows:
(Omitting datestamp & timestamp) gpg-agent[pid] listening on socket (path to)\S.gpg-agent
Datestamp timestamp gpg-agent[pid] DBG returning notify handle 00000734
I run the command:
gpg-preset-passphrase --passphrase (passphrase) --preset (hexcode)
and it outputs:
Gpg-preset-passphrase: problem with the agent
Gpg-preset-passphrase: caching passphrase failed: Invalid response
Checking the log again I see:
gpg-agent[pid] Assuan processing failed: IPC read error
How can I correct this error?
Thanks!
-Devin
From dougb at dougbarton.us Thu Jun 9 22:38:45 2011
From: dougb at dougbarton.us (Doug Barton)
Date: Thu, 09 Jun 2011 13:38:45 -0700
Subject: Working with a system-shared keyring
In-Reply-To: <877h93z8jq.fsf@vigenere.g10code.de>
References:
<877h93z8jq.fsf@vigenere.g10code.de>
Message-ID: <4DF12F55.2020707@dougbarton.us>
On 06/03/2011 00:19, Werner Koch wrote:
> Be warned that future gpg versions may not support the use of multiple
> keyrings.
IMO that would be a serious regression. I have several different spheres
where I use PGP, and I use various different keyrings to make it easy to
keep things up to date. I also use keyrings to keep the keys that have
signed my key, keys that I've signed, etc.
I realize that my use is exceptional, and that the average gnupg user
isn't going to have nearly as many separate keyrings as I do, but I'd
hate to lose that capability.
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
From wk at gnupg.org Fri Jun 10 08:52:07 2011
From: wk at gnupg.org (Werner Koch)
Date: Fri, 10 Jun 2011 08:52:07 +0200
Subject: Assuan processing failed
In-Reply-To: <1124743696-1307645515-cardhu_decombobulator_blackberry.rim.net-227799414-@b1.c27.bise6.blackberry>
(Devin Fisher's message of "Thu, 9 Jun 2011 18:51:54 +0000")
References: <1124743696-1307645515-cardhu_decombobulator_blackberry.rim.net-227799414-@b1.c27.bise6.blackberry>
Message-ID: <87hb7ytbzc.fsf@vigenere.g10code.de>
On Thu, 9 Jun 2011 20:51, lists at meumonus.com said:
> I'm running GnuPG 1.4.9 on Windows. I'm trying to cache a passphrase
1.4.9 is old; 1.4.11 is the current version.
> using gpg-preset-passphrase so I can batch decrypt a couple hundred
If you are using the agent you better use gpg2 which is part of the
package which provides gpg-agent.
I suggest that you remove gpg 1.4.x from your system and install gpg4win
which features the latest stable version of GnuPG (2.0.17).
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From wk at gnupg.org Fri Jun 10 08:56:22 2011
From: wk at gnupg.org (Werner Koch)
Date: Fri, 10 Jun 2011 08:56:22 +0200
Subject: Working with a system-shared keyring
In-Reply-To: <4DF12F55.2020707@dougbarton.us> (Doug Barton's message of "Thu,
09 Jun 2011 13:38:45 -0700")
References:
<877h93z8jq.fsf@vigenere.g10code.de> <4DF12F55.2020707@dougbarton.us>
Message-ID: <87d3imtbs9.fsf@vigenere.g10code.de>
On Thu, 9 Jun 2011 22:38, dougb at dougbarton.us said:
> IMO that would be a serious regression. I have several different
But fixes a lot of problems. The keyring is a database and if we
distribute this database to several files without a way to sync them;
this leads to problems. You may have not been affected by such problems
but only due to the way you use gpg.
> it easy to keep things up to date. I also use keyrings to keep the
> keys that have signed my key, keys that I've signed, etc.
That's easy to figure out. Your approach keeps duplicates of the keys;
duplicating data is something which should not been done.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From steve.strobel at link-comm.com Fri Jun 10 18:39:48 2011
From: steve.strobel at link-comm.com (Steve Strobel)
Date: Fri, 10 Jun 2011 10:39:48 -0600
Subject: GPG encryption and decryption in windows
In-Reply-To:
References:
Message-ID: <0MN27U-1QStI21Ti4-0071XN@mrelay.perfora.net>
>My question is how to get rid of the passphrase prompt during
>runtime in windows platform?
This may be completely unrelated, but I also ran into a problem where
I was prompted for a passphrase when the real issue was something
else. Running on an Ubuntu host trying to connect to and Ubuntu
server running on Amazon web services:
ssh -i keyfile.pem ubuntu at mydomain.net
Enter passphrase for key 'keyfile.pem':
Permission denied (publickey).
sudo ssh -i keyfile.pem ubuntu at vtrunk.net
The keyfile was created without a passphrase, but trying to use it
when I didn't have permission for the host's filesystem caused a
prompt for a passphrase that AFAIK doesn't exist. I don't see how or
why using sudo had anything to do with a passphrase for the
key. When the key was created without a passphrase, it seems wrong
for gpg to prompt for one regardless of what else might be wrong.
I guess what I am suggesting is that the logic that causes gpg to
prompt for a passphrase either has a problem or my understanding of
it does. Whether the problem you are experiencing on a Windows
system is related at all is a question I can't answer.
>Thanks
>Sethukumar
Steve
---
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve.strobel at link-comm.com
From dougb at dougbarton.us Fri Jun 10 20:43:34 2011
From: dougb at dougbarton.us (Doug Barton)
Date: Fri, 10 Jun 2011 11:43:34 -0700
Subject: Working with a system-shared keyring
In-Reply-To: <87d3imtbs9.fsf@vigenere.g10code.de>
References: <877h93z8jq.fsf@vigenere.g10code.de>
<4DF12F55.2020707@dougbarton.us>
<87d3imtbs9.fsf@vigenere.g10code.de>
Message-ID: <4DF265D6.8010507@dougbarton.us>
On 6/9/2011 11:56 PM, Werner Koch wrote:
> On Thu, 9 Jun 2011 22:38, dougb at dougbarton.us said:
>
>> IMO that would be a serious regression. I have several different
>
> But fixes a lot of problems. The keyring is a database and if we
> distribute this database to several files without a way to sync them;
> this leads to problems. You may have not been affected by such problems
> but only due to the way you use gpg.
Can you elaborate on those problems? I can think of several examples of
databases whose contents are stored in multiple files without any
difficulty, so I'm curious.
>> it easy to keep things up to date. I also use keyrings to keep the
>> keys that have signed my key, keys that I've signed, etc.
>
> That's easy to figure out. Your approach keeps duplicates of the keys;
> duplicating data is something which should not been done.
Actually I'm very careful to avoid doing just that. :) I have various
command-line aliases to move keys between rings depending on their
status, de-duplicate on import, and cross-check to make sure that I
haven't missed something.
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
From dkg at fifthhorseman.net Fri Jun 10 21:05:32 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 10 Jun 2011 15:05:32 -0400
Subject: Working with a system-shared keyring
In-Reply-To: <4DF265D6.8010507@dougbarton.us>
References: <877h93z8jq.fsf@vigenere.g10code.de> <4DF12F55.2020707@dougbarton.us> <87d3imtbs9.fsf@vigenere.g10code.de>
<4DF265D6.8010507@dougbarton.us>
Message-ID: <4DF26AFC.4050307@fifthhorseman.net>
On 06/10/2011 02:43 PM, Doug Barton wrote:
> Actually I'm very careful to avoid doing just that. :) I have various
> command-line aliases to move keys between rings depending on their
> status, de-duplicate on import, and cross-check to make sure that I
> haven't missed something.
Could you share these tools? They sound useful to me.
regards,
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL:
From expires2011 at ymail.com Sun Jun 12 15:23:19 2011
From: expires2011 at ymail.com (MFPA)
Date: Sun, 12 Jun 2011 14:23:19 +0100
Subject: Problem with faked-system-time option
In-Reply-To: <20110608153652.4F1508C074@nym.dizum.nl>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<87tyc4wueq.fsf@vigenere.g10code.de>
<20110605191504.54EB58C06D@nym.dizum.nl>
<8762oivyu7.fsf@vigenere.g10code.de>
<20110608153652.4F1508C074@nym.dizum.nl>
Message-ID: <26506331.20110612142319@my_localhost>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi
On Wednesday 8 June 2011 at 4:36:52 PM, in
, Amano Corunga wrote:
>>The batch key generation and that parameter is
>>supported by all versions.
> I gladly confirm it really works - Great! GPG1 key
> creation problem solved.
It would be really good if this could be used to create multiple
subkeys, and when adding UIDs, subkeys, signatures, etc. to existing
keys.
> But is there an equivalent for determining signature
> timestamps?
That would be an interesting feature. It is already available to
anybody who can change their system clock time (or use an app to pass
a fake time to gnupg).
> It's fair to say that GnuPG is one of the most
> important privacy tools out there. It protects data
> from unauthorized access, with 'throw-keyids' the
> recipient's identity is hidden, but why in the world do
> I involuntarily have to allow others to gain sensitive
> information about my time management with each mail I
> sign? I don't quite understand why that's of minor
> importance to others.
Some people labour under the misapprehension that the signature time
is significant and has potential legal implications.
> If OTOH you're aiming at a signature with a trusted
> timestamp in no way whatsoever the local computer's
> system clock can replace a validated time stamp service.
Unless the emails are sent via some form of "trusted" timestamp
service, signature timestamp means nothing. And even then, what gets
verified is the time/date of sending and *not* the time/date of
signing.
> So why not allow
> everybody to specify signatures' timestamps directly
> instead of making that option accessible only to those
> who are permitted to change their Windows computer's
> system time (thanks Daniel for your Linux advice) and
> tolerant against all the adverse side effects arising
> from that manipulation?
And why not allow the user to adjust the granularity of the timestamp?
For example specifying the date but no time, or simply indicating the
year and month?
- --
Best regards
MFPA mailto:expires2011 at ymail.com
Change is inevitable except from a vending machine
-----BEGIN PGP SIGNATURE-----
iQE7BAEBCgClBQJN9L3SnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf
a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC
OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB
MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5ptaAD/2Dz
zjMK7SRQk66Na7oC/9zl1AaknPOB3vNpOuORCP2tLhyHm6b2gNUUNIsFAnos0DD7
zv7TdRgZoT31jMTh6aHdcijrO2IxKEA4Vg1H8Sa9nj3MuAYz6q4i2wTdxVpTBlab
5X1Aa+ie4aRzhrxf+p8KIxxQJwJOVEp3f6a9XpOi
=xlxh
-----END PGP SIGNATURE-----
From mailinglisten at hauke-laging.de Sun Jun 12 19:35:57 2011
From: mailinglisten at hauke-laging.de (Hauke Laging)
Date: Sun, 12 Jun 2011 19:35:57 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <26506331.20110612142319@my_localhost>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<20110608153652.4F1508C074@nym.dizum.nl>
<26506331.20110612142319@my_localhost>
Message-ID: <201106121936.02971.mailinglisten@hauke-laging.de>
Am Sonntag, 12. Juni 2011, 15:23:19 schrieb MFPA:
> Some people labour under the misapprehension that the signature time
> is significant and has potential legal implications.
Why should that be a misapprehension? For which law does that not have
implications?
There is no reason to assume that you are less bound by the timestamp than by
the signature itself. The timestamp can be fake. So what? So can be the signed
data. You don't have to have a look at what you are going to sign. You can
sign the output of /dev/urandom. Nothing of that makes your declaration of
intent invalid. At least not in Germany. The relevant perspective is that of a
neutral third party. How toes it look like to them?
You can claim that the signing system has been compromised and that the act of
signing has been rigged. That may work. But a statement like "The key and the
signing system are both valid. Just don't care abour the timestamp." will not
be successful. Take that legal risk if you like.
> Unless the emails are sent via some form of "trusted" timestamp
> service, signature timestamp means nothing.
Funny theory. Either you trust all or nothing. How should you draw the line in
between?
> And even then, what gets
> verified is the time/date of sending and *not* the time/date of
> signing.
That is simply wrong. A signature refers to the supplied timestamp. That is
usually the current time. Even if you fake that it would just by chance be the
time of sending (but noone would expect it to be that). A signature is made at
a certain moment. It does not matter at all when the signed data gets sent.
The time of sending cannot change the signature. You would have to create a
new signature at a time that happens to be nearly the time of sending.
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:
From jerome at jeromebaum.com Sun Jun 12 20:00:39 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Sun, 12 Jun 2011 20:00:39 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <201106121936.02971.mailinglisten@hauke-laging.de>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<20110608153652.4F1508C074@nym.dizum.nl>
<26506331.20110612142319@my_localhost>
<201106121936.02971.mailinglisten@hauke-laging.de>
Message-ID:
> You can
> sign the output of /dev/urandom. Nothing of that makes your declaration of
> intent invalid. At least not in Germany.
I agree with your point and hate to be picky, but the output of
/dev/urandom wouldn't be a statement of intent, much less a valid one.
Unless, of course, the output is "I will pay John Doe 10 EUR". We can
safely ignore that case.
Doesn't make your point any less valid, but if we're going to discuss
the legal interpretation of your signature on a piece of data, we
might as well do it properly.
Now all gnupg-users have a nice Pentecost!
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From mail at kerrickstaley.com Sun Jun 12 23:15:04 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Sun, 12 Jun 2011 16:15:04 -0500
Subject: Generate digest and signature seperately
Message-ID:
Hello,
Is it possible to generate the digest for a file, and then create the
signature from that digest later?
I'm making this inquiry because developers for the Arch Linux distribution
need a way to sign databases (lists of software packages) on the central
repository (package server) without having to copy those repositories to
their local computer and back. There is the option of hashing the databases
and signing the hash, but this introduces additional complexity which
shouldn't be necessary. Another option is copying secret keys to the server,
but this is a bad idea because all developers' keys would need to be revoked
in the event that the server is compromised; key revocation would be a huge
hassle which would be compounded with the need to audit the server's
security.
So, being able to seperate the generation of digests and the generation of
signatures would be very useful, but I cannot find documentation anywhere on
how to do this. Can anyone help?
Thanks,
Kerrick Staley
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jerome at jeromebaum.com Mon Jun 13 00:37:42 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Mon, 13 Jun 2011 00:37:42 +0200
Subject: Generate digest and signature seperately
In-Reply-To:
References:
Message-ID:
On Sun, Jun 12, 2011 at 23:15, Kerrick Staley wrote:
> Is it possible to generate the digest for a file, and then create the
> signature from that digest later?
Problem is, you don't know what you're signing.
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From mail at kerrickstaley.com Mon Jun 13 01:00:06 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Sun, 12 Jun 2011 18:00:06 -0500
Subject: Generate digest and signature seperately
In-Reply-To:
References:
Message-ID:
On Sun, Jun 12, 2011 at 5:37 PM, Jerome Baum wrote:
>
> On Sun, Jun 12, 2011 at 23:15, Kerrick Staley wrote:
> > Is it possible to generate the digest for a file, and then create the
> > signature from that digest later?
>
> Problem is, you don't know what you're signing.
I realize that this is a problem; however, it considered to be an
acceptable risk. The same problem happens if the developers sign a
SHA512 of the database. The only way for developers to verify the
database is to copy it to their computer, but this is considered to be
too much of a hassle.
-Kerrick Staley
From jerome at jeromebaum.com Mon Jun 13 01:16:30 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Mon, 13 Jun 2011 01:16:30 +0200
Subject: Generate digest and signature seperately
In-Reply-To:
References:
Message-ID:
>> > Is it possible to generate the digest for a file, and then create the
>> > signature from that digest later?
>> Problem is, you don't know what you're signing.
> I realize that this is a problem; however, it considered to be an
> acceptable risk. The same problem happens if the developers sign a
> SHA512 of the database. The only way for developers to verify the
> database is to copy it to their computer, but this is considered to be
> too much of a hassle.
Who makes these considerations?
In any case, what kind of database is this that it's too much of a
hassle to copy over? What size, etc.?
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From ben at adversary.org Mon Jun 13 01:38:04 2011
From: ben at adversary.org (Ben McGinnes)
Date: Mon, 13 Jun 2011 09:38:04 +1000
Subject: Generate digest and signature seperately
In-Reply-To:
References:
Message-ID: <4DF54DDC.3090007@adversary.org>
On 13/06/11 9:16 AM, Jerome Baum wrote:
>
> Who makes these considerations?
>
> In any case, what kind of database is this that it's too much of a
> hassle to copy over? What size, etc.?
Given this line from the original post, "developers for the Arch Linux
distribution need a way to sign databases (lists of software packages)
on the central repository (package server) without having to copy those
repositories to their local computer and back" I'm guessing that it'd be
at least 4-6Gb per architecture.
Given not every developer may have the bandwidth to handle regular
transfers of that size, I can see why they'd want to avoid it. Why they
don't go for signing each package instead is another matter.
Regards,
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: OpenPGP digital signature
URL:
From jerome at jeromebaum.com Mon Jun 13 02:07:36 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Mon, 13 Jun 2011 02:07:36 +0200
Subject: Generate digest and signature seperately
In-Reply-To: <4DF54DDC.3090007@adversary.org>
References:
<4DF54DDC.3090007@adversary.org>
Message-ID:
>> In any case, what kind of database is this that it's too much of a
>> hassle to copy over? What size, etc.?
> Given this line from the original post, "developers for the Arch Linux
> distribution need a way to sign databases (lists of software packages)
> on the central repository (package server) without having to copy those
> repositories to their local computer and back" I'm guessing that it'd be
> at least 4-6Gb per architecture.
I wouldn't draw that conclusion and instead ask for more information.
"lists of software packages" is not the same as "software packages".
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From mail at kerrickstaley.com Mon Jun 13 02:52:01 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Sun, 12 Jun 2011 19:52:01 -0500
Subject: Generate digest and signature seperately
In-Reply-To:
References:
<4DF54DDC.3090007@adversary.org>
Message-ID:
>> Given this line from the original post, "developers for the Arch Linux
>> distribution need a way to sign databases (lists of software packages)
>> on the central repository (package server) without having to copy those
>> repositories to their local computer and back" I'm guessing that it'd be
>> at least 4-6Gb per architecture.
>
> I wouldn't draw that conclusion and instead ask for more information.
> "lists of software packages" is not the same as "software packages".
The databases (lists) are not very large, as far as I understand, but
it wasn't my call ("repositories" in the 4th line is a typo; I meant
"databases"). I'm not an Arch Linux developer; I'm just contributing
to their effort to implement package signing.
Individual packages will be signed, but for complete security, the
databases must themselves also be signed; otherwise, an attacker could
use DNS spoofing to deliver a database listing outdated packages with
known vulnerabilities, and it would happily be accepted by end-users'
systems. The vulnerable packages would not be updated, but the users
would most likely not notice, since other packages would be updated.
-Kerrick Staley
From jerome at jeromebaum.com Mon Jun 13 02:54:06 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Mon, 13 Jun 2011 02:54:06 +0200
Subject: Generate digest and signature seperately
In-Reply-To:
References:
<4DF54DDC.3090007@adversary.org>
Message-ID:
> The databases (lists) are not very large, as far as I understand, but
> it wasn't my call ("repositories" in the 4th line is a typo; I meant
> "databases"). I'm not an Arch Linux developer; I'm just contributing
> to their effort to implement package signing.
> Individual packages will be signed, but for complete security, the
> databases must themselves also be signed; otherwise, an attacker could
> use DNS spoofing to deliver a database listing outdated packages with
> known vulnerabilities, and it would happily be accepted by end-users'
> systems. The vulnerable packages would not be updated, but the users
> would most likely not notice, since other packages would be updated.
All makes sense. Just don't get why it's so expensive to download a
small package list?
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From wk at gnupg.org Mon Jun 13 10:47:34 2011
From: wk at gnupg.org (Werner Koch)
Date: Mon, 13 Jun 2011 10:47:34 +0200
Subject: Generate digest and signature seperately
In-Reply-To: (Kerrick
Staley's message of "Sun, 12 Jun 2011 16:15:04 -0500")
References:
Message-ID: <87sjreruc9.fsf@vigenere.g10code.de>
On Sun, 12 Jun 2011 23:15, mail at kerrickstaley.com said:
> Is it possible to generate the digest for a file, and then create the
> signature from that digest later?
No, this is not possible. We once considered to implement such a
feature but dropped that plan. The technical problem is that with
OpenPGP you don't just sign a plain hash of the message but the hash of
a modified message (in text mode) and further the hash includes a few
magic bytes. Thus to implement such a feature we we would need to do a
incomplete hash on the server and complete it on the client. It is
doable but would look ugly.
My suggestion is to sign a the hash of the file; i.e. create a file with
the SHA-x digests on the remote box, download it and sign it on the
local box.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
From dpmcgee at gmail.com Mon Jun 13 17:15:59 2011
From: dpmcgee at gmail.com (Dan McGee)
Date: Mon, 13 Jun 2011 10:15:59 -0500
Subject: Generate digest and signature seperately
In-Reply-To:
References:
<4DF54DDC.3090007@adversary.org>
Message-ID:
On Sun, Jun 12, 2011 at 7:54 PM, Jerome Baum wrote:
>> The databases (lists) are not very large, as far as I understand, but
>> it wasn't my call ("repositories" in the 4th line is a typo; I meant
>> "databases"). I'm not an Arch Linux developer; I'm just contributing
>> to their effort to implement package signing.
>
>> Individual packages will be signed, but for complete security, the
>> databases must themselves also be signed; otherwise, an attacker could
>> use DNS spoofing to deliver a database listing outdated packages with
>> known vulnerabilities, and it would happily be accepted by end-users'
>> systems. The vulnerable packages would not be updated, but the users
>> would most likely not notice, since other packages would be updated.
>
> All makes sense. Just don't get why it's so expensive to download a
> small package list?
I'll speak up as a developer here. I was the same one that asked about
a system-shared keyring last week if that helps bring it into context.
The actual issue isn't with package databases at all; those are, as
several people indicated, small enough to be copied, signed, and
uploaded as necessary. We're talking 50-500 KB or so here.
Our real issue revolves around signing very large packages. Take for
example, sage-mathematics [1]. This package clocks in at 306.3 MB
compressed. If this was built remotely on some build server and the
packager wanted to sign it, the current GPG signing workflow would
require to copy it locally where his secure keyring is located, sign
it, and then upload the signature file. The package itself could be
uploaded from either location.
With all that said, does anyone see a reasonable and secure workflow
for this? I did suggest [2] signing package hashes as one possible
option, after looking into agent forwarding and discovering that
doesn't seem to be a workable option at this point.
-Dan
[1] http://www.archlinux.org/packages/community/i686/sage-mathematics/
[2] http://mailman.archlinux.org/pipermail/pacman-dev/2011-June/013333.html
From mail at kerrickstaley.com Mon Jun 13 17:12:14 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Mon, 13 Jun 2011 10:12:14 -0500
Subject: Generate digest and signature seperately
In-Reply-To: <87sjreruc9.fsf@vigenere.g10code.de>
References:
<87sjreruc9.fsf@vigenere.g10code.de>
Message-ID:
On Mon, Jun 13, 2011 at 3:47 AM, Werner Koch wrote:
> On Sun, 12 Jun 2011 23:15, mail at kerrickstaley.com said:
>
>> Is it possible to generate the digest for a file, and then create the
>> signature from that digest later?
>
> No, this is not possible. ?We once considered to implement such a
> feature but dropped that plan. ?The technical problem is that with
> OpenPGP you don't just sign a plain hash of the message but the hash of
> a modified message (in text mode) and further the hash includes a few
> magic bytes. ?Thus to implement such a feature we we would need to do a
> incomplete hash on the server and complete it on the client. ?It is
> doable but would look ugly.
>
> My suggestion is to sign a the hash of the file; i.e. create a file with
> the SHA-x digests on the remote box, download it and sign it on the
> local box.
OK, that answers my question. I think we'll go with the hash-signing
implementation. Thanks!
-Kerrick Staley
From mailinglisten at hauke-laging.de Mon Jun 13 17:39:25 2011
From: mailinglisten at hauke-laging.de (Hauke Laging)
Date: Mon, 13 Jun 2011 17:39:25 +0200
Subject: Generate digest and signature seperately
In-Reply-To:
References:
Message-ID: <201106131739.26274.mailinglisten@hauke-laging.de>
Am Montag, 13. Juni 2011, 17:15:59 schrieb Dan McGee:
> I did suggest [2] signing package hashes as one possible option
I just realize that this does not solve the "you don't know what you sign"
argument at all. Whether you sign a file or the hash of that file is usually
not a difference to the user in the statement (just in convenience).
This is about "Shall you be able to 'sign' remote data", not so much about how
you do that. Let alone that downloading (and even compiling) source code
before signing does not guarantueee that you sign what you think you are
signing. You are just protected from signing something completely different.
Another point: One should not assume that somebody knows what he signs just
because there is a "direct" signature. What a signature means should be taken
solely from the signature policy.
I would like to have the possibility to pass the hash to be signed.
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:
From jerome at jeromebaum.com Mon Jun 13 19:03:15 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Mon, 13 Jun 2011 19:03:15 +0200
Subject: Generate digest and signature seperately
In-Reply-To: <201106131739.26274.mailinglisten@hauke-laging.de>
References:
<201106131739.26274.mailinglisten@hauke-laging.de>
Message-ID:
> I would like to have the possibility to pass the hash to be signed.
We had a discussion about smart-card signatures here and basically the
issue with passing just a hash is that you can't distinguish data
signatures from certifications/key signatures.
So, you might trust the remote server to give you a correct data hash
(i.e. you'll live with the implications of a manipulated data hash),
but not to give you a key hash. The problem is, you can't distinguish
between these cases.
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From jerome at jeromebaum.com Mon Jun 13 19:05:27 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Mon, 13 Jun 2011 19:05:27 +0200
Subject: Generate digest and signature seperately
In-Reply-To:
References:
<201106131739.26274.mailinglisten@hauke-laging.de>
Message-ID:
> We had a discussion about smart-card signatures here and basically the
> issue with passing just a hash is that you can't distinguish data
> signatures from certifications/key signatures.
To clarify, you can't tell from the hash, and you can't really add a
packet "I'm signing data here" vs. "I'm signing a key here". At least
that's what I got from the discussion on smart-cards, YMMV when it
comes to a full-blown gnupg install.
Of course, you could solve this problem by signing with a sub-key,
which isn't meant to certify other keys. I do wonder how e.g. PGP
would react on seeing a key certification from a sub-key.
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From dkg at fifthhorseman.net Mon Jun 13 19:09:43 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 13 Jun 2011 13:09:43 -0400
Subject: Generate digest and signature seperately
In-Reply-To:
References: <201106131739.26274.mailinglisten@hauke-laging.de>
Message-ID: <4DF64457.6040504@fifthhorseman.net>
On 06/13/2011 01:05 PM, Jerome Baum wrote:
> Of course, you could solve this problem by signing with a sub-key,
> which isn't meant to certify other keys. I do wonder how e.g. PGP
> would react on seeing a key certification from a sub-key.
it should depend on whether the key usage flags for the subkey (in the
subkey binding signature) include the "Certification" capability.
OpenPGP certifications issued by subkeys without the "Certification"
capability should be no more valid than any other random string of bits.
Regards.
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL:
From dshaw at jabberwocky.com Mon Jun 13 20:45:34 2011
From: dshaw at jabberwocky.com (David Shaw)
Date: Mon, 13 Jun 2011 14:45:34 -0400
Subject: Generate digest and signature seperately
In-Reply-To:
References:
<201106131739.26274.mailinglisten@hauke-laging.de>
Message-ID:
On Jun 13, 2011, at 1:05 PM, Jerome Baum wrote:
>> We had a discussion about smart-card signatures here and basically the
>> issue with passing just a hash is that you can't distinguish data
>> signatures from certifications/key signatures.
>
> To clarify, you can't tell from the hash, and you can't really add a
> packet "I'm signing data here" vs. "I'm signing a key here". At least
> that's what I got from the discussion on smart-cards, YMMV when it
> comes to a full-blown gnupg install.
>
> Of course, you could solve this problem by signing with a sub-key,
> which isn't meant to certify other keys. I do wonder how e.g. PGP
> would react on seeing a key certification from a sub-key.
It effectively ignores it. No OpenPGP program currently accepts certifications from subkeys. The standard doesn't say yes or no on the subject, but there is no code that does it today.
Trust models aren't really dealt with in any real depth in the standard - there were discussions at one point of making a different trust model RFC for that.
David
From venture37 at gmail.com Mon Jun 13 20:12:43 2011
From: venture37 at gmail.com (Sevan / Venture37)
Date: Mon, 13 Jun 2011 19:12:43 +0100
Subject: Key generation on card fails with key sizes larger than 1024 bits
In-Reply-To: <87y6236ryc.fsf@vigenere.g10code.de>
References:
<87zkmlqyz4.fsf@vigenere.g10code.de>
<87fwob92y4.fsf@vigenere.g10code.de>
<87y6236ryc.fsf@vigenere.g10code.de>
Message-ID:
On 19 May 2011 08:59, Werner Koch wrote:
> On Thu, 19 May 2011 00:26, venture37 at gmail.com said:
>
>> for FreeBSD, the implementation of libusb has diverged/lagged (i'm not
>> sure which tbh) where anything that depends on a recent version of
>> libusb is broken on anything newer than FreeBSD 7.x, this includes
>> pcscd which can't be built with USB support on newer versions.
>
> This might as weel be the problem with the internal CCID driver. ?The
> last time I tested an USB reader on my laptop was with 7.0 I think.
I've still not made any progress with this on the *BSD side, however I
had the opportunity to try my SCR335 on a friends ThinkPad running
OpenSUSE 11.4, I was also unable to generate 2048bit keys on the card
there as well.
System details
openSUSE 11.4 (x86_64)
VERSION = 11.4
CODENAME = Celadon
Linux vader.site 2.6.37.6-0.5-desktop #1 SMP PREEMPT 2011-04-25
21:48:33 +0200 x86_64 x86_64 x86_64 GNU/Linux
gpg (GnuPG) 2.0.17
libgcrypt 1.4.6
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
S | Name | Type | Version | Arch | Repository
--+--------------+---------+------------+--------+------------------
i | libusb-0_1-4 | package | 0.1.13-9.1 | x86_64 | openSUSE-11.4-Oss
Attempting to generate keys resulted in the following error:
scdaemon[5968]: please wait while key is being generated ...
scdaemon[5968]: ccid_transceive failed: (0x1000a)
scdaemon[5968]: apdu_send_simple(0) failed: card I/O error
scdaemon[5968]: generating key failed
So I configured scdaemon.conf with the values you suggested &
reattempted, below is a snippet from where it failed, I can post the
whole log file if required
2011-06-09 21:10:21 scdaemon[6556] please wait while key is being generated ...
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: PC_to_RDR_XfrBlock:
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: dwLength ..........: 15
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: bSlot .............: 0
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: bSeq ..............: 140
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: bBWI ..............: 0x04
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: wLevelParameter
...: 0x0000
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: [0010] 00 00 0B 00 47 80
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: [0016] 00 00
00 02 B6 00 08 00 70
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: RDR_to_PC_DataBlock:
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: dwLength ..........: 5
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: bSlot .............: 0
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: bSeq ..............: 140
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: bStatus ...........: 0
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: bChainParameter ...: 0x04
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: [0010] 00 C3 01 64 A6
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: T=1: S-block
request received cmd=3
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: T=1: waittime
extension of bwi=100
scdaemon[6556]: chan_7 -> S PROGRESS card_busy w 0 0
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: PC_to_RDR_XfrBlock:
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: dwLength ..........: 5
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: bSlot .............: 0
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: bSeq ..............: 141
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: bBWI ..............: 0x04
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: wLevelParameter
...: 0x0000
2011-06-09 21:10:21 scdaemon[6556] DBG: ccid-driver: [0010] 00 E3 01 64 86
2011-06-09 21:10:26 scdaemon[6556] DBG: ccid-driver: usb_bulk_read
error: Connection timed out
2011-06-09 21:10:26 scdaemon[6556] ccid_transceive failed: (0x1000a)
2011-06-09 21:10:26 scdaemon[6556] apdu_send_simple(0) failed: card I/O error
2011-06-09 21:10:26 scdaemon[6556] generating key failed
2011-06-09 21:10:26 scdaemon[6556] operation genkey result: Card error
scdaemon[6556]: chan_7 -> ERR 100663404 Card error
2011-06-09 21:10:26 scdaemon[6556] DBG: ccid-driver: usb_bulk_read
error: Connection timed out
2011-06-09 21:10:26 scdaemon[6556] DBG: ccid-driver: USB: CALLING USB_CLEAR_HALT
2011-06-09 21:10:27 scdaemon[6556] DBG: ccid-driver: bulk-in seqno
does not match (143/141)
2011-06-09 21:10:27 scdaemon[6556] DBG: ccid-driver: bulk-in seqno
does not match (143/142)
scdaemon[6556]: chan_7 OK
scdaemon[6556]: chan_7
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<20110608153652.4F1508C074@nym.dizum.nl>
<26506331.20110612142319@my_localhost>
<201106121936.02971.mailinglisten@hauke-laging.de>
Message-ID: <5610428783.20110613210707@my_localhost>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi
On Sunday 12 June 2011 at 6:35:57 PM, in
, Hauke Laging
wrote:
> Am Sonntag, 12. Juni 2011, 15:23:19 schrieb MFPA:
>> Some people labour under the misapprehension that the
>> signature time is significant and has potential legal
>> implications.
> Why should that be a misapprehension?
Because the signature time means nothing, unless there is
corroboration. It is trivial to alter a system clock (or to use
software to pass a different time to an app).
> For which law does that not have implications?
If the time/date of signing is legally significant, there had better
be more reliable evidence than the signature time.
>> Unless the emails are sent via some form of "trusted"
>> timestamp service, signature timestamp means nothing.
> Funny theory. Either you trust all or nothing. How
> should you draw the line in between?
Look at the various independent timestamping services available and
make up your own mind whether any of them may be relied upon.
>> And even then, what gets verified is the time/date of
>> sending and *not* the time/date of signing.
> That is simply wrong.
The time from a timestamping service is not the same thing as the time
the document was signed. The timestamping service cannot add its
timestamp until it receives the document. When it receives the
document will depend on when the local user sends it, not on when they
sign it.
> A signature is made at
> a certain moment. It does not matter at all when the signed data gets sent.
> The time of sending cannot change the signature. You would have to create a
> new signature at a time that happens to be nearly the time of sending.
As far as I understand, creating a new, additional signature is
precisely what a timestamping service does. It demonstrates the local
user signed before a particular date/time (but not how long before).
In order to give assurance the document was signed after (rather than
before) a particular date/time, the signature from the timestamping
service could be obtained before the local user's signature is
applied.
- --
Best regards
MFPA mailto:expires2011 at ymail.com
Never lean forward to push an invisible object.
-----BEGIN PGP SIGNATURE-----
iQE7BAEBCgClBQJN9m3wnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf
a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC
OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB
MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pXtMD/RSk
FsPC28yLXpsaFw2NxvaRf74KoEcqM1CDVrPFR0GGtJqa/tidfZiQHUxcCEEoGM10
r8jpvpel3ItRcm1BC8OF9BJ0DVS0fFnfPFtFnD+QCAUq/iUQehYzXHuh8P+2EPcV
uHpn0KCcMdA8rgK0m7y/so0f2Nihu+PUzTH3ft3L
=BWpy
-----END PGP SIGNATURE-----
From jerome at jeromebaum.com Mon Jun 13 22:19:18 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Mon, 13 Jun 2011 22:19:18 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <5610428783.20110613210707@my_localhost>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<20110608153652.4F1508C074@nym.dizum.nl>
<26506331.20110612142319@my_localhost>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
Message-ID:
>>> Some people labour under the misapprehension that the
>>> signature time is significant and has potential legal
>>> implications.
>
>> Why should that be a misapprehension?
>
> Because the signature time means nothing, unless there is
> corroboration. It is trivial to alter a system clock (or to use
> software to pass a different time to an app).
Yes, and it is trivial to write a fake date next to my signature. That
doesn't mean there are no legal implications. In fact, just as I can
commit fraud (under the right circumstances) by writing that fake date
on a piece of paper, I can commit fraud by using a fake time-stamp in
an OpenPGP signature.
Let's summarize: The signature time has potential legal implications.
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From expires2011 at ymail.com Tue Jun 14 00:00:00 2011
From: expires2011 at ymail.com (MFPA)
Date: Mon, 13 Jun 2011 23:00:00 +0100
Subject: Problem with faked-system-time option
In-Reply-To:
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<20110608153652.4F1508C074@nym.dizum.nl>
<26506331.20110612142319@my_localhost>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
Message-ID: <1492626498.20110613230000@my_localhost>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi
On Monday 13 June 2011 at 9:19:18 PM, in
, Jerome Baum
wrote:
> Yes, and it is trivial to write a fake date next to my
> signature. That doesn't mean there are no legal
> implications. In fact, just as I can commit fraud
> (under the right circumstances) by writing that fake
> date on a piece of paper, I can commit fraud by using a
> fake time-stamp in an OpenPGP signature.
Commit fraud, or make a trivial error...
> Let's summarize: The signature time has potential legal
> implications.
Fair enough. But, as you illustrate above, it is trivial for a
signature date/time to be incorrect. Therefore it is potentially
unsafe to rely on them as being correct.
- --
Best regards
MFPA mailto:expires2011 at ymail.com
Nothing a Pan-Galactic Gargle Blaster won't cure!
-----BEGIN PGP SIGNATURE-----
iQE7BAEBCgClBQJN9ohpnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf
a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC
OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB
MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5p/4ID/iUX
UbC2QZLJwcBsOOcGgNrrjhaR4tFPG0/RbKepbSP2kDi8XNH+zOAGgyrEqs8+iDBA
ONgfhuMnJHGpj9t8R/cT9qO6ljesATM/JcVs8aUAC4ARHUis3OXI+LllVSFCo2Pg
gVbriV8IpIXP7+naqa7L08/GWZ7qhd+4ydk7Bv6v
=Cp0G
-----END PGP SIGNATURE-----
From jerome at jeromebaum.com Tue Jun 14 00:09:31 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Tue, 14 Jun 2011 00:09:31 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <1492626498.20110613230000@my_localhost>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<20110608153652.4F1508C074@nym.dizum.nl>
<26506331.20110612142319@my_localhost>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<1492626498.20110613230000@my_localhost>
Message-ID:
>> Yes, and it is trivial to write a fake date next to my
>> signature. That doesn't mean there are no legal
>> implications. In fact, just as I can commit fraud
>> (under the right circumstances) by writing that fake
>> date on a piece of paper, I can commit fraud by using a
>> fake time-stamp in an OpenPGP signature.
>
> Commit fraud, or make a trivial error...
Right. I can also be mistaken when dating my signature. As I said, it
depends on the circumstances. Even if I purposely lie about the date,
if there's no damage it's not fraud. So I agree with your point about
not relying on the signature date, which necessarily includes the date
of a digital signature. That doesn't mean you should entirely ignore
it either -- sounds a bit "black and white", doesn't it? The date is
an indicator, nothing more, but also nothing less.
>> Let's summarize: The signature time has potential legal
>> implications.
>
> Fair enough. But, as you illustrate above, it is trivial for a
> signature date/time to be incorrect. Therefore it is potentially
> unsafe to rely on them as being correct.
No-one said you should rely on that. Just as you shouldn't rely solely
on the date next to a signature. Anyone can lie.
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From mailinglisten at hauke-laging.de Tue Jun 14 01:33:08 2011
From: mailinglisten at hauke-laging.de (Hauke Laging)
Date: Tue, 14 Jun 2011 01:33:08 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <5610428783.20110613210707@my_localhost>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
Message-ID: <201106140133.09131.mailinglisten@hauke-laging.de>
Am Montag, 13. Juni 2011, 22:07:07 schrieb MFPA:
> Because the signature time means nothing, unless there is
> corroboration. It is trivial to alter a system clock (or to use
> software to pass a different time to an app).
By that standards: What does a signature mean at all? As a parallel discussion
on this list shows, it does not even guarantee that the signer had access to
the signed data.
You should tell apart who has to prove something. Your argument is valid if
the signer has to prove that he has made the signature at (or before or after)
a certain date and time. His own signature is no proof in that case as he can
easily fake the timestamp.
If a third party has to prove that and when the signer has signed a document
then the signature timestamp is perfectly OK.
The rest of my former mail was probably a misunderstanding. I thought you were
talking about local signatures but your reply shows that you meant additional
signatures by a timestamp server.
> > Funny theory. Either you trust all or nothing. How
> > should you draw the line in between?
>
> Look at the various independent timestamping services available and
> make up your own mind whether any of them may be relied upon.
>
> >> And even then, what gets verified is the time/date of
> >> sending and *not* the time/date of signing.
> >
> > That is simply wrong.
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:
From faramir.cl at gmail.com Tue Jun 14 01:47:57 2011
From: faramir.cl at gmail.com (Faramir)
Date: Mon, 13 Jun 2011 19:47:57 -0400
Subject: Problem with faked-system-time option
In-Reply-To: <8762oivyu7.fsf@vigenere.g10code.de>
References: <20110603193259.4C19B8C069@nym.dizum.nl> <87tyc4wueq.fsf@vigenere.g10code.de> <20110605191504.54EB58C06D@nym.dizum.nl>
<8762oivyu7.fsf@vigenere.g10code.de>
Message-ID: <4DF6A1AD.5070102@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
El 07-06-2011 4:18, Werner Koch escribi?:
...
>> Those are a lot of questions, but I'm still highly sceptical towards
>> that GPG2 monster and would prefer to stay with my more manageable
>
> It is not a moster; rthe installer is only that larger becuase it
> includes the GTK+ libraries a full mail client and GPA.
After reading lots of messages with things like agent, I'm a bit
sceptical toward GPG2 too, and since I don't use outlook, I'm very happy
with GPG1. But if the installer allow me to chose what to install (as I
think it does), it is not a problem to me to download 25 or 50 Mb.
Best Regards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBCAAGBQJN9qGsAAoJEMV4f6PvczxA/30H/jji4EngLeDtAIpp0GA22T+7
x6QwwowIXjBaMn4i1hIN/Ej8qS1DxmaE4nnF69ryKpUDWnn/q+BWRcb0CFB2w/uc
wsZlw2iqJap3uG7CnQ0PsVrVHJ6o7kzg76kPn++L/DNmCtXHpL7wJ1SgMpoiARCT
+6QTRXHhIf3Rdt9ObItGaQwwbQC2CIKz3hWwpbs0yvkFZVETtTSz2ttF7GOy/pho
xBMLgA1YRepeqBfFT47+TJ8bsCMPv8HYTGz2S9R2VcKSlFzS9OK0eKHcP4/TXGTm
FMSITem/b4yt6W0TBwx38Sd0kUTGq1zcKyD9Eo68HwpCZaPrARXGvj6f4yCAP9c=
=68y0
-----END PGP SIGNATURE-----
From faramir.cl at gmail.com Tue Jun 14 00:36:36 2011
From: faramir.cl at gmail.com (Faramir)
Date: Mon, 13 Jun 2011 18:36:36 -0400
Subject: Generate digest and signature seperately
In-Reply-To: <201106131739.26274.mailinglisten@hauke-laging.de>
References:
<201106131739.26274.mailinglisten@hauke-laging.de>
Message-ID: <4DF690F4.80405@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
El 13-06-2011 11:39, Hauke Laging escribi?:
...
> I would like to have the possibility to pass the hash to be signed.
I suppose if the hash is sent using a "secure" connection, it should
be safe enough. But that option, no doubt, would be an "expert" option.
It sounds interesting to me, but of course, I'm not the one writing the
patch.
Best Regards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBCAAGBQJN9pD0AAoJEMV4f6PvczxAC/sH/2iJeXN9zWUIQjO9MlFWk/SX
UtfCDd4Zvk33J2oqCT7h1mpCdpO2dQ86AkJ8zat5TMH3Ps3r4Ndvvo4CsmJxuP7A
BchcbEFt2hhKA5uUz5I7omZYdjfNhWKLYieWcCUAPoDJUeuYthUdptEU7OMTEzXQ
kIstM9sHJfckiCjfB1RC8FuWwtr4jrxa8W42WhxVJQ28SfK2YDj1kReoBB6ALLh/
iMJBKpNv0mTued3rL93+DtEwJgGMnFi1Zx4ix2u39PuP4EYkKksHY5lswj/7GrvQ
nCuYo4ai2xBleqvXhqM/UFhbuNmO9RIXKzTYyE9JW76yJAhvvcx7OZukQ1hDFu0=
=Ttt9
-----END PGP SIGNATURE-----
From mail at kerrickstaley.com Tue Jun 14 02:31:01 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Mon, 13 Jun 2011 19:31:01 -0500
Subject: Generate digest and signature seperately
In-Reply-To: <4DF690F4.80405@gmail.com>
References:
<201106131739.26274.mailinglisten@hauke-laging.de>
<4DF690F4.80405@gmail.com>
Message-ID:
Just to make sure that I'm understanding this, a complete PGP signature does
not embed information about whether it is the signature of a file or the
signature of a certificate, so it's a bad idea to sign a remotely generated
digest?
-Kerrick Staley
On Mon, Jun 13, 2011 at 5:36 PM, Faramir wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> El 13-06-2011 11:39, Hauke Laging escribi?:
> ...
> > I would like to have the possibility to pass the hash to be signed.
>
> I suppose if the hash is sent using a "secure" connection, it should
> be safe enough. But that option, no doubt, would be an "expert" option.
> It sounds interesting to me, but of course, I'm not the one writing the
> patch.
>
> Best Regards
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBCAAGBQJN9pD0AAoJEMV4f6PvczxAC/sH/2iJeXN9zWUIQjO9MlFWk/SX
> UtfCDd4Zvk33J2oqCT7h1mpCdpO2dQ86AkJ8zat5TMH3Ps3r4Ndvvo4CsmJxuP7A
> BchcbEFt2hhKA5uUz5I7omZYdjfNhWKLYieWcCUAPoDJUeuYthUdptEU7OMTEzXQ
> kIstM9sHJfckiCjfB1RC8FuWwtr4jrxa8W42WhxVJQ28SfK2YDj1kReoBB6ALLh/
> iMJBKpNv0mTued3rL93+DtEwJgGMnFi1Zx4ix2u39PuP4EYkKksHY5lswj/7GrvQ
> nCuYo4ai2xBleqvXhqM/UFhbuNmO9RIXKzTYyE9JW76yJAhvvcx7OZukQ1hDFu0=
> =Ttt9
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jerome at jeromebaum.com Tue Jun 14 02:42:56 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Tue, 14 Jun 2011 02:42:56 +0200
Subject: Generate digest and signature seperately
In-Reply-To:
References:
<201106131739.26274.mailinglisten@hauke-laging.de>
<4DF690F4.80405@gmail.com>
Message-ID:
On Tue, Jun 14, 2011 at 02:31, Kerrick Staley wrote:
> Just to make sure that I'm understanding this, a complete PGP signature does
> not embed information about whether it is the signature of a file or the
> signature of a certificate, so it's a bad idea to sign a remotely generated
> digest?
It does, and the hash it signs is generated from that (key) data
prefixed with a string that differs between certs and data sigs.
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From dshaw at jabberwocky.com Tue Jun 14 04:58:47 2011
From: dshaw at jabberwocky.com (David Shaw)
Date: Mon, 13 Jun 2011 22:58:47 -0400
Subject: Generate digest and signature seperately
In-Reply-To:
References:
<201106131739.26274.mailinglisten@hauke-laging.de>
<4DF690F4.80405@gmail.com>
Message-ID: <5B8E924D-615A-486C-83F4-97E15C3CA699@jabberwocky.com>
On Jun 13, 2011, at 8:31 PM, Kerrick Staley wrote:
> Just to make sure that I'm understanding this, a complete PGP signature does not embed information about whether it is the signature of a file or the signature of a certificate, so it's a bad idea to sign a remotely generated digest?
No, it's the other way. A PGP signature does embed information about all sorts of things, including whether it is the signature of a file or signature over a certificate.
David
From jerome at jeromebaum.com Tue Jun 14 13:51:10 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Tue, 14 Jun 2011 13:51:10 +0200
Subject: Generate digest and signature seperately
In-Reply-To: <5B8E924D-615A-486C-83F4-97E15C3CA699@jabberwocky.com>
References:
<201106131739.26274.mailinglisten@hauke-laging.de>
<4DF690F4.80405@gmail.com>
<5B8E924D-615A-486C-83F4-97E15C3CA699@jabberwocky.com>
Message-ID:
> No, it's the other way. ?A PGP signature does embed information about all sorts of things, including whether it is the signature of a file or signature over a certificate.
I think it really boils down to "the details are significant". It's
not really the signature packet that is relevant, but the actual
signature (i.e. number generated using private key). This signature
definitely uses a hash. We know that hash varies between data sigs and
certs. So here's the question:
Does the (mathematical) signature differ between data sigs and certs
in any way besides the varying hash?
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From mailinglisten at hauke-laging.de Tue Jun 14 14:25:51 2011
From: mailinglisten at hauke-laging.de (Hauke Laging)
Date: Tue, 14 Jun 2011 14:25:51 +0200
Subject: Generate digest and signature seperately
In-Reply-To:
References:
<5B8E924D-615A-486C-83F4-97E15C3CA699@jabberwocky.com>
Message-ID: <201106141425.56659.mailinglisten@hauke-laging.de>
Am Dienstag, 14. Juni 2011, 13:51:10 schrieb Jerome Baum:
> Does the (mathematical) signature differ between data sigs and certs
> in any way besides the varying hash?
Does that matter and why?
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:
From jerome at jeromebaum.com Tue Jun 14 14:36:02 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Tue, 14 Jun 2011 14:36:02 +0200
Subject: Generate digest and signature seperately
In-Reply-To: <201106141425.56659.mailinglisten@hauke-laging.de>
References:
<5B8E924D-615A-486C-83F4-97E15C3CA699@jabberwocky.com>
<201106141425.56659.mailinglisten@hauke-laging.de>
Message-ID:
>> Does the (mathematical) signature differ between data sigs and certs
>> in any way besides the varying hash?
>
> Does that matter and why?
If only the hash varies, you need the data to be sure that the hash is
for a data sig (based on a previous discussion the hash is prefixed
with the "data vs. cert" code, so you can't partially generate the
hash and then add the code on your local machine).
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From jerome at jeromebaum.com Tue Jun 14 14:36:59 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Tue, 14 Jun 2011 14:36:59 +0200
Subject: Generate digest and signature seperately
In-Reply-To:
References:
<5B8E924D-615A-486C-83F4-97E15C3CA699@jabberwocky.com>
<201106141425.56659.mailinglisten@hauke-laging.de>
Message-ID:
> for a data sig (based on a previous discussion the hash is prefixed
(referring to the data that is hashed, and emphasis on prefixed vs. postfixed)
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From mail at kerrickstaley.com Tue Jun 14 19:16:31 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Tue, 14 Jun 2011 12:16:31 -0500
Subject: Aspects of trust
Message-ID:
This is to confirm my understanding of an important aspect of the way
GnuPG works:
When you decide whether to trust a signature, there are two questions
that must be asked:
a) Does the key used to make this signature really belong to the
person named in the certificates's UID?
b) Given that the key is valid, is the person trustworthy?
GnuPG and the web-of-trust concept only manage information related to
the first question. GnuPG provides no means of encoding or storing the
fact that a person is or is not trustworthy; it merely displays the
UID when verifying a signature, and the user is left to decide whether
the person should be trusted.
Am I correct in this?
Thanks,
Kerrick Staley
From rjh at sixdemonbag.org Tue Jun 14 20:35:30 2011
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 14 Jun 2011 11:35:30 -0700
Subject: Aspects of trust
In-Reply-To:
References:
Message-ID: <58a31436edaf6d8395b8d64035da2a71@localhost>
On Tue, 14 Jun 2011 12:16:31 -0500, Kerrick Staley
wrote:
> a) Does the key used to make this signature really belong to the
> person named in the certificates's UID?
> b) Given that the key is valid, is the person trustworthy?
These are the two Big Questions, yes: "do I have the correct certificate?"
and, "do I trust the issuer?" You have these two questions correct.
> GnuPG provides no means of encoding or storing the
> fact that a person is or is not trustworthy
Kind of. You can certainly do things with different signature classes to
denote distrust, but few people do this. You can also set a certificate's
trust to "I do NOT trust," IIRC -- it's been some years since I've needed
to do that.
>From a pedantic standpoint, GnuPG offers some tools you can use to state
"I do not find this certificate issuer trustworthy."
>From a practical standpoint, those tools are hardly ever used, so you're
basically correct.
From dshaw at jabberwocky.com Tue Jun 14 21:19:56 2011
From: dshaw at jabberwocky.com (David Shaw)
Date: Tue, 14 Jun 2011 15:19:56 -0400
Subject: Aspects of trust
In-Reply-To:
References:
Message-ID: <19F23BDA-A34A-43D0-BE9E-3CD2CE85AE8A@jabberwocky.com>
On Jun 14, 2011, at 1:16 PM, Kerrick Staley wrote:
> This is to confirm my understanding of an important aspect of the way
> GnuPG works:
>
> When you decide whether to trust a signature, there are two questions
> that must be asked:
> a) Does the key used to make this signature really belong to the
> person named in the certificates's UID?
> b) Given that the key is valid, is the person trustworthy?
> GnuPG and the web-of-trust concept only manage information related to
> the first question. GnuPG provides no means of encoding or storing the
> fact that a person is or is not trustworthy; it merely displays the
> UID when verifying a signature, and the user is left to decide whether
> the person should be trusted.
Sort of.
For signatures on keys (certifications), when building the web of trust, you get to specify a trust value (called "ownertrust") that is fed into the web of trust calculations. This is not "do I trust this keyholder", but rather "do I trust this keyholder to make good signatures". This influences which keys are marked as valid in the web of trust ("valid" meaning "we're pretty sure this key belongs to the person who it claims to belong to").
For example, a signature from someone who you trust to make good signatures can cause the key they sign to be valid, but you might want two signatures from two people who you only trust a little bit to make good signatures to make a key valid.
For signatures on data, this doesn't directly apply. A signature from a valid key on data is valid.
So the web of trust seeks to give you a), and you have the ability to customize the web of trust based on your opinion of how well the keyholders make signatures on other keys.
David
From expires2011 at ymail.com Tue Jun 14 21:25:06 2011
From: expires2011 at ymail.com (MFPA)
Date: Tue, 14 Jun 2011 20:25:06 +0100
Subject: Problem with faked-system-time option
In-Reply-To: <201106140133.09131.mailinglisten@hauke-laging.de>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<201106140133.09131.mailinglisten@hauke-laging.de>
Message-ID: <627125469.20110614202506@my_localhost>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi
On Tuesday 14 June 2011 at 12:33:08 AM, in
, Hauke Laging
wrote:
> You should tell apart who has to prove something. Your
> argument is valid if the signer has to prove that he
> has made the signature at (or before or after) a
> certain date and time. His own signature is no proof in
> that case as he can easily fake the timestamp.
> If a third party has to prove that and when the signer
> has signed a document then the signature timestamp is
> perfectly OK.
Suppose the party who originated the document to be signed
subsequently presents (possibly faked) evidence showing the document
to have been prepared later than the signature timestamp. The signer
is now unexpectedly in the position of having to prove something.
- --
Best regards
MFPA mailto:expires2011 at ymail.com
There is no snooze button for a cat that wants breakfast
-----BEGIN PGP SIGNATURE-----
iQE7BAEBCgClBQJN97W8nhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf
a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC
OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB
MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5ptlID/jG5
iQ/mY7tbhArxIDsT7O6RJcQcN6tMHmtQnQuFlPFUzebh57M1xfTBPn+fHnCJBl5h
oDb/qKKU0OXSwcqrBkE42yhlc4KT2KE8bb9Yw/sqezS+qvijwlHqojnuQPtIby+Q
mY8/54Z0Xj4m0HosIbGgjVXEuoEOHv5kGr0fLzb/
=1qYm
-----END PGP SIGNATURE-----
From mail at kerrickstaley.com Tue Jun 14 21:35:51 2011
From: mail at kerrickstaley.com (Kerrick Staley)
Date: Tue, 14 Jun 2011 14:35:51 -0500
Subject: Aspects of trust
In-Reply-To: <19F23BDA-A34A-43D0-BE9E-3CD2CE85AE8A@jabberwocky.com>
References:
<19F23BDA-A34A-43D0-BE9E-3CD2CE85AE8A@jabberwocky.com>
Message-ID:
OK, I think I understand:
Validity and trust are separate, but GnuPG lumps "validity" and
"trust, for the sole purpose of signing others' keys" together into a
single value (which is one of "unknown", "never", "marginal", "full",
and "ultimate"). One can imagine situations in which a key's owner is
"never" trusted to sign others' keys, but one would still like to keep
track of how valid the key itself is ("unknown", "marginal" or
"full"). However, such situations are corner cases, and GnuPG doesn't
provide facilities for dealing with them.
Is this correct?
Thanks,
Kerrick Staley
From kgo at grant-olson.net Tue Jun 14 21:46:20 2011
From: kgo at grant-olson.net (Grant Olson)
Date: Tue, 14 Jun 2011 15:46:20 -0400
Subject: Aspects of trust
In-Reply-To:
References: <19F23BDA-A34A-43D0-BE9E-3CD2CE85AE8A@jabberwocky.com>
Message-ID: <4DF7BA8C.8050106@grant-olson.net>
On 6/14/11 3:35 PM, Kerrick Staley wrote:
> OK, I think I understand:
>
> Validity and trust are separate, but GnuPG lumps "validity" and
> "trust, for the sole purpose of signing others' keys" together into a
> single value (which is one of "unknown", "never", "marginal", "full",
> and "ultimate"). One can imagine situations in which a key's owner is
> "never" trusted to sign others' keys, but one would still like to keep
> track of how valid the key itself is ("unknown", "marginal" or
> "full"). However, such situations are corner cases, and GnuPG doesn't
> provide facilities for dealing with them.
>
> Is this correct?
>
> Thanks,
> Kerrick Staley
No. It's two values.
Validity is established by signing a key, or via web-of-trust calculations.
Trust is a different value, which can be set through --edit-key, or by
running "gpg --update-trustdb"
If you sign a key, establishing validity, but don't give it at least
marginal trust, it won't be used in your web-of-trust calculations.
--
Grant
"I am gravely disappointed. Again you have made me unleash my dogs of war."
From jerome at jeromebaum.com Tue Jun 14 22:19:24 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Tue, 14 Jun 2011 22:19:24 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <627125469.20110614202506@my_localhost>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
Message-ID:
>> You should tell apart who has to prove something. Your
>> argument is valid if the signer has to prove that he
>> has made the signature at (or before or after) a
>> certain date and time. His own signature is no proof in
>> that case as he can easily fake the timestamp.
>
>> If a third party has to prove that and when the signer
>> has signed a document then the signature timestamp is
>> perfectly OK.
>
> Suppose the party who originated the document to be signed
> subsequently presents (possibly faked) evidence showing the document
> to have been prepared later than the signature timestamp. The signer
> is now unexpectedly in the position of having to prove something.
Not really, without any context. Nobody has to prove anything without
that context.
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From rjh at sixdemonbag.org Wed Jun 15 00:28:11 2011
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 14 Jun 2011 15:28:11 -0700
Subject: Problem with faked-system-time option
In-Reply-To:
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
Message-ID: <7eea2c792297b31b4e6448b8b88a9eb3@localhost>
On Tue, 14 Jun 2011 22:19:24 +0200, Jerome Baum
wrote:
> Not really, without any context. Nobody has to prove anything without
> that context.
This is also handwaving the bit about how we have extremely effective
social tools for determining how to handle contested signatures: namely,
court proceedings. This isn't a technological problem so much as a social
one, and modern democracies have developed robust social tools to address
it.
A good rule of thumb is to let technology do what it's good at, and
society do what it's good at, and not expect either to do the other one's
work. :)
From mailinglisten at hauke-laging.de Wed Jun 15 00:34:48 2011
From: mailinglisten at hauke-laging.de (Hauke Laging)
Date: Wed, 15 Jun 2011 00:34:48 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <627125469.20110614202506@my_localhost>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
Message-ID: <201106150034.54220.mailinglisten@hauke-laging.de>
Am Dienstag, 14. Juni 2011, 21:25:06 schrieb MFPA:
> Hi
>
>
> On Tuesday 14 June 2011 at 12:33:08 AM, in
> , Hauke Laging
>
> wrote:
> > You should tell apart who has to prove something. Your
> > argument is valid if the signer has to prove that he
> > has made the signature at (or before or after) a
> > certain date and time. His own signature is no proof in
> > that case as he can easily fake the timestamp.
> >
> > If a third party has to prove that and when the signer
> > has signed a document then the signature timestamp is
> > perfectly OK.
>
> Suppose the party who originated the document to be signed
> subsequently presents (possibly faked) evidence showing the document
> to have been prepared later than the signature timestamp. The signer
> is now unexpectedly in the position of having to prove something.
First: That is no contradiction to what I have said. Have a look at the
offline world: You never(?) sign anything in order to be able to prove that
you have done or have to do something. You sign in order for others to be able
tp prove that you have done or have to do something.
Second: I really doubt that your case is a practical problem. As I said: The
other one's interest is usually to be able to prove that you have signed and
not that you haven't.
A treaty is signed by both parties. So if you have not been fooled into a
faked signature by the other party then you have a signature with a timestamp
close to yours.
And even if you were "accused" of having signed with a faked system time: So
what? This accusation is very dangerous, BTW. Everyone can easily get
trustworthy timestamps for his documents or signatures. So you present a
"proof" that the other one has manipulated and he has a better proof that your
"proof" is fake? Faking such a proof is probably much worse than faking a
timestamp for a normal signature.
An idea: I suggest a standardized signature notation like "timestamp". It
would indicate that you don't make any statement about the signed content
(which even may be encrypted, even against you) but just confirm the time of
existence. That would solve (or reduced) the recently mentioned problem "You
don't know what you sign".
The real problem is IMHO that keys can be revoked (without any bad intention).
If you don't have a third party timestamp or something similar to prove that
the signature has been made before the key was revoked then the signature is
nearly worthless.
That's why I think it would be a good idea to add a signature to all signed
incoming emails. Then at least you know that those signatures can be trusted.
Better would be a third party confirmation. The ISPs could do that. Store the
hash of each delivered email and send you a signed hash list from time to
time.
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:
From jerome at jeromebaum.com Wed Jun 15 01:35:45 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Wed, 15 Jun 2011 01:35:45 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <201106150034.54220.mailinglisten@hauke-laging.de>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
<201106150034.54220.mailinglisten@hauke-laging.de>
Message-ID:
>> Suppose the party who originated the document to be signed
>> subsequently presents (possibly faked) evidence showing the document
>> to have been prepared later than the signature timestamp. The signer
>> is now unexpectedly in the position of having to prove something.
>
> First: That is no contradiction to what I have said. Have a look at the
> offline world: You never(?) sign anything in order to be able to prove that
> you have done or have to do something. You sign in order for others to be able
> tp prove that you have done or have to do something.
Addressing your "?", you might sign a memo regarding a phone call.
Three years later in court, nobody will believe that you can recall
exactly what you and the other party said. However, a written note,
bearing your signature and claimed date, makes your statement that
much more believable. I think we should all remember that proving
something is, like security, not a boolean. Your signature on the memo
isn't very strong as proof. It's also not worthless!
> Second: I really doubt that your case is a practical problem. As I said: The
> other one's interest is usually to be able to prove that you have signed and
> not that you haven't.
+1
> And even if you were "accused" of having signed with a faked system time: So
> what? This accusation is very dangerous, BTW. Everyone can easily get
> trustworthy timestamps for his documents or signatures. So you present a
> "proof" that the other one has manipulated and he has a better proof that your
> "proof" is fake? Faking such a proof is probably much worse than faking a
> timestamp for a normal signature.
Usually it'll be something like "false accusation", "falsification of
documents", etc. You can't say absolutely (without context) that the
fake proof is "much worse" than a fake timestamp. It really, really
depends on the context. Consider that the fake timestamp could also be
considered falsification of documents. An excellent source is the
German Criminal Code, section 267 ("Forgery"), and English translation
of which can be found at:
http://bundesrecht.juris.de/englisch_stgb/englisch_stgb.html#StGBengl_000P267
By the way, is there some Internet law mailing list around? I'm happy
with the "off-topic but Internet law related" posts but we might as
well cross-post for even more insight.
> An idea: I suggest a standardized signature notation like "timestamp". It
> would indicate that you don't make any statement about the signed content
> (which even may be encrypted, even against you) but just confirm the time of
> existence. That would solve (or reduced) the recently mentioned problem "You
> don't know what you sign".
Why modify the standard? Look at stamper (itconsult.co.uk), which just
adds some text to the signed content about no warranty etc. Should
suffice. Of course, not easy to parse, so obviously limited mostly to
human interpretation.
> The real problem is IMHO that keys can be revoked (without any bad intention).
> If you don't have a third party timestamp or something similar to prove that
> the signature has been made before the key was revoked then the signature is
> nearly worthless.
Yes! Says also German legal code when it comes to electronic
signatures. You're supposed to get timestamps from a third-party, and
regularly renew those timestamps. Not just for key revocation,
consider algorithm "decay" and the implicit invalidity introduced by
that.
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From jerome at jeromebaum.com Wed Jun 15 01:46:03 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Wed, 15 Jun 2011 01:46:03 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <7eea2c792297b31b4e6448b8b88a9eb3@localhost>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
<7eea2c792297b31b4e6448b8b88a9eb3@localhost>
Message-ID:
>> Not really, without any context. Nobody has to prove anything without
>> that context.
>
> This is also handwaving the bit about how we have extremely effective
> social tools for determining how to handle contested signatures: namely,
> court proceedings. ?This isn't a technological problem so much as a social
> one, and modern democracies have developed robust social tools to address
> it.
Err, I have to apologize if I misunderstand, not being a native
speaker, but based on http://en.wikipedia.org/wiki/Handwaving I
understand that you're saying something like this?
"You're ignore the fact that X"
(If you didn't mean to say that, ignore the rest of the email and use
the time to hack on gnupg ;)
That really surprises me because my point really was "X". I was saying
that the context is necessary and that context is a court proceeding
or something "equivalent" (in terms of what's going on, not in terms
of the legally binding nature etc).
We are discussing technological means to prove something formally, but
in court you're usually not proving anything in the logical, formal
sense. You're usually just demonstrating something with sufficient
plausibility. Now, "plausible" is definitely subjective, but to be
subjective there has to be a subject. That subject would be, say, a
judge.
All in all the entire discussion -- besides the technical parts about
timestamp notations etc. -- is huge BS unless there's a lawyer in the
audience. This is not to say that BS can't be fun to talk about.
That was my point. I'm definitely not ignoring the context that the
whole signing technology is inside. Of course, if you never meant to
say that and if I just misunderstood, disregard this email. And shame
on you for reading it and not coding!
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From mailinglisten at hauke-laging.de Wed Jun 15 02:59:21 2011
From: mailinglisten at hauke-laging.de (Hauke Laging)
Date: Wed, 15 Jun 2011 02:59:21 +0200
Subject: Problem with faked-system-time option
In-Reply-To:
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106150034.54220.mailinglisten@hauke-laging.de>
Message-ID: <201106150259.35579.mailinglisten@hauke-laging.de>
Am Mittwoch, 15. Juni 2011, 01:35:45 schrieb Jerome Baum:
> > An idea: I suggest a standardized signature notation like "timestamp". It
> > would indicate that you don't make any statement about the signed content
> > (which even may be encrypted, even against you) but just confirm the time
> > of existence. That would solve (or reduced) the recently mentioned
> > problem "You don't know what you sign".
>
> Why modify the standard?
Because signature notations are supposed to be standardized. There aren't any
yet though. Nobody suffers from defining a string to mark timestamp-only
signatures. That is easily parsable both for software and for humans.
Timestamps are an important application. I don't think that there is any equal
solution.
Furthermore this might make signature notations more popular. IMHO they are a
very useful nonetheless nearly unused feature.
To repeat myself again: I also hope that in a not so far future there will be
signature notations which can give detailed (and parsable) information about
the signature policy.
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:
From jerome at jeromebaum.com Wed Jun 15 03:16:16 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Wed, 15 Jun 2011 03:16:16 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <201106150259.35579.mailinglisten@hauke-laging.de>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106150034.54220.mailinglisten@hauke-laging.de>
<201106150259.35579.mailinglisten@hauke-laging.de>
Message-ID:
>> Why modify the standard?
>
> Because signature notations are supposed to be standardized. There aren't any
> yet though. Nobody suffers from defining a string to mark timestamp-only
> signatures. That is easily parsable both for software and for humans.
> Timestamps are an important application. I don't think that there is any equal
> solution.
>
> Furthermore this might make signature notations more popular. IMHO they are a
> very useful nonetheless nearly unused feature.
Good points (I think "notations are supposed to be standardized" is a
bit strong, but there is use in certain standardized notations so I
agree with your point overall).
So, um, let's just start using a non-standardized notation in the "@"
namespace and then wait for standardization? We just need to agree on
a name, maybe Werner can confirm we are free to use
"timestamp-only at gnupg.org"? What would the value mean?
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From rjh at sixdemonbag.org Wed Jun 15 04:26:57 2011
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 14 Jun 2011 22:26:57 -0400
Subject: Problem with faked-system-time option
In-Reply-To:
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
<7eea2c792297b31b4e6448b8b88a9eb3@localhost>
Message-ID: <4DF81871.7050605@sixdemonbag.org>
On 6/14/11 7:46 PM, Jerome Baum wrote:
> Err, I have to apologize if I misunderstand, not being a native
> speaker, but based on http://en.wikipedia.org/wiki/Handwaving I
> understand that you're saying something like this?
>
> "You're ignore the fact that X"
More like "the original poster is ignoring..." I am emphatically in
agreement with your general point, which is that social problems demand
social answers.
My use of "this" was unclear: I apologize for the confusion!
From mailinglisten at hauke-laging.de Wed Jun 15 10:56:21 2011
From: mailinglisten at hauke-laging.de (Hauke Laging)
Date: Wed, 15 Jun 2011 10:56:21 +0200
Subject: Problem with faked-system-time option
In-Reply-To:
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106150259.35579.mailinglisten@hauke-laging.de>
Message-ID: <201106151056.30969.mailinglisten@hauke-laging.de>
Am Mittwoch, 15. Juni 2011, 03:16:16 schrieb Jerome Baum:
> So, um, let's just start using a non-standardized notation in the "@"
> namespace and then wait for standardization?
A good procedure.
> We just need to agree on
> a name, maybe Werner can confirm we are free to use
> "timestamp-only at gnupg.org"? What would the value mean?
Shall I repeat the proposal, or is that a question to Werner? :-)
"The signer makes no statement about the content of the signed data (may not
even have been able to read it) but only confirms its existance at the time of
the given timestamp."
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:
From jerome at jeromebaum.com Wed Jun 15 12:23:40 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Wed, 15 Jun 2011 12:23:40 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <201106151056.30969.mailinglisten@hauke-laging.de>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106150259.35579.mailinglisten@hauke-laging.de>
<201106151056.30969.mailinglisten@hauke-laging.de>
Message-ID:
>> We just need to agree on
>> a name, maybe Werner can confirm we are free to use
>> "timestamp-only at gnupg.org"? What would the value mean?
>
> Shall I repeat the proposal, or is that a question to Werner? :-)
Both.
> "The signer makes no statement about the content of the signed data (may not
> even have been able to read it) but only confirms its existance at the time of
> the given timestamp."
I was referring to the value of the notation. We can set any value so
maybe use it for different "levels" of timestamping (like
certification levels)? Or just blank/null?
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From mailinglisten at hauke-laging.de Wed Jun 15 12:36:33 2011
From: mailinglisten at hauke-laging.de (Hauke Laging)
Date: Wed, 15 Jun 2011 12:36:33 +0200
Subject: Problem with faked-system-time option
In-Reply-To:
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106151056.30969.mailinglisten@hauke-laging.de>
Message-ID: <201106151236.33523.mailinglisten@hauke-laging.de>
Am Mittwoch, 15. Juni 2011, 12:23:40 schrieb Jerome Baum:
> I was referring to the value of the notation. We can set any value so
> maybe use it for different "levels" of timestamping (like
> certification levels)? Or just blank/null?
What would that refer to? You don't have to confirm the current time, do you?
I don't think that there is a need for high precision time stamps. A statement
about the accuracy might be part of the signature policy.
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:
From dkg at fifthhorseman.net Wed Jun 15 17:07:22 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 15 Jun 2011 11:07:22 -0400
Subject: Problem with faked-system-time option
In-Reply-To: <201106151056.30969.mailinglisten@hauke-laging.de>
References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106150259.35579.mailinglisten@hauke-laging.de>
<201106151056.30969.mailinglisten@hauke-laging.de>
Message-ID: <4DF8CAAA.3080103@fifthhorseman.net>
On 06/15/2011 04:56 AM, Hauke Laging wrote:
> Am Mittwoch, 15. Juni 2011, 03:16:16 schrieb Jerome Baum:
>> We just need to agree on
>> a name, maybe Werner can confirm we are free to use
>> "timestamp-only at gnupg.org"? What would the value mean?
>
> Shall I repeat the proposal, or is that a question to Werner? :-)
>
> "The signer makes no statement about the content of the signed data (may not
> even have been able to read it) but only confirms its existance at the time of
> the given timestamp."
I think it is a mistake to make this particular notation, when signature
type 0x40 already exists:
https://tools.ietf.org/html/rfc4880#page-21
---------------
0x40: Timestamp signature.
This signature is only meaningful for the timestamp contained in
it.
---------------
I'm happy with the proposal to start using notations more, and creating
a culture of publishing well-defined semantics around them; i just don't
think this particular goal is well-served by notations, since it is
already in the core protocol specification.
Regards,
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL:
From jerome at jeromebaum.com Wed Jun 15 17:26:24 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Wed, 15 Jun 2011 17:26:24 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <4DF8CAAA.3080103@fifthhorseman.net>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106150259.35579.mailinglisten@hauke-laging.de>
<201106151056.30969.mailinglisten@hauke-laging.de>
<4DF8CAAA.3080103@fifthhorseman.net>
Message-ID:
How did we miss that?
(Mobile/Handy)
Am 15.06.2011 17:15 schrieb "Daniel Kahn Gillmor" :
On 06/15/2011 04:56 AM, Hauke Laging wrote:
> Am Mittwoch, 15. Juni 2011, 03:16:16 schrieb Jerome Ba...
>> We just need to agree on
>> a name, maybe Werner can confirm we are free to use
>> "timestamp-onl...
I think it is a mistake to make this particular notation, when signature
type 0x40 already exists:
https://tools.ietf.org/html/rfc4880#page-21
---------------
0x40: Timestamp signature.
This signature is only meaningful for the timestamp contained in
it.
---------------
I'm happy with the proposal to start using notations more, and creating
a culture of publishing well-defined semantics around them; i just don't
think this particular goal is well-served by notations, since it is
already in the core protocol specification.
Regards,
--dkg
_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mailinglisten at hauke-laging.de Wed Jun 15 17:39:47 2011
From: mailinglisten at hauke-laging.de (Hauke Laging)
Date: Wed, 15 Jun 2011 17:39:47 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <4DF8CAAA.3080103@fifthhorseman.net>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106151056.30969.mailinglisten@hauke-laging.de>
<4DF8CAAA.3080103@fifthhorseman.net>
Message-ID: <201106151739.52559.mailinglisten@hauke-laging.de>
Am Mittwoch, 15. Juni 2011, 17:07:22 schrieb Daniel Kahn Gillmor:
> I think it is a mistake to make this particular notation, when signature
> type 0x40 already exists:
>
> https://tools.ietf.org/html/rfc4880#page-21
>
> ---------------
> 0x40: Timestamp signature.
> This signature is only meaningful for the timestamp contained in
> it.
> ---------------
Funny.
Is it possible to create such signatures with GnuPG? How?
CU
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:
From dshaw at jabberwocky.com Wed Jun 15 21:09:51 2011
From: dshaw at jabberwocky.com (David Shaw)
Date: Wed, 15 Jun 2011 15:09:51 -0400
Subject: Problem with faked-system-time option
In-Reply-To:
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106150034.54220.mailinglisten@hauke-laging.de>
<201106150259.35579.mailinglisten@hauke-laging.de>
Message-ID: <0CD8BC7C-DBC4-4398-8CF1-48308694C2B3@jabberwocky.com>
On Jun 14, 2011, at 9:16 PM, Jerome Baum wrote:
>>> Why modify the standard?
>>
>> Because signature notations are supposed to be standardized. There aren't any
>> yet though. Nobody suffers from defining a string to mark timestamp-only
>> signatures. That is easily parsable both for software and for humans.
>> Timestamps are an important application. I don't think that there is any equal
>> solution.
>>
>> Furthermore this might make signature notations more popular. IMHO they are a
>> very useful nonetheless nearly unused feature.
>
> Good points (I think "notations are supposed to be standardized" is a
> bit strong, but there is use in certain standardized notations so I
> agree with your point overall).
>
> So, um, let's just start using a non-standardized notation in the "@"
> namespace and then wait for standardization?
A minor point about notations. The "@" notations are not non-standardized. They are just not standardized by the IETF via the RFC process. The "@" notations are owned by whatever domain appears on the right hand size of the string. So mynotation at example.com is defined and controlled by whoever runs example.com. It is completely appropriate for you to define a notation under any domain (including your own) that gives you permission to do so. These notations are not in any way less good than an IETF notation.
For example, the PGP people saw the need for a notation to hint whether a person can understand PGP/MIME or only inline. They drew up a spec for the preferred-email-encoding at pgp.com notation, and published it. It's their standard.
David
From dshaw at jabberwocky.com Wed Jun 15 21:10:45 2011
From: dshaw at jabberwocky.com (David Shaw)
Date: Wed, 15 Jun 2011 15:10:45 -0400
Subject: Problem with faked-system-time option
In-Reply-To: <201106151739.52559.mailinglisten@hauke-laging.de>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106151056.30969.mailinglisten@hauke-laging.de>
<4DF8CAAA.3080103@fifthhorseman.net>
<201106151739.52559.mailinglisten@hauke-laging.de>
Message-ID: <70B3FD04-2CFF-4B9D-906C-A32292459FBF@jabberwocky.com>
On Jun 15, 2011, at 11:39 AM, Hauke Laging wrote:
> Am Mittwoch, 15. Juni 2011, 17:07:22 schrieb Daniel Kahn Gillmor:
>
>> I think it is a mistake to make this particular notation, when signature
>> type 0x40 already exists:
>>
>> https://tools.ietf.org/html/rfc4880#page-21
>>
>> ---------------
>> 0x40: Timestamp signature.
>> This signature is only meaningful for the timestamp contained in
>> it.
>> ---------------
>
> Funny.
>
> Is it possible to create such signatures with GnuPG? How?
It is not currently possible. The code to do it is trivial, but nobody has really pushed for it before.
That said I'd probably suggest notations for this, even though 0x40 exists in the standard. 0x40 signatures are a bit of a leftover tail in the standard, and are not well specified (0x40 sigclass - is it a binary signature? a text signature?). Using notations also gives you more flexibility since you can do key=value stuff and specify different variations on timestamp signatures.
David
From mailinglisten at hauke-laging.de Wed Jun 15 21:30:38 2011
From: mailinglisten at hauke-laging.de (Hauke Laging)
Date: Wed, 15 Jun 2011 21:30:38 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <70B3FD04-2CFF-4B9D-906C-A32292459FBF@jabberwocky.com>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106151739.52559.mailinglisten@hauke-laging.de>
<70B3FD04-2CFF-4B9D-906C-A32292459FBF@jabberwocky.com>
Message-ID: <201106152130.44220.mailinglisten@hauke-laging.de>
Am Mittwoch, 15. Juni 2011, 21:10:45 schrieb David Shaw:
> It is not currently possible. The code to do it is trivial, but nobody has
> really pushed for it before.
Even if the next GnuPG version allowed to do that it might be almost useless
if the older and other implementations do not show it (cannot show it at all).
But I don't know how they react to such a signature packet.
Notations can be seen (and set) in old and other implementations (are not
shown by default, though).
However this may be done: It makes sense that GnuPG prints a hint/warning if
such a standard notation is used even if notations are not shown.
> and are not well specified (0x40 sigclass - is it a binary
> signature? a text signature?).
How is this a problem? Does it matter for that purpose (or any other) how a
signature is encoded (does "text signature" mean --armor?)?
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:
From dkg at fifthhorseman.net Wed Jun 15 21:50:20 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 15 Jun 2011 15:50:20 -0400
Subject: Problem with faked-system-time option
In-Reply-To: <70B3FD04-2CFF-4B9D-906C-A32292459FBF@jabberwocky.com>
References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106151056.30969.mailinglisten@hauke-laging.de> <4DF8CAAA.3080103@fifthhorseman.net> <201106151739.52559.mailinglisten@hauke-laging.de>
<70B3FD04-2CFF-4B9D-906C-A32292459FBF@jabberwocky.com>
Message-ID: <4DF90CFC.5060002@fifthhorseman.net>
On 06/15/2011 03:10 PM, David Shaw wrote:
> That said I'd probably suggest notations for this, even though 0x40 exists in the standard. 0x40 signatures are a bit of a leftover tail in the standard, and are not well specified (0x40 sigclass - is it a binary signature? a text signature?). Using notations also gives you more flexibility since you can do key=value stuff and specify different variations on timestamp signatures.
Note that if you do decide to use a notation for this, you should mark
the relevant notation subpacket as "critical", so that the signature is
not interpreted by an unwitting implementation as meaning something
other than the specific declaration:
https://tools.ietf.org/html/rfc4880#page-26
Currently, the proposal as it stands is to use a notation within the
@gnupg.org domain. It would be good to get verification from the
maintainers/owners of that domain to know if they're OK with the
specific proposal.
According to whois, that's Werner and g10 code GmbH. Werner, can you
comment on any policy for use of @gnupg.org notations? Would it help if
someone set up a registry someplace documenting the specific notations?
I'm willing to set up such a registry on a domain i control, but i'm not
sure people would want to use it because my domains aren't as strongly
associated with OpenPGP as gnupg.org.
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL:
From expires2011 at ymail.com Wed Jun 15 21:55:45 2011
From: expires2011 at ymail.com (MFPA)
Date: Wed, 15 Jun 2011 20:55:45 +0100
Subject: Problem with faked-system-time option
In-Reply-To:
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
Message-ID: <992640380.20110615205545@my_localhost>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi
On Tuesday 14 June 2011 at 9:19:24 PM, in
, Jerome Baum
wrote:
> Not really, without any context. Nobody has to prove
> anything without that context.
The context was simple: for some reason it mattered when the signature
was made. I was outlining a hypothetical situation in broad terms
without getting hung up on the details of a specific example, so I
don't care why the signature time/date mattered.
- --
Best regards
MFPA mailto:expires2011 at ymail.com
Live your life as though every day it was your last.
-----BEGIN PGP SIGNATURE-----
iQE7BAEBCgClBQJN+Q5VnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf
a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC
OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB
MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pBnID/10i
wyAIcrx6mblSLHRbx0VtaBq+y9/3TlmlxlC4dm5nuFOTzyJ/tnAEoqt0N+tSEQU4
MXs9iY9fxbUSM43zgwXvcmbta0YtmjytfKnGXKSbF4eZHyGH7IJbWJhDa3m73ugd
2HdlKzqhtylgR+q6SU5eeYQksDFla13aziEJp1Yv
=Jx/U
-----END PGP SIGNATURE-----
From jerome at jeromebaum.com Wed Jun 15 21:59:49 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Wed, 15 Jun 2011 21:59:49 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <992640380.20110615205545@my_localhost>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
<992640380.20110615205545@my_localhost>
Message-ID:
>> Not really, without any context. Nobody has to prove
>> anything without that context.
>
>
> The context was simple: for some reason it mattered when the signature
> was made. I was outlining a hypothetical situation in broad terms
> without getting hung up on the details of a specific example, so I
> don't care why the signature time/date mattered.
Um, yeah, so you used a blurry specification of the problem that you
could adjust as needed for your arguments -- possibly in contradicting
ways? I wouldn't consider "what is being proven and who has an
interest in proving that -- i.e. who will cooperate" as a "detail",
but as a minimal basis for discussion.
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From expires2011 at ymail.com Wed Jun 15 22:12:02 2011
From: expires2011 at ymail.com (MFPA)
Date: Wed, 15 Jun 2011 21:12:02 +0100
Subject: Problem with faked-system-time option
In-Reply-To: <7eea2c792297b31b4e6448b8b88a9eb3@localhost>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
<7eea2c792297b31b4e6448b8b88a9eb3@localhost>
Message-ID: <589083827.20110615211202@my_localhost>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi
On Tuesday 14 June 2011 at 11:28:11 PM, in
, Robert J. Hansen
wrote:
> On Tue, 14 Jun 2011 22:19:24 +0200, Jerome Baum
> wrote:
>> Not really, without any context. Nobody has to prove anything without
>> that context.
> This is also handwaving the bit about how we have
> extremely effective social tools for determining how to
> handle contested signatures: namely, court proceedings.
> This isn't a technological problem so much as a social
> one, and modern democracies have developed robust
> social tools to address it.
Court proceedings tend to require evidence. The use of a timestamping
service could provide this.
> A good rule of thumb is to let technology do what it's
> good at, and society do what it's good at, and not
> expect either to do the other one's work. :)
Given that technology is required to produce an OpenPGP signature, it
seems reasonable (to me) to suggest using technology to provide a
verifiable time period for when that signature was made. Technology
can be a tool to assist society in its work.
- --
Best regards
MFPA mailto:expires2011 at ymail.com
Is it possible to be a closet claustrophobic?
-----BEGIN PGP SIGNATURE-----
iQE7BAEBCgClBQJN+RIYnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf
a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC
OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB
MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5p80cEAMUj
u0/Upk+2W1f7qlMHTdh7w1vZh64HBrX42WFlqu1pWHn7deDRRimsK6c4cj42drMU
TmnUKXCymeoKP4nnee2OFDgF0ECTfxIcznlGTd6Ridrq11mDbPdfdHwyp0wh2ZXI
LqCHb8jMfYIVM4MstzTe2oQ4o22jb5DNcBMepryg
=Jyrk
-----END PGP SIGNATURE-----
From dshaw at jabberwocky.com Wed Jun 15 23:14:54 2011
From: dshaw at jabberwocky.com (David Shaw)
Date: Wed, 15 Jun 2011 17:14:54 -0400
Subject: Problem with faked-system-time option
In-Reply-To: <201106152130.44220.mailinglisten@hauke-laging.de>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106151739.52559.mailinglisten@hauke-laging.de>
<70B3FD04-2CFF-4B9D-906C-A32292459FBF@jabberwocky.com>
<201106152130.44220.mailinglisten@hauke-laging.de>
Message-ID: <7A0CC342-C083-417C-95FA-DD77AA30AD81@jabberwocky.com>
On Jun 15, 2011, at 3:30 PM, Hauke Laging wrote:
> Am Mittwoch, 15. Juni 2011, 21:10:45 schrieb David Shaw:
>> and are not well specified (0x40 sigclass - is it a binary
>> signature? a text signature?).
>
> How is this a problem? Does it matter for that purpose (or any other) how a
> signature is encoded (does "text signature" mean --armor?)?
It matters for text input. That's why there are actually two different forms of data signature: 0x00 for data, and 0x01 for text where line endings are canonicalized. This is so a signed text message created on one platform is verifiable on a different platform with different line endings.
There is only one 0x40, so it's either data or text, but cannot be both.
David
From expires2011 at ymail.com Wed Jun 15 23:16:39 2011
From: expires2011 at ymail.com (MFPA)
Date: Wed, 15 Jun 2011 22:16:39 +0100
Subject: Problem with faked-system-time option
In-Reply-To:
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
<992640380.20110615205545@my_localhost>
Message-ID: <1015435212.20110615221639@my_localhost>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi
On Wednesday 15 June 2011 at 8:59:49 PM, in
, Jerome Baum
wrote:
> Um, yeah, so you used a blurry specification of the
> problem
The "problem" is very simple: the timestamp contained in an OpenPGP
signature cannot be relied upon as accurate without independent
corroboration. An example of such corroboration is to use a
timestamping service that is trusted by the relevant parties.
You asserted that the signer's own signature timestamp was sufficient
when a third party needs to prove when the document was signed. I
replied with the bare bones of a scenario where the third party brings
evidence that suggests the signature timestamp to be incorrect, so
that the signer needs to refute that evidence.
> that you could adjust as needed for your
> arguments -- possibly in contradicting ways?
The "problem" is not sufficiently complex to allow this.
> I wouldn't
> consider "what is being proven and who has an interest
> in proving that -- i.e. who will cooperate" as a
> "detail", but as a minimal basis for discussion.
The "what is being proven" is when the document was signed.
The "who has an interest" matters only if it affects the proposed
solution. As an example, if an independent timestamping service can be
shown to be sufficiently reliable, it could provide the proof
regardless of which party has an interest in using that proof.
- --
Best regards
MFPA mailto:expires2011 at ymail.com
Time flies like an arrow. Fruit flies like a banana. -- Groucho Marx
-----BEGIN PGP SIGNATURE-----
iQE7BAEBCgClBQJN+SFHnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf
a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC
OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB
MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5paRcD/A1a
vGREESSNMEkqWxV6+4pM16e+BuoVRB5CS2hde2MB62AGMIPhmAq5PX7Z0nDNUi9q
xbgfeeEWwN8MyhXPuW7Tn3wpfneigLCppshdnzzSeoiTidA61hmOYiwoGnJCsx7M
48nnAJThfd1THyMOKKnG08uHuuhAOypRHrJB7HHY
=l7mc
-----END PGP SIGNATURE-----
From dshaw at jabberwocky.com Wed Jun 15 23:19:33 2011
From: dshaw at jabberwocky.com (David Shaw)
Date: Wed, 15 Jun 2011 17:19:33 -0400
Subject: Problem with faked-system-time option
In-Reply-To: <4DF90CFC.5060002@fifthhorseman.net>
References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106151056.30969.mailinglisten@hauke-laging.de> <4DF8CAAA.3080103@fifthhorseman.net> <201106151739.52559.mailinglisten@hauke-laging.de>
<70B3FD04-2CFF-4B9D-906C-A32292459FBF@jabberwocky.com>
<4DF90CFC.5060002@fifthhorseman.net>
Message-ID: <0446B244-5607-416D-9C83-2D82A434189A@jabberwocky.com>
On Jun 15, 2011, at 3:50 PM, Daniel Kahn Gillmor wrote:
> On 06/15/2011 03:10 PM, David Shaw wrote:
>> That said I'd probably suggest notations for this, even though 0x40 exists in the standard. 0x40 signatures are a bit of a leftover tail in the standard, and are not well specified (0x40 sigclass - is it a binary signature? a text signature?). Using notations also gives you more flexibility since you can do key=value stuff and specify different variations on timestamp signatures.
>
> Note that if you do decide to use a notation for this, you should mark
> the relevant notation subpacket as "critical", so that the signature is
> not interpreted by an unwitting implementation as meaning something
> other than the specific declaration:
I'm not sure I agree with that. Essentially, this notation is a way for a user to say "This is what I mean by this signature". Meaning and intent is difficult for GnuPG to divine :)
In practice, the critical flag tells GnuPG to reject the signature (mark it as invalid) if it doesn't know about the notation. Why does GnuPG need to know about this notation? Or more specifically, what should GnuPG do differently for a timestamp-only signature compared to a regular signature?
I'm not against the user deciding to mark the notation as critical if he chooses to do so. I just wouldn't have it automatically and always critical. Unless I'm misunderstanding your point, I don't see that the semantics of a timestamp notation require that.
David
From rjh at sixdemonbag.org Wed Jun 15 23:32:55 2011
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 15 Jun 2011 14:32:55 -0700
Subject: Problem with faked-system-time option
In-Reply-To: <1015435212.20110615221639@my_localhost>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
<992640380.20110615205545@my_localhost>
<1015435212.20110615221639@my_localhost>
Message-ID:
On Wed, 15 Jun 2011 22:16:39 +0100, MFPA wrote:
> The "problem" is very simple: the timestamp contained in an OpenPGP
> signature cannot be relied upon as accurate without independent
> corroboration.
Corroboration is simply not possible. A timestamp cannot be proven good
or bad. You ultimately have to rely on someone's word: all you get to do
is choose whose word you will accept and why.
> An example of such corroboration is to use a
> timestamping service that is trusted by the relevant parties.
This isn't really "corroboration" so much as it is, "I choose to trust
someone else."
> You asserted that the signer's own signature timestamp was sufficient
> when a third party needs to prove when the document was signed.
And it is, assuming the third party trusts the signer. If the third party
doesn't trust the signer, then we've left the realm of problems OpenPGP can
solve and we're into the realm of problems legal systems exist to solve.
("I don't trust your timestamp! You didn't use my preferred timestamping
service! I'm not going to honor this agreement!" "Fine, bucko: see you in
court!")
> I replied with the bare bones of a scenario where the third party
> brings evidence that suggests the signature timestamp to be
> incorrect, so that the signer needs to refute that evidence.
Quite probably the signer *shouldn't* refute that. Refuting claims
doesn't convince anyone of anything except a particular claim is not
supported by facts -- it doesn't prove the claim is actually wrong. "Okay,
so you've convinced me not to trust this evidence saying the timestamp is
incorrect: but you haven't done anything to persuade me the timestamp is
correct, which is actually the important thing."
(This is also why, e.g., it makes no sense to argue with a conspiracy
theorist: with a lot of effort you can prove the conspiracy theory to be
*unsupported*, but you can't actually prove it *wrong*.)
> As an example, if an independent timestamping service can be
> shown to be sufficiently reliable, it could provide the proof
> regardless of which party has an interest in using that proof.
It can't provide proof. It can't even provide evidence. It can only
provide a data point which both parties stipulate as being uncontested --
and nothing is easier to reverse than a stipulation. ("Well, sure, I
trusted Honest Al's Timestamping Service... up until I saw they signed
THAT. I repudiate this timestamp! I don't trust Honest Al's Timestamping
Service any more!")
From dkg at fifthhorseman.net Wed Jun 15 23:33:00 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 15 Jun 2011 17:33:00 -0400
Subject: Problem with faked-system-time option
In-Reply-To: <0446B244-5607-416D-9C83-2D82A434189A@jabberwocky.com>
References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106151056.30969.mailinglisten@hauke-laging.de> <4DF8CAAA.3080103@fifthhorseman.net> <201106151739.52559.mailinglisten@hauke-laging.de> <70B3FD04-2CFF-4B9D-906C-A32292459FBF@jabberwocky.com> <4DF90CFC.5060002@fifthhorseman.net>
<0446B244-5607-416D-9C83-2D82A434189A@jabberwocky.com>
Message-ID: <4DF9250C.7040308@fifthhorseman.net>
On 06/15/2011 05:19 PM, David Shaw wrote:
> I'm not sure I agree with that. Essentially, this notation is a way for a user to say "This is what I mean by this signature". Meaning and intent is difficult for GnuPG to divine :)
If we're going with the semantics of 0x40 (but without the text/binary
ambiguity:
This signature is only meaningful for the timestamp contained in it.
Then you'd want such a signature only to be interpreted as
valid/acceptable in a context in which the *only* thing being checked
was the timestamp.
For example, if i set up a timestamping service that makes these
signatures with a subkey of my own key, i would not want those
timestamping signatures to be considered as valid signatures by, say,
the debian build queue.
Another example: If you were to set up such a timestamping service with
a subkey, i would not want my mail user agent to say "good signature
from David Shaw" if an e-mail was signed by that service.
So my point is: mark it as critical; then tools which know what to do
with a timestamp signature will use it fine, and other, existing tools
will not misinterpret it as any other intent.
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL:
From rjh at sixdemonbag.org Wed Jun 15 23:38:00 2011
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 15 Jun 2011 14:38:00 -0700
Subject: Problem with faked-system-time option
In-Reply-To: <589083827.20110615211202@my_localhost>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
<7eea2c792297b31b4e6448b8b88a9eb3@localhost>
<589083827.20110615211202@my_localhost>
Message-ID: <49d3d13e0743dca7849ce69ead91eb6c@localhost>
On Wed, 15 Jun 2011 21:12:02 +0100, MFPA wrote:
> Court proceedings tend to require evidence. The use of a timestamping
> service could provide this.
As soon as you're able to prove to a court that a timestamping service's
clock is fair and honest, sure.
But if you're able to prove that a timestamping service's clock is fair
and honest, then the original signer could use the same process to prove
*his* timestamp is fair and honest -- and thereby remove the need for a
timestamping service in the first place.
Your argument leads to a paradox. If a timestamping service's clock can
be proven to be fair and honest, then there is no need for timestamping
services.
Timestamp authorities are *trusted* to be fair and honest -- but that's
not the same thing as *proven* to be, and nothing in the world is easier to
revoke than trust.
From jerome at jeromebaum.com Wed Jun 15 23:51:44 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Wed, 15 Jun 2011 23:51:44 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <49d3d13e0743dca7849ce69ead91eb6c@localhost>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
<7eea2c792297b31b4e6448b8b88a9eb3@localhost>
<589083827.20110615211202@my_localhost>
<49d3d13e0743dca7849ce69ead91eb6c@localhost>
Message-ID:
>> Court proceedings tend to require evidence. The use of a timestamping
>> service could provide this.
>
> As soon as you're able to prove to a court that a timestamping service's
> clock is fair and honest, sure.
See itconsult.co.uk/stamper.htm
If you only care about the week (for instance), then a timestamping
service that publishes signatures on a weekly basis doesn't require a
correct clock. In fact, a realistic question might be "did X happen
before Y", and a simple hash list of signatures, published after each
new signature, would suffice. No need for a clock at all.
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From dshaw at jabberwocky.com Wed Jun 15 23:54:17 2011
From: dshaw at jabberwocky.com (David Shaw)
Date: Wed, 15 Jun 2011 17:54:17 -0400
Subject: Problem with faked-system-time option
In-Reply-To: <4DF9250C.7040308@fifthhorseman.net>
References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106151056.30969.mailinglisten@hauke-laging.de> <4DF8CAAA.3080103@fifthhorseman.net> <201106151739.52559.mailinglisten@hauke-laging.de> <70B3FD04-2CFF-4B9D-906C-A32292459FBF@jabberwocky.com> <4DF90CFC.5060002@fifthhorseman.net>
<0446B244-5607-416D-9C83-2D82A434189A@jabberwocky.com>
<4DF9250C.7040308@fifthhorseman.net>
Message-ID: <399BB708-B2E7-449A-A4C1-F951B4130968@jabberwocky.com>
On Jun 15, 2011, at 5:33 PM, Daniel Kahn Gillmor wrote:
> On 06/15/2011 05:19 PM, David Shaw wrote:
>> I'm not sure I agree with that. Essentially, this notation is a way for a user to say "This is what I mean by this signature". Meaning and intent is difficult for GnuPG to divine :)
>
> If we're going with the semantics of 0x40 (but without the text/binary
> ambiguity:
>
> This signature is only meaningful for the timestamp contained in it.
>
> Then you'd want such a signature only to be interpreted as
> valid/acceptable in a context in which the *only* thing being checked
> was the timestamp.
>
> For example, if i set up a timestamping service that makes these
> signatures with a subkey of my own key, i would not want those
> timestamping signatures to be considered as valid signatures by, say,
> the debian build queue.
>
> Another example: If you were to set up such a timestamping service with
> a subkey, i would not want my mail user agent to say "good signature
> from David Shaw" if an e-mail was signed by that service.
>
> So my point is: mark it as critical; then tools which know what to do
> with a timestamp signature will use it fine, and other, existing tools
> will not misinterpret it as any other intent.
I think that's fine and reasonable. My only difference is that I would not mandate it being marked as critical, and let the signer decide whether they want that or not. Note that marking it as critical means that all current code will reject it. Updating that code won't happen quickly.
My question still remains though: what should GnuPG do differently for a timestamp-only signature compared to a regular signature? Print "good timestamp from David Shaw" instead of "good signature from David Shaw"?
Out of curiosity, as long as we're talking about things that current code will reject, does the 0x50 signature meet the semantics desired here? This all sounds vaguely notary-like ("I saw this document on such-and-such date") to me, and the intent of 0x50 is a notary signature. The nice thing about a 0x50 signature is that it is a signature on a signature, so the timestamp service doesn't need to see the document - just the (detached) signature.
(To be sure, you could implement this this with the current timestamp services by hashing the original document and/or signature and getting the hash timestamped)
David
From mailinglisten at hauke-laging.de Wed Jun 15 23:58:31 2011
From: mailinglisten at hauke-laging.de (Hauke Laging)
Date: Wed, 15 Jun 2011 23:58:31 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <0446B244-5607-416D-9C83-2D82A434189A@jabberwocky.com>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<4DF90CFC.5060002@fifthhorseman.net>
<0446B244-5607-416D-9C83-2D82A434189A@jabberwocky.com>
Message-ID: <201106152358.44002.mailinglisten@hauke-laging.de>
Am Mittwoch, 15. Juni 2011, 23:19:33 schrieb David Shaw:
> Or more specifically, what should GnuPG do
> differently for a timestamp-only signature compared to a regular
> signature?
It should at least change the message from
"Good signature from ..."
to
"Good timestamp-only signature from..."
in order to help the user avoid a misunderstanding. It is good if you can show
that you acted correctly (used this notation) and someone has misunderstood
what you did. It is better to prevent the other one from misunderstanding it
at all.
> I'm not against the user deciding to mark the notation as critical if he
> chooses to do so. I just wouldn't have it automatically and always
> critical.
I support that. A non-critical timestamp signature is technically usable on
"all" systems, a critical one would be usable on few only. That's IMHO a much
bigger problem then the non-recognition of the feature. After all the correct
understanding of a signature is up to the recipient anyway (impossible without
the signature policy). This notation allows you to skip checking the policy.
I would like "popular" notations to be mentioned in the GnuPG documentation. I
guess that will not take much space. :-) Or at least a document describing
those should be given.
You also might consider introducing --timestamp-only (easy to remember) or
similar as an alias for --sig-notation timestamp-only at gnupg.org=default.
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:
From jerome at jeromebaum.com Wed Jun 15 23:58:27 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Wed, 15 Jun 2011 23:58:27 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <1015435212.20110615221639@my_localhost>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
<992640380.20110615205545@my_localhost>
<1015435212.20110615221639@my_localhost>
Message-ID:
>> Um, yeah, so you used a blurry specification of the
>> problem
>
> The "problem" is very simple: the timestamp contained in an OpenPGP
> signature cannot be relied upon as accurate without independent
> corroboration. An example of such corroboration is to use a
> timestamping service that is trusted by the relevant parties.
So, we timestamp stuff for fun? Whether something can be "relied upon"
depends on what you're going to do with the accuracy assumption. I can
timestamp an empty document and -- besides stuff like "the key must
have existed before the timestamp" or "I must have started or
scheduled a task for the time in the timestamp" -- you can trust the
timestamp to be fully correct without consequence. There would be no
point in contesting. There would, of course, be no point for you in
trusting the timestamp, but it wouldn't be a problem either.
> You asserted that the signer's own signature timestamp was sufficient
> when a third party needs to prove when the document was signed.
When?
> I
> replied with the bare bones of a scenario where the third party brings
> evidence that suggests the signature timestamp to be incorrect, so
> that the signer needs to refute that evidence.
The signer doesn't need to do anything until, say, there is a chance
of falsification charges.
>> I wouldn't
>> consider "what is being proven and who has an interest
>> in proving that -- i.e. who will cooperate" as a
>> "detail", but as a minimal basis for discussion.
>
> The "what is being proven" is when the document was signed.
Correct.
> The "who has an interest" matters only if it affects the proposed
> solution. As an example, if an independent timestamping service can be
> shown to be sufficiently reliable, it could provide the proof
> regardless of which party has an interest in using that proof.
"sufficiently"? For whom? Who has this interest and who decides what
is sufficient?
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From jerome at jeromebaum.com Thu Jun 16 00:02:27 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Thu, 16 Jun 2011 00:02:27 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <399BB708-B2E7-449A-A4C1-F951B4130968@jabberwocky.com>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106151056.30969.mailinglisten@hauke-laging.de>
<4DF8CAAA.3080103@fifthhorseman.net>
<201106151739.52559.mailinglisten@hauke-laging.de>
<70B3FD04-2CFF-4B9D-906C-A32292459FBF@jabberwocky.com>
<4DF90CFC.5060002@fifthhorseman.net>
<0446B244-5607-416D-9C83-2D82A434189A@jabberwocky.com>
<4DF9250C.7040308@fifthhorseman.net>
<399BB708-B2E7-449A-A4C1-F951B4130968@jabberwocky.com>
Message-ID:
> Out of curiosity, as long as we're talking about things that current code will reject, does the 0x50 signature meet the semantics desired here? ?This all sounds vaguely notary-like ("I saw this document on such-and-such date") to me, and the intent of 0x50 is a notary signature. ?The nice thing about a 0x50 signature is that it is a signature on a signature, so the timestamp service doesn't need to see the document - just the (detached) signature.
My understanding of a notary's job would include "I trust this key to
be valid, in possession only of the person named in the uid, while
that person was in sufficient mental state, not being threatened at
gun-point, ..." -- why should we use a signature type that could be
misinterpreted, when there is a "timestamp" signature type that fits
our needs exactly?
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From jerome at jeromebaum.com Thu Jun 16 00:08:48 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Thu, 16 Jun 2011 00:08:48 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <201106152358.44002.mailinglisten@hauke-laging.de>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<4DF90CFC.5060002@fifthhorseman.net>
<0446B244-5607-416D-9C83-2D82A434189A@jabberwocky.com>
<201106152358.44002.mailinglisten@hauke-laging.de>
Message-ID:
> You also might consider introducing --timestamp-only (easy to remember) or
> similar as an alias for --sig-notation timestamp-only at gnupg.org=default.
So back to timestamp-only at gnupg.org (vs. 0x40 or 0x50), and blatantly
abusing gnupg.org, is other data of relevance? e.g.:
timestamp-resolution at gnupg.org =
As for critical or not, I would vote for critical. Let's consider the
average OpenPGP user (*any* implementation, not just gnupg). Will they
care to display notations on data signatures, or will they see "good"
and take that key to be the author's?
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From dshaw at jabberwocky.com Thu Jun 16 00:40:06 2011
From: dshaw at jabberwocky.com (David Shaw)
Date: Wed, 15 Jun 2011 18:40:06 -0400
Subject: Problem with faked-system-time option
In-Reply-To:
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106151056.30969.mailinglisten@hauke-laging.de>
<4DF8CAAA.3080103@fifthhorseman.net>
<201106151739.52559.mailinglisten@hauke-laging.de>
<70B3FD04-2CFF-4B9D-906C-A32292459FBF@jabberwocky.com>
<4DF90CFC.5060002@fifthhorseman.net>
<0446B244-5607-416D-9C83-2D82A434189A@jabberwocky.com>
<4DF9250C.7040308@fifthhorseman.net>
<399BB708-B2E7-449A-A4C1-F951B4130968@jabberwocky.com>
Message-ID: <456716BE-FE41-4F8E-9194-D628D38EDD56@jabberwocky.com>
On Jun 15, 2011, at 6:02 PM, Jerome Baum wrote:
>> Out of curiosity, as long as we're talking about things that current code will reject, does the 0x50 signature meet the semantics desired here? This all sounds vaguely notary-like ("I saw this document on such-and-such date") to me, and the intent of 0x50 is a notary signature. The nice thing about a 0x50 signature is that it is a signature on a signature, so the timestamp service doesn't need to see the document - just the (detached) signature.
>
> My understanding of a notary's job would include "I trust this key to
> be valid, in possession only of the person named in the uid, while
> that person was in sufficient mental state, not being threatened at
> gun-point, ..."
The 0x50 signature should not be interpreted as the output of a real-world notary (whose task varies in different locations anyway). It is merely analogous to a notary in that the "notary" sees a signature, and affixes a seal to it indicating "I saw this" (oversimplification, but forgive me).
OpenPGP calls this signature a "Third-Party Confirmation signature". It is merely a signature on a signature for whatever purpose is desired by the signer.
> -- why should we use a signature type that could be
> misinterpreted, when there is a "timestamp" signature type that fits
> our needs exactly?
Because as already noted, the 0x40 signature is not fully specified in the standard. There is not enough information to know how to generate one.
David
From mailinglisten at hauke-laging.de Thu Jun 16 00:58:09 2011
From: mailinglisten at hauke-laging.de (Hauke Laging)
Date: Thu, 16 Jun 2011 00:58:09 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <399BB708-B2E7-449A-A4C1-F951B4130968@jabberwocky.com>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<4DF9250C.7040308@fifthhorseman.net>
<399BB708-B2E7-449A-A4C1-F951B4130968@jabberwocky.com>
Message-ID: <201106160058.09815.mailinglisten@hauke-laging.de>
Am Mittwoch, 15. Juni 2011, 23:54:17 schrieb David Shaw:
> I think that's fine and reasonable. My only difference is that I would not
> mandate it being marked as critical, and let the signer decide whether
> they want that or not. Note that marking it as critical means that all
> current code will reject it. Updating that code won't happen quickly.
Maybe both intentions (alert and compatibility) can be combined at another
level: Isn't it possible to create two signatures, one with the notation
marked critical the other one not? Except for the problem that some old PGP
version crashes when seeing more than one sig... Recognizing implementations
would give notice of two valid signatures (and maybe supress one), the other
ones of one valid and one invalid. Thus users of the latter would have both a
valid signature and a reason to check what's up...
> My question still remains though: what should GnuPG do differently for a
> timestamp-only signature compared to a regular signature? Print "good
> timestamp from David Shaw" instead of "good signature from David Shaw"?
Something like that. A hint at the documentation (like "(see --timestamp-
only)") could be added but I guess that the output shall be kept to minimum
length.
> Out of curiosity, as long as we're talking about things that current code
> will reject, does the 0x50 signature meet the semantics desired here?
This one does not have the problem you mentioned for 0x40 (cleartext)? Because
it refers to an (unambigious) signature instead of to (ambigious) data?
> This all sounds vaguely notary-like ("I saw this document on such-and-such
> date") to me, and the intent of 0x50 is a notary signature. The nice
> thing about a 0x50 signature is that it is a signature on a signature, so
> the timestamp service doesn't need to see the document - just the
> (detached) signature.
That is simultaneously the nice and the bad thing. The bad part is that this
cannot be the only implementation of this feature as it is limited to
signatures. A timstamp service should sign anything, not just signatures.
There may be reasons not to reveal a signature (with the key ID) but rather to
get a signed timestamp anonymously.
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:
From jerome at jeromebaum.com Thu Jun 16 01:19:03 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Thu, 16 Jun 2011 01:19:03 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <456716BE-FE41-4F8E-9194-D628D38EDD56@jabberwocky.com>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106151056.30969.mailinglisten@hauke-laging.de>
<4DF8CAAA.3080103@fifthhorseman.net>
<201106151739.52559.mailinglisten@hauke-laging.de>
<70B3FD04-2CFF-4B9D-906C-A32292459FBF@jabberwocky.com>
<4DF90CFC.5060002@fifthhorseman.net>
<0446B244-5607-416D-9C83-2D82A434189A@jabberwocky.com>
<4DF9250C.7040308@fifthhorseman.net>
<399BB708-B2E7-449A-A4C1-F951B4130968@jabberwocky.com>
<456716BE-FE41-4F8E-9194-D628D38EDD56@jabberwocky.com>
Message-ID:
>>> Out of curiosity, as long as we're talking about things that current code will reject, does the 0x50 signature meet the semantics desired here? ?This all sounds vaguely notary-like ("I saw this document on such-and-such date") to me, and the intent of 0x50 is a notary signature. ?The nice thing about a 0x50 signature is that it is a signature on a signature, so the timestamp service doesn't need to see the document - just the (detached) signature.
>>
>> My understanding of a notary's job would include "I trust this key to
>> be valid, in possession only of the person named in the uid, while
>> that person was in sufficient mental state, not being threatened at
>> gun-point, ..."
>
> The 0x50 signature should not be interpreted as the output of a real-world notary
Who says that?
> OpenPGP calls this signature a "Third-Party Confirmation signature". ?It is merely a signature on a signature for whatever purpose is desired by the signer.
So, is it interpretation-dependent?
>> -- why should we use a signature type that could be
>> misinterpreted, when there is a "timestamp" signature type that fits
>> our needs exactly?
>
> Because as already noted, the 0x40 signature is not fully specified in the standard. ?There is not enough information to know how to generate one.
Looking at :
1. Referring to 0x50: "It is analogous to a notary seal on the signed
data." -- see my problem with that above.
2. If the issue is "text vs. binary", ? 5.2.1 ("Signature Types")
seems to suggest all signatures besides 0x01 are binary.
3. If the issue is "what do we sign (data vs. another signature)?", I
would say it depends what you're trying to do: Are you asserting that
you saw the signature, or are you asserting that you saw the data?
--
Jerome Baum
tel +49-1578-8434336
email jerome at jeromebaum.com
web www.jeromebaum.com
--
PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A
PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
From expires2011 at ymail.com Thu Jun 16 01:39:41 2011
From: expires2011 at ymail.com (MFPA)
Date: Thu, 16 Jun 2011 00:39:41 +0100
Subject: Problem with faked-system-time option
In-Reply-To:
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<201106121936.02971.mailinglisten@hauke-laging.de>
<5610428783.20110613210707@my_localhost>
<201106140133.09131.mailinglisten@hauke-laging.de>
<627125469.20110614202506@my_localhost>
<992640380.20110615205545@my_localhost>
<1015435212.20110615221639@my_localhost>
Message-ID: <1678798055.20110616003941@my_localhost>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi
On Wednesday 15 June 2011 at 10:32:55 PM, in
, Robert J. Hansen
wrote:
> On Wed, 15 Jun 2011 22:16:39 +0100, MFPA
> wrote:
>> An example of such corroboration is to use a
>> timestamping service that is trusted by the relevant
>> parties.
> This isn't really "corroboration" so much as it is, "I
> choose to trust someone else."
It is corroboration in the same sense that independent witnesses
attesting to the same thing corroborate each other's story.
>> I replied with the bare bones of a scenario where the
>> third party brings evidence that suggests the
>> signature timestamp to be incorrect, so that the
>> signer needs to refute that evidence.
> Quite probably the signer *shouldn't* refute that.
> Refuting claims doesn't convince anyone of anything
> except a particular claim is not supported by facts --
> it doesn't prove the claim is actually wrong.
Unless, of course, you refute the claim by producing evidence that
shows it to be wrong.
> "Okay, so
> you've convinced me not to trust this evidence saying
> the timestamp is incorrect: but you haven't done
> anything to persuade me the timestamp is correct, which
> is actually the important thing."
Without knowing why my hypothetical parties are seeking to claim
different signature times, I don't know which is the important thing
to prove in this imaginary situation.
> (This is also why, e.g., it makes no sense to argue
> with a conspiracy theorist: with a lot of effort you
> can prove the conspiracy theory to be *unsupported*,
> but you can't actually prove it *wrong*.)
Yes, just 'cos I'm paranoid, it doesn't mean they're not out to get
me. And being a hypochondriac doesn't preclude me from being ill.
>> As an example, if an independent timestamping service
>> can be shown to be sufficiently reliable, it could
>> provide the proof regardless of which party has an
>> interest in using that proof.
> It can't provide proof. It can't even provide
> evidence. It can only provide a data point which both
> parties stipulate as being uncontested -- and nothing
> is easier to reverse than a stipulation.
It doesn't cease to be evidence just because it is no longer
uncontested.
> ("Well, sure,
> I trusted Honest Al's Timestamping Service... up until
> I saw they signed THAT.
I would hope a timestamping service would sign any document that was
passed to it for a timestamping signature.
> I repudiate this timestamp! I
> don't trust Honest Al's Timestamping Service any
> more!")
Fair enough. But is it so easy to repudiate something like
http://guardtime.com/publications/ ?
- --
Best regards
MFPA mailto:expires2011 at ymail.com
My mind works like lightning... one brilliant flash and it's gone
-----BEGIN PGP SIGNATURE-----
iQE7BAEBCgClBQJN+ULHnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf
a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC
OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB
MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pnEMEAIDr
uNwkIDGScLH4bKyYns2TUUtsTC6/a3oo3OmObrn6W6nmMOLiwH7Ttdv06sCl0u2n
aui41MBadT7SO3p2Vpm/+VEag2u3+n1yt0igzzfgzd/I1Ey4GhI0PmnFaWSrUowZ
F9o8+doAqYOeQ9u9T1Ls0ItLVpgydNpq3qVXvWyd
=NViJ
-----END PGP SIGNATURE-----
From jerome at jeromebaum.com Thu Jun 16 01:42:52 2011
From: jerome at jeromebaum.com (Jerome Baum)
Date: Thu, 16 Jun 2011 01:42:52 +0200
Subject: Problem with faked-system-time option
In-Reply-To: <201106160058.09815.mailinglisten@hauke-laging.de>
References: <20110603193259.4C19B8C069@nym.dizum.nl>
<4DF9250C.7040308@fifthhorseman.net>
<399BB708-B2E7-449A-A4C1-F951B4130968@jabberwocky.com>
<201106160058.09815.mailinglisten@hauke-laging.de>
Message-ID: