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 <- RESTART scdaemon[6556]: chan_7 -> OK scdaemon[6556]: chan_7 <- [eof] 2011-06-09 21:10:32 scdaemon[6556] handler for fd -1 terminated 2011-06-09 21:10:32 scdaemon[6556] scdaemon (GnuPG) 2.0.17 stopped Sevan From expires2011 at ymail.com Mon Jun 13 22:07:07 2011 From: expires2011 at ymail.com (MFPA) Date: Mon, 13 Jun 2011 21:07:07 +0100 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: <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: > 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. For instance, a document that I don't want to sign, only to timestamp. -- 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 Thu Jun 16 01:51:27 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 15 Jun 2011 19:51:27 -0400 Subject: Problem with faked-system-time option In-Reply-To: <1678798055.20110616003941@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> <1678798055.20110616003941@my_localhost> Message-ID: <4DF9457F.1040508@sixdemonbag.org> On 6/15/11 7:39 PM, MFPA wrote: > It is corroboration in the same sense that independent witnesses > attesting to the same thing corroborate each other's story. Except this isn't a witness: it's the output of a wholly automated process that has no real connection to temporality except for the ticks of a system clock which, by everyone's admission, can be set any way the timestamper wants. It is no witness at all, in fact -- it doesn't even rise to the level of a fact. It is merely a *claim*, unless stipulated by all parties: and then it becomes something rather more than a claim. > Unless, of course, you refute the claim by producing evidence that > shows it to be wrong. Even that's insufficient. Show what's *right*. > 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. Then it would seem to me your hypothetical is so poorly considered as to not warrant further discussion. > It doesn't cease to be evidence just because it is no longer > uncontested. ... In point of fact, that's *exactly what happens to it*. If both parties stipulate to the accuracy of the third-party timestamp, then it's evidence. If one party doesn't, then it becomes a *claim*, and it's up to the jury to decide the strength of the claim. > Fair enough. But is it so easy to repudiate something like > http://guardtime.com/publications/ ? I'm fairly sure it is. Most of the tricks lawyers use to repudiate timestamps on physical documents also apply against electronic documents, and I'm pretty sure contract lawyers are worth their paychecks. From jerome at jeromebaum.com Thu Jun 16 01:51:39 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 01:51:39 +0200 Subject: Problem with faked-system-time option In-Reply-To: <1678798055.20110616003941@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> <1678798055.20110616003941@my_localhost> Message-ID: >> 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/ ? A bit OT but: I looked at those guys a while ago and I don't think I quite understand their concept. So, they publish hashes in the newspaper -- all fine and good, in a sense better than what stamper does. Problem is, how do I go from that hash to verifying a timestamp without their cooperation? With stamper I can just archive the published signatures and be done. With guardtime, as far as I can see they would have to send over the entire hash tree -- which isn't published, so I'd have to ask for/subpoena it -- just for a simple verification? -- 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 02:11:59 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 02:11:59 +0200 Subject: Problem with faked-system-time option In-Reply-To: <4DF9457F.1040508@sixdemonbag.org> 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> <1678798055.20110616003941@my_localhost> <4DF9457F.1040508@sixdemonbag.org> Message-ID: >> It doesn't cease to be evidence just because it is no longer >> uncontested. > > ... In point of fact, that's *exactly what happens to it*. Actually, no. It's still evidence. It's just not evidence that says "this document existed on the 10th of July". It's evidence that says "someone who was at any point in time in possession of this key, and who has the ability to manipulate the timestamp (or was in possession at the actual time listed in the signature), is claiming that the document existed on the 10th of July". 1. X is evidence for: A is true. 2. X is evidence for: Tom claims: A is true. Notice the indirection. >> Fair enough. But is it so easy to repudiate something like >> http://guardtime.com/publications/ ? > > I'm fairly sure it is. ?Most of the tricks lawyers use to repudiate > timestamps on physical documents also apply against electronic > documents, and I'm pretty sure contract lawyers are worth their paychecks. What tricks would those be? I'd love to see a Bailiff's records repudiated in court. The point is, just because I can falsify a timestamp on a physical document, doesn't mean I can falsify every timestamp that could be used to support a claim. Electronic timestamps are not physical timestamps, records held by notaries, bailiffs, even any other witnesses, are definitely more difficult to repudiate than the date I put down next to my signature. Oh, and I am pretty sure that a timestamp created in accordance with federal electronic signature laws would be considered reliable and be very difficult to dispute. -- 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 02:19:39 2011 From: expires2011 at ymail.com (MFPA) Date: Thu, 16 Jun 2011 01:19:39 +0100 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: <371609928.20110616011939@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 15 June 2011 at 10:38:00 PM, in , Robert J. Hansen wrote: > 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 It depends on the proof. If it involved referring the court to hashed/signed information regularly published by the timestamping service, such as to newsgroups or in newspapers, the original signer may not have similar to rely upon. > -- and thereby remove the > need for a timestamping service in the first place. The parties themselves could nest signatures on a document: A signs, B signs the signed document, A signs again, B signs again. Each party has a signature that is constrained to have been applied between two signatures of the other party. Would that not remove the need for a timestamping service? > 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. Proving a timestamping service's clock to be fair and honest would not remove my ability to alter my system clock or to use software to pass a different time to GnuPG. > 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. Even those that publish records/hashes are not really *proving* their integrity. http://guardtime.com/publications/ http://stamper.itconsult.co.uk/stamper-files/index.htm - -- Best regards MFPA mailto:expires2011 at ymail.com Time flies like an arrow. Fruit flies like a banana. -- Groucho Marx -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN+UwhnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pO50D/1kC AXvnpvLiABqrsWEqFD82KRqhjwFDENSk75XAo3omIEYkGe0pmyxNx+3AF8XcPdcl I9di7JbQPOGXpruM4wIZyZMArQPatpiFHigrF7b5A8QXMFWBZc6sJKIy7RJAxS2w NUCIybJoHcbldHKfjmVoJeJtW3sZ+XCbEe+swc9H =kjfq -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Thu Jun 16 02:29:49 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 15 Jun 2011 20:29:49 -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> <992640380.20110615205545@my_localhost> <1015435212.20110615221639@my_localhost> <1678798055.20110616003941@my_localhost> <4DF9457F.1040508@sixdemonbag.org> Message-ID: <4DF94E7D.80401@sixdemonbag.org> On 6/15/11 8:11 PM, Jerome Baum wrote: > Actually, no. It's still evidence. It's just not evidence that says > "this document existed on the 10th of July". It's evidence that says > "someone who was at any point in time in possession of this key, and > who has the ability to manipulate the timestamp (or was in possession > at the actual time listed in the signature), is claiming that the > document existed on the 10th of July". You're moving the goalposts: you're changing the terms of what the statement is meant to prove. By moving the statement from "A is true" to "Tom claims A is true", you've moved it back to something both parties stipulate -- presumably, Tom and Jerry both will agree that Tom claims A is true. Etc., etc. Simply put, if both parties agree that "X, and X indicates the truth of A, therefore A," then X is evidence for A. As soon as one party objects to either the fact (X) or the deduction (the inferential rule), then it becomes simply a claim to be evaluated by a jury. Claiming that "well, it becomes evidence, just evidence for a different thing," is the sort of thing that, while true, kind of misses the point. > What tricks would those be? At this point, you need to ask a contract lawyer. I know enough contract lawyers to be certain they are very on top of their game, and they've already given thought to the subject of repudiating electronic documents -- but I haven't been fascinated enough to go to law school, myself. > Oh, and I am pretty sure that a timestamp created in accordance with > federal electronic signature laws would be considered reliable and be > very difficult to dispute. As I am given to understand, the major problem with creating documents in perfect accordance with all extant law and precedent is just how difficult it is to keep track of everything that's applicable. It sounds nice and simple to say "create something in accordance with signature laws and applicable precedent," but my understanding is that's a highly nontrivial task. From jerome at jeromebaum.com Thu Jun 16 02:30:37 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 02:30:37 +0200 Subject: Problem with faked-system-time option In-Reply-To: <371609928.20110616011939@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> <49d3d13e0743dca7849ce69ead91eb6c@localhost> <371609928.20110616011939@my_localhost> Message-ID: > The parties themselves could nest signatures on a document: A signs, B > signs the signed document, A signs again, B signs again. Each party > has a signature that is constrained to have been applied between two > signatures of the other party. Would that not remove the need for a > timestamping service? Sounds interesting. Assuming the court will understand the second signature to mean "I confirm that the timestamp of the other party's signature is correct", then in your scenario A and B are both unable to repudiate the inner timestamps. Doesn't stop a third party from disputing the accuracy of the timestamps though, as A and B may have shared interests in inaccurate timestamps (picture back-dating an invoice/contract for tax fraud). >> 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. > > Even those that publish records/hashes are not really *proving* their > integrity. Right. The service isn't trusted, the published signatures are (and only w.r.t. time interval/week and possibly order, depending on implementation). -- 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 Thu Jun 16 02:32:02 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 15 Jun 2011 20:32:02 -0400 Subject: Problem with faked-system-time option In-Reply-To: <371609928.20110616011939@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> <49d3d13e0743dca7849ce69ead91eb6c@localhost> <371609928.20110616011939@my_localhost> Message-ID: <4DF94F02.5060802@sixdemonbag.org> On 6/15/11 8:19 PM, MFPA wrote: >> 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. > > Proving a timestamping service's clock to be fair and honest would not > remove my ability to alter my system clock or to use software to pass > a different time to GnuPG. It would mean that you could, in anticipation of a challenge being made, use the same procedure the "provable" timestamp authority would use: and thereby remove the need for it. From jerome at jeromebaum.com Thu Jun 16 02:37:19 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 02:37:19 +0200 Subject: Problem with faked-system-time option In-Reply-To: <4DF94F02.5060802@sixdemonbag.org> 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> <371609928.20110616011939@my_localhost> <4DF94F02.5060802@sixdemonbag.org> Message-ID: > It would mean that you could, in anticipation of a challenge being made, > use the same procedure the "provable" timestamp authority would use: and > thereby remove the need for it. Yes. I can set up my own timestamping business. That would be quite cost-ineffective though. -- 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 amanoc at dizum.nl Thu Jun 16 02:29:44 2011 From: amanoc at dizum.nl (Amano Corunga) Date: Thu, 16 Jun 2011 02:29:44 +0200 (CEST) Subject: Problem with faked-system-time option 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> <4DF81871.7050605@sixdemonbag.org> Message-ID: <20110616002944.974948C0D8@nym.dizum.nl> On Tue, 14 Jun 2011 22:26:57 -0400, Robert J. Hansen wrote: >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. This discussion is more and more moving away from my initial problem of not revealing the exact time when signing a piece of data in case I just want to acknowledge its origin (or receipt) but no further information, which is far from trying to invoke any temporal implications with intent to defraud. Here's a mundane real world example, a scenario where an exact signature timestamp means a tremendous danger, in your words a social problem arising from a technical deficit, which in my opinion has to be addressed (to forestall suspicion I must start by mentioning that I'm running my own small business with a few employees like Bob or Alice ;-)): Bob always carries a USB drive containing his mailing system with him, during leisure time as well as at work. Now, with a periodically changing volume of work there's idleness from time to time at his job. In those slack periods he has the chance to deal with his correspondence. And being a diligent person he's used to signing and encrypting his mail. But now he's toast. One of the messages he wrote at work was accidentally forwarded to his boss, who saw the signature, which was made on company time. It was up to him to provide evidence that that timestamp was wrong, which he couldn't. He lost his job, his existence. How could that threatening risk have been avoided (disregarding kicking one's heels instead of always aiming at being productive)? Bob wasn't granted access to the computer's system time, which furthermore got synchronized with an NTP server in regular intervals. And now about Alice. Being in a simular situation she uses her own netbook, for privacy reasons adjusts clock time back and forth with every signature she creates, and, to indicate that the timestamp of the signature is artificial, chooses the key's exact creation timestamp for all her signatures as well, as by setting it to '0' or any other time before key creation she would risk the rejection of those potentially invalid signatures, and by using a later time she might be accused of fraud. Key revocation is of no relevance, as in this respect the time of message reception by the addressee is an adequate substitute for the lack of a valid signature timestamp. Alice only wishes to get around the annoying system time manipulations she has to repeat again and again. Do you think Alice's approach is or may become an acceptable strategy, not breaking existing conventions, and getting the chance to become supported by kind of a '--no-signature-timestamp' GnuPG option? Regards Amano From jerome at jeromebaum.com Thu Jun 16 02:41:29 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 02:41:29 +0200 Subject: Problem with faked-system-time option In-Reply-To: <4DF94E7D.80401@sixdemonbag.org> 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> <1678798055.20110616003941@my_localhost> <4DF9457F.1040508@sixdemonbag.org> <4DF94E7D.80401@sixdemonbag.org> Message-ID: >> Actually, no. It's still evidence. It's just not evidence that says >> "this document existed on the 10th of July". It's evidence that says >> "someone who was at any point in time in possession of this key, and >> who has the ability to manipulate the timestamp (or was in possession >> at the actual time listed in the signature), is claiming that the >> document existed on the 10th of July". > > You're moving the goalposts: you're changing the terms of what the > statement is meant to prove. ?By moving the statement from "A is true" > to "Tom claims A is true", you've moved it back to something both > parties stipulate -- presumably, Tom and Jerry both will agree that Tom > claims A is true. ?Etc., etc. So, I'm stating my point? I'm seeing a lot of unqualified statements (like "it's not evidence"). Yes, you could argue that it should be read as: "it's not evidence [for fact X]", but being explicit can be a Good Thing(tm). > Simply put, if both parties agree that "X, and X indicates the truth of > A, therefore A," then X is evidence for A. ?As soon as one party objects > to either the fact (X) or the deduction (the inferential rule), then it > becomes simply a claim to be evaluated by a jury. ?Claiming that "well, > it becomes evidence, just evidence for a different thing," is the sort > of thing that, while true, kind of misses the point. Which point? Your point? I was making my own point (per above), not addressing yours. My point was that I see a lot of talking past each other and most of that is due to implicit statements. I think if we all are a bit more explicit (e.g. what is something evidence for? for whom is something "good enough"? in what context are we proving something? -- i.e. yes, we *do* need context!) then we'll have a much more efficient discussion. >> What tricks would those be? > > At this point, you need to ask a contract lawyer. ?I know enough > contract lawyers to be certain they are very on top of their game, and > they've already given thought to the subject of repudiating electronic > documents -- but I haven't been fascinated enough to go to law school, > myself. Let's summarize: You: Lawyers are able to repudiate electronic signatures with some magic tricks. Me: Please, show me those tricks. You: Go ask a lawyer. I only know lawyers are smart people and it would be in their interests (really?) to repudiate electronic *documents*. (emphasis mine, obviously) >> Oh, and I am pretty sure that a timestamp created in accordance with >> federal electronic signature laws would be considered reliable and be >> very difficult to dispute. > > As I am given to understand, the major problem with creating documents > in perfect accordance with all extant law and precedent is just how > difficult it is to keep track of everything that's applicable. ?It > sounds nice and simple to say "create something in accordance with > signature laws and applicable precedent," but my understanding is that's > a highly nontrivial task. Not really. My CPA sends me an electronic invoice that is "in accordance with signature laws and applicable precedent". In fact, my ISP does as well, and so does my mobile carrier. Federal electronic signature laws are pretty simple and easy to understand. There's even a brochure I think. :) -- 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 Thu Jun 16 02:44:17 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 15 Jun 2011 20:44:17 -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> <589083827.20110615211202@my_localhost> <49d3d13e0743dca7849ce69ead91eb6c@localhost> <371609928.20110616011939@my_localhost> <4DF94F02.5060802@sixdemonbag.org> Message-ID: <4DF951E1.7050107@sixdemonbag.org> On 6/15/11 8:37 PM, Jerome Baum wrote: > Yes. I can set up my own timestamping business. That would be quite > cost-ineffective though. Possibly -- but it still assumes that timestamps can be proven in a way that makes the impossible to contest. This really isn't possible, as evidenced by the fact we continually refer to them as *trusted* timestamp authorities. There is no way to prove to someone that a timestamp is trustworthy. All you can do is present the timestamp authority's methods and let the person make their own decision as to whether to vest the timestamp authority with trust. Even if a timestamp authority were to publish every timestamp signature in the _New York Times_ on the day of issuing, that would still be insufficient for some people -- they would say, "well, how do I know the timestamp authority isn't running a con?", or whatnot. Ultimately, it always reduces to trust. If there were a way to *prove* the timestamp of a message, we wouldn't need timestamp authorities at all. Instead, we have trusted third parties who are uninvolved in the matter of controversy -- and that works well enough for us. From expires2011 at ymail.com Thu Jun 16 02:46:46 2011 From: expires2011 at ymail.com (MFPA) Date: Thu, 16 Jun 2011 01:46:46 +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: <614927599.20110616014646@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 15 June 2011 at 10:58:27 PM, in , Jerome Baum wrote: MFPA wrote: >> You asserted that the signer's own signature timestamp >> was sufficient when a third party needs to prove when >> the document was signed. > When? Sorry, that was Hauke. MFPA wrote: >> 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? All good questions. Each individual case would have its own set of circumstances and therefore its own set of answers. Whatever the sufficiency condition and whoever gets to decide what's sufficient, if the condition is met the use of the timestamping service is capable of providing the proof. - -- Best regards MFPA mailto:expires2011 at ymail.com Is it bad luck to be superstitious? -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN+VJ7nhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pfzID/3DW 5JzXWdrCcmRN52PcV4z4mxbLT4wURgeB2vGW384SvqQMTviPjX7GEq/rHHAKPH9Y sBK8GkNbmmxhtLQQae0pGv2JJ5nzmJutIQwbKfR6a7c9h67h5sUq5u3biSBth4RI iXgf9YAXy/Kr6TtNQ8HIDeCuCL5GyLaguFzMDuyE =INj1 -----END PGP SIGNATURE----- From jerome at jeromebaum.com Thu Jun 16 02:53:34 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 02:53:34 +0200 Subject: Problem with faked-system-time option In-Reply-To: <4DF951E1.7050107@sixdemonbag.org> 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> <371609928.20110616011939@my_localhost> <4DF94F02.5060802@sixdemonbag.org> <4DF951E1.7050107@sixdemonbag.org> Message-ID: >> Yes. I can set up my own timestamping business. That would be quite >> cost-ineffective though. > > Possibly -- but it still assumes that timestamps can be proven in a way > that makes the impossible to contest. ?This really isn't possible, as > evidenced by the fact we continually refer to them as *trusted* > timestamp authorities. Who does? > There is no way to prove to someone that a timestamp is trustworthy. > All you can do is present the timestamp authority's methods and let the > person make their own decision as to whether to vest the timestamp > authority with trust. Huh? > Even if a timestamp authority were to publish every timestamp signature > in the _New York Times_ on the day of issuing, that would still be > insufficient for some people -- they would say, "well, how do I know the > timestamp authority isn't running a con?", or whatnot. Yeah, uh, I can probably say "this trial is probably a con", but I don't think the judge will buy it and acquit me. > Ultimately, it always reduces to trust. ?If there were a way to *prove* > the timestamp of a message, we wouldn't need timestamp authorities at > all. ?Instead, we have trusted third parties who are uninvolved in the > matter of controversy -- and that works well enough for us. Okay, let's take a look at the formal theory behind this: Assumptions: 1. The cryptographic hash function C is "secure" (i.e. not broken at the moment -- for verification at a later time there's the whole "resigning" thing that federal electronic signature law requires). 1a. We'll ignore those resigning signature chains for the purposes of keeping the proof small. It is easy to adapt the scheme to include resigning chains. 2. The issue of newspaper N for date D (called N(D) ) is "known good" (through public archives etc.) Conjecture: I can hash a document M before D and later prove in court that the document existed before D. Proof: Publish C(M) in N(D) 10 years later in court, show N(D), M and compute C(M). Verify that C(M) is published in N(D). Mathematically strong proof that it is computationally infeasible to have published C(M) in N(D) if M didn't exist before D -- i.e. proof that the document M existed before D. -- 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 Thu Jun 16 03:08:29 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 15 Jun 2011 21:08:29 -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> <992640380.20110615205545@my_localhost> <1015435212.20110615221639@my_localhost> <1678798055.20110616003941@my_localhost> <4DF9457F.1040508@sixdemonbag.org> <4DF94E7D.80401@sixdemonbag.org> Message-ID: <4DF9578D.4070408@sixdemonbag.org> On 6/15/11 8:41 PM, Jerome Baum wrote: > You: Go ask a lawyer. I only know lawyers are smart people and it > would be in their interests (really?) to repudiate electronic > *documents*. (emphasis mine, obviously) There are two main reasons why I'm referring you to a lawyer: (a) to the extent I know some lawyers' strategies, I am generally not at liberty to talk about them, and (b) to the extent I am at liberty to talk about the rest, I am not confident of my ability to present their methods correctly, due to the fact I haven't spent ten years learning all the intricacies of contract law Neither (a) nor (b) interferes with my confidence in the statement, "contract lawyers are well-prepared for repudiating electronic documents." (To explain (a): a few years ago I worked as the chief sysadmin for a law firm, and got to sit in on their strategy sessions for how to handle the changes electronic documents presented for subpoenas, signatures, and so forth. I am not at liberty to talk about their methods: I can only tell you the lawyers I worked for took this quite seriously, and were confident of their ability to repudiate electronic signatures.) > Not really. My CPA sends me an electronic invoice that is "in > accordance with signature laws and applicable precedent". Your CPA and ISP claim to do this. Nobody knows whether it truly is until a court declares it to be so. From jerome at jeromebaum.com Thu Jun 16 03:08:52 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 03:08:52 +0200 Subject: Problem with faked-system-time option In-Reply-To: <20110616002944.974948C0D8@nym.dizum.nl> 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> <4DF81871.7050605@sixdemonbag.org> <20110616002944.974948C0D8@nym.dizum.nl> Message-ID: > Bob always carries a USB drive containing his mailing system with him, > during leisure time as well as at work. ?Now, with a periodically > changing volume of work there's idleness from time to time at his job. > In those slack periods he has the chance to deal with his > correspondence. ?And being a diligent person he's used to signing and > encrypting his mail. ?But now he's toast. ?One of the messages he > wrote at work was accidentally forwarded to his boss, who saw the > signature, which was made on company time. ?It was up to him to > provide evidence that that timestamp was wrong, which he couldn't. ?He > lost his job, his existence. It isn't up to him to provide that evidence. As a civil case, he must show that it is plausible that the timestamp is wrong, and he must claim so (obviously). The evidence that his employer shows (signature w/ timestamp) becomes weak. Again, the circumstances are really, really important. Your employer won't usually go to court with just that signature. Most likely, the signature will be a tiny, insignificant, part of the case. Rightly so, as the timestamp in an average signature is very weak evidence. > How could that threatening risk have been avoided (disregarding > kicking one's heels instead of always aiming at being productive)? Bob > wasn't granted access to the computer's system time, which furthermore > got synchronized with an NTP server in regular intervals. Claim you signed from another computer where you did have access to the system time and where there was no synchronization, you set a random time at installation, etc. If the employer can prove you signed from that computer, and that that computer's system time was close enough to legal time, then you're fucked. But then, if you cheat your employer out of their money, shouldn't you be? Note that the scenario feels very constructed. Your employer would likely not go to court with only that signature. They'd have all sorts of evidence and it wouldn't be a problem if the signature turns out to be worthless/ignored. -- 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 03:12:21 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 03:12:21 +0200 Subject: Problem with faked-system-time option In-Reply-To: <4DF9578D.4070408@sixdemonbag.org> 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> <1678798055.20110616003941@my_localhost> <4DF9457F.1040508@sixdemonbag.org> <4DF94E7D.80401@sixdemonbag.org> <4DF9578D.4070408@sixdemonbag.org> Message-ID: >> Not really. My CPA sends me an electronic invoice that is "in >> accordance with signature laws and applicable precedent". > > Your CPA and ISP claim to do this. ?Nobody knows whether it truly is > until a court declares it to be so. No, I don't rely on random people (CPA, ISP) for that. The tax office accepts these invoices as "in accordance with signature laws [and obviously applicable precedent]". I would assume that if they had any chance of disputing the validity, and thereby saving all that tax money, they would do exactly 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 Thu Jun 16 03:15:15 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 03:15:15 +0200 Subject: Problem with faked-system-time option In-Reply-To: <4DF9578D.4070408@sixdemonbag.org> 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> <1678798055.20110616003941@my_localhost> <4DF9457F.1040508@sixdemonbag.org> <4DF94E7D.80401@sixdemonbag.org> <4DF9578D.4070408@sixdemonbag.org> Message-ID: > There are two main reasons why I'm referring you to a lawyer: > > (a) to the extent I know some lawyers' strategies, I am generally > ? ?not at liberty to talk about them, and > (b) to the extent I am at liberty to talk about the rest, I am > ? ?not confident of my ability to present their methods correctly, > ? ?due to the fact I haven't spent ten years learning all the > ? ?intricacies of contract law > > Neither (a) nor (b) interferes with my confidence in the statement, > "contract lawyers are well-prepared for repudiating electronic documents." Does (b) not interfere? You either understand whether a strategy is valid or not, or you don't. At the very least, if you have any confidence in a strategy (that you are at liberty to talk about), you'd be able to give an overview, right? Otherwise, if you are not confident in your ability to present the strategy correctly, how can you be confident in your ability to understand and *evaluate* the strategy as to its correctness and success likelihood? -- 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 Thu Jun 16 03:20:07 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 15 Jun 2011 21:20:07 -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> <589083827.20110615211202@my_localhost> <49d3d13e0743dca7849ce69ead91eb6c@localhost> <371609928.20110616011939@my_localhost> <4DF94F02.5060802@sixdemonbag.org> <4DF951E1.7050107@sixdemonbag.org> Message-ID: <4DF95A47.8010802@sixdemonbag.org> On 6/15/11 8:53 PM, Jerome Baum wrote: > I can hash a document M before D and later prove in court that the > document existed before D. > > Proof: > > Publish C(M) in N(D) Your claim would be submitted to a jury for consideration, as it's a question of fact and not law. The jury would look at your claim of mathematical strength, be confused, and proceed to move on to something else. Nothing in law is proven until a jury has declared it to be so... and pretty much everyone in a courtroom hates math. You can attempt to prove your timestamp is correct: but ultimately, that's *not within your control*. It's entirely within the jury's purview, and if the jury says "we don't buy this," then you haven't proven a thing. "Proof," in a mathematical sense, is irrelevant in a courtroom. Proof is whatever you can sneak past the judge that will make the jury buy your claim -- nothing more. You don't get to declare what proofs are valid or invalid: only the jury does, and the jury doesn't care what you think. Consider this: MD5 is still the standard hash algorithm used in digital forensics. Makes all of us have the flaming heebie-jeebies, of course: it's crazy to use MD5 to authenticate digital data, given the collision attacks against it. But for the courts... what the courts think of as "proof" is not what we think of as "proof." We think MD5's weakness has been proven: but so far, juries are still regularly accepting MD5 as a cryptographically secure hash algorithm, which means that in the eyes of the court *it is*. From jerome at jeromebaum.com Thu Jun 16 03:19:27 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 03:19:27 +0200 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> <1678798055.20110616003941@my_localhost> <4DF9457F.1040508@sixdemonbag.org> <4DF94E7D.80401@sixdemonbag.org> <4DF9578D.4070408@sixdemonbag.org> Message-ID: >> There are two main reasons why I'm referring you to a lawyer: >> >> (a) to the extent I know some lawyers' strategies, I am generally >> ? ?not at liberty to talk about them, and >> (b) to the extent I am at liberty to talk about the rest, I am >> ? ?not confident of my ability to present their methods correctly, >> ? ?due to the fact I haven't spent ten years learning all the >> ? ?intricacies of contract law >> >> Neither (a) nor (b) interferes with my confidence in the statement, >> "contract lawyers are well-prepared for repudiating electronic documents." > > Does (b) not interfere? You either understand whether a strategy is > valid or not, or you don't. At the very least, if you have any > confidence in a strategy (that you are at liberty to talk about), > you'd be able to give an overview, right? Otherwise, if you are not > confident in your ability to present the strategy correctly, how can > you be confident in your ability to understand and *evaluate* the > strategy as to its correctness and success likelihood? In fact, how about an analogy? I have an algebra (in the high school sense) exam tomorrow. I have prepared myself by developing the strategy: "answer every question with '2 + 2 = 5'". I am prepared. However, I am badly prepared. If you don't understand algebra, you can't know that. You can't know whether I'm "well-prepared" or badly prepared, only that I am prepared in some way. -- 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 Thu Jun 16 03:26:30 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 15 Jun 2011 21:26:30 -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> <992640380.20110615205545@my_localhost> <1015435212.20110615221639@my_localhost> <1678798055.20110616003941@my_localhost> <4DF9457F.1040508@sixdemonbag.org> <4DF94E7D.80401@sixdemonbag.org> <4DF9578D.4070408@sixdemonbag.org> Message-ID: <4DF95BC6.6040200@sixdemonbag.org> On 6/15/11 9:15 PM, Jerome Baum wrote: > Does (b) not interfere? You either understand whether a strategy is > valid or not, or you don't. It's kind of like how in college I saw Professor Lichty derive special relativity from the Pythagorean Theorem and first principles. Do I know it can be done? Sure, because I remember my eyes popping out of my head at the elegance and simplicity, and realizing "my God, relativity is so important because it's /background independent!/" But if you were to say, "hey, that's really cool, show me!", I'd tell you that you'd have to ask Professor Lichty. From jerome at jeromebaum.com Thu Jun 16 03:26:07 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 03:26:07 +0200 Subject: Problem with faked-system-time option In-Reply-To: <4DF95A47.8010802@sixdemonbag.org> 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> <371609928.20110616011939@my_localhost> <4DF94F02.5060802@sixdemonbag.org> <4DF951E1.7050107@sixdemonbag.org> <4DF95A47.8010802@sixdemonbag.org> Message-ID: >> I can hash a document M before D and later prove in court that the >> document existed before D. >> >> Proof: >> >> Publish C(M) in N(D) > > Your claim would be submitted to a jury for consideration, as it's a > question of fact and not law. ?The jury would look at your claim of > mathematical strength, be confused, and proceed to move on to something > else. ?Nothing in law is proven until a jury has declared it to be so... > and pretty much everyone in a courtroom hates math. What jury? > You can attempt to prove your timestamp is correct: but ultimately, > that's *not within your control*. ?It's entirely within the jury's > purview, and if the jury says "we don't buy this," then you haven't > proven a thing. What jury? > "Proof," in a mathematical sense, is irrelevant in a courtroom. ?Proof > is whatever you can sneak past the judge that will make the jury buy > your claim -- nothing more. ?You don't get to declare what proofs are > valid or invalid: only the jury does, and the jury doesn't care what you > think. Repeating yourself does not make your argument more valid. > Consider this: MD5 is still the standard hash algorithm used in digital > forensics. ?Makes all of us have the flaming heebie-jeebies, of course: > it's crazy to use MD5 to authenticate digital data, given the collision > attacks against it. > > But for the courts... what the courts think of as "proof" is not what we > think of as "proof." ?We think MD5's weakness has been proven: but so > far, juries are still regularly accepting MD5 as a cryptographically > secure hash algorithm, which means that in the eyes of the court *it is*. What juries? Look at my signature and pay close attention to the "+49". -- 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 Thu Jun 16 03:29:01 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 15 Jun 2011 21:29:01 -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> <589083827.20110615211202@my_localhost> <49d3d13e0743dca7849ce69ead91eb6c@localhost> <371609928.20110616011939@my_localhost> <4DF94F02.5060802@sixdemonbag.org> <4DF951E1.7050107@sixdemonbag.org> <4DF95A47.8010802@sixdemonbag.org> Message-ID: <4DF95C5D.8090405@sixdemonbag.org> On 6/15/11 9:26 PM, Jerome Baum wrote: > What jury? Submitted before the tribunal, then -- the upshot of it is that *you don't get to decide what the court does*. From jerome at jeromebaum.com Thu Jun 16 03:29:35 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 03:29:35 +0200 Subject: Problem with faked-system-time option In-Reply-To: <4DF95BC6.6040200@sixdemonbag.org> 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> <1678798055.20110616003941@my_localhost> <4DF9457F.1040508@sixdemonbag.org> <4DF94E7D.80401@sixdemonbag.org> <4DF9578D.4070408@sixdemonbag.org> <4DF95BC6.6040200@sixdemonbag.org> Message-ID: >> Does (b) not interfere? You either understand whether a strategy is >> valid or not, or you don't. > > It's kind of like how in college I saw Professor Lichty derive special > relativity from the Pythagorean Theorem and first principles. ?Do I know > it can be done? ?Sure, because I remember my eyes popping out of my head > at the elegance and simplicity, and realizing "my God, relativity is so > important because it's /background independent!/" ?But if you were to > say, "hey, that's really cool, show me!", I'd tell you that you'd have > to ask Professor Lichty. You'd agree that "ask Professor Lichty" doesn't count as a formal proof (or even significant evidence), right? -- 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 03:34:23 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 03:34:23 +0200 Subject: Problem with faked-system-time option In-Reply-To: <4DF95C5D.8090405@sixdemonbag.org> 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> <371609928.20110616011939@my_localhost> <4DF94F02.5060802@sixdemonbag.org> <4DF951E1.7050107@sixdemonbag.org> <4DF95A47.8010802@sixdemonbag.org> <4DF95C5D.8090405@sixdemonbag.org> Message-ID: >> What jury? > > Submitted before the tribunal, then -- the upshot of it is that *you > don't get to decide what the court does*. Do you assume that, say, the judges at the federal constitutional court are too dumb to get a specialist and inquire as to the status of cryptographic hash functions etc.? I could deliver a mathematically valid proof to anyone and they could ignore it. That is freedom of thought. I can also assume that people with at least a basic understanding of formal logic, and the ability to call on any subject field expert as deemed necessary to uncover the truth, would be able to follow my train of thought. If that train of thought proves without (significant) doubt that a timestamp must be valid, and assuming they are impartial, they should consider the timestamp to be valid. Juries and judges are not the same, so you can't just apply one to the other. A jury might not understand, a judge at the BVerfG probably would. -- 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 Thu Jun 16 03:37:30 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 15 Jun 2011 21:37:30 -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> <992640380.20110615205545@my_localhost> <1015435212.20110615221639@my_localhost> <1678798055.20110616003941@my_localhost> <4DF9457F.1040508@sixdemonbag.org> <4DF94E7D.80401@sixdemonbag.org> <4DF9578D.4070408@sixdemonbag.org> <4DF95BC6.6040200@sixdemonbag.org> Message-ID: <4DF95E5A.2040503@sixdemonbag.org> On 6/15/11 9:29 PM, Jerome Baum wrote: > You'd agree that "ask Professor Lichty" doesn't count as a formal > proof (or even significant evidence), right? No. It does, however, qualify as "here is where you need to look if you want to verify my claims," which is the best you can hope for on a mailing list. I'm done with this thread: it seems to have devolved about as far as it can go. From jerome at jeromebaum.com Thu Jun 16 03:45:45 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 03:45:45 +0200 Subject: Problem with faked-system-time option In-Reply-To: <4DF95E5A.2040503@sixdemonbag.org> 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> <1678798055.20110616003941@my_localhost> <4DF9457F.1040508@sixdemonbag.org> <4DF94E7D.80401@sixdemonbag.org> <4DF9578D.4070408@sixdemonbag.org> <4DF95BC6.6040200@sixdemonbag.org> <4DF95E5A.2040503@sixdemonbag.org> Message-ID: >> You'd agree that "ask Professor Lichty" doesn't count as a formal >> proof (or even significant evidence), right? > > No. ?It does, however, qualify as "here is where you need to look if you > want to verify my claims," which is the best you can hope for on a > mailing list. ?I'm done with this thread: it seems to have devolved > about as far as it can go. That's okay, it was a fun excursion. I believe the part of the thread discussing timestamp signatures is still on-going, with interesting material. -- 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 04:44:20 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 15 Jun 2011 22:44:20 -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> <456716BE-FE41-4F8E-9194-D628D38EDD56@jabberwocky.com> Message-ID: <9D35C90E-D69A-4967-98FC-30F7EBA7B21A@jabberwocky.com> On Jun 15, 2011, at 7:19 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 > > Who says that? RFC-4880 says that. And speaking as the person who suggested it, I can tell you my intent ;) The draft spec actually called it a "notary signature", but after discussion, the name was intentionally changed to "Third-Party Confirmation signature" explicitly to avoid any confusion with a real-world notary or what they do. The word notary is just an analogy. >> 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? No more than any other signature in the standard, no. David From jerome at jeromebaum.com Thu Jun 16 05:23:25 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 05:23:25 +0200 Subject: Problem with faked-system-time option In-Reply-To: <9D35C90E-D69A-4967-98FC-30F7EBA7B21A@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> <9D35C90E-D69A-4967-98FC-30F7EBA7B21A@jabberwocky.com> Message-ID: >>> The 0x50 signature should not be interpreted as the output of a real-world notary >> >> Who says that? > > RFC-4880 says that. ?And speaking as the person who suggested it, I can tell you my intent ;) Fom : Referring to 0x50: "It is analogous to a notary seal on the signed data." > The draft spec actually called it a "notary signature", but after discussion, the name was intentionally changed to "Third-Party Confirmation signature" explicitly to avoid any confusion with a real-world notary or what they do. ?The word notary is just an analogy. Yeah and that was my point. The analogy is bad because a notary doesn't just timestamp. That's not even the main purpose of a notary (at least here in DE). Having the 0x50 signature on another signature packet is definitely not helpful -- what part of the signature are you asserting? The timestamp? There's a timestamp in the 0x50. The validity signing key? No (per you). The mental state that the signer was in? No (per you). The data and time? Yes, if we use this for timestamping. But then, why am I not signing the data and asserting the timestamp in my 0x50 signature packet? I would think that, if anything, we could use 0x50 for those resigning chains (you know, renewing the cryptographic validity of a signature). But not for timestamping arbitrary data. >>> 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? > > No more than any other signature in the standard, no. Except that, say, 0x00 "certifies that [the document] has not been modified" as a minimum condition (owner- and authorship would both imply this). 0x50 is entirely interpretation-dependent: Something that a notary does, but not really what a notary does (!= timestamping), rather something that someone does who saw some part of either the data or the signature, or something else, and is making some kind of statement. Of course, I can abuse an 0x00 signature for anything I want, but the standard at least sets a common-sense basis for what an 0x00 sig means. An 0x50 sig on the other hand seems to have less of that basis. I say let's put in a request for interpretation for the 0x40, as those are designated for timestamps. That is, if we choose not to go with a notation. -- 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 05:54:30 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 15 Jun 2011 23:54:30 -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> <456716BE-FE41-4F8E-9194-D628D38EDD56@jabberwocky.com> <9D35C90E-D69A-4967-98FC-30F7EBA7B21A@jabberwocky.com> Message-ID: <5978304A-34EE-4AD4-BE0C-91D1311B0198@jabberwocky.com> On Jun 15, 2011, at 11:23 PM, Jerome Baum wrote: >>>> The 0x50 signature should not be interpreted as the output of a real-world notary >>> >>> Who says that? >> >> RFC-4880 says that. And speaking as the person who suggested it, I can tell you my intent ;) > > Fom : > > Referring to 0x50: "It is analogous to a notary seal on the signed data." > >> The draft spec actually called it a "notary signature", but after discussion, the name was intentionally changed to "Third-Party Confirmation signature" explicitly to avoid any confusion with a real-world notary or what they do. The word notary is just an analogy. > > Yeah and that was my point. The analogy is bad because a notary > doesn't just timestamp. That's not even the main purpose of a notary > (at least here in DE). Having the 0x50 signature on another signature > packet is definitely not helpful -- what part of the signature are you > asserting? The timestamp? There's a timestamp in the 0x50. The > validity signing key? No (per you). The mental state that the signer > was in? No (per you). The data and time? Yes, if we use this for > timestamping. But then, why am I not signing the data and asserting > the timestamp in my 0x50 signature packet? Forget the word notary. Just erase it from your head. If you don't like the analogy, then don't use it. It's just a third-party confirmation signature. It means only that a third party wants to make a signature on a signature. It's just like 0x00, except where the data is a signature packet. The reason you might want a signature on a signature is because the 0x50 gives you something really useful in the context of time stamping: it means the stamper entity/process/person doesn't need to see the original data. I can sign the data myself, then send the signature alone to the stamper. The stamper then signs my signature, using the notation we've already discussed to indicate they are making a timestamp alone. As you phrase the question, the stamper needs to see the original data ("why am I not signing the data"). That's not always desirable. As I noted before, you can more or less create this by sending hashes around and timestamp-notation signing them, but 0x50 is cleaner and easier to machine parse. It doesn't matter in any event. 0x50 isn't implemented in any deployed code any more than 0x40 is. I'd use a notation. David From jerome at jeromebaum.com Thu Jun 16 06:12:20 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 06:12:20 +0200 Subject: Problem with faked-system-time option In-Reply-To: <5978304A-34EE-4AD4-BE0C-91D1311B0198@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> <9D35C90E-D69A-4967-98FC-30F7EBA7B21A@jabberwocky.com> <5978304A-34EE-4AD4-BE0C-91D1311B0198@jabberwocky.com> Message-ID: >>>>> The 0x50 signature should not be interpreted as the output of a real-world notary >>>> >>>> Who says that? >>> >>> RFC-4880 says that. ?And speaking as the person who suggested it, I can tell you my intent ;) >> >> Fom : >> >> Referring to 0x50: "It is analogous to a notary seal on the signed data." >> >>> The draft spec actually called it a "notary signature", but after discussion, the name was intentionally changed to "Third-Party Confirmation signature" explicitly to avoid any confusion with a real-world notary or what they do. ?The word notary is just an analogy. >> >> Yeah and that was my point. The analogy is bad because a notary >> doesn't just timestamp. > > Forget the word notary. ?Just erase it from your head. ?If you don't like the analogy, then don't use it. Do you not agree that a bad analogy is going to cause confusion? It already has, and likely will continue to. If the signature is analogous to a notary signature, then other implementations will interpret it that way. I won't forget the word notary because it's in the standard. If it's not applicable, it shouldn't be in there. It's in there, so there is a gap between the intention and the wording of the standard w.r.t. 0x50. So, we shouldn't use it a.t.m. as it's "unclear". > ?It's just a third-party confirmation signature. ?It means only that a third party wants to make a signature on a signature. ?It's just like 0x00, except where the data is a signature packet. So I'm signing that the signature hasn't been changed, or that I am the owner or author of the signature? Is that *really* what I mean with a timestamp signature? Because the standard says that's what 0x00 "usually" means. > The reason you might want a signature on a signature is because the 0x50 gives you something really useful in the context of time stamping: it means the stamper entity/process/person doesn't need to see the original data. ?I can sign the data myself, then send the signature alone to the stamper. ?The stamper then signs my signature, using the notation we've already discussed to indicate they are making a timestamp alone. > > As you phrase the question, the stamper needs to see the original data ("why am I not signing the data"). ?That's not always desirable. Don't interpret that into what I said. You may sign either the data or the signature, but that should be explicit -- you should be signing the signature if you saw the signature, and the data if you saw the data (rather, it is your choice). If we use 0x50 that means it's not your choice, as you can only sign the signature. So, how do you sign (i.e. timestamp) data that isn't already signed by someone else? > As I noted before, you can more or less create this by sending hashes around and timestamp-notation signing them, but 0x50 is cleaner and easier to machine parse. But you can't sign data. > It doesn't matter in any event. ?0x50 isn't implemented in any deployed code any more than 0x40 is. ?I'd use a notation. Exactly my point. If 0x40 is not clear enough (per others), and 0x50 isn't clear enough (per me), and a notation can be used right now with any requests for clarification/interpretation and can be marked critical or non-critical and be appropriately handled by existing implementations, and if we can use it to promote notations in general, then we should use it. I think the general consensus seems to be on a notation anyway (as far as there is concensus), so let's just focus on specifying the notation more closely. Assuming Werner's confirmation, we are at this state: 1. timestamp-only at gnupg.org. If this notation exists on the signature, that indicates it is a timestamp signature. 1 a. Should we set this notation critical, non-critical, or user's choice? We also had the suggestion of doing two signatures, one w/ critical and one w/out. The idea was that the user will be inclined to look more closely. 2. Suggestion: timestamp-resolution at gnupg.org. Value is number of seconds of error in both directions. 2 a. Thinking about it, this should be two notations: timestamp-error at gnupg.org, and timestamp-resolution at gnupg.org (the difference being: error = clock drift, while resolution = fixed intervals, e.g. for datestamps resolution would be 86400 and timestamp would be at 00:00). 2 b. Need a more formal spec on how this works (how is the interval defined). 3. Other stuff? -- 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 06:54:44 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 16 Jun 2011 00:54:44 -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> <456716BE-FE41-4F8E-9194-D628D38EDD56@jabberwocky.com> <9D35C90E-D69A-4967-98FC-30F7EBA7B21A@jabberwocky.com> <5978304A-34EE-4AD4-BE0C-91D1311B0198@jabberwocky.com> Message-ID: On Jun 16, 2011, at 12:12 AM, Jerome Baum wrote: >>>> The draft spec actually called it a "notary signature", but after discussion, the name was intentionally changed to "Third-Party Confirmation signature" explicitly to avoid any confusion with a real-world notary or what they do. The word notary is just an analogy. >>> >>> Yeah and that was my point. The analogy is bad because a notary >>> doesn't just timestamp. >> >> Forget the word notary. Just erase it from your head. If you don't like the analogy, then don't use it. > > Do you not agree that a bad analogy is going to cause confusion? It > already has, and likely will continue to. I'm not sure how much more this dead horse needs to be beaten. Fact: the standard used to call this a "notary signature". Fact: the people behind the standard removed all but one mentions of the word "notary" for fear of confusing people, and the one remaining mention explicitly calls it an analogy. Evidently, it's still confusing. I'm not sure how many different ways I need to try and get past the horrible word "notary", but it seems to be at least one more than I'm willing to. The original proposal for 0x50 as well as every discussion on the meaning and interpretation is online, including the thread where the title "notary" was removed, and the explicit intent of the 0x50 is restated. I'm done with this. If you feel it's unclear, there is a ready solution to that. > So, how do you sign > (i.e. timestamp) data that isn't already signed by someone else? You use a regular old 0x00 signature. 0x50 gives you capabilities that 0x00 doesn't. That doesn't mean 0x50 takes over all purposes of an 0x00. 0x00+notation or 0x50+notation covers either set of semantics. > 1. timestamp-only at gnupg.org. If this notation exists on the signature, > that indicates it is a timestamp signature. > > 1 a. Should we set this notation critical, non-critical, or user's > choice? We also had the suggestion of doing two signatures, one w/ > critical and one w/out. The idea was that the user will be inclined to > look more closely. I don't see any particular need beyond a straightforward "timestamp-only" at most. Clock drift and clock resolution seems like massive overkill and overcomplexity to me, but if someone else wants it, that's the nice thing about notations - anyone can define them to whatever semantics they like. Pick critical or not depending on the semantics you want: critical means more or less "the receiving system needs to understand this notation to properly understand/handle the signature". It causes (intentional) incompatibility with all deployed code. If those are the desired semantics, then you have no choice, but it's a bit of a hamper (months to years) to adoption. David From jerome at jeromebaum.com Thu Jun 16 07:32:34 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 07:32:34 +0200 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> <456716BE-FE41-4F8E-9194-D628D38EDD56@jabberwocky.com> <9D35C90E-D69A-4967-98FC-30F7EBA7B21A@jabberwocky.com> <5978304A-34EE-4AD4-BE0C-91D1311B0198@jabberwocky.com> Message-ID: >> So, how do you sign >> (i.e. timestamp) data that isn't already signed by someone else? > > You use a regular old 0x00 signature. ?0x50 gives you capabilities that 0x00 doesn't. ?That doesn't mean 0x50 takes over all purposes of an 0x00. ?0x00+notation or 0x50+notation covers either set of semantics. I understood your suggestion as 0x50, not 0x50+n. 0x50+n, where n is "timestamp-only", seems redundant. 0x50 doesn't give additional capabilities. You can sign a signature packet with 0x00 as well. 0x50 is more restricted than 0x00, not more flexible. In any case, let's just use a notation and concentrate on that. The 0x50, clarity/confusion, notation, 0x40, etc. discussion is wasteful and not really fun. >> 1 a. Should we set this notation critical, non-critical, or user's >> choice? We also had the suggestion of doing two signatures, one w/ >> critical and one w/out. The idea was that the user will be inclined to >> look more closely. > > > I don't see any particular need beyond a straightforward "timestamp-only" at most. ?Clock drift and clock resolution seems like massive overkill and overcomplexity to me, but if someone else wants it, that's the nice thing about notations - anyone can define them to whatever semantics they like. I'm thinking in terms of stamper, which does timestamps at scheduled intervals (some 10-15 minutes or so). > Pick critical or not depending on the semantics you want: critical means more or less "the receiving system needs to understand this notation to properly understand/handle the signature". ?It causes (intentional) incompatibility with all deployed code. ?If those are the desired semantics, then you have no choice, but it's a bit of a hamper (months to years) to adoption. I rather was asking (anyone listening in) for an opinion. We've already discussed the trade-offs that you mention. What I'm looking for is to get this specified a bit more formally and get everyone's input, instead of just throwing any random solution out there. My personal vote would be for critical, because while it might hinder compatibility, there's no chance of a user mistaking the signature for something it isn't. The two-part signature sounds interesting but I'm afraid one of the signatures might get lost (leaving the issue of non-critical notation and misinterpretation) and it generally seems somewhat overkill. As for the error/resolution notation, someone else (can't recall who and the gmail thread is unbearable) mentioned that this would be relevant, and with the same breath that you could state this in your signing policy. My thought process is, what if I have two machines, and one is NTP-synced (or even takes legal time from the broadcast signal) while the other regularly drifts up to 10 minutes, or runs timestamping in batches, etc. Of course, I could set up separate keys. Personally I'd opt for the notation, as that's also computer-readable (think "Good timestamp from Alice, between 10:00 and 11:00 on 2011-06-16" or whatever automated processing people want to cook up -- e.g. keeping signatures valid under decaying algorithms by resigning/chaining: This could be verified by some script that you tell when each algorithm was declared "insufficient"). Basically it allows us to do stuff that a note in my policy doesn't, and if we think this through, it won't be very complex. That was the "why have this data?", here's the "how": Another alternative is timestamp-interval at gnupg.org = which describes the interval during which the timestamp was made, accounting for precision and error, and leaving no room for interpretation of the interval, but making it the signer's duty to compute this interval. That's also a lot less complex than a timestamp-precision and timestamp-error, so we're out of "massive overkill" territory. -- 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 Thu Jun 16 09:14:43 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Jun 2011 09:14:43 +0200 Subject: Problem with faked-system-time option In-Reply-To: <4DF90CFC.5060002@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 15 Jun 2011 15:50:20 -0400") 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: <87sjrap7rw.fsf@vigenere.g10code.de> On Wed, 15 Jun 2011 21:50, dkg at fifthhorseman.net said: > 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 If it is a reasonable thing I see no problem to register it and setup an email alias or autoresponder. This thread is way to long to follow; in particular because I am not really interested in a general purpose timestamping service; such services used to exist in the past with non-clear semantics. If you need timestamping for a project, you can simply do it for that particular project without any problems. Will you be so kind and re-explain for what this notation is to be used? David, is that okay for you? > someone set up a registry someplace documenting the specific notations? I have to see whether we already have a list somewhere (there are not too many well-known notation keys). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mailinglisten at hauke-laging.de Thu Jun 16 13:21:09 2011 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 16 Jun 2011 13:21:09 +0200 Subject: timestamp notation @gnupg.org (was: Problem with faked-system-time option) In-Reply-To: <87sjrap7rw.fsf@vigenere.g10code.de> References: <20110603193259.4C19B8C069@nym.dizum.nl> <4DF90CFC.5060002@fifthhorseman.net> <87sjrap7rw.fsf@vigenere.g10code.de> Message-ID: <201106161321.14462.mailinglisten@hauke-laging.de> Am Donnerstag, 16. Juni 2011, 09:14:43 schrieb Werner Koch: > This thread is way to long to follow Especially as it is at least three threads with a common subject... > in > particular because I am not really interested in a general purpose > timestamping service; OK but GnuPG is an infrastructure tool and not so much about personal preferences, isn't it? ;-) So the relevant questions should be: a) Is signed timestamping an important feature for cryptography? b) Do we want to enable easy "cloud timestamping" (on the lines of the web of trust) or do we leave this up to certain services (on the lines of a CA)? c) Who should set a pre-standard (for a testing phase)? > such services used to exist in the past with > non-clear semantics. If you need timestamping for a project, you can > simply do it for that particular project without any problems. That's right but not the web of trust idea. Putting such a feature into GnuPG (even if its just a non-IETF standard notation and the documentation) will raise awareness for the problem to be solved. > Will you be so kind and re-explain for what this notation is to be used? This notation is a more compatible alternative to the signature type 0x40. So its explanation could be used: "Timestamp signature. This signature is only meaningful for the timestamp contained in it." I would add for clarity: "The signer makes no statement about the signed data (including that he has read it or at least could read it at all) except that it existed at the time given in the signature timestamp." It would be used by people who want to securely timestamp data without introducing new (unambigious, like those of a timestamping service) keys for it. The timestamping services may use this, too, for third parties to more easily understand what the signature is about. 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 wk at gnupg.org Thu Jun 16 14:56:32 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Jun 2011 14:56:32 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: <201106161321.14462.mailinglisten@hauke-laging.de> (Hauke Laging's message of "Thu, 16 Jun 2011 13:21:09 +0200") References: <20110603193259.4C19B8C069@nym.dizum.nl> <4DF90CFC.5060002@fifthhorseman.net> <87sjrap7rw.fsf@vigenere.g10code.de> <201106161321.14462.mailinglisten@hauke-laging.de> Message-ID: <87fwnaory7.fsf@vigenere.g10code.de> On Thu, 16 Jun 2011 13:21, mailinglisten at hauke-laging.de said: > OK but GnuPG is an infrastructure tool and not so much about personal > preferences, isn't it? ;-) So the relevant questions should be: I believe it is. However, I maintain GnuPG as a pro-bono service for more than a decade now and thus it matters whether I have a personal interest in a feature. > This notation is a more compatible alternative to the signature type 0x40. So > its explanation could be used: > > "Timestamp signature. This signature is only meaningful for the timestamp > contained in it." That is a bit too terse. What is a timestamp how is it formatted in the message and what does such a signature actually mean. Oh, I see: We are back to that long thread and to the reason why the rfc1991 defined timestamp signature class has nevver been used in reality. > I would add for clarity: "The signer makes no statement about the signed data > (including that he has read it or at least could read it at all) except that > it existed at the time given in the signature timestamp." Well, so write that into the signed data or the signature meta data and you are done. We have a policy flag for that. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gnupg.user at seibercom.net Thu Jun 16 14:18:57 2011 From: gnupg.user at seibercom.net (Jerry) Date: Thu, 16 Jun 2011 08:18:57 -0400 Subject: Understanding the "--refresh-keys" output Message-ID: <20110616081857.2b83d7f2@scorpio> This is probably a really dumb question; however, I am hoping that someone can answer it for me. On a FreeBSD-8.2 system, running "/usr/local/bin/gpg2 --refresh-keys" ends with the following output. gpg: Total number processed: 396 gpg: unchanged: 395 gpg: new signatures: 35 gpg: public key E6602099 is 129863409 seconds newer than the signature gpg: public key E6602099 is 129863409 seconds newer than the signature gpg: public key E6602099 is 129863409 seconds newer than the signature gpg: public key E6602099 is 129863409 seconds newer than the signature gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 17 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 17u Why is the same line repeated four times and what do lines 8 and 9 mean? I have been reading through the documentation but have not been able to ascertain that information. -- Jerry ? GNUPG.user at seibercom.net _____________________________________________________________________ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. From gnupg.user at seibercom.net Thu Jun 16 14:24:12 2011 From: gnupg.user at seibercom.net (Jerry) Date: Thu, 16 Jun 2011 08:24:12 -0400 Subject: Problem with "hkp server wwwkeys.eu.pgp.net" Message-ID: <20110616082412.6e71c884@scorpio> The "hkp server wwwkeys.eu.pgp.net" has been unreachable for several days at least from my locale. I was wondering if anyone had any information regarding it or who I could report this problem to? Thanks! -- Jerry ? GNUPG.user at seibercom.net _____________________________________________________________________ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. From dshaw at jabberwocky.com Thu Jun 16 15:31:36 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 16 Jun 2011 09:31:36 -0400 Subject: Understanding the "--refresh-keys" output In-Reply-To: <20110616081857.2b83d7f2@scorpio> References: <20110616081857.2b83d7f2@scorpio> Message-ID: <067A0B63-AA35-4670-B7AA-AF9B83A17540@jabberwocky.com> On Jun 16, 2011, at 8:18 AM, Jerry wrote: > This is probably a really dumb question; however, I am hoping that > someone can answer it for me. > > On a FreeBSD-8.2 system, running "/usr/local/bin/gpg2 --refresh-keys" > ends with the following output. > > > gpg: Total number processed: 396 > gpg: unchanged: 395 > gpg: new signatures: 35 > gpg: public key E6602099 is 129863409 seconds newer than the signature > gpg: public key E6602099 is 129863409 seconds newer than the signature > gpg: public key E6602099 is 129863409 seconds newer than the signature > gpg: public key E6602099 is 129863409 seconds newer than the signature > gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model > gpg: depth: 0 valid: 17 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 17u > > > Why is the same line repeated four times and what do lines 8 and 9 > mean? I have been reading through the documentation but have not been > able to ascertain that information. The repeated line is a warning that the key itself has a timestamp that is *after* one of the signatures on it. This indicates that either the key or the signature in question has a wonky timestamp. Line 8 means you are using the PGP trust model, and you have configured it so that it takes 3 marginal signatures or one complete signature to treat a key as valid. See the manual options --trust-model, --marginals-needed, and --completes-needed. Briefly, these are the terms that GPG will follow when building the web of trust, to decide what keys are valid and what are not. Line 9 is just a key count. You have 17 valid keys. All of them ("u") are ultimately trusted, which suggests that you have 17 keys that you have generated as ultimate trust is generally used for people's own keys. (If you can't trust yourself, who can you trust?) David From dshaw at JABBERWOCKY.COM Thu Jun 16 15:53:59 2011 From: dshaw at JABBERWOCKY.COM (David Shaw) Date: Thu, 16 Jun 2011 09:53:59 -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> <456716BE-FE41-4F8E-9194-D628D38EDD56@jabberwocky.com> <9D35C90E-D69A-4967-98FC-30F7EBA7B21A@jabberwocky.com> <5978304A-34EE-4AD4-BE0C-91D1311B0198@jabberwocky.com> Message-ID: <1503B6DC-D72D-4824-B9A0-E57239DD1618@JABBERWOCKY.COM> On Jun 16, 2011, at 1:32 AM, Jerome Baum wrote: >>> So, how do you sign >>> (i.e. timestamp) data that isn't already signed by someone else? >> >> You use a regular old 0x00 signature. 0x50 gives you capabilities that 0x00 doesn't. That doesn't mean 0x50 takes over all purposes of an 0x00. 0x00+notation or 0x50+notation covers either set of semantics. > > I understood your suggestion as 0x50, not 0x50+n. 0x50+n, where n is > "timestamp-only", seems redundant. > > 0x50 doesn't give additional capabilities. You can sign a signature > packet with 0x00 as well. 0x50 is more restricted than 0x00, not more > flexible. I can make a key signature 0x10 with 0x00 as well (heck, I can make a 0x01 signature using 0x00 as well). It doesn't make it a smart thing to do since GPG can't automatically canonicalize the data. The point of 0x50 is that *GPG understands it's a sig-on-a-sig* and can treat it differently, using signature canonicalization (otherwise, why would we have created 0x50 in the first place?) Thus 0x50+notation means we can make timestamp signatures over other signatures. That's a good thing. It means the proposed notation can be used in multiple places. > In any case, let's just use a notation and concentrate on that. The > 0x50, clarity/confusion, notation, 0x40, etc. discussion is wasteful > and not really fun. You still don't understand. You are proposing a new feature for OpenPGP, so it needs to consider the various interactions this new "timestamp-only" flag has with different signature types. These are the sorts of comments and questions that need to be looked at when adding a new feature to the standard. This is not adversarial! The goal is to have the best possible design that considers how this new thing fits in to the OpenPGP standard as a whole and that there aren't any gotchas or "Ugh, I wish we would have done xxxx" later. David From dshaw at JABBERWOCKY.COM Thu Jun 16 15:58:47 2011 From: dshaw at JABBERWOCKY.COM (David Shaw) Date: Thu, 16 Jun 2011 09:58:47 -0400 Subject: Problem with faked-system-time option In-Reply-To: <87sjrap7rw.fsf@vigenere.g10code.de> 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> <87sjrap7rw.fsf@vigenere.g10code.de> Message-ID: <7563828B-366B-4D7C-A390-2CCB3155CDB4@JABBERWOCKY.COM> On Jun 16, 2011, at 3:14 AM, Werner Koch wrote: > On Wed, 15 Jun 2011 21:50, dkg at fifthhorseman.net said: > >> 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 > > If it is a reasonable thing I see no problem to register it and setup an > email alias or autoresponder. This thread is way to long to follow; in > particular because I am not really interested in a general purpose > timestamping service; such services used to exist in the past with > non-clear semantics. If you need timestamping for a project, you can > simply do it for that particular project without any problems. > > Will you be so kind and re-explain for what this notation is to be used? > > David, is that okay for you? I got into this discussion because there was talk of new subpackets or sigclasses and a misunderstanding of how notations worked. I don't have a particular desire or need for a timestamp signature, but I do have a particular desire for OpenPGP and GPG to grow cleanly. I see two parts to this: one, the definition of a new notation to indicate timestamp-only and what that means and how it is used, and two, the incorporation of new code in GPG to use the new notation. On the first part, my feeling is that if someone needs a notation and wants it to be as widely useful and well designed as possible, they should treat it a a new subpacket would be treated on ietf-openpgp: propose, discuss, revise, etc, and consider it in the context of the whole standard. Very frequently, a subpacket could be more generally useful than a single original purpose, and it's worth looking at things from that perspective. For example, one of the proposed notations is a timestamp accuracy notation - could that be also useful for regular non-timestamp signatures? New subpackets or notations can also be dangerous or at least confusing: what does a timestamp-only key signature mean? Unless it's marked critical, the web of trust code in both GPG and PGP will treat those signatures as fully qualified ones and not just timestamp-only, yet if it is marked critical, it's not very useful without code changes. All of that is solvable, of course, but it should be addressed. In this particular case, people seem to want a notation under the gnupg.org domain, arguing that it will be more likely to be adopted as the gnupg.org domain lends some cachet. I don't agree with that, but don't care enough to argue it. In terms of the second part, GPG itself, I don't yet see a need for any code change, which will have to be written and then maintained in the code (semi-)indefinitely. Perhaps I'm cynical, but I don't really see a lot of people clamoring for this or blocked for the lack of it, especially given that if people desire to tag their signatures as timestamp-only, they can do that now via --notation-data, and look for its presence via show-notations, which is the default anyway. David From dshaw at jabberwocky.com Thu Jun 16 16:10:19 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 16 Jun 2011 10:10:19 -0400 Subject: Problem with "hkp server wwwkeys.eu.pgp.net" In-Reply-To: <20110616082412.6e71c884@scorpio> References: <20110616082412.6e71c884@scorpio> Message-ID: <0F9AF9B2-694B-4D14-9EFC-8B1961995F93@jabberwocky.com> On Jun 16, 2011, at 8:24 AM, Jerry wrote: > The "hkp server wwwkeys.eu.pgp.net" has been unreachable for several > days at least from my locale. I was wondering if anyone had any > information regarding it or who I could report this problem to? wwwkeys.eu.pgp.net is intended to be a round-robin of all EU keyservers. In practice, it's only one server at the moment, which does seem to be down. I think your best bet is to mention this on sks-devel where most of the keyserver operators hang out. See http://lists.nongnu.org/mailman/listinfo/sks-devel David From mailinglisten at hauke-laging.de Thu Jun 16 16:27:12 2011 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 16 Jun 2011 16:27:12 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: <87fwnaory7.fsf@vigenere.g10code.de> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161321.14462.mailinglisten@hauke-laging.de> <87fwnaory7.fsf@vigenere.g10code.de> Message-ID: <201106161627.13391.mailinglisten@hauke-laging.de> Am Donnerstag, 16. Juni 2011, 14:56:32 schrieb Werner Koch: > > This notation is a more compatible alternative to the signature type > > 0x40. So its explanation could be used: > > > > "Timestamp signature. This signature is only meaningful for the timestamp > > contained in it." > > That is a bit too terse. What is a timestamp how is it formatted in the > message and what does such a signature actually mean. Perhaps you have misunderstood the intention: This is not about changing data formats. This is not about changing gpg code (could be for convenience but is not necessary). This is primarily about a uniform understanding of already available features so that the usage of these features gets easier (and more common). If anyone is not happy with the OpenPGP timestamp format (which I haven't noticed yet) then that would be a completely different discussion. > > I would add for clarity: "The signer makes no statement about the signed > > data (including that he has read it or at least could read it at all) > > except that it existed at the time given in the signature timestamp." > > Well, so write that into the signed data or the signature meta data and > you are done. We have a policy flag for that. Nobody said it was not possible at all. The discussion is about making it much easier. The easy of use has (at least) two parts: Accessibility of the information and a uniform format. Of course, it would not make sense to make a standard for every possible information that could be contained in a signature policy. But this is a very basic statement (possibly extended by a policy URL) for a feature which has been mentioned by several GnuPG related RfCs, which is offered by commercial and free services and even covered by crypto law. There is no need to use @gnupg.org as a test phase name space; it just makes sense IMHO. But if you prefer to limit gnupg.org to the code that's perfectly OK. This question is not even related to this timestamp discussion: Do you want to promote the uniform usage of notations (perhaps later taken over into IETF namespace) via this mailinglist and an officially maintained list of notations in the gnupg.org namespace or not? If you want to avoid notations in gnupg.org then the discussion is finished anyway. 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 Thu Jun 16 16:38:06 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 16 Jun 2011 10:38:06 -0400 Subject: Understanding the "--refresh-keys" output In-Reply-To: <067A0B63-AA35-4670-B7AA-AF9B83A17540@jabberwocky.com> References: <20110616081857.2b83d7f2@scorpio> <067A0B63-AA35-4670-B7AA-AF9B83A17540@jabberwocky.com> Message-ID: <4DFA154E.3010608@fifthhorseman.net> On 06/16/2011 09:31 AM, David Shaw wrote: > Line 9 is just a key count. You have 17 valid keys. All of them ("u") are ultimately trusted, which suggests that you have 17 keys that you have generated as ultimate trust is generally used for people's own keys. (If you can't trust yourself, who can you trust?) 17 keys is a lot of keys to have generated yourself (though there are some circumstances where i'm sure it makes some sort of sense). But if those aren't all your own keys: If you have been in the habit of assigning ultimate ownertrust to keys other than your own, you probably want to reconsider that decision. ultimate ownertrust allows a keyholder to make any certification whatsoever (including over their own keys) and have you accept their certification. In general, use full or marginal ownertrust for parties other than yourself. --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 venture37 at gmail.com Thu Jun 16 18:40:59 2011 From: venture37 at gmail.com (Sevan / Venture37) Date: Thu, 16 Jun 2011 17:40:59 +0100 Subject: Key generation on card fails with key sizes larger than 1024 bits In-Reply-To: References: <87zkmlqyz4.fsf@vigenere.g10code.de> <87fwob92y4.fsf@vigenere.g10code.de> <87y6236ryc.fsf@vigenere.g10code.de> Message-ID: Made a fresh install of Debian i386 6.0.1 with gpg 1.4.10 I was able to successfully generate 3072bit keys on the card without any problems. Now to roll back to FreeBSD 7 & try that. Sevan From jerome at jeromebaum.com Thu Jun 16 18:55:33 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 18:55:33 +0200 Subject: Problem with faked-system-time option In-Reply-To: <7563828B-366B-4D7C-A390-2CCB3155CDB4@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> <87sjrap7rw.fsf@vigenere.g10code.de> <7563828B-366B-4D7C-A390-2CCB3155CDB4@JABBERWOCKY.COM> Message-ID: (In the context below, "we" refers to the people to whom the respective statement applies.) > I got into this discussion because there was talk of new subpackets or sigclasses and a misunderstanding of how notations worked. What talk of new subpackets and signature classes? Feel free to quote. As for the misunderstanding of how notations work, what's their purpose then? Aren't they incorporated into the standard to make it easier to extend/add features? Is it a "bad thing" to have a computer-readable notation? (Of course, I'm assuming that "how notations worked" refers to "what they are meant for", and not to the technical aspects [notations being key-value pairs etc]. The latter would be non-sense, as we've not shown a misunderstanding for how notations technically work.) > On the first part, my feeling is that if someone needs a notation and wants it to be as widely useful and well designed as possible, they should treat it a a new subpacket would be treated on ietf-openpgp: propose, discuss, revise, etc, and consider it in the context of the whole standard. Haven't we proposed a specification, asked for input (discuss), revised it (I've posted at least one update)? Just because you've withheld your input until now, doesn't meant we haven't discussed this, and that we aren't still discussing this. > Very frequently, a subpacket could be more generally useful than a single original purpose, and it's worth looking at things from that perspective. For example, one of the proposed notations is a timestamp accuracy notation - could that be also useful for regular non-timestamp signatures? Probably not. Everyone seems to agree that timestamps in a normal signature are somewhat meaningless and only serve as an indicator. If you want a reliable timestamp, why not make a timestamp signature? In fact, even if there was a way to indicate timestamp accuracy for a standard 0x00 (e.g. appropriately specifying the notation), I have strong feelings against that. If I do a timestamp signature, I'm aware that I should worry about my system time being correct. If I do a plain 0x00 signature, I may well forget, and if my defaults say "this timestamp is accurate, add the appropriate field/notation", suddenly I'll be in trouble for falsification, fraud, or something of the kind. I'm thinking of an average user here, who doesn't have 100% reliable memory and may forget stuff. I'll simply ignore any argument that assumes the average user doesn't forget stuff. Looking at it though, this still doesn't speak against a notation. I have yet to hear a solid reason for not using a notation (besides "I like 0x50. It severely limits what you can do with it, but I feel reuse must be done at all costs. Use 0x50" -- note that I'm not even bringing up the confusion argument anymore, as that's highly subjective -- but the inability to sign data is an objective fact). > New subpackets or notations can also be dangerous or at least confusing: what does a timestamp-only key signature mean? timestamp-only at gnupg.org would apply only to data signatures. But see below. > Unless it's marked critical, the web of trust code in both GPG and PGP will treat those signatures as fully qualified ones and not just timestamp-only, yet if it is marked critical, it's not very useful without code changes. We never suggested timestamp-only certifications. How would those make sense anyway? Are you saying that this key was valixistant at some point in time? (Sure, there can be a reason, and I'd love to hear it. The point is, you didn't bring this up before and now you're complaining we haven't discussed it?) > All of that is solvable, of course, but it should be addressed. Which is why I've repeatedly asked for input on the proposed specification. > In terms of the second part, GPG itself, I don't yet see a need for any code change, which will have to be written and then maintained in the code (semi-)indefinitely. ?Perhaps I'm cynical, but I don't really see a lot of people clamoring for this or blocked for the lack of it, especially given that if people desire to tag their signatures as timestamp-only, they can do that now via --notation-data, and look for its presence via show-notations, which is the default anyway. That's one of the reasons we're preferring the notation. It "just works". In fact, unlike 0x40/0x50, we can choose how an older implementation reacts to a notation-marked timestamp-only signature (by setting critical or not). -- 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 19:15:39 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 19:15:39 +0200 Subject: Problem with faked-system-time option In-Reply-To: <1503B6DC-D72D-4824-B9A0-E57239DD1618@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> <9D35C90E-D69A-4967-98FC-30F7EBA7B21A@jabberwocky.com> <5978304A-34EE-4AD4-BE0C-91D1311B0198@jabberwocky.com> <1503B6DC-D72D-4824-B9A0-E57239DD1618@JABBERWOCKY.COM> Message-ID: >> In any case, let's just use a notation and concentrate on that. The >> 0x50, clarity/confusion, notation, 0x40, etc. discussion is wasteful >> and not really fun. > > You still don't understand. Really? Maybe *you* just haven't brought up all those issues until now. Here's what I see: Me: Guys, we're looking to do X. Do you have any input? You: Don't do X, do Y. Here's why: A. Me: A is invalid. We'll still do X. You: But A! Me: A is invalid. You: You still don't understand. B is a good reason not to do X. You haven't discussed B! You never brought up "various interactions this [notation] has with different signature types" until now. You were suggesting to dump the notation entirely, and use an 0x50 instead. Of course, I can only see what you've written (and only what I recall), not what you may have intended to write. >?You are proposing a new feature for OpenPGP, so it needs to consider the various interactions this new "timestamp-only" flag has with different signature types. ?These are the sorts of comments and questions that need to be looked at when adding a new feature to the standard. ?This is not adversarial! ? The goal is to have the best possible design that considers how this new thing fits in to the OpenPGP standard as a whole and that there aren't any gotchas or "Ugh, I wish we would have done xxxx" later. The goal depends on who's looking. My goal is to have a notation that we can use for simple timestamp-only signatures on data like stamper does, as easily as possible but still somewhat flexible -- note how "somewhat" contrasts with "entirely". Your goal may be "to have the best possible design", but it's not mine. I consider "best possible" a fallacy, as there are *always* trade-offs. There will always be gotchas, you will always wish you "would have done xxxx". Note that I wouldn't. I would simply assume that humans make errors, and that I am human. I would move on and work on the next version, instead of complaining that my design wasn't "the best possible". Given all that, I am very happy that you've uncovered an implicit assumption I was making: That the timestamp-only at gnupg.org notation would be defined only on 0x00 (possibly 0x01). We need to either explicitly add that to the spec, or change the assumption. -- 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 19:21:35 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 19:21:35 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: <201106161627.13391.mailinglisten@hauke-laging.de> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161321.14462.mailinglisten@hauke-laging.de> <87fwnaory7.fsf@vigenere.g10code.de> <201106161627.13391.mailinglisten@hauke-laging.de> Message-ID: > Do you want to promote the uniform usage of notations (perhaps later taken > over into IETF namespace) via this mailinglist and an officially maintained > list of notations in the gnupg.org namespace or not? > > If you want to avoid notations in gnupg.org then the discussion is finished > anyway. As the last post I will contribute to this thread (unless we get a positive response from Werner), here's a summary of where we are: 1. timestamp-only at gnupg.org. If this notation exists on the signature, that indicates it is a timestamp signature. 1 a. Should we set this notation critical, non-critical, or user's choice? We also had the suggestion of doing two signatures, one w/ critical and one w/out. The idea was that the user will be inclined to look more closely. 1 b. On what signature types may this notation be defined? 0x00 definitely, what else? 2. Suggestion: timestamp-resolution at gnupg.org. Value is number of seconds of error in both directions. 2 a. Thinking about it, this should be two notations: timestamp-error at gnupg.org, and timestamp-resolution at gnupg.org (the difference being: error = clock drift, while resolution = fixed intervals, e.g. for datestamps resolution would be 86400 and timestamp would be at 00:00). 2 b. Another alternative is timestamp-interval at gnupg.org = which describes the interval during which the timestamp was made, accounting for precision and error, and leaving no room for interpretation of the interval, but making it the signer's duty to compute this interval. 2 c. Again, where may this be defined? At least all of # 1 b. 3. Other stuff? Just so that Werner has a summary of what we've discussed, to base a decision on. -- 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 19:32:51 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 16 Jun 2011 13:32:51 -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> <87sjrap7rw.fsf@vigenere.g10code.de> <7563828B-366B-4D7C-A390-2CCB3155CDB4@JABBERWOCKY.COM> Message-ID: <71CB91D3-093A-4B2E-92DD-EE22DDE541F5@jabberwocky.com> On Jun 16, 2011, at 12:55 PM, Jerome Baum wrote: > (In the context below, "we" refers to the people to whom the > respective statement applies.) > >> I got into this discussion because there was talk of new subpackets or sigclasses and a misunderstanding of how notations worked. > > What talk of new subpackets and signature classes? Feel free to quote. Daniel raised the question of using sigclass 0x40 (not subpacket). The misunderstanding about notations was that the non-IETF namespace was some sort of temporary place where things could be tried out until IETF standardization came. You said, and I quote: > So, um, let's just start using a non-standardized notation in the "@" > namespace and then wait for standardization? That's not how notations work. You know, I actually started responding to the rest of this note, and your actively hostile and accusatory other email, but there is really little point. You seem to want what you want, and see any discussion as an attack. Many responses to you on both the subthread of why someone would want this, and also this subthread of how to do it have been met with hostility and condescension. I'm out. I have better things to spend time on. David From dkg at fifthhorseman.net Thu Jun 16 19:37:02 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 16 Jun 2011 13:37:02 -0400 Subject: what does a timestamp signature mean? [was: Re: 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> <87sjrap7rw.fsf@vigenere.g10code.de> <7563828B-366B-4D7C-A390-2CCB3155CDB4@JABBERWOCKY.COM> Message-ID: <4DFA3F3E.5060707@fifthhorseman.net> On 06/16/2011 12:55 PM, Jerome Baum wrote: > Probably not. Everyone seems to agree that timestamps in a normal > signature are somewhat meaningless and only serve as an indicator. If > you want a reliable timestamp, why not make a timestamp signature? I don't think this is the general consensus. Timestamps *are* meaningful -- they are an assertion by the person making the signature of what time they made the signature. That assertion could be false, of course, but then nothing is stopping you from signing any other sort of false assertion either. That doesn't make the assertion meaningless; it just makes it wrong. What it sounds like you want is an *unforgeable* timestamp indicator. That is, you want some way to prove "this signature was made at time X" Due to the imprecision of any mechanical timekeeping device, there will be some wiggle-room in such a signature, so it's useful to clarify that this hypothetical claim is actually: "this signature was made at time X ? e" or, alternately, two separate assertions: a) "This signature was made after time X-e", and b) "This signature was made before time X+e" let's take these two cases separately for a moment. (a) is easy to do with existing tools and some sort of globally-published, inherently unpredictable data (e.g. the number of words on the front page of some particular edition of the New York Times, or perhaps the digest of the most recent block added to the global bitcoin blockchain). If you want to specify that as its own notation, i think that's a pretty clean mechanism to prove part (a). I think part (b) is much harder to prove effectively, and (alas) it's probably what people really want to know. To do that properly, i do think you'd need some sort of public service, to which you would submit cryptographically-strong digests of things to be published in such a way that people could confirm it by date. It would need to publish all timestamped signatures in a way that people could verify and accumulate the digests independently. I don't think the information for (b) is possible to embed in a signature on its own, due to the way we experience time (we can remember/recreate how things were in the past; we can't do the same about the future). So if your goal is to have such an unforgeable timestamp, i'd suggest focusing on a clearly-defined specification for (a) (probably in-scope for this list and for the IETF OpenPGP WG), and on implementing a global service for (b) (probably out-of-scope for this mailing list) FWIW, i actually think the assertion-by-signer part (which we already have) is more useful and meaningful than any arbitrary "unforgeable timestamp". I'd be happy to be wrong about the above analysis. --dkg PS i have omitted questions about relativity, but anyone making a claim about time should be aware that there are already known practical problems in dealing with time due to different inertial frames: https://secure.wikimedia.org/wikipedia/en/wiki/Clock_drift#Relativity -------------- 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 Thu Jun 16 19:44:00 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 16 Jun 2011 13:44:00 -0400 Subject: Understanding the "--refresh-keys" output In-Reply-To: <4DFA154E.3010608@fifthhorseman.net> References: <20110616081857.2b83d7f2@scorpio> <067A0B63-AA35-4670-B7AA-AF9B83A17540@jabberwocky.com> <4DFA154E.3010608@fifthhorseman.net> Message-ID: <734A54CD-C8DE-4806-8866-3D6656801A87@jabberwocky.com> On Jun 16, 2011, at 10:38 AM, Daniel Kahn Gillmor wrote: > On 06/16/2011 09:31 AM, David Shaw wrote: >> Line 9 is just a key count. You have 17 valid keys. All of them ("u") are ultimately trusted, which suggests that you have 17 keys that you have generated as ultimate trust is generally used for people's own keys. (If you can't trust yourself, who can you trust?) > > 17 keys is a lot of keys to have generated yourself (though there are > some circumstances where i'm sure it makes some sort of sense). Just 17? My current GPG test VM used for development: gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 154 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 154u ;) Seriously, though, Daniel is right. If those 17 keys aren't just endless test keys like mine, you might be doing something you didn't intend to. David From dshaw at jabberwocky.com Thu Jun 16 19:51:02 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 16 Jun 2011 13:51:02 -0400 Subject: Question regarding the migration of the pgp keyring to gpg In-Reply-To: <2225D816DF89824D9DE3D8163420E90E748493CAC0@TLEMLMBX15P.email.target.com> References: <2225D816DF89824D9DE3D8163420E90E7459655917@TLEMLMBX15P.email.target.com> <2225D816DF89824D9DE3D8163420E90E748493CAC0@TLEMLMBX15P.email.target.com> Message-ID: <822A2FF7-A161-423B-9D13-20218EEA4E0F@jabberwocky.com> On May 27, 2011, at 8:24 AM, Pramod.R wrote: > Hi David, > > Thanks so much for your response on this. > > Now, when I tried decrypting a pgp encrypted file through a gpg (using the gpg --decrypt command), I'm running into this problem of "idea encryption (0) failed" even when I tried compiling one of the idea.c that I downloaded, using the command: gcc -Wall -O2 -shared -fPIC -DBIG_ENDIAN_HOST -o idea idea.c > > I came across one of your posts in the below link where you mentioned that you edited the idea.c for the "endianness" and got it working: > > http://markmail.org/message/gmev3dorhh7xa5nt#query:+page:1+mid:omfowi5jah2w2xxt+state:results > > Could you please let send me the latest version of the idea.c that has taken care of this problem? Probably your best bet for IDEA support is to build it right into the binary. To do this, take the idea.c file and put it in the "cipher" directory of the GnuPG distribution (you said earlier you were using 1.4.11). Then do the usual ./configure and make as you normally do. The build scripts have code to recognize this case and will incorporate IDEA directly into the resulting gpg binary. David From jerome at jeromebaum.com Thu Jun 16 20:27:38 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 20:27:38 +0200 Subject: what does a timestamp signature mean? [was: Re: Problem with faked-system-time option] In-Reply-To: <4DFA3F3E.5060707@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> <87sjrap7rw.fsf@vigenere.g10code.de> <7563828B-366B-4D7C-A390-2CCB3155CDB4@JABBERWOCKY.COM> <4DFA3F3E.5060707@fifthhorseman.net> Message-ID: Hey, this discussion is much more interesting. Let's keep the arguments about specification, usefulness, etc. out of this thread! >> Probably not. Everyone seems to agree that timestamps in a normal >> signature are somewhat meaningless and only serve as an indicator. If >> you want a reliable timestamp, why not make a timestamp signature? > > I don't think this is the general consensus. ?Timestamps *are* > meaningful -- they are an assertion by the person making the signature > of what time they made the signature. I would say that it's a matter of interpretation, and often enough the timestamps in a signature are not correct. However, yes, a lot of people certainly watch out for correct timestamps. The problem is, if you have a signature without a signing policy, how do you know if the timestamp is meaningful? > That assertion could be false, of course, but then nothing is stopping > you from signing any other sort of false assertion either. ?That doesn't > make the assertion meaningless; it just makes it wrong. The law tends to consider two parts: 1. What's noted down (in a document/signature). 2. What you actually meant. # 1 is unambiguous. # 2 has to be interpreted (in the theoretical model, # 2 is taken to be what an "average" person -- context-dependent! -- would have meant by noting down the stuff in # 1). So, it could be argued that the average OpenPGP user does not care for the timestamp, or vice versa. It would depend what the judiciary considers to be most plausible and likely. As it's highly subjective, let's end that part right here and just say "it depends". > What it sounds like you want is an *unforgeable* timestamp indicator. > That is, you want some way to prove "this signature was made at time X" Not really. What I want is some way to say "I saw this at-or-before time X". Rather, for a third-party to say this about my data. Whether that third-party can be trusted, or how they might publish their records to make the data -- not the party -- more trustworthy, wasn't the scope of the discussion. We already came to the conclusion that a timestamp's authenticity is subjective, and it again depends: Can you convince the judge? > Due to the imprecision of any mechanical timekeeping device, there will > be some wiggle-room in such a signature, so it's useful to clarify that > this hypothetical claim is actually: > > ?"this signature was made at time X ? e" > > or, alternately, two separate assertions: > > ?a) "This signature was made after time X-e", and > ?b) "This signature was made before time X+e" > > let's take these two cases separately for a moment. ?(a) is easy to do > with existing tools and some sort of globally-published, inherently > unpredictable data (e.g. the number of words on the front page of some > particular edition of the New York Times, or perhaps the digest of the > most recent block added to the global bitcoin blockchain). ?If you want > to specify that as its own notation, i think that's a pretty clean > mechanism to prove part (a). Does anyone really have an interest in proving (a) (other than to dispute (b), of course)? (Don't take this as "you say BS", but rather as "I am honestly curious to hear about real-world applications".) > I think part (b) is much harder to prove effectively, and (alas) it's > probably what people really want to know. ?To do that properly, i do > think you'd need some sort of public service, to which you would submit > cryptographically-strong digests of things to be published in such a way > that people could confirm it by date. ?It would need to publish all > timestamped signatures in a way that people could verify and accumulate > the digests independently. e.g. stamper. > I don't think the information for (b) is possible to embed in a > signature on its own, due to the way we experience time (we can > remember/recreate how things were in the past; we can't do the same > about the future). That wasn't the goal. You can't embed this into a signature without real-world context. The reason is simple: Time runs in the real world. A signature is just bits and bytes, without the "meta-data" of "when did I create this?" > So if your goal is to have such an unforgeable timestamp, i'd suggest > focusing on a clearly-defined specification for (a) (probably in-scope > for this list and for the IETF OpenPGP WG), and on implementing a global > service for (b) (probably out-of-scope for this mailing list) It's not the goal. Anyway, you'd have a hard time specifying (a) entirely, as there's the problem of choice: Do I use NYT or bitcoin's data? As for (b), the idea behind this notation was to enable lots of smaller services, just like the WoT. > FWIW, i actually think the assertion-by-signer part (which we already > have) is more useful and meaningful than any arbitrary "unforgeable > timestamp". Again, wasn't the goal. As for usefulness of assertion-by-signer, see above for repudiating that you made/intended to make that assertion. > PS i have omitted questions about relativity, but anyone making a claim > about time should be aware that there are already known practical > problems in dealing with time due to different inertial frames: > > ?https://secure.wikimedia.org/wikipedia/en/wiki/Clock_drift#Relativity "[citation needed]" (Just that I have a bit of a dislike against Wikipedia. Doesn't make your point less valid in any way, I'm just saying.) In the context of law, at least in Germany, it is assumed that there is a single legal time throughout the whole of Germany. You don't usually care about absolute time anyway. It's a tool to establish ordering of events, and interval length between two events (think deadlines). When it comes to deadlines, usually you're talking on the order of days, weeks, months, and usually you have to act during business hours to meet a deadline, so there is a big gap between two "time units". No need to worry about relativity. I also doubt that OpenPGP signatures will be relevant in a proceeding where relativity comes into play. At least in practice. If you think about a timestamp is for, usually you're not actually concerned with saying "I did X yesterday". You're usually concerned with saying "I did X within 2 weeks of your notice", or "I did X before you did Y". Other options include "I did X before the cancellation deadline" and "I did X within 2 minutes, so I was acting promptly and wasn't negligent". -- 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 Thu Jun 16 20:40:51 2011 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 16 Jun 2011 20:40:51 +0200 Subject: what does a timestamp signature mean? In-Reply-To: <4DFA3F3E.5060707@fifthhorseman.net> References: <20110603193259.4C19B8C069@nym.dizum.nl> <4DFA3F3E.5060707@fifthhorseman.net> Message-ID: <201106162040.57487.mailinglisten@hauke-laging.de> Am Donnerstag, 16. Juni 2011, 19:37:02 schrieb Daniel Kahn Gillmor: > On 06/16/2011 12:55 PM, Jerome Baum wrote: > > Probably not. Everyone seems to agree that timestamps in a normal > > signature are somewhat meaningless and only serve as an indicator. If > > you want a reliable timestamp, why not make a timestamp signature? > > I don't think this is the general consensus. So don't I. By my understanding the result of the discussion was there are situation in which a third party timestamp is necessary to prove a signature correct. Then the discussion moved to problems of timestamping. As timestamping (for other ones) is useful it should be as simple and risk free as possible. There was the argument that there is an unpleasant ambiguity if there are two meanings of signatures (normal signatures which refer to content and timestamp and timestamp signatures which shall not make any statement about the content) but no technical difference. Strictly speaking you always have to consult the signature policy to know the intention but that is not easily done (let alone the fact that many signatures (and keys) do not have a policy URL). > What it sounds like you want is an *unforgeable* timestamp indicator. I would describe it so: The aim is an explicit reduction of trust (in order to avoid misunderstandings instead of perhaps painfully solve them afterwards). My wish is a reduction to the timestamp. Jerome also wants a standard statement of the possible timestamp error. I don't think that is important but there is no namespace problem so I don't care. My argument about the last point is that you immediately see the timestamp of the third party signature and have to react if its wrong. After all a statement about the assumed clock precision does not prevent clock problems. 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 Thu Jun 16 20:53:34 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 16 Jun 2011 14:53:34 -0400 Subject: what does a timestamp signature mean? [was: Re: 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> <87sjrap7rw.fsf@vigenere.g10code.de> <7563828B-366B-4D7C-A390-2CCB3155CDB4@JABBERWOCKY.COM> <4DFA3F3E.5060707@fifthhorseman.net> Message-ID: <4DFA512E.1060807@fifthhorseman.net> On 06/16/2011 02:27 PM, Jerome Baum wrote: > this discussion is much more interesting. Let's keep the arguments > about specification, usefulness, etc. out of this thread! Actually, i think usefulness and specification are quite important. Without them, this discussion is just noise to me. > [dkg wrote]: >> I don't think this is the general consensus. Timestamps *are* >> meaningful -- they are an assertion by the person making the signature >> of what time they made the signature. > > I would say that it's a matter of interpretation, I actually don't think what i said above is a matter of interpretation. > The law tends to consider two parts: I'm not actually on this list ("gnupg-users", ahem) to discuss the law; can we stick to the crypto and its real-world consequences, specifications, and usefulness (or lack thereof)? This does mean that we'll occasionally venture into legal territory, but (a) there are probably many different jurisdictions represented on this list, and (b) many of us (myself included) have little to no legal training. > Not really. What I want is some way to say "I saw this at-or-before > time X". This is (roughly) what i defined as (b) later in my message. If you'd like to replace "i saw this" instead of "i made this signature" then fine; that's a matter of signing policy; or, you could simply make a document that says "I saw the document with digest XXXX". At any rate, we're talking about what the timestamp in the signature means (or can mean). >> a) "This signature was made after time X-e", and >> b) "This signature was made before time X+e" [...] > Does anyone really have an interest in proving (a) (other than to > dispute (b), of course)? [...] >> I think part (b) is much harder to prove effectively, and (alas) it's >> probably what people really want to know. i answered your question in the original mail here, i think. > Anyway, you'd have a hard time specifying (a) > entirely, as there's the problem of choice: Do I use NYT or bitcoin's > data? That's not actually that hard; it's just some (somewhat political) legwork to make sure there is a rough consensus on one decision or the other, then making that decision, writing up the detailed specifications publicly in an unambiguous manner. Writing some code to make it easy to use might be hard, but specifying it is not particularly difficult, if you decide you want it. > As for (b), the idea behind this notation was to enable lots of > smaller services, just like the WoT. I'm afraid i don't see the analogy. Can you spell out what you intend to enable with more specifics, and why it would be useful? > Again, wasn't the goal. As for usefulness of assertion-by-signer, see > above for repudiating that you made/intended to make that assertion. ??? When i make a signature with a timestamp in it, i am very much making (and intending to make) the assertion that the signature was made at that time. I see no repudiation in your message, only that "some people don't know that they are making this claim". I'd also argue that some people don't know that when they put a date next to their pen-and-ink signature, they're making the claim that that pen-and-ink signature was made on that date. But it's certainly what most of us mean by it. > I also doubt that OpenPGP signatures will be relevant in a proceeding > where relativity comes into play. At least in practice. If you say so; i'd like for the code i write to be able to work on spacecraft or satellites at some point, so it's worth keeping the idea in mind (again, i'm ignoring the "proceeding" remark because i'm talking about useful, specified code, not legal proceedings) > If you think about a timestamp is for, usually you're not actually > concerned with saying "I did X yesterday". You're usually concerned > with saying "I did X within 2 weeks of your notice", or "I did X > before you did Y". Other options include "I did X before the > cancellation deadline" and "I did X within 2 minutes, so I was acting > promptly and wasn't negligent". right, and this is what i suspect you'd need a global, published timestamping service for. Maybe your time would be better spent working out what such a service would look like. If you can define the service itself (centralized, distributed, or whatever), then you'll get a better sense of what semantics you need from OpenPGP. Maybe such a service already exists! I haven't looked for it; have you? 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 Thu Jun 16 21:08:47 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 21:08:47 +0200 Subject: what does a timestamp signature mean? [was: Re: Problem with faked-system-time option] In-Reply-To: <4DFA512E.1060807@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> <87sjrap7rw.fsf@vigenere.g10code.de> <7563828B-366B-4D7C-A390-2CCB3155CDB4@JABBERWOCKY.COM> <4DFA3F3E.5060707@fifthhorseman.net> <4DFA512E.1060807@fifthhorseman.net> Message-ID: >> this discussion is much more interesting. Let's keep the arguments >> about specification, usefulness, etc. out of this thread! > > Actually, i think usefulness and specification are quite important. > Without them, this discussion is just noise to me. If this is going to be a thread about specification, then as I said I am keeping out of it until I hear from Werner. I'll address the non-specification comments though: >> [dkg wrote]: >>> I don't think this is the general consensus. ?Timestamps *are* >>> meaningful -- they are an assertion by the person making the signature >>> of what time they made the signature. >> >> I would say that it's a matter of interpretation, > > I actually don't think what i said above is a matter of interpretation. ... and that is your interpretation. >> Again, wasn't the goal. As for usefulness of assertion-by-signer, see >> above for repudiating that you made/intended to make that assertion. > > ??? ?When i make a signature with a timestamp in it, i am very much > making (and intending to make) the assertion that the signature was made > at that time. ?I see no repudiation in your message, only that "some > people don't know that they are making this claim". ?I'd also argue that > some people don't know that when they put a date next to their > pen-and-ink signature, they're making the claim that that pen-and-ink > signature was made on that date. ?But it's certainly what most of us > mean by it. Most of "us"? You really need some context to have this discussion. I suggested the context of legal proceedings, you are free to suggest another real-world context. The assertion then depends on that context. I would have thought the requirement of context was a point that's come across by now. Technology is meaningless without context. >> If you think about a timestamp is for, usually you're not actually >> concerned with saying "I did X yesterday". You're usually concerned >> with saying "I did X within 2 weeks of your notice", or "I did X >> before you did Y". Other options include "I did X before the >> cancellation deadline" and "I did X within 2 minutes, so I was acting >> promptly and wasn't negligent". > > right, and this is what i suspect you'd need a global, published > timestamping service for. Do you realize that I listed several options and they don't all require the same kind of timestamping? > ?Maybe your time would be better spent working > out what such a service would look like. ?If you can define the service > itself (centralized, distributed, or whatever), then you'll get a better > sense of what semantics you need from OpenPGP. ?Maybe such a service > already exists! ?I haven't looked for it; have you? I want to create a basis for any kind of timestamping service. For instance, stamper. Or, just me making the assertion that I saw some data at some point. Those are both pretty well-specified. I already know what semantics I need from OpenPGP: Some key makes the assertion that some data was available to the owner of that key at-or-before a specific point in time. Oh, and yes, I have looked for timestamping services before engaging in a discussion about them. Maybe you should look at the existing options as well? -- 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 21:12:54 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 16 Jun 2011 21:12:54 +0200 Subject: what does a timestamp signature mean? [was: Re: 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> <87sjrap7rw.fsf@vigenere.g10code.de> <7563828B-366B-4D7C-A390-2CCB3155CDB4@JABBERWOCKY.COM> <4DFA3F3E.5060707@fifthhorseman.net> <4DFA512E.1060807@fifthhorseman.net> Message-ID: > If this is going to be a thread about specification, then as I said I > am keeping out of it until I hear from Werner. I'll address the > non-specification comments though: In fact, I think I'll keep out of the entire thread. I misunderstood your original email as implying you are open for a purely academic discussion of timestamp meaning. My bad. -- 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 lopaki at gmail.com Fri Jun 17 01:02:11 2011 From: lopaki at gmail.com (Scott Lambdin) Date: Thu, 16 Jun 2011 19:02:11 -0400 Subject: Understanding the "--refresh-keys" output In-Reply-To: <734A54CD-C8DE-4806-8866-3D6656801A87@jabberwocky.com> References: <20110616081857.2b83d7f2@scorpio> <067A0B63-AA35-4670-B7AA-AF9B83A17540@jabberwocky.com> <4DFA154E.3010608@fifthhorseman.net> <734A54CD-C8DE-4806-8866-3D6656801A87@jabberwocky.com> Message-ID: How can I get a report like this without refreshing the keys, please? gpg: depth: 0 valid: 17 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 17u On Thu, Jun 16, 2011 at 1:44 PM, David Shaw wrote: > On Jun 16, 2011, at 10:38 AM, Daniel Kahn Gillmor wrote: > > > On 06/16/2011 09:31 AM, David Shaw wrote: > >> Line 9 is just a key count. You have 17 valid keys. All of them ("u") > are ultimately trusted, which suggests that you have 17 keys that you have > generated as ultimate trust is generally used for people's own keys. (If > you can't trust yourself, who can you trust?) > > > > 17 keys is a lot of keys to have generated yourself (though there are > > some circumstances where i'm sure it makes some sort of sense). > > Just 17? My current GPG test VM used for development: > > gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model > gpg: depth: 0 valid: 154 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 154u > > ;) > > Seriously, though, Daniel is right. If those 17 keys aren't just endless > test keys like mine, you might be doing something you didn't intend to. > > David > > > _______________________________________________ > 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 dshaw at jabberwocky.com Fri Jun 17 01:58:49 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 16 Jun 2011 19:58:49 -0400 Subject: Understanding the "--refresh-keys" output In-Reply-To: References: <20110616081857.2b83d7f2@scorpio> <067A0B63-AA35-4670-B7AA-AF9B83A17540@jabberwocky.com> <4DFA154E.3010608@fifthhorseman.net> <734A54CD-C8DE-4806-8866-3D6656801A87@jabberwocky.com> Message-ID: <59381E76-1350-4919-8B37-16AE935B6A9C@jabberwocky.com> On Jun 16, 2011, at 7:02 PM, Scott Lambdin wrote: > How can I get a report like this without refreshing the keys, please? > > gpg: depth: 0 valid: 17 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 17u Run "gpg --check-trustdb". By default --refresh-keys calls --check-trustdb for you automatically, but you can call it yourself if you like. David From venture37 at gmail.com Fri Jun 17 17:12:43 2011 From: venture37 at gmail.com (Sevan / Venture37) Date: Fri, 17 Jun 2011 16: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: >> However, I have just managed to pick up a Gemalto pcmcia card reader >> (lenovo part # 41N3004) so I can give that a try instead, as soon as > > Please let me know - I have one here but never tested it. Hi Werner, I installed Debian i386 6.0.1 on my ThinkPad X61s, I can confirm I was able to generate 3072bit keys on my openpgp v2 card using the Gemalto PCMCIA card reader mentioned above. Now onto FreeBSD 7.4 & to see how far that goes. Sevan From venture37 at gmail.com Fri Jun 17 17:24:44 2011 From: venture37 at gmail.com (Sevan / Venture37) Date: Fri, 17 Jun 2011 16:24:44 +0100 Subject: Key generation on card fails with key sizes larger than 1024 bits In-Reply-To: References: <87zkmlqyz4.fsf@vigenere.g10code.de> <87fwob92y4.fsf@vigenere.g10code.de> <87y6236ryc.fsf@vigenere.g10code.de> Message-ID: On 17 June 2011 16:12, Sevan / Venture37 wrote: > On 19 May 2011 08:59, Werner Koch wrote: >>> However, I have just managed to pick up a Gemalto pcmcia card reader >>> (lenovo part # 41N3004) so I can give that a try instead, as soon as >> >> Please let me know - I have one here but never tested it. > > Hi Werner, > I installed Debian i386 6.0.1 on my ThinkPad X61s, I can confirm I was > able to generate 3072bit keys on my openpgp v2 card using the Gemalto > PCMCIA card reader mentioned above. > > Now onto FreeBSD 7.4 & to see how far that goes. > > Sevan > gpg 2.0.14 libgcrypt 1.4.5 Sevan From expires2011 at ymail.com Fri Jun 17 20:43:53 2011 From: expires2011 at ymail.com (MFPA) Date: Fri, 17 Jun 2011 19:43:53 +0100 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> <456716BE-FE41-4F8E-9194-D628D38EDD56@jabberwocky.com> <9D35C90E-D69A-4967-98FC-30F7EBA7B21A@jabberwocky.com> <5978304A-34EE-4AD4-BE0C-91D1311B0198@jabberwocky.com> Message-ID: <431328973.20110617194353@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 16 June 2011 at 6:32:34 AM, in , Jerome Baum wrote: > As for the error/resolution notation, someone else > (can't recall who and the gmail thread is unbearable) > mentioned that this would be relevant, and with the > same breath that you could state this in your signing > policy. My thought process is, what if I have two > machines, and one is NTP-synced (or even takes legal > time from the broadcast signal) while the other > regularly drifts up to 10 minutes, or runs timestamping > in batches, etc. > Of course, I could set up separate keys. Personally I'd > opt for the notation, as that's also computer-readable > (think "Good timestamp from Alice, between 10:00 and > 11:00 on 2011-06-16" Excuse the pedantry but how do we get "between 10:00 and 11:00" reliably from a clock that regularly drifts up to 10 minutes? - -- Best regards MFPA mailto:expires2011 at ymail.com Don't cry because it is over - smile because it happened -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN+6B7nhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pctgEALZA wadWGwVeFDGbjWgWIbmE4imLj2dSa/MhJMVVPf+towmalJWmxdIk3d+rkeP70mb7 lKelvAWCY7UUUayVbfgaOtsvFpKjhX+DqjJqtxaXaKcm+Iu6R2M8r2TzHlpwNqr7 WfFK7eLhKuvv8vrMujCerpVihG+efVHd0DpuSuto =qj3t -----END PGP SIGNATURE----- From expires2011 at ymail.com Fri Jun 17 22:33:28 2011 From: expires2011 at ymail.com (MFPA) Date: Fri, 17 Jun 2011 21:33:28 +0100 Subject: what does a timestamp signature mean? [was: Re: Problem with faked-system-time option] In-Reply-To: <4DFA3F3E.5060707@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> <87sjrap7rw.fsf@vigenere.g10code.de> <7563828B-366B-4D7C-A390-2CCB3155CDB4@JABBERWOCKY.COM> <4DFA3F3E.5060707@fifthhorseman.net> Message-ID: <369639556.20110617213328@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 16 June 2011 at 6:37:02 PM, in , Daniel Kahn Gillmor wrote: > Timestamps *are* meaningful -- they are an assertion by > the person making the signature of what time they made > the signature. In some cases the person making the signature simply wishes to provide assurance the message really came from them and it has not been altered in transit. In such a case, the timestamp is very much an irrelevance. There was a desire expressed by the starter of this thread (in Message-id <20110608153652.4F1508C074 at nym.dizum.nl> and expanded upon in Message-id <20110616002944.974948C0D8 at nym.dizum.nl>) for an ability to create signatures without revealing information about the signer's time management. - -- Best regards MFPA mailto:expires2011 at ymail.com Greater than being great is being grateful. -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN+7oknhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pyM0D/jrf IRfv1SWpt0xcI9BbwO6FLIBwA0GPI8tcl3NsXmKpRusaVjWVIAIzDYdHVjCcZzQ7 fKVitYF94OPNvhtXqdm7aPUHVxi0HZwTuGd1ILtYSEy+c8P5jxxb2EX1nVKjMHe5 DPf5qRkIkgE/Lu5+PgzNW3nDi/KgbGbpqOd6U1Dr =mhyy -----END PGP SIGNATURE----- From expires2011 at ymail.com Fri Jun 17 22:44:35 2011 From: expires2011 at ymail.com (MFPA) Date: Fri, 17 Jun 2011 21:44:35 +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> <7eea2c792297b31b4e6448b8b88a9eb3@localhost> <4DF81871.7050605@sixdemonbag.org> <20110616002944.974948C0D8@nym.dizum.nl> Message-ID: <1981748960.20110617214435@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 16 June 2011 at 2:08:52 AM, in , Jerome Baum wrote: >> if you cheat your employer out of their money, The scenario stated that a fluctuating work volume resulted in periods when there was no work to do. Using that time for your own purposes does not look to me like cheating your employer. - -- Best regards MFPA mailto:expires2011 at ymail.com Greater than being great is being grateful. -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN+7y5nhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pW1QD/iee Pv1x1cqwqsirN9OYjmD+P/1PZ4vmKXI+0j2NfCcchRBIPYvtJibjdJkEob+v4Scf MlOp2BB5U89XP8tz3ZcfEkwzo3ZvBtd3MzpHfYOq76YKQKww4cQ0T2Xjdb9pqwM3 Td4yu6WqG8n4lCwOx751C467pYRmx9Tvjalj6Jdy =jhFe -----END PGP SIGNATURE----- From expires2011 at ymail.com Fri Jun 17 23:08:58 2011 From: expires2011 at ymail.com (MFPA) Date: Fri, 17 Jun 2011 22:08:58 +0100 Subject: what does a timestamp signature mean? [was: Re: Problem with faked-system-time option] In-Reply-To: <4DFA512E.1060807@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> <87sjrap7rw.fsf@vigenere.g10code.de> <7563828B-366B-4D7C-A390-2CCB3155CDB4@JABBERWOCKY.COM> <4DFA3F3E.5060707@fifthhorseman.net> <4DFA512E.1060807@fifthhorseman.net> Message-ID: <1903172910.20110617220858@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 16 June 2011 at 7:53:34 PM, in , Daniel Kahn Gillmor wrote: > ??? When i make a signature with a timestamp in it, i > am very much making (and intending to make) the > assertion that the signature was made at that time. I > see no repudiation in your message, only that "some > people don't know that they are making this claim". How would somebody make a signature without a timestamp in it? > I'd also argue that > some people don't know that when they put a date next to their > pen-and-ink signature, they're making the claim that that pen-and-ink > signature was made on that date. But it's certainly what most of us > mean by it. Perhaps. But in the pen-and-ink case they consciously added the date. In the OpenPGP case, the timestamp automatically tags along as part of the signature. - -- Best regards MFPA mailto:expires2011 at ymail.com Ballerinas are always on their toes. We need taller ballerinas! -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN+8JvnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pDgoD/iU8 J/7EZ2ozVn1rGUzrjQ5B5gicZPAZTegzFckC49/bJiNfywA+jIP+7KZuV2t0cToz FyYPyf7ibDs3HQuRPvOHB6/xnmg0G/VuFssVjW8bOTRn6N+QDjDMf6u1TSEfHoh/ YTPgbPj1StfSJ12FonkgwUgxDDk5jNwlg4jY8Ict =X798 -----END PGP SIGNATURE----- From expires2011 at ymail.com Fri Jun 17 23:23:34 2011 From: expires2011 at ymail.com (MFPA) Date: Fri, 17 Jun 2011 22:23:34 +0100 Subject: timestamp notation @gnupg.org In-Reply-To: <201106161627.13391.mailinglisten@hauke-laging.de> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161321.14462.mailinglisten@hauke-laging.de> <87fwnaory7.fsf@vigenere.g10code.de> <201106161627.13391.mailinglisten@hauke-laging.de> Message-ID: <1302649023.20110617222334@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 16 June 2011 at 3:27:12 PM, in , Hauke Laging wrote: > If anyone is not happy with the OpenPGP timestamp > format (which I haven't noticed yet) Then I refer you to two postings from Amano Corunga Message-id <20110608153652.4F1508C074 at nym.dizum.nl> and Message-id <20110616002944.974948C0D8 at nym.dizum.nl> which refer to a requirement to be able to create signatures without revealing (possibly sensitive) information about the signer's time management. - -- Best regards MFPA mailto:expires2011 at ymail.com Consistency is the last refuge of the unimaginative -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN+8XgnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pgJ0D+wUD Vn+ZB+btGFtkwnvdtDYjinZTRtHeq5Lsz9tW1DbT20VpJTZxQuj0+Jo6KY8hOP8X e4YHs/Z+ZAZHhBvbe1LMRnlp+izFrIBYfyEYH+chZj0QWGfX+Bt0uQlBrH9OZZEN WKs+o7qmHpnFu9Vw3Uz7z4fpogvFPtpBaWyupXf1 =hYzo -----END PGP SIGNATURE----- From mailinglisten at hauke-laging.de Sat Jun 18 00:21:12 2011 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 18 Jun 2011 00:21:12 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: <1302649023.20110617222334@my_localhost> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> Message-ID: <201106180021.17972.mailinglisten@hauke-laging.de> Am Freitag, 17. Juni 2011, 23:23:34 schrieb MFPA: > Hi > > > On Thursday 16 June 2011 at 3:27:12 PM, in > , Hauke Laging > > wrote: > > If anyone is not happy with the OpenPGP timestamp > > format (which I haven't noticed yet) > > Then I refer you to two postings from Amano Corunga > Message-id <20110608153652.4F1508C074 at nym.dizum.nl> and > Message-id <20110616002944.974948C0D8 at nym.dizum.nl> > which refer to a requirement to be able to create signatures without > revealing (possibly sensitive) information about the signer's time > management. To me that is quite clear not a problem of the FORMAT of the 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 expires2011 at ymail.com Sat Jun 18 01:40:32 2011 From: expires2011 at ymail.com (MFPA) Date: Sat, 18 Jun 2011 00:40:32 +0100 Subject: timestamp notation @gnupg.org In-Reply-To: <201106180021.17972.mailinglisten@hauke-laging.de> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> <201106180021.17972.mailinglisten@hauke-laging.de> Message-ID: <895023152.20110618004032@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 17 June 2011 at 11:21:12 PM, in , Hauke Laging wrote: > To me that is quite clear not a problem of the FORMAT > of the timestamp. Consider these two formats:- (A) Signature made 06/17/11 23:21:17 (B) Signature made 06/17/11 A signature that contained only the information for (B) would reveal less about the signer's behaviour than a signature containing the information for (A). Whether that's possible as an option is another question, if the date is stored in the signature packet as seconds since epoch. - -- Best regards MFPA mailto:expires2011 at ymail.com Put knot yore trust inn spel chequers -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN++X7nhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pFM0EAJFd 9GXFy/MtnXG+VBS3vTxhwD9Zkz3LFKK9gZ9ShYYNGRyl1eJYX51/vLgyc5T2XvcU Qk6Vq2pW6Btx2MjF0Bnal04k8KCzIQQs7G2adwwBp1Xfx6jw5edueVDWb/wZUZ7R 4GdKZ5Pmi3UobShn4xVzW8tr0OOdq2CnHaNWlnxO =C3q5 -----END PGP SIGNATURE----- From jerome at jeromebaum.com Sat Jun 18 02:48:43 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 18 Jun 2011 02:48:43 +0200 Subject: Problem with faked-system-time option In-Reply-To: <431328973.20110617194353@my_localhost> 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> <9D35C90E-D69A-4967-98FC-30F7EBA7B21A@jabberwocky.com> <5978304A-34EE-4AD4-BE0C-91D1311B0198@jabberwocky.com> <431328973.20110617194353@my_localhost> Message-ID: >> ..., or runs timestamping >> in batches, etc. (snip) > Excuse the pedantry but how do we get "between 10:00 and 11:00" > reliably from a clock that regularly drifts up to 10 minutes? -- 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 Sat Jun 18 02:52:14 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 18 Jun 2011 02:52:14 +0200 Subject: Problem with faked-system-time option In-Reply-To: <1981748960.20110617214435@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> <4DF81871.7050605@sixdemonbag.org> <20110616002944.974948C0D8@nym.dizum.nl> <1981748960.20110617214435@my_localhost> Message-ID: >>> if you cheat your employer out of their money, > > > The scenario stated that a fluctuating work volume resulted in periods > when there was no work to do. Using that time for your own purposes > does not look to me like cheating your employer. In that case you have nothing to fear from your timestamp. I personally hold the opinion that you should have a good work relationship with your employer (including your manager), and therefore when there is really no work to do, using it for learning new stuff, or yes even for reading /. or TDWTF, shouldn't lead to a court case. But, of course, you should discuss with your manager when there is no work to do, and get their permission first. If you go ahead and make this decision on your own, then yes you are cheating your employer -- he might have had work for you to do if only you had told him there's nothing left. -- 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 Sat Jun 18 03:00:25 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 18 Jun 2011 03:00:25 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: <895023152.20110618004032@my_localhost> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> <201106180021.17972.mailinglisten@hauke-laging.de> <895023152.20110618004032@my_localhost> Message-ID: > Consider these two formats:- > > (A) ? ? ?Signature made 06/17/11 23:21:17 > > (B) ? ? ?Signature made 06/17/11 > > A signature that contained only the information for (B) would reveal > less about the signer's behaviour than a signature containing the > information for (A). > > Whether that's possible as an option is another question, if the date > is stored in the signature packet as seconds since epoch. Which was my point about adding a resolution/interval. There's a difference between "2011-06-17 00:00:00" and "2011-06-17/P1D" (both technically, and in court). Leaving my hands off the "timestamp-only" part of the thread, does anyone have objections to "timestamp-interval" in the ISO 8601 interval format? In my head, it would be a non-critical field (as it doesn't change the meaning of the signature, only the accuracy of the timestamp field). Thoughts? -- 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 borisbiljeskovic at rambler.ru Fri Jun 17 15:15:47 2011 From: borisbiljeskovic at rambler.ru (Boris =?utf-8?B?QmlsamXFoWtvdmnEhw==?=) Date: Fri, 17 Jun 2011 15:15:47 +0200 Subject: Distributed symmetric key management Message-ID: <20110617131543.B408E84460@maild.rambler.ru> I have various directories that I need to keep in sync on various machines. To do so, I would like to, say, once a week, tar the directories, encrypt them and push them on the internet. On other machines I'd pull accordingly. This process itself is quite simple. I can come up with some bash magic for that. Here's the tricky part: Each directory has a key attached to it. My main machine, which pushes all changes, has 'access' to all keys. My other machines just 'have' a subset of all keys. I do not think asymmetric encryption makes much sense here. Rather than that, I'd use symmetric encryption using keys generated with 'gpg2 --gen-random 2'. When I am setting up a new machine, I can distribute the keys that I need on that machine using a safe exchange medium. Here's basically what I have: Machine A (main machine): keys: project-a key, project-b key, private-stuff key directory project-a directory project-b directory private-stuff Machine B: keys: project-a key, project-b key directory project-a directory project-b Machine C: keys: private-stuff key directory private-stuff Machine A pushes project-a, project-b and private-stuff, encrypting with the according keys. Machine B pulls project-a and project-b, decrypting with the keys it 'has', Machine C pulls private-stuff. So, here is the problem. How can I keep track of the keys? I do not like having them as plain text files laying in some directory. Does gpg-agent have some way of keeping them in a keyring? If not, I am also using gnome-keyring which can store passwords. Is there any method to forward keys from gnome-keyring to gpg2? From jerome at jeromebaum.com Sat Jun 18 10:48:32 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 18 Jun 2011 10:48:32 +0200 Subject: Distributed symmetric key management In-Reply-To: <20110617131543.B408E84460@maild.rambler.ru> References: <20110617131543.B408E84460@maild.rambler.ru> Message-ID: > Each directory has a key attached to it. ?My main machine, which pushes > all changes, has 'access' to all keys. ?My other machines just 'have' a > subset of all keys. ?I do not think asymmetric encryption makes much > sense here. ?Rather than that, I'd use symmetric encryption using keys > generated with 'gpg2 --gen-random 2'. Why does asymmetric encryption not make sense? You could picture an asymmetric key-pair as a single symmetric key. In fact, for all practical purposes, if you never separate the private and public components, an asymmetric key-pair *is* a symmetric key. The only difference is: gpg has built-in functionality to handle asymmetric key-pairs. -- 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 Sat Jun 18 14:22:48 2011 From: expires2011 at ymail.com (MFPA) Date: Sat, 18 Jun 2011 13:22:48 +0100 Subject: timestamp notation @gnupg.org In-Reply-To: References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> <201106180021.17972.mailinglisten@hauke-laging.de> <895023152.20110618004032@my_localhost> Message-ID: <73411352.20110618132248@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 18 June 2011 at 2:00:25 AM, in , Jerome Baum wrote: > Which was my point about adding a resolution/interval. > There's a difference between "2011-06-17 00:00:00" and > "2011-06-17/P1D" (both technically, and in court). Obviously, one refers to a one-second period of time and the other refers to a whole day. It would refer to a whole day even without the "/P1D" but that doesn't affect the point. In the examples "2011-06-16/P2D" or "2011-06-13/P1W" the time period makes a difference. > Leaving my hands off the "timestamp-only" part of the > thread, does anyone have objections to > "timestamp-interval" in the ISO 8601 interval format? > In my head, it would be a non-critical field (as it > doesn't change the meaning of the signature, only the > accuracy of the timestamp field). > Thoughts? If the time period were to be included as an additional field without altering the contents of the timestamp field, the latter would still reveal exactly the information it reveals now about the signer's time management behaviour. The value stored in the timestamp field would need to be altered, so that the exact time of signing was not stored but also so that existing apps didn't choke on it. - -- Best regards MFPA mailto:expires2011 at ymail.com Dogs look up to us. Cats look down on us. Pigs treat us as equals. -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN/JienhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5p8RMD/jIq XFwIsTZePRcLgM37watk305GVcb+xi0U/E7hGtO/+fCo3m4NmTLL+EMRe59ZoFJN t2hYHBY3Y2r323eKwG6Y5r2sRbGAwXqXMgwb7QTJ/n0yd7NVwUrvUhki6RGuPwTj 6XDthrnVUj7e46AvYB51fdAj0KcEtzmpVePJFW8Z =DbC6 -----END PGP SIGNATURE----- From jerome at jeromebaum.com Sat Jun 18 14:29:29 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 18 Jun 2011 14:29:29 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: <73411352.20110618132248@my_localhost> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> <201106180021.17972.mailinglisten@hauke-laging.de> <895023152.20110618004032@my_localhost> <73411352.20110618132248@my_localhost> Message-ID: >> Which was my point about adding a resolution/interval. >> There's a difference between "2011-06-17 00:00:00" and >> "2011-06-17/P1D" (both technically, and in court). > > Obviously, one refers to a one-second period of time and the other > refers to a whole day. It would refer to a whole day even without the > "/P1D" but that doesn't affect the point. In the examples "2011-06-16/P2D" or > "2011-06-13/P1W" the time period makes a difference. Right. Which is why I wrote "2011-06-17 00:00:00" -- there are multiple interpretations of "2011-06-17", and e.g. ISO 8601 takes it to be the instant at the start of the day. "2011-06-17/P1D" is unambiguous (especially if we specify "the value is an ISO 8601 interval"). > If the time period were to be included as an additional field without > altering the contents of the timestamp field, the latter would still > reveal exactly the information it reveals now about the signer's time > management behaviour. The value stored in the timestamp field would > need to be altered, so that the exact time of signing was not stored > but also so that existing apps didn't choke on it. Exactly. I see it as two parts: 1. Add a notation for timestamp-interval. This makes the protocol more flexible. 2. Using # 1, we can then change application code to make the implementation more flexible. e.g.: Add an option to round down to the start of the day and set timestamp-interval to "/P1D". -- 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 Sat Jun 18 18:02:00 2011 From: expires2011 at ymail.com (MFPA) Date: Sat, 18 Jun 2011 17:02:00 +0100 Subject: timestamp notation @gnupg.org In-Reply-To: References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> <201106180021.17972.mailinglisten@hauke-laging.de> <895023152.20110618004032@my_localhost> <73411352.20110618132248@my_localhost> Message-ID: <1708159137.20110618170200@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 18 June 2011 at 1:29:29 PM, in , Jerome Baum wrote: > Right. Which is why I wrote "2011-06-17 00:00:00" -- > there are multiple interpretations of "2011-06-17", and > e.g. ISO 8601 takes it to be the instant at the start > of the day. Really? The references I have read suggest to me that ISO 8601 takes YYYY-MM-DD to be a 24-hour period, and YYYY-MM-DDT00:00:00 to be the second at the start of the day. > Exactly. I see it as two parts: > 1. Add a notation for timestamp-interval. This makes > the protocol more flexible. And this was the field you said should be non-critical, right? > 2. Using # 1, we can then change application code to > make the implementation more flexible. e.g.: Add an > option to round down to the start of the day and set > timestamp-interval to "/P1D". Or to the start of the week(or month or year, etc.) and use /P1W (or P1M or P1Y, etc.). What about a user who desired no datestamp at all? Would they just use something like 1970-01-01T00:00:00/P68Y? What about time zones? Lets say person A, signing the document, has a local time offset of GMT+2 and person B, receiving the document, has a local time offset of GMT+1. Person A has their app set to round down to the beginning of the day, which in person B's local time is 23:00:00 on the previous day. I guess person A seeing 20110618T000000/P1D and person B seeing 20110617T230000/P1D is a non-issue, since the two refer to the same time interval in UTC. - -- Best regards MFPA mailto:expires2011 at ymail.com Pain is inevitable, but misery is optional. -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN/MwAnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5poxcD/A3h hbgAqMlilzqIbTPoBLUIkdhG09tAcixQfgJTIvSIue/WY0VoZ3Z5KoDZ4znIYkK5 5gbhFN0/F753LJ+TAec+8+BjD3z0r4htqvblQPyh/8KbTZ3Mrv6kM/xnN07f/seT EFtbiNStHPPWPE8mcMUqFDLoLQbBmVA4GFc2959B =tn5l -----END PGP SIGNATURE----- From jerome at jeromebaum.com Sat Jun 18 18:24:45 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 18 Jun 2011 18:24:45 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: <1708159137.20110618170200@my_localhost> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> <201106180021.17972.mailinglisten@hauke-laging.de> <895023152.20110618004032@my_localhost> <73411352.20110618132248@my_localhost> <1708159137.20110618170200@my_localhost> Message-ID: >> Right. Which is why I wrote "2011-06-17 00:00:00" -- >> there are multiple interpretations of "2011-06-17", and >> e.g. ISO 8601 takes it to be the instant at the start >> of the day. > > Really? The references I have read suggest to me that ISO 8601 takes > YYYY-MM-DD to be a 24-hour period, and YYYY-MM-DDT00:00:00 to be the > second at the start of the day. See http://tech.groups.yahoo.com/group/ISO8601/message/226 for details (be sure to look at the other replies as well). I don't have ISO 8601 handy, so I can't speak first hand. However, this example seems very rational: "The 20th Century 1901-01-01 / P100Y 1901-01-01 T 00:00:00 / 2001-01-01 T 00:00:00" >> Exactly. I see it as two parts: > >> 1. Add a notation for timestamp-interval. This makes >> the protocol more flexible. > > And this was the field you said should be non-critical, right? Yes. I'm purposely leaving out the whole timestamp-only discussion. >> 2. Using # 1, we can then change application code to >> make the implementation more flexible. e.g.: Add an >> option to round down to the start of the day and set >> timestamp-interval to "/P1D". > > Or to the start of the week(or month or year, etc.) > and use /P1W (or P1M or P1Y, etc.). Exactly. This would be an implementation choice. I think a good first start for gnupg would be a parameter to specify a fake timestamp. The notation is already possible. Then it's easy to write a command-line wrapper for custom stuff, or even just specify a fixed notation and fixed fake timestamp ("1970/P68Y" with timestamp 0). > What about a user who desired no datestamp at all? Would they just use > something like 1970-01-01T00:00:00/P68Y? Not sure. Personally I'd use P200Y. Nice "pun" there, btw. :) > What about time zones? Lets say person A, signing the document, has a > local time offset of GMT+2 and person B, receiving the document, has a > local time offset of GMT+1. Person A has their app set to round down > to the beginning of the day, which in person B's local time is > 23:00:00 on the previous day. I guess person A seeing > 20110618T000000/P1D and person B seeing 20110617T230000/P1D is a > non-issue, since the two refer to the same time interval in UTC. Ah, we've been careless. Append a "Z" to your dates and they are UTC (or append a timezone, if you want that). Those two intervals are actually ambiguous AFAIK. We could specify either: 1. All times must be UTC ("Z") or have a timezone; or 2. Ambiguous times are interpreted as UTC. -- 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 Sat Jun 18 23:44:01 2011 From: expires2011 at ymail.com (MFPA) Date: Sat, 18 Jun 2011 22:44:01 +0100 Subject: timestamp notation @gnupg.org In-Reply-To: References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> <201106180021.17972.mailinglisten@hauke-laging.de> <895023152.20110618004032@my_localhost> <73411352.20110618132248@my_localhost> <1708159137.20110618170200@my_localhost> Message-ID: <879087301.20110618224401@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 18 June 2011 at 5:24:45 PM, in , Jerome Baum wrote: > See > http://tech.groups.yahoo.com/group/ISO8601/message/226 > for details (be sure to look at the other replies as > well). Like most discussion threads, I see opposing views represented there. > I don't have ISO 8601 handy, so I can't speak > first hand. However, this example seems very rational: > "The 20th Century 1901-01-01 / P100Y > 1901-01-01 T 00:00:00 / 2001-01-01 T 00:00:00" I would prefer to say the century finished at 2000-12-31T24:00:00. (-; Also, I think 1901-01-01T00:00:00/2001-01-01T00:00:00 would be equivalent to 1901-01-01T00:00:00/P100Y, and 1901-01-01/2001-01-01 would be equivalent to 1901-01-01/P100Y. They are different in the same way as 5 Euros is different to 5.00 Euros. >> What about time zones? Lets say person A, signing the >> document, has a local time offset of GMT+2 and person >> B, receiving the document, has a local time offset of >> GMT+1. Person A has their app set to round down to the >> beginning of the day, which in person B's local time >> is 23:00:00 on the previous day. I guess person A >> seeing 20110618T000000/P1D and person B seeing >> 20110617T230000/P1D is a non-issue, since the two >> refer to the same time interval in UTC. > Ah, we've been careless. Append a "Z" to your dates and > they are UTC (or append a timezone, if you want that). > Those two intervals are actually ambiguous AFAIK. We > could specify either: > 1. All times must be UTC ("Z") or have a timezone; or Aren't the timestamps recorded in the signature packets as unix time [1], and displayed in the local time detected from the user's system? > 2. Ambiguous times are interpreted as UTC. I think the ISO 8601 standard assumes local time unless otherwise specified. So it makes sense for each person viewing the signature to see the timestamp in their own local time if no time zone information is included. 20110618T000000+0200/P1D and 20110617T230000+0100/P1D both refer to the same time period without ambiguity. If people feel there is ambiguity here, maybe this is best dealt with by adding some simple text to the GnuPG output to indicate that times are shown in local time, as per the user's system. [1] http://tools.ietf.org/html/rfc4880#section-3.5 - -- Best regards MFPA mailto:expires2011 at ymail.com What's another word for synonym? -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN/RwqnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pNhYD/jb0 cdtifNupzq+UNH5usQr8smod+FwL2IIPAh1Cd2jphwH9bZoOsRGwmbWmDBkJu3ui b5mZHLSEQFgqtwfy5dKf4Uadt3rSrq4AMUTPL4MX3Pj3c0CYSeqoeLhcGDGqCL6+ SJV6N0wRo9T9redqgOMWGSH429TvG1M6LoUffVDB =DJMF -----END PGP SIGNATURE----- From jerome at jeromebaum.com Sat Jun 18 23:50:08 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 18 Jun 2011 23:50:08 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: <879087301.20110618224401@my_localhost> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> <201106180021.17972.mailinglisten@hauke-laging.de> <895023152.20110618004032@my_localhost> <73411352.20110618132248@my_localhost> <1708159137.20110618170200@my_localhost> <879087301.20110618224401@my_localhost> Message-ID: >> I don't have ISO 8601 handy, so I can't speak >> first hand. However, this example seems very rational: > >> "The 20th Century 1901-01-01 / P100Y >> 1901-01-01 T 00:00:00 / 2001-01-01 T 00:00:00" > > I would prefer to say the century finished at 2000-12-31T24:00:00. (-; > > Also, I think 1901-01-01T00:00:00/2001-01-01T00:00:00 > would be equivalent to 1901-01-01T00:00:00/P100Y, > and 1901-01-01/2001-01-01 would be equivalent to 1901-01-01/P100Y. > > They are different in the same way as 5 Euros is different to > 5.00 Euros. Exactly. 5 Euros is still 5 Euros, whether you say "5,00 Euros", "5,-- Euros", "5 Euros, but no cents", "5 Euros exactly", "5 Euros sharp", or just "5 Euros". Still the same thing. >> Ah, we've been careless. Append a "Z" to your dates and >> they are UTC (or append a timezone, if you want that). >> Those two intervals are actually ambiguous AFAIK. We >> could specify either: > >> 1. All times must be UTC ("Z") or have a timezone; or > > Aren't the timestamps recorded in the signature packets as unix time > [1], and displayed in the local time detected from the user's system? I was referring to the interval notation. >> 2. Ambiguous times are interpreted as UTC. > > I think the ISO 8601 standard assumes local time unless otherwise > specified. So it makes sense for each person viewing the signature to > see the timestamp in their own local time if no time zone information > is included. Except, what is "local time" if you have two people in different timezones? That's why we'd need either the "all times UTC" rule, or a forced timezone in the field. > 20110618T000000+0200/P1D and 20110617T230000+0100/P1D both refer to > the same time period without ambiguity. Those have timezones. Your (and my) previous examples didn't. > If people feel there is ambiguity here, maybe this is best dealt with > by adding some simple text to the GnuPG output to indicate that times > are shown in local time, as per the user's system. That isn't what I was referring to. 20110618T000000/P1D is ambiguous: Is it 20110618T000000+0200/P1D or 20110618T000000+0100/P1D ? -- 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 ypLxswPm8C24VUMt at lavabit.com Sun Jun 19 00:04:34 2011 From: ypLxswPm8C24VUMt at lavabit.com (0) Date: Sat, 18 Jun 2011 18:04:34 -0400 Subject: formatting of gpg blocks In-Reply-To: References: Message-ID: <1308434675.9191.12.camel@n-pc> When including one gpg block inside another, as in public key inside a signed message, there is a space created after the first dash. Like here: - -----BEGIN PGP PUBLIC KEY BLOCK----- Why is this needed? This complicates working with the message (I have to manually remove the space if I want to import the public key) and I haven't found any info about it. Another question is, when I'm sending a message with my public key, if I'm going to sign the message, should I also sign the public key? That amounts to two signatures. From jerome at jeromebaum.com Sun Jun 19 01:34:09 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sun, 19 Jun 2011 01:34:09 +0200 Subject: formatting of gpg blocks In-Reply-To: <1308434675.9191.12.camel@n-pc> References: <1308434675.9191.12.camel@n-pc> Message-ID: > When including one gpg block inside another, as in public key inside a > signed message, there is a space created after the first dash. > Like here: > - -----BEGIN PGP PUBLIC KEY BLOCK----- > Why is this needed? This complicates working with the message (I have to > manually remove the space if I want to import the public key) and I > haven't found any info about it. This is needed to make sure OpenPGP (i.e. gnupg) doesn't misinterpret stuff inside the block. Imagine enclosing some signed data inside a signed block. How does gnupg tell apart the "END" lines from the inner/outer blocks? Shouldn't be a big problem to work with though: Just run the message through gnupg and it'll remove the extra dashes. > Another question is, when I'm sending a message with my public key, if > I'm going to sign the message, should I also sign the public key? That > amounts to two signatures. Be careful to distinguish between data signatures (signing a message) and certifications (signing a key). Are you trying to wrap a data signature around the key? Unless you have a special use-case, that probably doesn't make sense. Instead try to use a certification. -- 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 jziff at sindegra.com Sun Jun 19 06:55:56 2011 From: jziff at sindegra.com (Joseph Ziff) Date: Sun, 19 Jun 2011 00:55:56 -0400 Subject: gpg fails to decrypt files encrypted to the same name as the original input Message-ID: <4DFD815C.1020502@sindegra.com> Hey hackers, I noticed this very interesting behavior in my version of gpg (2.0.17): 1. take a simple text file and call it say test.txt, encrypt it to a file named test.txt in the same directory so that it overwrites it. (gpg -o test.txt -e test.txt) 2. decrypt file test.txt with gpg (gpg -d test.txt) and get gibberish. It does not seem to happen when I have the output renamed to something else. I know this is a highly unusual (and probably ineffective way) of using gpg but I still thought it was interesting that it would fail. Any thoughts on this (potential) bug? Can anyone else recreate it, or is it actually a feature/unavoidable side-effect? Regards, -- Joseph Ziff , . Signed with gnupg 2.0.17 for your convenience. Go to http://www.sindegra.com/jziff.txt to retrieve the public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From ypLxswPm8C24VUMt at lavabit.com Sun Jun 19 10:20:10 2011 From: ypLxswPm8C24VUMt at lavabit.com (0) Date: Sun, 19 Jun 2011 04:20:10 -0400 Subject: formatting of gpg blocks In-Reply-To: References: <1308434675.9191.12.camel@n-pc> Message-ID: <1308471611.9191.327.camel@n-pc> > This is needed to make sure OpenPGP (i.e. gnupg) doesn't misinterpret stuff inside the block. Imagine enclosing some signed data inside a > signed block. How does gnupg tell apart the "END" lines from the > inner/outer blocks? Is this design better than one allowing the last END line to be the closing one? I see that nested blocks are possible, but is this format documented somewhere? I suppose I keep wondering where the format is described because when I first came across this, I spent a lot of time trying to import the public key embedded in a clear-signed message. I didn't realize that I needed to decrypt it until you mentioned it. And now I'm trying to learn how not to make that mistake again in general. > Be careful to distinguish between data signatures (signing a message) > and certifications (signing a key). Are you trying to wrap a data > signature around the key? Unless you have a special use-case, that > probably doesn't make sense. Instead try to use a certification. I see. I read that it is a good practice to sign one's public key before giving it to other people. I thought they meant signing the key as a message. Now that you clarified this, I went to seahorse, Names and Signatures, sign key. It gives me a choice to let others see this signature. Should I allow that? I would also appreciate it, if you could explain how key certification is useful. From faramir.cl at gmail.com Sun Jun 19 10:28:52 2011 From: faramir.cl at gmail.com (Faramir) Date: Sun, 19 Jun 2011 04:28:52 -0400 Subject: formatting of gpg blocks In-Reply-To: <1308471611.9191.327.camel@n-pc> References: <1308434675.9191.12.camel@n-pc> <1308471611.9191.327.camel@n-pc> Message-ID: <4DFDB344.8090804@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 19-06-2011 4:20, 0 escribi?: > .... > I see. I read that it is a good practice to sign one's public key before > giving it to other people. I thought they meant signing the key as a > message. Now that you clarified this, I went to seahorse, Names and > Signatures, sign key. It gives me a choice to let others see this > signature. Should I allow that? I would also appreciate it, if you could > explain how key certification is useful. AFAIK, but I might be wrong, public keys are self-signed by default. Maybe there was a time when that was not the rule, but now it is. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJN/bNEAAoJEMV4f6PvczxAz7wH/Rb/xTS8K3EYtCTWuatMyG++ CeBEKtdZmj3AcvvVk42n5pbEquRG4N4wSfQ+0B5k1wa/vFvRDuC5fFRBiG49ncLw JLXhd+Oy9AAjgK8XkO7Edw2M9uzFXS7PD8z3xGneU+s82dNB7ji+mv6BbhYl7YYr UJI0E2yqY8XBByCDTmjZ3e2WgJKlCGs9U5fCLDnBSTGaYt8C94zSjKfgElMoEHh4 eERqiHBw5vpsJyx4QulYznfrR2wpH1doYo8FX5WPQEJ7UkcZKZALoQ8WWItKUFuo dTK24BOod8XENiQC1VW87p61fLg5wbwBjTxGmeZaYLmOKpOs0qFvZApBRXi7cUU= =Jmoe -----END PGP SIGNATURE----- From expires2011 at ymail.com Sun Jun 19 14:03:25 2011 From: expires2011 at ymail.com (MFPA) Date: Sun, 19 Jun 2011 13:03:25 +0100 Subject: timestamp notation @gnupg.org In-Reply-To: References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> <201106180021.17972.mailinglisten@hauke-laging.de> <895023152.20110618004032@my_localhost> <73411352.20110618132248@my_localhost> <1708159137.20110618170200@my_localhost> <879087301.20110618224401@my_localhost> Message-ID: <1534549809.20110619130325@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 18 June 2011 at 10:50:08 PM, in , Jerome Baum wrote: > Exactly. 5 Euros is still 5 Euros, whether you say > "5,00 Euros", "5,-- Euros", "5 Euros, but no cents", "5 > Euros exactly", "5 Euros sharp", or just "5 Euros". > Still the same thing. The point I was making was stating a value accurate to a different number of significant figures subtly alters the meaning. "5 Euros" was evidently a poor example but it does illustrate there can be a difference. A retailer stating the price of something in any of the styles you mention above would mean exactly the same thing. A friend or colleague discussing the price or value of something who stated "5 Euros" rather than any of the more exact forms, quite possibly does not mean "5 Euros exactly." Your example time period of "the 20th century" clearly starts and ends at midnight, so nothing is effectively changed by your switch from omitting the time in "1901-01-01 / P100Y" to including it in "1901-01-01 T 00:00:00 / 2001-01-01 T 00:00:00," even though the second form is stated to a greater level of accuracy. More generally, a time period of YYYY-MM-DD/PnD does not necessarily run from midnight at the beginning of the first day to midnight at the end of the last day; in the absence of any further information this cannot be known, and is not a safe assumption. Context may show something different, such as business hours only. But I digress. - -- Best regards MFPA mailto:expires2011 at ymail.com Those who do not read are no better off than those who cannot. -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN/eWbnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5prEkD/2kT nA5pLsmUyV5mtafMgfahOHB5un/Iy8zblzeksh2nvThKdFXYjLceUWxx+dcRG9pq aCUryrFDMM7XPN02esqgwi5XR7Uq6I0umm4XkiEV7W8unRAncAEhy+4a+kTuJkgQ 7CAj+sQam0Eo3yBXW8foLM9/GGi4SZESg7L/dZe2 =QqAw -----END PGP SIGNATURE----- From expires2011 at ymail.com Sun Jun 19 14:17:46 2011 From: expires2011 at ymail.com (MFPA) Date: Sun, 19 Jun 2011 13:17:46 +0100 Subject: formatting of gpg blocks In-Reply-To: <1308434675.9191.12.camel@n-pc> References: <1308434675.9191.12.camel@n-pc> Message-ID: <656421949.20110619131746@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 18 June 2011 at 11:04:34 PM, in , 0 wrote: > When including one gpg block inside another, as in > public key inside a signed message, there is a space > created after the first dash. Like here: - -----BEGIN > PGP PUBLIC KEY BLOCK----- It's not a created after the first , it's an additional placed in front of any line that begins with a . > Another question is, when I'm sending a message with my > public key, if I'm going to sign the message, should I > also sign the public key? That amounts to two > signatures. My preference when I receive a key in a message is for the key to be outside the signed portion of the message. That is, write the message, then sign it if you are going to, then paste the key below the "-----END PGP SIGNATURE-----" line. But that's my personal preference only and others will have different preferences. - -- Best regards MFPA mailto:expires2011 at ymail.com The greater the power, the more dangerous the abuse. -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN/ej0nhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pxp0D/Rvo 99YzED+uaDOejGcU8JspFGFf7U9SC431WvLPGPR8VHxV+Y07DeMC8Q1PqzmXrI0b KOTpCjZOakgyaWGBptCCq3l/K1nklecqgQic5zXtWEX3cfeYZso/0zSxscSaGGoD 2vAyHukrNQ1bv5JEjhv+Hl292XQCjhrm4nGd1k2U =6+ZA -----END PGP SIGNATURE----- From gnupg.user at seibercom.net Sun Jun 19 14:39:09 2011 From: gnupg.user at seibercom.net (Jerry) Date: Sun, 19 Jun 2011 08:39:09 -0400 Subject: Error message when refreshing keys Message-ID: <20110619083909.7cdccd62@scorpio> gpg --version gpg (GnuPG) 2.0.17 libgcrypt 1.4.6 When doing a "gpg2 --refresh-keys" I find the following being displayed: gpg: requesting key D02B0179 from http server jeremy.qux.net gpg: invalid radix64 character 2D skipped gpg: invalid radix64 character 2D skipped gpg: invalid radix64 character 2D skipped gpg: invalid radix64 character 2D skipped gpg: invalid radix64 character 2D skipped gpg: invalid radix64 character 2D skipped gpg: invalid radix64 character 2D skipped gpg: invalid radix64 character 2D skipped gpg: invalid radix64 character 2D skipped gpg: invalid radix64 character 2D skipped gpg: [don't know]: invalid packet (ctb=10) gpg: read_block: read error: Invalid packet gpg: Total number processed: 0 gpg: no valid OpenPGP data found. Is this a problem on my end or on the server? -- Jerry ? GNUPG.user at seibercom.net _____________________________________________________________________ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. From expires2011 at ymail.com Sun Jun 19 16:48:15 2011 From: expires2011 at ymail.com (MFPA) Date: Sun, 19 Jun 2011 15:48:15 +0100 Subject: timestamp notation @gnupg.org In-Reply-To: References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> <201106180021.17972.mailinglisten@hauke-laging.de> <895023152.20110618004032@my_localhost> <73411352.20110618132248@my_localhost> <1708159137.20110618170200@my_localhost> <879087301.20110618224401@my_localhost> Message-ID: <1376000135.20110619154815@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 18 June 2011 at 10:50:08 PM, in , Jerome Baum wrote: >>> Ah, we've been careless. Append a "Z" to your dates >>> and they are UTC (or append a timezone, if you want >>> that). Those two intervals are actually ambiguous >>> AFAIK. We could specify either: >>> 1. All times must be UTC ("Z") or have a timezone; or >> Aren't the timestamps recorded in the signature >> packets as unix time [1], and displayed in the local >> time detected from the user's system? > I was referring to the interval notation. I see. I'm not sure how the interval notation will interact with the timestamp. If "behind the scenes" the interval were actually recorded as seconds (and the timestamp is recorded as seconds since epoch), then it is automatically anchored to UTC. But, as at present, does not have to be displayed in UTC. >>> 2. Ambiguous times are interpreted as UTC. >> I think the ISO 8601 standard assumes local time >> unless otherwise specified. So it makes sense for each >> person viewing the signature to see the timestamp in >> their own local time if no time zone information is >> included. > Except, what is "local time" if you have two people in > different timezones? Local time to each person is the time in their respective timezone. > That's why we'd need either the > "all times UTC" rule, or a forced timezone in the > field. I think we do not need it. What is wrong with your system displaying that a signature was made 20110618T000000/P1D (your local time) and my system showing that the same signature was made 20110617T230000/P1D (my local time)? That's what happens now (with exact times rather than intervals) and I have seen no discussions of ambiguity or the need to state timezones. >> 20110618T000000+0200/P1D and 20110617T230000+0100/P1D >> both refer to the same time period without ambiguity. > Those have timezones. Your (and my) previous examples > didn't. What I was trying to impart was that when I see a time, I interpret it to be a time stated in my local time unless I am aware of a reason to think otherwise. So when I see 20110617T230000/P1D, in the absence of any information to the contrary, I understand it as local time which (in the Summer) is 20110617T230000+0100/P1D. It seems likely to me that somebody in a +0200 time zone would similarly assume a time to be in their local time zone, so would interpret 20110618T000000/P1D to mean 20110618T000000+0200/P1D. >> If people feel there is ambiguity here, maybe this is >> best dealt with by adding some simple text to the >> GnuPG output to indicate that times are shown in local >> time, as per the user's system. > That isn't what I was referring to. 20110618T000000/P1D > is ambiguous: Is it 20110618T000000+0200/P1D or > 20110618T000000+0100/P1D ? GnuPG stores the timestamp in seconds since epoch and displays it in the local time detected from the machine it is running on. AFAIK, we were not suggesting this changed. If the signature was created on a machine with local time zone set to +0200, then it means 20110618T000000+0200/P1D. If somebody views that signature on a machine with local time zone set to +0100, then they will see 20110617T230000/P1D, which means 20110617T230000+0100/P1D and refers to the same interval as 20110618T000000+0200/P1D. - -- Best regards MFPA mailto:expires2011 at ymail.com Does anybody really read these things? -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN/gxDnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pOqQEAIOG z/hYg0wwvr30O6SpWtgmMQ/YyRVqpifwIbUdJfhVndtlPoLHR3AswEjTfZXJDEmm N5d/uBdoLYj+7CFk87pLc5SytLuUYCJv7dv2Nd4NIXnvmEW5MUyQH1KWCf8CjkeA WzQsEJInWlrlrr/ejKliwS25qrZZqcjEYOpLWTRP =rpLn -----END PGP SIGNATURE----- From jerome at jeromebaum.com Sun Jun 19 20:26:53 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sun, 19 Jun 2011 20:26:53 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: <1376000135.20110619154815@my_localhost> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> <201106180021.17972.mailinglisten@hauke-laging.de> <895023152.20110618004032@my_localhost> <73411352.20110618132248@my_localhost> <1708159137.20110618170200@my_localhost> <879087301.20110618224401@my_localhost> <1376000135.20110619154815@my_localhost> Message-ID: >>> Aren't the timestamps recorded in the signature >>> packets as unix time [1], and displayed in the local >>> time detected from the user's system? > >> I was referring to the interval notation. > > I see. I'm not sure how the interval notation will interact with the > timestamp. If "behind the scenes" the interval were actually recorded > as seconds (and the timestamp is recorded as seconds since epoch), > then it is automatically anchored to UTC. But, as at present, does not > have to be displayed in UTC. Why are we even talking about ISO 8601? Because I suggested it as a format to record the data. Not seconds since epoch, twice; ISO 8601 interval, and be done. Local display is something entirely different: 1. Protocol on the one hand (needs to be unambiguous); and 2. Local interaction on the other hand (can be local timezone, UTC, another timezone, who cares?). >> Except, what is "local time" if you have two people in >> different timezones? > > Local time to each person is the time in their respective timezone. The point is, if there's no timezone noted down in the interval, there is no way to know what the timezone was when the person made the signature. We're talking about data at rest, that could be interpreted many years later, and it'll be difficult to "guess" the timezone then. Plus, it shouldn't be a guess anyway. >> That's why we'd need either the >> "all times UTC" rule, or a forced timezone in the >> field. > > I think we do not need it. > > What is wrong with your system displaying that a signature was made > 20110618T000000/P1D (your local time) and my system showing that the > same signature was made 20110617T230000/P1D (my local time)? That's > what happens now (with exact times rather than intervals) and I have > seen no discussions of ambiguity or the need to state timezones. Ah, but now we're talking display. I was talking about the content of the notation. Display can be however an implementation chooses to display this (raw notation value if I just use current gnupg with show-notations), but that isn't really a question here. What's more important is how an implementation constructs the interval, and how another de-constructs/parses it. > What I was trying to impart was that when I see a time, I interpret it > to be a time stated in my local time unless I am aware of a reason to > think otherwise. So when I see 20110617T230000/P1D, in the absence of > any information to the contrary, I understand it as local time which > (in the Summer) is 20110617T230000+0100/P1D. > > It seems likely to me that somebody in a +0200 time zone would > similarly assume a time to be in their local time zone, so would > interpret 20110618T000000/P1D to mean 20110618T000000+0200/P1D. Right. So discussing your actual point (after we've resolved that we were talking about different things/"past each other"), I would say local timezone is fine for display. I would say, let the user choose, give them a configuration option. >> That isn't what I was referring to. 20110618T000000/P1D >> is ambiguous: Is it 20110618T000000+0200/P1D or >> 20110618T000000+0100/P1D ? > > GnuPG stores the timestamp in seconds since epoch and displays it in > the local time detected from the machine it is running on. AFAIK, we > were not suggesting this changed. > > If the signature was created on a machine with local time zone set to > +0200, then it means 20110618T000000+0200/P1D. If somebody views that > signature on a machine with local time zone set to +0100, then they > will see 20110617T230000/P1D, which means 20110617T230000+0100/P1D and > refers to the same interval as 20110618T000000+0200/P1D. Right. Local display vs. recording. I'll just summarize again: 1. Interval is recorded as an ISO 8601 interval, and must be unambiguous (i.e. contain a proper timezone for each timestamp). 2. OpenPGP's timestamp is not changed (seconds since epoch UTC). 3. Local display, of both the timestamp and interval, is out of the question for now. However, I would suggest some option to let the user configure it. It's up to each implementation anyway. In terms of moving forward, I think the ISO 8601 ambiguity of lower precision in an interval is something we need to resolve. Since we're introducing the interval to allow for lower precision (e.g. round to the start of the day), I think the interval itself should have full precision. We would interpret any dropped components as zeros/ones resp. ("01" for months/days, "00" for hours, minutes, seconds, fractional seconds). Looking at this practically, say I round down to the start of the day. Clock drift isn't really an argument for an imprecise interval, because "2010Z" still means "at or after 2010-01-01T00:00:00Z", but clock drift could have me signing this on 2009-12-31Z. So in short, clock drift, the thing that would be the most likely concern, isn't a problem of precision (clock still resolves down to (nano-)seconds), but of accuracy. Less precise intervals cannot solve that, bigger intervals can. So here's the new suggested spec: 1. timestamp-only at gnupg.org. Let's omit this part for the sake of a friendly discussion. 2. Suggestion: timestamp-interval at gnupg.org. Value is an ISO 8601 time interval during which the timestamp was made, leaving no room for interpretation of the interval, but making it the signer's duty to compute this interval. 2 a. Non-critical. 2 b. Must have a timezone associated for each timestamp. "Z", "+0100", etc. As a safe-guard for broken implementations, should we assume an implied "Z" if there is no timezone? 2 c. Local display/interaction is something the implementations will sort out. We recommend at least the obvious "canonical" options of local timezone and UTC display. Practically, after parsing the interval into two timestamps, handling would be similar to the OpenPGP timestamp field (except that isn't enriched with the timezone, which you could use to enhance the output). Often enough, this boils down to "whatever the locale is configured to do" and that sounds in line with *NIX philosophy. -- 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 Sun Jun 19 20:29:04 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sun, 19 Jun 2011 20:29:04 +0200 Subject: Error message when refreshing keys In-Reply-To: <20110619083909.7cdccd62@scorpio> References: <20110619083909.7cdccd62@scorpio> Message-ID: > gpg --version > gpg (GnuPG) 2.0.17 > libgcrypt 1.4.6 > > When doing a "gpg2 --refresh-keys" I find the following being displayed: > > gpg: requesting key D02B0179 from http server jeremy.qux.net > gpg: invalid radix64 character 2D skipped > gpg: invalid radix64 character 2D skipped Could you post the output of "gpg --export D02B0179 | gpg --list-packets" ? > Is this a problem on my end or on the server? Very rough first guess: Server. -- 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 Sun Jun 19 20:32:58 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sun, 19 Jun 2011 20:32:58 +0200 Subject: gpg fails to decrypt files encrypted to the same name as the original input In-Reply-To: <4DFD815C.1020502@sindegra.com> References: <4DFD815C.1020502@sindegra.com> Message-ID: > I noticed this very interesting behavior in my version of gpg (2.0.17): > > 1. take a simple text file and call it say test.txt, encrypt it to a > file named test.txt in the same directory so that it overwrites it. (gpg > -o test.txt -e test.txt) > 2. decrypt file test.txt with gpg (gpg -d test.txt) and get gibberish. > > It does not seem to happen when I have the output renamed to something > else. I know this is a highly unusual (and probably ineffective way) of > using gpg but I still thought it was interesting that it would fail. Any > thoughts on this (potential) bug? Can anyone else recreate it, or is it > actually a feature/unavoidable side-effect? That's actually quite common for software to do. There are a few notable exceptions (sort(1) comes to mind), but it's not something you normally have to worry about. People tend to append ".gpg" anyway. :) -- 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 Sun Jun 19 20:47:39 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sun, 19 Jun 2011 20:47:39 +0200 Subject: formatting of gpg blocks In-Reply-To: <1308471611.9191.327.camel@n-pc> References: <1308434675.9191.12.camel@n-pc> <1308471611.9191.327.camel@n-pc> Message-ID: >> This is needed to make sure OpenPGP (i.e. gnupg) doesn't misinterpret stuff inside the block. Imagine enclosing some signed data inside a >> signed block. How does gnupg tell apart the "END" lines from the >> inner/outer blocks? > > Is this design better than one allowing the last END line to be the > closing one? This could lead to ambiguities. > I see that nested blocks are possible, but is this format documented > somewhere? OpenPGP standard, RFC 4880, section 6. > I suppose I keep wondering where the format is described because when I > first came across this, I spent a lot of time trying to import the > public key embedded in a clear-signed message. I didn't realize that I > needed to decrypt it until you mentioned it. And now I'm trying to learn > how not to make that mistake again in general. As a general recommendation, if the data is in OpenPGP format, interpret it as such first. Then if there is other OpenPGP data inside, use the interpreted version. Wrong interpretation ("taking shortcuts") is what leads to all these XSS and injection vulnerabilities we hear about every day. If your data is in format A, use A's interpreter to understand it. If there's B inside ("A(B)"), then use A's interpreter first, then B's interpreter. Your example is just the case of A = B = OpenPGP. >> Be careful to distinguish between data signatures (signing a message) >> and certifications (signing a key). Are you trying to wrap a data >> signature around the key? Unless you have a special use-case, that >> probably doesn't make sense. Instead try to use a certification. > > I see. I read that it is a good practice to sign one's public key before > giving it to other people. I thought they meant signing the key as a > message. Now that you clarified this, I went to seahorse, Names and > Signatures, sign key. It gives me a choice to let others see this > signature. Should I allow that? I would also appreciate it, if you could > explain how key certification is useful. Whose key is it? When you make a signature (whether on key or data), you need to be aware of what that signature says. Is this your key? It should already be signed by default. Is this another person's key? Why are you signing it? Have you verified that the key is valid? etc. Read through http://www.gnupg.org/gph/en/manual.html to get a better understanding -- before you make any certifications. -- 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 ypLxswPm8C24VUMt at lavabit.com Sun Jun 19 22:33:53 2011 From: ypLxswPm8C24VUMt at lavabit.com (0) Date: Sun, 19 Jun 2011 16:33:53 -0400 Subject: formatting of gpg blocks In-Reply-To: References: <1308434675.9191.12.camel@n-pc> <1308471611.9191.327.camel@n-pc> Message-ID: <1308515633.17650.34.camel@n-pc> On Sun, 2011-06-19 at 20:47 +0200, Jerome Baum wrote: > Whose key is it? When you make a signature (whether on key or data), > you need to be aware of what that signature says. Is this your key? It > should already be signed by default. Is this another person's key? Why > are you signing it? Have you verified that the key is valid? etc. Read > through http://www.gnupg.org/gph/en/manual.html to get a better > understanding -- before you make any certifications. This is my own public key. I was talking about signing my own public key before giving it to other people. Maybe it is already signed, because when I click on sign, nothing seems to change. However there is nothing under the column 'signature id' next to my email. I guess those recommendations were outdated if the key is already signed by default. seahorse, however, might not be representative of what's actually going on, so I went to kgpg and saw that were two signatures under my key: one inside the key pair, and another inside the sub key. I couldn't delete either. From gnupg.user at seibercom.net Sun Jun 19 22:36:56 2011 From: gnupg.user at seibercom.net (Jerry) Date: Sun, 19 Jun 2011 16:36:56 -0400 Subject: Error message when refreshing keys In-Reply-To: References: <20110619083909.7cdccd62@scorpio> Message-ID: <20110619163656.4fd87d64@scorpio> On Sun, 19 Jun 2011 20:29:04 +0200 Jerome Baum articulated: > > gpg --version > > gpg (GnuPG) 2.0.17 > > libgcrypt 1.4.6 > > > > When doing a "gpg2 --refresh-keys" I find the following being > > displayed: > > > > gpg: requesting key D02B0179 from http server jeremy.qux.net > > gpg: invalid radix64 character 2D skipped > > gpg: invalid radix64 character 2D skipped > > Could you post the output of "gpg --export D02B0179 | gpg > --list-packets" ? > > > Is this a problem on my end or on the server? > > Very rough first guess: Server. I hope this is what you wanted. The output seems rather long. :public key packet: version 4, algo 17, created 1241915844, expires 0 pkey[0]: [1024 bits] pkey[1]: [160 bits] pkey[2]: [1024 bits] pkey[3]: [1024 bits] keyid: 58BB961BD02B0179 :user ID packet: "Jeremy Mooney (GSWoT Key) " :signature packet: algo 17, keyid 7A921BC23C4A1809 version 4, created 1242360197, md5len 0, sigclass 0x12 digest algo 2, begin of digest 58 d7 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 7A921BC23C4A1809) data: [160 bits] data: [160 bits] :signature packet: algo 17, keyid 17A0B50DE3A7DE0B version 4, created 1242364709, md5len 0, sigclass 0x12 digest algo 2, begin of digest de e3 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 17A0B50DE3A7DE0B) data: [158 bits] data: [159 bits] :signature packet: algo 17, keyid 36E71C2A5A932E53 version 4, created 1242392410, md5len 0, sigclass 0x12 digest algo 2, begin of digest cf 02 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 36E71C2A5A932E53) data: [158 bits] data: [160 bits] :signature packet: algo 17, keyid 7EF74851923B023B version 4, created 1242482853, md5len 0, sigclass 0x12 digest algo 2, begin of digest fb 29 hashed subpkt 2 len 4 (sig created 2009-05-16) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID 7EF74851923B023B) data: [160 bits] data: [157 bits] :signature packet: algo 17, keyid F2C67E7909C0D15B version 4, created 1242413007, md5len 0, sigclass 0x13 digest algo 2, begin of digest 3e 97 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID F2C67E7909C0D15B) data: [160 bits] data: [159 bits] :signature packet: algo 17, keyid 7A921BC23C4A1809 version 4, created 1258851399, md5len 0, sigclass 0x12 digest algo 2, begin of digest 81 79 hashed subpkt 2 len 4 (sig created 2009-11-22) hashed subpkt 26 len 24 (policy: http://www.gswot.org/cps) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID 7A921BC23C4A1809) data: [160 bits] data: [160 bits] :signature packet: algo 17, keyid 58BB961BD02B0179 version 4, created 1242503176, md5len 0, sigclass 0x30 digest algo 2, begin of digest ec dc hashed subpkt 2 len 4 (sig created 2009-05-16) hashed subpkt 29 len 60 (revocation reason 0x00 (This uid was temporary and not supposed to reach keyservers)) subpkt 16 len 8 (issuer key ID 58BB961BD02B0179) data: [159 bits] data: [159 bits] :signature packet: algo 17, keyid 58BB961BD02B0179 version 4, created 1241916070, md5len 0, sigclass 0x13 digest algo 2, begin of digest a1 07 hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 9 len 4 (key expires after 5y0d0h0m) hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2) hashed subpkt 21 len 3 (pref-hash-algos: 2 8 3) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (key server preferences: 80) hashed subpkt 2 len 4 (sig created 2009-05-10) hashed subpkt 24 len 54 (preferred key server: http://jeremy.qux.net/keys/gpg-D02B0179/0xD02B0179.gpg) subpkt 16 len 8 (issuer key ID 58BB961BD02B0179) data: [158 bits] data: [157 bits] :signature packet: algo 1, keyid 4F92D6B846753F38 version 4, created 1242368248, md5len 0, sigclass 0x10 digest algo 2, begin of digest e4 91 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 4F92D6B846753F38) data: [2048 bits] :signature packet: algo 1, keyid 11EECBEEB464DD0F version 4, created 1242396070, md5len 0, sigclass 0x12 digest algo 2, begin of digest b8 d3 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 11EECBEEB464DD0F) data: [2047 bits] :signature packet: algo 1, keyid 1086CBD780B42B0F version 4, created 1242362313, md5len 0, sigclass 0x12 digest algo 8, begin of digest e0 b2 hashed subpkt 2 len 4 (sig created 2009-05-15) critical hashed subpkt 3 len 4 (sig expires after 4y359d19h58m) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 1086CBD780B42B0F) data: [2043 bits] :signature packet: algo 1, keyid B6ABE088B62E904D version 4, created 1242416545, md5len 0, sigclass 0x10 digest algo 2, begin of digest 32 e4 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID B6ABE088B62E904D) data: [4094 bits] :signature packet: algo 1, keyid C8294C3642464EF2 version 4, created 1242364754, md5len 0, sigclass 0x12 digest algo 2, begin of digest 35 68 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID C8294C3642464EF2) data: [4096 bits] :signature packet: algo 1, keyid 9EF9FA30154FDAF0 version 4, created 1242363971, md5len 0, sigclass 0x12 digest algo 2, begin of digest 28 fa hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 9EF9FA30154FDAF0) data: [8191 bits] :user ID packet: "Jeremy Mooney (GSWoT:US71) " :signature packet: algo 17, keyid 628B682545500782 version 4, created 1256002863, md5len 0, sigclass 0x12 digest algo 2, begin of digest d8 39 hashed subpkt 2 len 4 (sig created 2009-10-20) subpkt 16 len 8 (issuer key ID 628B682545500782) data: [160 bits] data: [160 bits] :signature packet: algo 17, keyid 361C5F70A9772DD3 version 4, created 1242424789, md5len 0, sigclass 0x13 digest algo 2, begin of digest 41 4b hashed subpkt 2 len 4 (sig created 2009-05-15) subpkt 16 len 8 (issuer key ID 361C5F70A9772DD3) data: [156 bits] data: [159 bits] :signature packet: algo 17, keyid 6493D78F4245D7F5 version 4, created 1242424891, md5len 0, sigclass 0x13 digest algo 2, begin of digest 41 51 hashed subpkt 2 len 4 (sig created 2009-05-15) subpkt 16 len 8 (issuer key ID 6493D78F4245D7F5) data: [159 bits] data: [160 bits] :signature packet: algo 17, keyid 6CB5A871BFC29C5F version 4, created 1242477610, md5len 0, sigclass 0x10 digest algo 2, begin of digest be aa hashed subpkt 2 len 4 (sig created 2009-05-16) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID 6CB5A871BFC29C5F) data: [160 bits] data: [159 bits] :signature packet: algo 17, keyid 561ADA409E791EEE version 4, created 1242576822, md5len 0, sigclass 0x10 digest algo 2, begin of digest 41 5b hashed subpkt 2 len 4 (sig created 2009-05-17) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID 561ADA409E791EEE) data: [157 bits] data: [159 bits] :signature packet: algo 17, keyid 03365206E10774CE version 4, created 1243766456, md5len 0, sigclass 0x10 digest algo 2, begin of digest a4 d7 hashed subpkt 2 len 4 (sig created 2009-05-31) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 03365206E10774CE) data: [160 bits] data: [160 bits] :signature packet: algo 17, keyid AB8693D989387612 version 4, created 1247302203, md5len 0, sigclass 0x10 digest algo 2, begin of digest 68 d8 hashed subpkt 2 len 4 (sig created 2009-07-11) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID AB8693D989387612) data: [157 bits] data: [157 bits] :signature packet: algo 17, keyid 4FA40C8FE5F63E80 version 4, created 1255637307, md5len 0, sigclass 0x10 digest algo 2, begin of digest bf 37 hashed subpkt 2 len 4 (sig created 2009-10-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 4FA40C8FE5F63E80) data: [155 bits] data: [159 bits] :signature packet: algo 17, keyid 3C225E4804F7BAB8 version 4, created 1242521004, md5len 0, sigclass 0x10 digest algo 8, begin of digest a3 4b hashed subpkt 2 len 4 (sig created 2009-05-17) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 3C225E4804F7BAB8) data: [159 bits] data: [160 bits] :signature packet: algo 17, keyid 7A921BC23C4A1809 version 4, created 1242360197, md5len 0, sigclass 0x12 digest algo 2, begin of digest 9a 77 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 7A921BC23C4A1809) data: [159 bits] data: [156 bits] :signature packet: algo 17, keyid 17A0B50DE3A7DE0B version 4, created 1242364709, md5len 0, sigclass 0x12 digest algo 2, begin of digest 5a 6e hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 17A0B50DE3A7DE0B) data: [160 bits] data: [159 bits] :signature packet: algo 17, keyid 36E71C2A5A932E53 version 4, created 1242392410, md5len 0, sigclass 0x12 digest algo 2, begin of digest 67 19 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 36E71C2A5A932E53) data: [156 bits] data: [158 bits] :signature packet: algo 17, keyid F693F0F246C171A0 version 4, created 1242480530, md5len 0, sigclass 0x12 digest algo 2, begin of digest 71 ea hashed subpkt 2 len 4 (sig created 2009-05-16) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID F693F0F246C171A0) data: [155 bits] data: [160 bits] :signature packet: algo 17, keyid 7EF74851923B023B version 4, created 1242482848, md5len 0, sigclass 0x12 digest algo 2, begin of digest b3 f2 hashed subpkt 2 len 4 (sig created 2009-05-16) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID 7EF74851923B023B) data: [157 bits] data: [159 bits] :signature packet: algo 17, keyid F729AFD981802954 version 4, created 1242578625, md5len 0, sigclass 0x12 digest algo 2, begin of digest 63 4e hashed subpkt 2 len 4 (sig created 2009-05-17) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID F729AFD981802954) data: [160 bits] data: [160 bits] :signature packet: algo 17, keyid 771A25BCE6778A77 version 4, created 1243445591, md5len 0, sigclass 0x12 digest algo 2, begin of digest a7 bb hashed subpkt 2 len 4 (sig created 2009-05-27) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 771A25BCE6778A77) data: [158 bits] data: [160 bits] :signature packet: algo 17, keyid 47855DA96D1158BC version 4, created 1243535211, md5len 0, sigclass 0x12 digest algo 2, begin of digest 01 d1 hashed subpkt 2 len 4 (sig created 2009-05-28) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 47855DA96D1158BC) data: [160 bits] data: [157 bits] :signature packet: algo 17, keyid 06C51F49E827E9D8 version 4, created 1243535694, md5len 0, sigclass 0x12 digest algo 2, begin of digest 91 47 hashed subpkt 2 len 4 (sig created 2009-05-28) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 06C51F49E827E9D8) data: [160 bits] data: [160 bits] :signature packet: algo 17, keyid E0FDA36B9372A24E version 4, created 1243580199, md5len 0, sigclass 0x12 digest algo 2, begin of digest e0 12 hashed subpkt 2 len 4 (sig created 2009-05-29) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID E0FDA36B9372A24E) data: [157 bits] data: [159 bits] :signature packet: algo 17, keyid D019F5EF9027AB88 version 4, created 1243580769, md5len 0, sigclass 0x12 digest algo 2, begin of digest 6e ea hashed subpkt 2 len 4 (sig created 2009-05-29) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID D019F5EF9027AB88) data: [159 bits] data: [158 bits] :signature packet: algo 17, keyid 68E1252B7DA5C53B version 4, created 1243583847, md5len 0, sigclass 0x12 digest algo 2, begin of digest d8 d3 hashed subpkt 2 len 4 (sig created 2009-05-29) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID 68E1252B7DA5C53B) data: [160 bits] data: [159 bits] :signature packet: algo 17, keyid F1834EAB0DD95241 version 4, created 1243598095, md5len 0, sigclass 0x12 digest algo 2, begin of digest 98 ec hashed subpkt 2 len 4 (sig created 2009-05-29) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID F1834EAB0DD95241) data: [160 bits] data: [159 bits] :signature packet: algo 17, keyid 1D67A5C0C06AD806 version 4, created 1243598294, md5len 0, sigclass 0x12 digest algo 2, begin of digest 80 ca hashed subpkt 2 len 4 (sig created 2009-05-29) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 1D67A5C0C06AD806) data: [159 bits] data: [156 bits] :signature packet: algo 17, keyid 91FD46894A00352C version 4, created 1243803779, md5len 0, sigclass 0x12 digest algo 2, begin of digest 5d 30 hashed subpkt 2 len 4 (sig created 2009-05-31) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 91FD46894A00352C) data: [160 bits] data: [159 bits] :signature packet: algo 17, keyid 2F1A3886D4CB6DA4 version 4, created 1243879201, md5len 0, sigclass 0x12 digest algo 2, begin of digest d3 6d hashed subpkt 2 len 4 (sig created 2009-06-01) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 2F1A3886D4CB6DA4) data: [160 bits] data: [160 bits] :signature packet: algo 17, keyid 7B38E7A1B14E82B1 version 4, created 1243934518, md5len 0, sigclass 0x12 digest algo 2, begin of digest 9f 08 hashed subpkt 2 len 4 (sig created 2009-06-02) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID 7B38E7A1B14E82B1) data: [159 bits] data: [154 bits] :signature packet: algo 17, keyid 7A2E91FB7885DAFC version 4, created 1244994031, md5len 0, sigclass 0x12 digest algo 2, begin of digest 01 ac hashed subpkt 2 len 4 (sig created 2009-06-14) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 7A2E91FB7885DAFC) data: [158 bits] data: [160 bits] :signature packet: algo 17, keyid CF8D6CC1ECAC896E version 4, created 1249238804, md5len 0, sigclass 0x12 digest algo 2, begin of digest 1f 26 hashed subpkt 2 len 4 (sig created 2009-08-02) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID CF8D6CC1ECAC896E) data: [159 bits] data: [160 bits] :signature packet: algo 17, keyid F7F352CF8895E80F version 4, created 1250455143, md5len 0, sigclass 0x12 digest algo 2, begin of digest 87 47 hashed subpkt 2 len 4 (sig created 2009-08-16) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID F7F352CF8895E80F) data: [158 bits] data: [159 bits] :signature packet: algo 17, keyid 5FCE5F9EE8D80906 version 4, created 1264895309, md5len 0, sigclass 0x12 digest algo 2, begin of digest b5 33 hashed subpkt 2 len 4 (sig created 2010-01-30) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 5FCE5F9EE8D80906) data: [160 bits] data: [160 bits] :signature packet: algo 17, keyid 6DEF21BEF98E995C version 4, created 1271097056, md5len 0, sigclass 0x12 digest algo 2, begin of digest 81 f5 hashed subpkt 2 len 4 (sig created 2010-04-12) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID 6DEF21BEF98E995C) data: [160 bits] data: [159 bits] :signature packet: algo 17, keyid F2C67E7909C0D15B version 4, created 1242413004, md5len 0, sigclass 0x13 digest algo 2, begin of digest 03 70 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID F2C67E7909C0D15B) data: [159 bits] data: [153 bits] :signature packet: algo 17, keyid 10720B1536BF3AED version 4, created 1242499539, md5len 0, sigclass 0x13 digest algo 2, begin of digest 31 d4 hashed subpkt 2 len 4 (sig created 2009-05-16) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 10720B1536BF3AED) data: [159 bits] data: [159 bits] :signature packet: algo 17, keyid D7993ED4BDD13B90 version 4, created 1242499597, md5len 0, sigclass 0x13 digest algo 2, begin of digest 03 63 hashed subpkt 2 len 4 (sig created 2009-05-16) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID D7993ED4BDD13B90) data: [160 bits] data: [160 bits] :signature packet: algo 17, keyid C9D7E2DF688B7D98 version 4, created 1242486465, md5len 0, sigclass 0x12 digest algo 2, begin of digest a3 2e hashed subpkt 2 len 4 (sig created 2009-05-16) critical hashed subpkt 3 len 4 (sig expires after 4y358d9h29m) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID C9D7E2DF688B7D98) data: [160 bits] data: [159 bits] :signature packet: algo 17, keyid 6FAD5A48561D5E6F version 4, created 1243656278, md5len 0, sigclass 0x12 digest algo 2, begin of digest b7 33 hashed subpkt 2 len 4 (sig created 2009-05-30) critical hashed subpkt 3 len 4 (sig expires after 4y344d20h32m) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 6FAD5A48561D5E6F) data: [158 bits] data: [157 bits] :signature packet: algo 17, keyid 4CF4E7F584E70EE6 version 4, created 1255633983, md5len 0, sigclass 0x12 digest algo 2, begin of digest 7b 3a hashed subpkt 2 len 4 (sig created 2009-10-15) critical hashed subpkt 3 len 4 (sig expires after 4y206d5h24m) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 4CF4E7F584E70EE6) data: [158 bits] data: [160 bits] :signature packet: algo 17, keyid 8575BC4C6126D1F5 version 4, created 1243470040, md5len 0, sigclass 0x12 digest algo 8, begin of digest 37 d2 hashed subpkt 2 len 4 (sig created 2009-05-28) critical hashed subpkt 3 len 4 (sig expires after 4y347d0h16m) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 8575BC4C6126D1F5) data: [159 bits] data: [159 bits] :signature packet: algo 17, keyid 7A921BC23C4A1809 version 4, created 1258851399, md5len 0, sigclass 0x12 digest algo 2, begin of digest b7 27 hashed subpkt 2 len 4 (sig created 2009-11-22) hashed subpkt 26 len 24 (policy: http://www.gswot.org/cps) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID 7A921BC23C4A1809) data: [155 bits] data: [160 bits] :signature packet: algo 17, keyid D2BB0D0165D0FD58 version 4, created 1243745664, md5len 0, sigclass 0x10 digest algo 2, begin of digest af 18 hashed subpkt 2 len 4 (sig created 2009-05-31) critical hashed subpkt 3 len 4 (sig expires after 1y1d0h0m) hashed subpkt 26 len 29 (policy: http://www.cacert.org/cps.php) subpkt 16 len 8 (issuer key ID D2BB0D0165D0FD58) data: [159 bits] data: [158 bits] :signature packet: algo 17, keyid 72D4DFF8D4C3F197 version 4, created 1243579527, md5len 0, sigclass 0x12 digest algo 2, begin of digest 5b be hashed subpkt 2 len 4 (sig created 2009-05-29) hashed subpkt 26 len 49 (policy: http://www.nic-nac-project.org/~blaap/policy.html) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 72D4DFF8D4C3F197) data: [159 bits] data: [157 bits] :signature packet: algo 17, keyid 58BB961BD02B0179 version 4, created 1242347838, md5len 0, sigclass 0x13 digest algo 2, begin of digest a5 6e hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 9 len 4 (key expires after 5y0d0h0m) hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2) hashed subpkt 21 len 3 (pref-hash-algos: 2 8 3) hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1) hashed subpkt 30 len 1 (features: 01) hashed subpkt 23 len 1 (key server preferences: 80) hashed subpkt 25 len 1 (primary user ID) hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 24 len 54 (preferred key server: http://jeremy.qux.net/keys/gpg-D02B0179/0xD02B0179.gpg) subpkt 16 len 8 (issuer key ID 58BB961BD02B0179) data: [159 bits] data: [159 bits] :signature packet: algo 1, keyid 4F92D6B846753F38 version 4, created 1242368248, md5len 0, sigclass 0x10 digest algo 2, begin of digest a4 d5 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 4F92D6B846753F38) data: [2048 bits] :signature packet: algo 1, keyid E9FB0F52434343D6 version 4, created 1243908642, md5len 0, sigclass 0x10 digest algo 2, begin of digest fc db hashed subpkt 2 len 4 (sig created 2009-06-02) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID E9FB0F52434343D6) data: [2048 bits] :signature packet: algo 1, keyid D8C3E3DF331A8BD3 version 4, created 1247246789, md5len 0, sigclass 0x10 digest algo 2, begin of digest e2 10 hashed subpkt 2 len 4 (sig created 2009-07-10) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID D8C3E3DF331A8BD3) data: [2048 bits] :signature packet: algo 1, keyid CEB1A3408DB5A80F version 4, created 1256040052, md5len 0, sigclass 0x10 digest algo 2, begin of digest de 69 hashed subpkt 2 len 4 (sig created 2009-10-20) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID CEB1A3408DB5A80F) data: [2048 bits] :signature packet: algo 1, keyid 1FCC141A4BBF1017 version 4, created 1243615364, md5len 0, sigclass 0x10 digest algo 8, begin of digest 6d 52 hashed subpkt 2 len 4 (sig created 2009-05-29) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 1FCC141A4BBF1017) data: [2044 bits] :signature packet: algo 1, keyid 11EECBEEB464DD0F version 4, created 1242396070, md5len 0, sigclass 0x12 digest algo 2, begin of digest a9 a5 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 11EECBEEB464DD0F) data: [2048 bits] :signature packet: algo 1, keyid 8631BE41EF27ED5F version 4, created 1242573593, md5len 0, sigclass 0x12 digest algo 2, begin of digest 2f a5 hashed subpkt 2 len 4 (sig created 2009-05-17) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID 8631BE41EF27ED5F) data: [2046 bits] :signature packet: algo 1, keyid 59F6C071426B6FBB version 4, created 1256222211, md5len 0, sigclass 0x12 digest algo 2, begin of digest a8 2b hashed subpkt 2 len 4 (sig created 2009-10-22) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 59F6C071426B6FBB) data: [2047 bits] :signature packet: algo 1, keyid C5592ACB80C7D647 version 4, created 1242580688, md5len 0, sigclass 0x13 digest algo 8, begin of digest 41 69 hashed subpkt 2 len 4 (sig created 2009-05-17) hashed subpkt 5 len 2 (trust signature of depth 2, value 60) subpkt 16 len 8 (issuer key ID C5592ACB80C7D647) data: [2044 bits] :signature packet: algo 1, keyid 82121A454319410E version 4, created 1242503563, md5len 0, sigclass 0x12 digest algo 2, begin of digest 5d 99 hashed subpkt 2 len 4 (sig created 2009-05-16) critical hashed subpkt 3 len 4 (sig expires after 4y358d4h44m) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 82121A454319410E) data: [2047 bits] :signature packet: algo 1, keyid ADF32EDFE3F1D8F7 version 4, created 1242503785, md5len 0, sigclass 0x12 digest algo 2, begin of digest a4 9a hashed subpkt 2 len 4 (sig created 2009-05-16) critical hashed subpkt 3 len 4 (sig expires after 4y358d4h40m) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID ADF32EDFE3F1D8F7) data: [2046 bits] :signature packet: algo 1, keyid 1086CBD780B42B0F version 4, created 1242362313, md5len 0, sigclass 0x12 digest algo 8, begin of digest f9 51 hashed subpkt 2 len 4 (sig created 2009-05-15) critical hashed subpkt 3 len 4 (sig expires after 4y359d19h58m) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 1086CBD780B42B0F) data: [2046 bits] :signature packet: algo 1, keyid 75AA9F9CF8180E9E version 4, created 1247680112, md5len 0, sigclass 0x12 digest algo 2, begin of digest 14 e7 hashed subpkt 2 len 4 (sig created 2009-07-15) hashed subpkt 26 len 46 (policy: http://www.babylonfarms.com/secure/Policy.html) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID 75AA9F9CF8180E9E) data: [2046 bits] :signature packet: algo 1, keyid 628FDB78D212A16E version 4, created 1247802481, md5len 0, sigclass 0x12 digest algo 2, begin of digest fc 37 hashed subpkt 2 len 4 (sig created 2009-07-17) hashed subpkt 26 len 46 (policy: http://www.babylonfarms.com/secure/Policy.html) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID 628FDB78D212A16E) data: [2047 bits] :signature packet: algo 1, keyid B6ABE088B62E904D version 4, created 1242416546, md5len 0, sigclass 0x10 digest algo 2, begin of digest 4f a0 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID B6ABE088B62E904D) data: [4095 bits] :signature packet: algo 1, keyid 1E4FF6543BC7B65E version 4, created 1247302181, md5len 0, sigclass 0x10 digest algo 2, begin of digest c4 98 hashed subpkt 2 len 4 (sig created 2009-07-11) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 1E4FF6543BC7B65E) data: [4095 bits] :signature packet: algo 1, keyid C8294C3642464EF2 version 4, created 1242364754, md5len 0, sigclass 0x12 digest algo 2, begin of digest b7 bc hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID C8294C3642464EF2) data: [4095 bits] :signature packet: algo 1, keyid 35D7DAA9FE7C7CE9 version 4, created 1244118001, md5len 0, sigclass 0x12 digest algo 2, begin of digest 13 f8 hashed subpkt 2 len 4 (sig created 2009-06-04) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID 35D7DAA9FE7C7CE9) data: [4093 bits] :signature packet: algo 1, keyid A9C86C8DD3AE8D3A version 4, created 1252855616, md5len 0, sigclass 0x12 digest algo 2, begin of digest 4a 47 hashed subpkt 2 len 4 (sig created 2009-09-13) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID A9C86C8DD3AE8D3A) data: [4092 bits] :signature packet: algo 1, keyid E377254719851166 version 4, created 1256034468, md5len 0, sigclass 0x12 digest algo 2, begin of digest 64 f4 hashed subpkt 2 len 4 (sig created 2009-10-20) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID E377254719851166) data: [4095 bits] :signature packet: algo 1, keyid 6B558272F8F15181 version 4, created 1280067078, md5len 0, sigclass 0x12 digest algo 2, begin of digest af ac hashed subpkt 2 len 4 (sig created 2010-07-25) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 6B558272F8F15181) data: [4096 bits] :signature packet: algo 1, keyid 9EC002FE1C9CA517 version 4, created 1248633475, md5len 0, sigclass 0x12 digest algo 8, begin of digest 31 3e hashed subpkt 2 len 4 (sig created 2009-07-26) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 9EC002FE1C9CA517) data: [4096 bits] :signature packet: algo 1, keyid D11C2911CE519CDE version 4, created 1271080454, md5len 0, sigclass 0x12 digest algo 8, begin of digest 34 12 hashed subpkt 2 len 4 (sig created 2010-04-12) hashed subpkt 5 len 2 (trust signature of depth 1, value 60) subpkt 16 len 8 (issuer key ID D11C2911CE519CDE) data: [4096 bits] :signature packet: algo 1, keyid CC6F3AB7B85B5EA6 version 4, created 1286837252, md5len 0, sigclass 0x12 digest algo 10, begin of digest a7 a7 hashed subpkt 2 len 4 (sig created 2010-10-11) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID CC6F3AB7B85B5EA6) data: [4096 bits] :signature packet: algo 1, keyid 15431D1BBD5D7808 version 4, created 1243598843, md5len 0, sigclass 0x12 digest algo 2, begin of digest fc d1 hashed subpkt 2 len 4 (sig created 2009-05-29) critical hashed subpkt 3 len 4 (sig expires after 4y345d12h30m) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 15431D1BBD5D7808) data: [4096 bits] :signature packet: algo 1, keyid 9D897DE1D242D57F version 4, created 1255946527, md5len 0, sigclass 0x12 digest algo 2, begin of digest ac 1e hashed subpkt 2 len 4 (sig created 2009-10-19) critical hashed subpkt 3 len 4 (sig expires after 4y202d14h35m) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 9D897DE1D242D57F) data: [4096 bits] :signature packet: algo 1, keyid 2B9880E1E6602099 version 4, created 1252196450, md5len 0, sigclass 0x12 digest algo 8, begin of digest e2 32 hashed subpkt 2 len 4 (sig created 2009-09-06) critical hashed subpkt 3 len 4 (sig expires after 4y246d0h16m) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 2B9880E1E6602099) data: [4096 bits] :signature packet: algo 1, keyid 9EF9FA30154FDAF0 version 4, created 1242363971, md5len 0, sigclass 0x12 digest algo 2, begin of digest 83 d8 hashed subpkt 2 len 4 (sig created 2009-05-15) hashed subpkt 5 len 2 (trust signature of depth 1, value 120) subpkt 16 len 8 (issuer key ID 9EF9FA30154FDAF0) data: [8192 bits] :public sub key packet: version 4, algo 17, created 1243574980, expires 0 pkey[0]: [1024 bits] pkey[1]: [160 bits] pkey[2]: [1023 bits] pkey[3]: [1023 bits] keyid: 197E62A965389A60 :signature packet: algo 17, keyid 58BB961BD02B0179 version 4, created 1243574980, md5len 0, sigclass 0x18 digest algo 2, begin of digest dc da hashed subpkt 2 len 4 (sig created 2009-05-29) hashed subpkt 27 len 1 (key flags: 02) hashed subpkt 9 len 4 (key expires after 2y0d0h0m) subpkt 16 len 8 (issuer key ID 58BB961BD02B0179) subpkt 32 len 93 (signature: v4, class 0x19, algo 17, digest algo 2) data: [159 bits] data: [154 bits] :public sub key packet: version 4, algo 16, created 1241980808, expires 0 pkey[0]: [2048 bits] pkey[1]: [3 bits] pkey[2]: [2046 bits] keyid: 807CA723B5DF0AD2 :signature packet: algo 17, keyid 58BB961BD02B0179 version 4, created 1241980808, md5len 0, sigclass 0x18 digest algo 2, begin of digest 61 3f hashed subpkt 2 len 4 (sig created 2009-05-10) hashed subpkt 27 len 1 (key flags: 0C) hashed subpkt 9 len 4 (key expires after 1y0d0h0m) subpkt 16 len 8 (issuer key ID 58BB961BD02B0179) data: [159 bits] data: [159 bits] From jerome at jeromebaum.com Sun Jun 19 22:42:18 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sun, 19 Jun 2011 22:42:18 +0200 Subject: formatting of gpg blocks In-Reply-To: <1308515633.17650.34.camel@n-pc> References: <1308434675.9191.12.camel@n-pc> <1308471611.9191.327.camel@n-pc> <1308515633.17650.34.camel@n-pc> Message-ID: > This is my own public key. I was talking about signing my own public key > before giving it to other people. Maybe it is already signed, because > when I click on sign, nothing seems to change. However there is nothing > under the column 'signature id' next to my email. I guess those > recommendations were outdated if the key is already signed by default. > > seahorse, however, might not be representative of what's actually going > on, so I went to kgpg and saw that were two signatures under my key: one > inside the key pair, and another inside the sub key. I couldn't delete > either. In that case there should be no need to sign it. If you want, give us the output of "gpg --list-sigs " and we should be able to tell you. -- 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 ypLxswPm8C24VUMt at lavabit.com Sun Jun 19 22:46:03 2011 From: ypLxswPm8C24VUMt at lavabit.com (0) Date: Sun, 19 Jun 2011 16:46:03 -0400 Subject: GnuPG Shell installed but cannot be launched In-Reply-To: References: Message-ID: <1308516363.17650.45.camel@n-pc> I download and installed GnuPG Shell .deb in ubuntu, and soft center says it's installed; however I cannot launch it. It's not in the menu, and running 'gnupgshell' doesn't work. I was trying to find a front end more alike in capabilities with kgpg than with seahorse, but that works better in gnome. What's the problem with GnuPG Shell? Can you suggest a better front end? KGpg requires me to make certain kde config changes to make it suitable for comfortable work, however, I don't know how to install kcontrol to make those changes. Package kcontrol is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: kdebase-workspace-bin kdebase-runtime kdelibs4c2a Which one of kdebase-workspace-bin kdebase-runtime kdelibs4c2a should I install? From jerome at jeromebaum.com Sun Jun 19 22:50:22 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sun, 19 Jun 2011 22:50:22 +0200 Subject: Error message when refreshing keys In-Reply-To: <20110619163656.4fd87d64@scorpio> References: <20110619083909.7cdccd62@scorpio> <20110619163656.4fd87d64@scorpio> Message-ID: >> Could you post the output of "gpg --export D02B0179 | gpg >> --list-packets" ? >> > I hope this is what you wanted. The output seems rather long. > > :public key packet: (snip) Yes, that's the right output. As I get the same issues, apparently gpg (v1 here) doesn't like non-armored keys via HTTP. RFC 4880 doesn't discuss the issue, but in any case Jeremy would be well-advised to upload an armored version of his key. That'll resolve the problem. Just as a reference, can you try pulling my key (from http://jeromebaum.com/jerome.asc), importing it, and then refreshing it? Does it throw any errors? -- 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 gnupg.user at seibercom.net Sun Jun 19 23:27:46 2011 From: gnupg.user at seibercom.net (Jerry) Date: Sun, 19 Jun 2011 17:27:46 -0400 Subject: Error message when refreshing keys In-Reply-To: References: <20110619083909.7cdccd62@scorpio> <20110619163656.4fd87d64@scorpio> Message-ID: <20110619172746.5b399b2b@scorpio> On Sun, 19 Jun 2011 22:50:22 +0200 Jerome Baum articulated: > >> Could you post the output of "gpg --export D02B0179 | gpg > >> --list-packets" ? > >> > > I hope this is what you wanted. The output seems rather long. > > > > :public key packet: > (snip) > > Yes, that's the right output. As I get the same issues, apparently gpg > (v1 here) doesn't like non-armored keys via HTTP. RFC 4880 doesn't > discuss the issue, but in any case Jeremy would be well-advised to > upload an armored version of his key. That'll resolve the problem. > > Just as a reference, can you try pulling my key (from > http://jeromebaum.com/jerome.asc), importing it, and then refreshing > it? Does it throw any errors? gpg: requesting key C58C753A from http server jeromebaum.com gpg: key C58C753A: "Jerome Baum " not changed gpg: key 215236DA: "Jerome Baum" not changed gpg: Total number processed: 2 gpg: unchanged: 2 -- Jerry ? GNUPG.user at seibercom.net _____________________________________________________________________ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. From cr at oratorperfectus.com Sun Jun 19 23:14:08 2011 From: cr at oratorperfectus.com (//c) Date: Sun, 19 Jun 2011 23:14:08 +0200 Subject: GnuPG Shell installed but cannot be launched In-Reply-To: <1308516363.17650.45.camel@n-pc> References: <1308516363.17650.45.camel@n-pc> Message-ID: <20110619211407.GA26393@heart-of-gold.fritz.box> Hi, On Sun, 19 Jun 2011, 0 wrote: > I download and installed GnuPG Shell .deb in ubuntu, and soft center > says it's installed; however I cannot launch it. It's not in the menu, > and running 'gnupgshell' doesn't work. I was trying to find a front end > more alike in capabilities with kgpg than with seahorse, but that works > better in gnome. > > Can you suggest a better front end? Perhaps you should give GPA (GNU Privacy Assistant) a try. http://gpa.wald.intevation.org/ http://packages.debian.org/squeeze/gpa http://packages.ubuntu.com/search?keywords=gpa IMHO it is far better than seahorse. Yours //c -- Christian Ro?berg Rhetorikberater | Consulting Rhetorician OratorPerfectus GbR | http://oratorperfectus.com From expires2011 at ymail.com Mon Jun 20 02:47:24 2011 From: expires2011 at ymail.com (MFPA) Date: Mon, 20 Jun 2011 01:47:24 +0100 Subject: timestamp notation @gnupg.org In-Reply-To: References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> <201106180021.17972.mailinglisten@hauke-laging.de> <895023152.20110618004032@my_localhost> <73411352.20110618132248@my_localhost> <1708159137.20110618170200@my_localhost> <879087301.20110618224401@my_localhost> <1376000135.20110619154815@my_localhost> Message-ID: <719370430.20110620014724@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 19 June 2011 at 7:26:53 PM, in , Jerome Baum wrote: > Local display is something entirely different: > 1. Protocol on the one hand (needs to be unambiguous); > and > 2. Local interaction on the other hand (can be local > timezone, UTC, another timezone, who cares?). Fair enough. > The point is, if there's no timezone noted down in the > interval, there is no way to know what the timezone was > when the person made the signature. We're talking about > data at rest, that could be interpreted many years > later, and it'll be difficult to "guess" the timezone > then. Plus, it shouldn't be a guess anyway. We know the timestamp, rounded back to the start of the interval; that is recorded in the timestamp field. We know the length of the interval (/P1D, /P1M, or whatever), that will be recorded in the interval field. Those two pieces of information uniquely define the interval without the need for guesswork and without the need to know the signer's local timezone. > Right. Local display vs. recording. I'll just summarize > again: > 1. Interval is recorded as an ISO 8601 interval, and > must be unambiguous (i.e. contain a proper timezone for > each timestamp). As already mentioned, I do not see the need for a timezone. I'm not against including one if there a need can be demonstrated. > 2. OpenPGP's timestamp is not changed (seconds since > epoch UTC). Unless the timestamp is rounded back to the start of the interval, it still reveals (potentially sensitive) information about the signer's time management. > 3. Local display, of both the timestamp and interval, > is out of the question for now. You mean because we are only discussing how the interval is to be recorded? Fair enough. > In terms of moving forward, I think the ISO 8601 > ambiguity of lower precision in an interval is > something we need to resolve. Since we're introducing > the interval to allow for lower precision (e.g. round > to the start of the day), I think the interval itself > should have full precision. We would interpret any > dropped components as zeros/ones resp. ("01" for > months/days, "00" for hours, minutes, seconds, > fractional seconds). I think that is implicit. However, what intervals may be allowable? If the interval is one hour/day/month/year then we round to the start of the current one. If the interval is one week, which day does the week start? Do we allow a period of two hours/months etc. and if so, where do we round back to? What about ten years? > So here's the new suggested spec: > 1. timestamp-only at gnupg.org. Let's omit this part for > the sake of a friendly discussion. Agreed. > 2. Suggestion: timestamp-interval at gnupg.org. Somewhere along the line I interpreted the suggestion as adding a timestamp-interval field to the signature packet, and rounding the timestamp field down to the start of that interval. > Value is > an ISO 8601 time interval during which the timestamp > was made, leaving no room for interpretation of the > interval, but making it the signer's duty to compute > this interval. You mean actually computing /P (or alternatively /) and placing it in a signature notation for each signature or batch of signatures? Automation would be needed for many people to take this up. Or at the very least, using long intervals so that the notation needs editing infrequently. (-; > 2 a. Non-critical. Is the effect of this that the interval is simply ignored by an app that doesn't understand it? Would it look like the signature was created at the start of the interval or the actual clock time it was signed? > 2 b. Must have a timezone associated for each > timestamp. "Z", "+0100", etc. As a safe-guard for > broken implementations, should we assume an implied "Z" > if there is no timezone? Rather than an assumed "Z" we should have a marker that indicates we do not know the time zone. This is one of those cases where the technology can't guess for the user. I think the ISO 8601 solution to ambiguous or unknown timezone is to use "-0000." I didn't understand how that was different from "+0000" or "Z" when I read it. > 2 c. Local display/interaction is something the > implementations will sort out. We recommend at least > the obvious "canonical" options of local timezone and > UTC display. I would suggest three options: UTC, the local timezone of the user viewing the signature, and the timezone stated in the interval field. > Practically, after parsing the interval > into two timestamps, handling would be similar to the > OpenPGP timestamp field (except that isn't enriched > with the timezone, which you could use to enhance the > output). Often enough, this boils down to "whatever the > locale is configured to do" and that sounds in line > with *NIX philosophy. Fair enough. But if it is simply a signature notation, how/why does it get parsed at all rather than simply displayed? Are you suggesting the value recorded in the OpenPGP timestamp field in the signature packet is rounded back to the start of the interval before recording, or left intact? - -- Best regards MFPA mailto:expires2011 at ymail.com Two rights do not make a wrong. They make an airplane. -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN/piwnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pIoQD/2To OgxjCmW0Jat+acQKmHmzIs8eqxt0+GADveXWubVo28AwghnpBL4osyHJf4M5nVl4 lSDGgqPuf4s9ednELSivcj3H41Ei+2lQnupI6n3MZ3Te19d+36HMQRCojahxdgpq Lr7dm/M4JP7I111btlDnK3qeDfbiL7YuKd+zGaC0 =ZCml -----END PGP SIGNATURE----- From ben at adversary.org Mon Jun 20 04:10:38 2011 From: ben at adversary.org (Ben McGinnes) Date: Mon, 20 Jun 2011 12:10:38 +1000 Subject: gpg fails to decrypt files encrypted to the same name as the original input In-Reply-To: References: <4DFD815C.1020502@sindegra.com> Message-ID: <4DFEAC1E.7010907@adversary.org> On 20/06/11 4:32 AM, Jerome Baum wrote: > > That's actually quite common for software to do. There are a few > notable exceptions (sort(1) comes to mind), but it's not something you > normally have to worry about. People tend to append ".gpg" anyway. :) Actually people tend to ignore the -o flag and let GPG add whichever extension is appropriate, either .gpg or .asc, to the filename. 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 20 05:43:19 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Mon, 20 Jun 2011 05:43:19 +0200 Subject: Error message when refreshing keys In-Reply-To: <20110619172746.5b399b2b@scorpio> References: <20110619083909.7cdccd62@scorpio> <20110619163656.4fd87d64@scorpio> <20110619172746.5b399b2b@scorpio> Message-ID: >> Yes, that's the right output. As I get the same issues, apparently gpg >> (v1 here) doesn't like non-armored keys via HTTP. RFC 4880 doesn't >> discuss the issue, but in any case Jeremy would be well-advised to >> upload an armored version of his key. That'll resolve the problem. >> >> Just as a reference, can you try pulling my key (from >> http://jeromebaum.com/jerome.asc), importing it, and then refreshing >> it? Does it throw any errors? > > gpg: requesting key C58C753A from http server jeromebaum.com > gpg: key C58C753A: "Jerome Baum " not changed > gpg: key 215236DA: "Jerome Baum" not changed > gpg: Total number processed: 2 > gpg: ? ? ? ? ? ? ?unchanged: 2 Okay, so Jeremy should definitely upload an armored version of the key. That is the cause of the problem. Whether it is intentional or not, and whether this applies to other implementations, I cannot say. But I know for sure that if it should work for gpg, he has to upload an armored version. -- 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 20 06:07:25 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Mon, 20 Jun 2011 06:07:25 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: <719370430.20110620014724@my_localhost> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> <201106180021.17972.mailinglisten@hauke-laging.de> <895023152.20110618004032@my_localhost> <73411352.20110618132248@my_localhost> <1708159137.20110618170200@my_localhost> <879087301.20110618224401@my_localhost> <1376000135.20110619154815@my_localhost> <719370430.20110620014724@my_localhost> Message-ID: >> The point is, if there's no timezone noted down in the >> interval, there is no way to know what the timezone was >> when the person made the signature. We're talking about >> data at rest, that could be interpreted many years >> later, and it'll be difficult to "guess" the timezone >> then. Plus, it shouldn't be a guess anyway. > > We know the timestamp, rounded back to the start of the interval; that > is recorded in the timestamp field. We know the length of the interval > (/P1D, /P1M, or whatever), that will be recorded in the interval > field. Those two pieces of information uniquely define the interval > without the need for guesswork and without the need to know the > signer's local timezone. Wait. Are you assuming my interval will always be YYYY-MM-DD/P1D etc.? How about YYYY-MM-DDT12:00/P1D? >> Right. Local display vs. recording. I'll just summarize >> again: > >> 1. Interval is recorded as an ISO 8601 interval, and >> must be unambiguous (i.e. contain a proper timezone for >> each timestamp). > > As already mentioned, I do not see the need for a timezone. I'm not > against including one if there a need can be demonstrated. See above. >> 2. OpenPGP's timestamp is not changed (seconds since >> epoch UTC). > > Unless the timestamp is rounded back to the start of the interval, it > still reveals (potentially sensitive) information about the signer's > time management. By "not changed" I mean "the interpretation is not changed, the byte format is not changed, etc." -- if the signer wants to round down, they may. This is the loss of accuracy described in the timestamp-interval field. That does not change the precision of the timestamp field, nor does it change the fact that it is seconds since epoch ("UTC", but that is per definition of epoch). >> In terms of moving forward, I think the ISO 8601 >> ambiguity of lower precision in an interval is >> something we need to resolve. Since we're introducing >> the interval to allow for lower precision (e.g. round >> to the start of the day), I think the interval itself >> should have full precision. We would interpret any >> dropped components as zeros/ones resp. ("01" for >> months/days, "00" for hours, minutes, seconds, >> fractional seconds). > > I think that is implicit. You've been arguing that ISO 8601 does not state this implicitly. Or did I misunderstand what you meant with "2010-01-01 can be any time during that day"? > However, what intervals may be allowable? If > the interval is one hour/day/month/year then we round to the start of > the current one. If the interval is one week, which day does the week > start? Do we allow a period of two hours/months etc. and if so, where do > we round back to? What about ten years? Why restrict the intervals that are allowable? Why demand that the implementations should round down? I can use the intervals to describe accuracy, not just to hide my time management. As for P1W, remember that there will be an associated date: "2011-06-16/P1W" is one week, from Thursday to Wednesday. >> 2. Suggestion: timestamp-interval at gnupg.org. > > Somewhere along the line I interpreted the suggestion as adding a > timestamp-interval field to the signature packet, and rounding the > timestamp field down to the start of that interval. No, just a notation. Also, rounding down is something the implementations can do, if they choose to (e.g. through a user option). This does not change the encoding. >> Value is >> an ISO 8601 time interval during which the timestamp >> was made, leaving no room for interpretation of the >> interval, but making it the signer's duty to compute >> this interval. > > You mean actually computing /P > (or alternatively /) and placing > it in a signature notation for each signature or batch of signatures? > Automation would be needed for many people to take this up. Or at the > very least, using long intervals so that the notation needs editing > infrequently. (-; That note about it being the signer's duty doesn't really need to be said. The interval computation must obviously be the signer's duty, as the interval will contain a date. Whether the implementation computes this, the user sets it in the notation explicitly, the user sets a huge interval in the configuration, or something else happens, isn't something we're interested in -- that's the implementation and interface level. However, of course we need to consider this in context. I would say an interval -- as opposed to a duration -- is ideal, as it leaves no room for interpretation. Think "2011-06-20/P1W" vs. timestamp = "2011-06-20T12:00:00Z" and duration = "P1W" -- one is ambiguous as to when the week starts, the other is not (besides the issue of the first example not having a timezone -- is "2011-06-20Z" valid?). >> 2 a. Non-critical. > > Is the effect of this that the interval is simply ignored by an app > that doesn't understand it? Would it look like the signature was > created at the start of the interval or the actual clock time it was > signed? It would look like whatever is in the packet's timestamp field. This could be rounded down, left at the original value, etc. The point with a non-critical notation is that we've had some good arguments against a critical one. For instance, it'll just break all your signatures for current implementations. Another option: "Usually non-critical, but up to the implementation." This way the user/implementation can choose whether or not the interval/inaccuracy is important enough to go in as critical, or if it's just a "helpful note". >> 2 b. Must have a timezone associated for each >> timestamp. "Z", "+0100", etc. As a safe-guard for >> broken implementations, should we assume an implied "Z" >> if there is no timezone? > > Rather than an assumed "Z" we should have a marker that indicates we > do not know the time zone. This is one of those cases where the > technology can't guess for the user. I think the ISO 8601 solution to > ambiguous or unknown timezone is to use "-0000." I didn't understand > how that was different from "+0000" or "Z" when I read it. Wait, ISO 8601 says that if there's no timezone at all, then it's just "local time" (i.e. unknown to us). I would have thought "-0000" is exactly the same as "Z" and "+0000". Are you saying the standard has a different meaning for "-0000"? However, good point. Let's say "Must have a timezone...", but leave it up to the interpretation to inform the user when there is no timezone, or even reject it entirely. The protocol just has to say what's a valid value ("Must have a timezone...") and the implementation can handle "what happens if I get a 'mostly valid' packet?" situations. >> 2 c. Local display/interaction is something the >> implementations will sort out. We recommend at least >> the obvious "canonical" options of local timezone and >> UTC display. > > I would suggest three options: UTC, the local timezone of the user > viewing the signature, and the timezone stated in the interval field. Okay, let's suggest those three. It's advisory anyway, which is all we can demand. >> Practically, after parsing the interval >> into two timestamps, handling would be similar to the >> OpenPGP timestamp field (except that isn't enriched >> with the timezone, which you could use to enhance the >> output). Often enough, this boils down to "whatever the >> locale is configured to do" and that sounds in line >> with *NIX philosophy. > > Fair enough. But if it is simply a signature notation, how/why does it > get parsed at all rather than simply displayed? Are you suggesting the > value recorded in the OpenPGP timestamp field in the signature packet > is rounded back to the start of the interval before recording, or left > intact? Left intact. I would say we parse it because "20110620154236Z/P1D2H1M7S" is not too easy on the eyes. :) It's also the reason why implementations tend to parse the timestamp field and display it as a date, rather than displaying "1308542795". However, it is again up to the implementations. All we specify is what format to use and how to interpret it, input and output interfaces are implementation-specific and we can only advise as to what we think is best for the user/what is most "canonical". -- 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 Mon Jun 20 23:19:13 2011 From: expires2011 at ymail.com (MFPA) Date: Mon, 20 Jun 2011 22:19:13 +0100 Subject: timestamp notation @gnupg.org In-Reply-To: References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161627.13391.mailinglisten@hauke-laging.de> <1302649023.20110617222334@my_localhost> <201106180021.17972.mailinglisten@hauke-laging.de> <895023152.20110618004032@my_localhost> <73411352.20110618132248@my_localhost> <1708159137.20110618170200@my_localhost> <879087301.20110618224401@my_localhost> <1376000135.20110619154815@my_localhost> <719370430.20110620014724@my_localhost> Message-ID: <1717050952.20110620221913@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 20 June 2011 at 5:07:25 AM, in , Jerome Baum wrote: >>> that could be >>> interpreted many years later, and it'll be difficult >>> to "guess" the timezone then. Plus, it shouldn't be a >>> guess anyway. >> We know the timestamp, rounded back to the start of >> the interval; that is recorded in the timestamp field. >> We know the length of the interval (/P1D, /P1M, or >> whatever), that will be recorded in the interval >> field. Those two pieces of information uniquely define >> the interval without the need for guesswork and >> without the need to know the signer's local timezone. > Wait. Are you assuming my interval will always be > YYYY-MM-DD/P1D etc.? Yes. We already said round the timestamp back to the start of the current interval. That would be the beginning of the current hour, or day, month, year, etc. > How about YYYY-MM-DDT12:00/P1D? Or (as previously mentioned) YYYY-MM-DDT23:00/P1D. Somebody with their system set to a different time zone would see those. > By "not changed" I mean "the interpretation is not > changed, the byte format is not changed, etc." -- if > the signer wants to round down, they may. This is the > loss of accuracy described in the timestamp-interval > field. That does not change the precision of the > timestamp field, nor does it change the fact that it is > seconds since epoch ("UTC", but that is per definition > of epoch). Cool. That is what I thought you said before, but the "not changed" confused me. >>> In terms of moving forward, I think the ISO 8601 >>> ambiguity of lower precision in an interval is >>> something we need to resolve. Since we're introducing >>> the interval to allow for lower precision (e.g. round >>> to the start of the day), I think the interval itself >>> should have full precision. We would interpret any >>> dropped components as zeros/ones resp. ("01" for >>> months/days, "00" for hours, minutes, seconds, >>> fractional seconds). >> I think that is implicit. > You've been arguing that ISO 8601 does not state this > implicitly. Or did I misunderstand what you meant with > "2010-01-01 can be any time during that day"? No, I mean that if the interval is (for example) one day, then it is implicit that it means exactly one day plus zero years, zero months, zero hours, etc. >> However, what intervals may be allowable? If the >> interval is one hour/day/month/year then we round to >> the start of the current one. If the interval is one >> week, which day does the week start? Do we allow a >> period of two hours/months etc. and if so, where do we >> round back to? What about ten years? > Why restrict the intervals that are allowable? I don't know. There may be a technical reason we've not thought of. Or it may be desirable for clarity and simplicity. I just thought it appropriate to raise the question. > Why > demand that the implementations should round down? Without rounding it says "I signed this at 11:37 but it could have been any time that day" and with rounding, it simply says "I signed it some time that day." Do you not think "11:37 but it could have been any time that day" will just be perceived as "11:37 that day?" > I > can use the intervals to describe accuracy, not just to > hide my time management. What is the difference? Are they not different motivations to the same end? (Both seek to broaden the interval for a signature time to something longer than the current single second.) > As for P1W, remember that there will be an associated > date: "2011-06-16/P1W" is one week, from Thursday to > Wednesday. Yes, of course. A week can start any day an individual or organisation wants it to. To always pick the associated date as the start of the one-week interval seems wrong to me. It may be appropriate to allow the user to set what day their week starts (or even to allow a random week that starts on the associated date or any of the six previous days). >>> 2. Suggestion: timestamp-interval at gnupg.org. >> Somewhere along the line I interpreted the suggestion >> as adding a timestamp-interval field to the signature >> packet, and rounding the timestamp field down to the >> start of that interval. > No, just a notation. Also, rounding down is something > the implementations can do, if they choose to (e.g. > through a user option). Does the OpenPGP standard allow tying together a signature notation with altering the content of the signature packet (in this case by possibly rounding off the timestamp)? I don't know. > However, of course we need to consider this in context. > I would say an interval -- as opposed to a duration -- > is ideal, as it leaves no room for interpretation. > Think "2011-06-20/P1W" vs. timestamp = > "2011-06-20T12:00:00Z" and duration = "P1W" -- one is > ambiguous as to when the week starts, the other is not I agree that the start of the interval needs to be precisely defined, and so does either the length or the end of that interval. > (besides the issue of the first example not having a > timezone -- is "2011-06-20Z" valid?). "Z" is valid for UTC. Otherwise it's the offset +hhmm or -hhmm. > Another option: "Usually non-critical, but up to the > implementation." This way the user/implementation can > choose whether or not the interval/inaccuracy is > important enough to go in as critical, or if it's just > a "helpful note". Does that option exist with notations, or is it something you would like added? > Wait, ISO 8601 says that if there's no timezone at all, > then it's just "local time" (i.e. unknown to us). I > would have thought "-0000" is exactly the same as "Z" > and "+0000". Are you saying the standard has a > different meaning for "-0000"? Some descriptions on the internet say so but I could not devine a useful meaning. I have not purchased the original document. > However, good point. Let's say "Must have a > timezone...", but leave it up to the interpretation to > inform the user when there is no timezone, or even > reject it entirely. The protocol just has to say what's > a valid value ("Must have a timezone...") and the > implementation can handle "what happens if I get a > 'mostly valid' packet?" situations. The implementation has the timestamp field in the signature packet to refer to, even if rounded, if it doesn't know what to do with the notation. >> Fair enough. But if it is simply a signature notation, >> how/why does it get parsed at all rather than simply >> displayed? Are you suggesting the value recorded in >> the OpenPGP timestamp field in the signature packet is >> rounded back to the start of the interval before >> recording, or left intact? > Left intact. That would preclude this scheme from being used to mask time management. > I would say we parse it because > "20110620154236Z/P1D2H1M7S" is not too easy on the > eyes. :) It's also the reason why implementations tend > to parse the timestamp field and display it as a date, > rather than displaying "1308542795". Fair enough. And an implementation that doesn't know what to do with this notation will display or ignore it. - -- Best regards MFPA mailto:expires2011 at ymail.com Gypsy Dwarf Escapes Prison: Small Medium at large -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJN/7lwnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pQHsEAJCb Dv0h/tHLxvpMbjVCcL/JTMW0ltwTxbqzrx4eNUL0CyDIAKUDQBEmLIGQpbG/oolf Cntm52S9h0g/cf8YaE27MAJ7x5YUDCr0u9oRQ49Czbne2OO8D+KnQpOCZMZEx3D/ jSTMyKiSl3aJXgq/NJsivqj5BFGt9QKxZml/2wFH =XbXQ -----END PGP SIGNATURE----- From lists at chrispoole.com Tue Jun 21 16:25:58 2011 From: lists at chrispoole.com (Chris Poole) Date: Tue, 21 Jun 2011 15:25:58 +0100 Subject: Temporarily remember passphrase? In-Reply-To: <4DD5B57A.7060103@grant-olson.net> References: <4DD5B57A.7060103@grant-olson.net> Message-ID: Thanks. I have gpg 1.4.11 on a Mac. I ended up using the `--multifile` option, without starting gpg-agent directly. It seems to do exactly what I want (presumably doing some caching in the background for me). One small issue, which I can't see from the man page: is there a way to specify the passphrase cache time? I was decrypting a large number of files (> 12,000), and about half way through I was asked for my passphrase again. I assume the cache had expired. On Fri, May 20, 2011 at 1:27 AM, Grant Olson wrote: > On 5/19/2011 7:07 AM, Chris Poole wrote: >> Hi >> >> I often decrypt several files in quick succession (with a simple script). >> >> Is it possible to have gpg remember my passphrase, only very >> temporarily? (Perhaps for 10 seconds or so.) >> >> I've looked into gpg-agent, and tried using the --use-agent option >> with gpg, but I can't find much documentation on the matter, or even >> whether or not this is the best approach. >> > > Yes you want to use gpg-agent. ?What OS are you on? ?You might need to > install gpg2 if you're on Linux or Mac. > > -- > Grant > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > From lane at brooks.nu Thu Jun 23 17:11:37 2011 From: lane at brooks.nu (Lane Brooks) Date: Thu, 23 Jun 2011 09:11:37 -0600 Subject: DH Key Message-ID: <4E0357A9.8030105@gmail.com> I need to generate a 2048-bit PGP version 6.5.3 or later and of the type DH/DSS public key. I have read in the FAQ how to edit the key to be compatible with PGP, but I cannot find how to generate a DH type key. The gnupg on Fedora 15 has the following options when I run gpg2 --gen-key: Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? I compiled the latest 2.0 version myself and it has the same options. I was hoping the configure output would tell me I was missing a DH crypt library, but it didn't. How do I compile DH support into gpg? I cannot find anything on google. Lane From dkg at fifthhorseman.net Thu Jun 23 21:47:23 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 23 Jun 2011 15:47:23 -0400 Subject: DH Key In-Reply-To: <4E0357A9.8030105@gmail.com> References: <4E0357A9.8030105@gmail.com> Message-ID: <4E03984B.8010805@fifthhorseman.net> On 06/23/2011 11:11 AM, Lane Brooks wrote: > I need to generate a 2048-bit PGP version 6.5.3 or later and of the type > DH/DSS public key. I have read in the FAQ how to edit the key to be > compatible with PGP, but I cannot find how to generate a DH type key. > The gnupg on Fedora 15 has the following options when I run gpg2 --gen-key: > > > Please select what kind of key you want: > (1) RSA and RSA (default) > (2) DSA and Elgamal > (3) DSA (sign only) > (4) RSA (sign only) > Your selection? > > I compiled the latest 2.0 version myself and it has the same options. I > was hoping the configure output would tell me I was missing a DH crypt > library, but it didn't. How do I compile DH support into gpg? I cannot > find anything on google. I think you're getting confused by the (admittedly confusing) terminology. DH is Diffie-Hellman, which is a form of anonymous session-key exchange. It is not a public key crypto algorithm, though it can be used in conjunction with public key crypto. DSS is the Digital Signature Standard, which is also known as DSA (the Digital Signature Algorithm). So i think you want either 2 or 3 in the menu above. If you choose 3, you will only have a signing-capable key. That should be fine, if the only requirements you have are that you need a DSS-capable key; DSS is for signatures, not encryption. However, if you want people to be able to encrypt information to you, you'll need to add an encryption capable key. The reasonable choices for that today are either Elgamal (very similar to DSS, but for encryption) or RSA. once your primary key is generated, you can add an encryption-capable subkey with: gpg --edit-key $KEYID addkey (replace $KEYID with the id of your new key, of course). hope this helps, --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 Thu Jun 23 22:05:39 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 23 Jun 2011 13:05:39 -0700 Subject: DH Key In-Reply-To: <4E0357A9.8030105@gmail.com> References: <4E0357A9.8030105@gmail.com> Message-ID: On Thu, 23 Jun 2011 09:11:37 -0600, Lane Brooks wrote: > I need to generate a 2048-bit PGP version 6.5.3 or later and of the type > DH/DSS public key. For reasons I've never been able to understand, PGP insists on calling Elgamal "Diffie-Hellman," and insists on calling the Digital Signature Algorithm ("DSA") the Digital Signature Standard ("DSS"). What PGP calls a DH/DSS key is really a DSA-and-Elgamal key. Hope this helps! From rjh at sixdemonbag.org Thu Jun 23 22:06:58 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 23 Jun 2011 13:06:58 -0700 Subject: DH Key In-Reply-To: <4E03984B.8010805@fifthhorseman.net> References: <4E0357A9.8030105@gmail.com> <4E03984B.8010805@fifthhorseman.net> Message-ID: <57b37675204adce96cb06374fc310c01@localhost> > DSS is the Digital Signature Standard, which is also known as DSA (the > Digital Signature Algorithm). Not quite. DSA can be used with any 160-bit hash, but DSS specifies the use of SHA-1. From dshaw at jabberwocky.com Thu Jun 23 22:24:10 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 23 Jun 2011 16:24:10 -0400 Subject: DH Key In-Reply-To: References: <4E0357A9.8030105@gmail.com> Message-ID: <6EE02A74-4E1D-452B-B71F-3D6507401655@jabberwocky.com> On Jun 23, 2011, at 4:05 PM, Robert J. Hansen wrote: > On Thu, 23 Jun 2011 09:11:37 -0600, Lane Brooks wrote: >> I need to generate a 2048-bit PGP version 6.5.3 or later and of the type > >> DH/DSS public key. > > For reasons I've never been able to understand, PGP insists on calling > Elgamal "Diffie-Hellman," and insists on calling the Digital Signature > Algorithm ("DSA") the Digital Signature Standard ("DSS"). It's one of those historical oddities. Back in the 1990s, Cylink offered the PGP company a free patent license if PGP called Elgamal Diffie-Hellman instead. Cylink was pushing that name for marketing reasons. The name stuck in PGP for the simple reason that it would confuse people if they suddenly saw their keys change type after upgrading to a newer version of PGP. Note that this is only true in the PGP Desktop - PGP command line calls it Elgamal. That which we call a rose by any other name would smell as sweet... David From onemailid4mailinglists at edpnet.be Fri Jun 24 00:42:52 2011 From: onemailid4mailinglists at edpnet.be (Olivier N.) Date: Fri, 24 Jun 2011 00:42:52 +0200 Subject: Error messages when generating new keys In-Reply-To: References: Message-ID: <4E03C16C.1040200@edpnet.be> Hello! I'm a newbie GPG user. I'm using Linux and GPG2. When generating new keys, I get several error messages: gpg: problem with the agent: Bad CA certificate gpg: problem with the agent: Invalid card gpg: Key generation canceled. What mean ?Bad CA certificate? and ?Invalid card?? How can I solve these problems? Thanks in advance for your help! Olivier From hugo.seifert at hushmail.com Sun Jun 26 14:16:04 2011 From: hugo.seifert at hushmail.com (Hugo Seifert) Date: Sun, 26 Jun 2011 12:16:04 +0000 Subject: Problem with faked-system-time option Message-ID: <20110626121604.D99C814DBD4@smtp.hushmail.com> Jerome Baum wrote in message : > >>> if you cheat your employer out of their money, > > > > > > The scenario stated that a fluctuating work volume resulted in periods > > when there was no work to do. Using that time for your own purposes > > does not look to me like cheating your employer. > > In that case you have nothing to fear from your timestamp. > > I personally hold the opinion that you should have a good work > relationship with your employer (including your manager), and > therefore when there is really no work to do, using it for learning > new stuff, or yes even for reading /. or TDWTF, shouldn't lead to a > court case. But, of course, you should discuss with your manager when > there is no work to do, and get their permission first. If you go > ahead and make this decision on your own, then yes you are cheating > your employer -- he might have had work for you to do if only you had > told him there's nothing left. "In that case you have nothing to fear from your timestamp"??? Then why use encryption at all, when we're always honest, don't plan evil things and have nothing to hide, nothing to fear? And there arises the question who is privileged to determine what's evil and what isn't? Protection only to those who comply with your rules sounds like censorship. Do you think GnuPG should only support people who adhere to your social conventions and not OBL hiding in his "cave"? If I understand you correctly, in that case being able to locate the ill-affected originator of a message with the assistance of his signatures' timestamps is acceptable. But how about a U.S. agent acting undercover in enemy territory or someone participating in a Usenet discussion on the HIV disease he suffers from? With such a differentiation you're treading on thin ice, aren't you? I read most of this lengthy thread and wondered why for some it is so hard to accept that there are negative implications of exact timestamps, which is why I venture one further example. Have you ever heard of OmniMix (http://www.danner-net.de/om.htm)? That's a tool aiming at freedom of speech by making it very easy to address onion remailers with your mail and news client software. I use it when posting anonymously to the Usenet, which means with almost all of my newsgroup contributions. No less than 4 years ago in gnupg-devel, message <84uor29d9cc2r9ilnvt5bc16non5elup05 at domain.is.invalid>, its author complained about security risks for not having a chance to alter key and signature timestamps and argued the case for a GnuPG 1.4 -- creation-date option. He wrote : Is there a chance to get an additional GPG option that allows to set : the creation date of keys and signatures? : : I'm developing a Windows proxy server that works as a gateway to anon : remailers and nym servers. For such an application it's mandatory to : disguise all timestamps within messages, as e.g. getting knowledge of : the exact shipping time would make it a lot easier for an adversary to : compromise the author. Currently I see no alternative to a temporary : manipulation of the system time when such sensitive action takes : place. But that strategy entails a lot of potential side effects, : especially in a server environment. If that's no valid reason to add such an option, what else would be? In <87lkjkp7pz.fsf at wheatstone.g10code.de> Werner kindly promised to act, but four years have passed and nothing happened. Or is the agenda behind GnuPG to provide privacy but forget about or even prevent anonymity ignoring the fact that we're living in a world where escaping ubiquitous surveillance becomes harder and harder. Just my 2 cents. Hugo S. From jerome at jeromebaum.com Sun Jun 26 15:40:10 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sun, 26 Jun 2011 15:40:10 +0200 Subject: Problem with faked-system-time option In-Reply-To: <20110626121604.D99C814DBD4@smtp.hushmail.com> References: <20110626121604.D99C814DBD4@smtp.hushmail.com> Message-ID: On Sun, Jun 26, 2011 at 14:16, Hugo Seifert wrote: > Or is the agenda behind GnuPG to provide privacy but forget about or even prevent anonymity (...) Since when was it called "GNU Anonymity Guard"? Last time I checked, it was called "GNU Privacy Guard". -- 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 Sun Jun 26 15:59:36 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 26 Jun 2011 09:59:36 -0400 Subject: Problem with faked-system-time option In-Reply-To: <20110626121604.D99C814DBD4@smtp.hushmail.com> References: <20110626121604.D99C814DBD4@smtp.hushmail.com> Message-ID: <4E073B48.7010909@sixdemonbag.org> On 6/26/11 8:16 AM, Hugo Seifert wrote: > Protection only to those who comply with your rules sounds like > censorship. I hereby invoke Godwin's Corollary. From expires2011 at ymail.com Sun Jun 26 16:37:02 2011 From: expires2011 at ymail.com (MFPA) Date: Sun, 26 Jun 2011 15:37:02 +0100 Subject: Problem with faked-system-time option In-Reply-To: <20110626121604.D99C814DBD4@smtp.hushmail.com> References: <20110626121604.D99C814DBD4@smtp.hushmail.com> Message-ID: <62730804.20110626153702@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 26 June 2011 at 1:16:04 PM, in , Hugo Seifert wrote: > "In that case you have nothing to fear from your > timestamp"??? Then why use encryption at all, We were actually talking about signature timestamps; if the message/data is encrypted but not signed, does it even have a timestamp? > when > we're always honest, don't plan evil things and have > nothing to hide, nothing to fear? And there arises > the question who is privileged to determine what's > evil and what isn't? And also the question about being seeking privacy and/or anonymity to try and hide from another party who is "evil." > Protection only to those who comply with your rules > sounds like censorship. Very much so. > I read most of this lengthy thread and wondered why > for some it is so hard to accept that there are > negative implications of exact timestamps, which is > why I venture one further example. > Have you ever heard of OmniMix > (http://www.danner-net.de/om.htm)? That's a tool > aiming at freedom of speech by making it very easy to > address onion remailers with your mail and news client > software. I use it when posting anonymously to the > Usenet, which means with almost all of my newsgroup > contributions. I have bookmarked that URL and will read another time. Is it easier than using anonymous remailers, etc.? They always looked like a good idea but quite some hassle, so I never got around to trying them. > No less than 4 years ago in gnupg-devel, message > <84uor29d9cc2r9ilnvt5bc16non5elup05 at domain.is.invalid>, > its author complained about security risks for not > having a chance to alter key and signature timestamps > and argued the case for a GnuPG 1.4 -- creation-date > option. > He wrote > : Is there a chance to get an additional GPG option > that allows to set : the creation date of keys and > signatures? : : [snipped] > If that's no valid reason to add such an option, what > else would be? In > <87lkjkp7pz.fsf at wheatstone.g10code.de> Werner kindly > promised to act, but four years have passed and nothing > happened. - --faked-system-time doesn't work, at least in GnuPG 1.4.11 under Windows XP. You can create keys in batch mode and specify the creation and self-signature timestamps but can only create one subkey; as far as I can tell, there is no option to specify the creation time of subsequent signatures or additional subkeys. > Or is the agenda behind GnuPG to provide > privacy but forget about or even prevent anonymity > ignoring the fact that we're living in a world where > escaping ubiquitous surveillance becomes harder and > harder. I can't comment about anybody's "agenda" but in previous discussions, suggestions for hashed UIDs have certainly had a rough ride (for example, see the lengthy thread on this list starting on 28 February 2011 with Message-ID: ). - -- Best regards MFPA mailto:expires2011 at ymail.com Ultimate consistency lies in being consistently inconsistent -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJOB0QYnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pX2MEALQF NIJZ8PRC5A61RcWBKjZzrvAgjoBLwe3Aoxh0QBBAT6gWFau+QtqkXRbmkvYYRu/D UX+z3BD4+6mtBiVPz/jjmXV3h0DA5VdpIzhtFkoUsYwZ5IajMU/bTCzvFQ6prKNA kxr91WaMQuM8Ijb1nUwr+N/CQurNBCMlvsJ1050S =CPXU -----END PGP SIGNATURE----- From lane at brooks.nu Thu Jun 23 22:10:46 2011 From: lane at brooks.nu (Lane Brooks) Date: Thu, 23 Jun 2011 14:10:46 -0600 Subject: DH Key In-Reply-To: References: <4E0357A9.8030105@gmail.com> Message-ID: <4E039DC6.5000206@brooks.nu> On 06/23/2011 02:05 PM, Robert J. Hansen wrote: > On Thu, 23 Jun 2011 09:11:37 -0600, Lane Brooks wrote: >> I need to generate a 2048-bit PGP version 6.5.3 or later and of the type >> DH/DSS public key. > For reasons I've never been able to understand, PGP insists on calling > Elgamal "Diffie-Hellman," and insists on calling the Digital Signature > Algorithm ("DSA") the Digital Signature Standard ("DSS"). > > What PGP calls a DH/DSS key is really a DSA-and-Elgamal key. > > Hope this helps! > Thanks for the reply. I don't know if a lot of people face this issue, but if so, I would recommend putting it in the FAQ. It would supplement the question about PGP that is already in there. This is exactly what I needed to know. Thanks, Lane From gitter at Safe-mail.net Fri Jun 24 23:15:16 2011 From: gitter at Safe-mail.net (gitter at Safe-mail.net) Date: Fri, 24 Jun 2011 17:15:16 -0400 Subject: No subject Message-ID: I am using gpg-agent to manage my github ssh key. I generate my (private) ssh key via openpgp2ssh from my private gpg key. Unfortunately, although my private gpg key is not password protected, gpg-agent asks me for a password (via a nice X dialog) before I ssh to github. Entering nothing works fine, and I can connect to github. ~$ eval "$(gpg-agent --enable-ssh-support --daemon)" ~$ gpg2 --export-secret-keys | openpgp2ssh | ssh-add /dev/stdin Identity added: /dev/stdin (/dev/stdin) ~$ ssh git at github.com PTY allocation request failed on channel 0 Hi xxx! You've successfully authenticated, but GitHub does not provide shell access. Connection to github.com closed. Is there any way I can disable this needless dialog? I am running GNU/Linux; Debian 6; x86_64 - gpg-agent 2.0.14 From DocWebb at e-business-hosting.com Sat Jun 25 20:03:34 2011 From: DocWebb at e-business-hosting.com (Doc Webb) Date: Sat, 25 Jun 2011 11:03:34 -0700 Subject: how encrypt data/text stream instead of a file? Message-ID: Sorry if I am out of line contacting you by email but I didn't see any other way to ask a question. I am a newbie Perl programmer and I want to pipe plain text to GPG and have it return the text encrypted. I have read quite a few articles and came up with this chunk of code on my own BUT it doesn't work and I was wondering if you can tell me what I am doing wrong... my $public_key = "nameofpublickey"; my $plain_text = "this is a test message"; my $gpg_command = '/usr/local/bin/gpg'; open (GPGCOMMAND, "|$gpg_command"); my $encrypted_text = print GPGCOMMAND $plain_text | '$gpg_command -ea -r $public_key'; close (GPGCOMMAND); print "encrypted text=$encrypted_text"; It prints: encrypted text=1 What am I doing wrong? Doc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gitter at Safe-mail.net Sun Jun 26 21:29:23 2011 From: gitter at Safe-mail.net (gitter at Safe-mail.net) Date: Sun, 26 Jun 2011 15:29:23 -0400 Subject: gpg-agent asks for ssh passphrase, although the private key has no passphras set Message-ID: I am using gpg-agent to manage my one and only ssh key. I generate my (private) ssh key via openpgp2ssh from my private gpg key. Unfortunately, although my private gpg key is not password protected, gpg-agent asks me for a passphrase (via a nice X dialog) before I ssh to my server. Entering nothing works fine, and I can connect to the server. ~$ eval "$(gpg-agent --enable-ssh-support --daemon)" ~$ gpg2 --export-secret-keys | openpgp2ssh | ssh-add /dev/stdin Identity added: /dev/stdin (/dev/stdin) ~$ ssh me at myserver.con ... Is there any way I can disable this needless dialog? I am running GNU/Linux; Debian 6; x86_64 - gpg-agent 2.0.14 From jerome at jeromebaum.com Mon Jun 27 14:48:06 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Mon, 27 Jun 2011 14:48:06 +0200 Subject: how encrypt data/text stream instead of a file? In-Reply-To: References: Message-ID: Hey Doc, > Sorry if I am out of line contacting you by email but I didn't see any other > way to ask a question. That's what this mailing list is for. > I am a newbie Perl programmer and I want to pipe plain text to GPG and have > it return the text encrypted. > > I have read quite a few articles and came up with this chunk of code on my > own BUT it doesn't work and I was wondering if you can tell me what I am > doing wrong... > > ??? my $public_key = "nameofpublickey"; > ??? my $plain_text = "this is a test message"; > ??? my $gpg_command = '/usr/local/bin/gpg'; > ??? open (GPGCOMMAND, "|$gpg_command"); > ??? my $encrypted_text = print GPGCOMMAND $plain_text | '$gpg_command -ea -r > $public_key'; > ??? close (GPGCOMMAND); > ??? print "encrypted text=$encrypted_text"; > > It prints: encrypted text=1 > > What am I doing wrong? Seems like a Perl-related issue to me, not a GnuPG-related issue. Basically $encrypted_text is not, as you intended, the output from the gpg -- I think it's the output from print, in this case 1 ("true") for "yes, we managed to pipe this into gpg". I suggest consulting with the appropriate Perl mailing list for how to pipe into a command and get the output. Also consider "--batch" and related options, see . Best, -- 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 -- Q: Why is this email five sentences or less? A: http://five.sentenc.es From wk at gnupg.org Mon Jun 27 15:05:35 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Jun 2011 15:05:35 +0200 Subject: Problem with faked-system-time option In-Reply-To: <7563828B-366B-4D7C-A390-2CCB3155CDB4@JABBERWOCKY.COM> (David Shaw's message of "Thu, 16 Jun 2011 09:58:47 -0400") 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> <87sjrap7rw.fsf@vigenere.g10code.de> <7563828B-366B-4D7C-A390-2CCB3155CDB4@JABBERWOCKY.COM> Message-ID: <87ei2fmnkw.fsf@vigenere.g10code.de> On Thu, 16 Jun 2011 15:58, dshaw at JABBERWOCKY.COM said: > key signature mean? Unless it's marked critical, the web of trust > code in both GPG and PGP will treat those signatures as fully > qualified ones and not just timestamp-only, yet if it is marked This is why one should use a separate key for a timestamping service. I still fail to understand the use case for a timestamp-only key signature. > In this particular case, people seem to want a notation under the > gnupg.org domain, arguing that it will be more likely to be adopted as > the gnupg.org domain lends some cachet. I don't agree with that, but > don't care enough to argue it. That's fine and easy to implement - i.e we don't need anything to implement and don't change any code. Notations are fully supported by gpgme and thus applications may cope with them as they need. If the idea is that those timestamping-only key signatures have some effect on the WoT, I doubt that we want to support them. > In terms of the second part, GPG itself, I don't yet see a need for > any code change, which will have to be written and then maintained in > the code (semi-)indefinitely. Perhaps I'm cynical, but I don't really ACK. Let me add that I view the WoT as an entirely overrated mechanism. It works fine in some (maybe even only in that one hacker) communities but for the broad mass of users (if they will ever adopt OpenPGP) it is irrelevant. Far too complex. If the WoT would be used like X.509 is used by web browsers, we would soon get all the same usual problems as with all global PKIs. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jun 27 15:23:26 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Jun 2011 15:23:26 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: (Jerome Baum's message of "Thu, 16 Jun 2011 19:21:35 +0200") References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161321.14462.mailinglisten@hauke-laging.de> <87fwnaory7.fsf@vigenere.g10code.de> <201106161627.13391.mailinglisten@hauke-laging.de> Message-ID: <87aad3mmr5.fsf@vigenere.g10code.de> On Thu, 16 Jun 2011 19:21, jerome at jeromebaum.com said: > Just so that Werner has a summary of what we've discussed, to base a > decision on. Thanks for that summary. What I miss is a real use case for it. Is there someone implementing a general purpose time stamping service? IIRC, there used to be some 10 years or more ago. Still any? I don't know. How if that is the case, please go ahead, implement it using whatever notation you like and get that service running. gpgme has the features to display such notations, thus you can easily write a check-timestamp application for your service. How if that service is in real use, it might be the time to see whether it is worth an I-D or whether GPG should understand such an notation if - then - marked critical. We have way too many features in OpenPGP and GPG with the majority of them not being used. Adding a yet another new feature should only be done if there is real world need for it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jerome at jeromebaum.com Mon Jun 27 15:31:56 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Mon, 27 Jun 2011 15:31:56 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: <87aad3mmr5.fsf@vigenere.g10code.de> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161321.14462.mailinglisten@hauke-laging.de> <87fwnaory7.fsf@vigenere.g10code.de> <201106161627.13391.mailinglisten@hauke-laging.de> <87aad3mmr5.fsf@vigenere.g10code.de> Message-ID: > What I miss is a real use case for it. ?Is there someone implementing a > general purpose time stamping service? ?IIRC, there used to be some 10 > years or more ago. Still any? ?I don't know. There are a lot of general purpose time stamping services, such as -- though that is the only one I know of that is OpenPGP-based. > We have way too many features in OpenPGP and GPG with the majority of > them not being used. ?Adding a yet another new feature should only be > done if there is real world need for it. I think the timestamp-only notation has a disputable use-case, but timestamp-interval doesn't. If this were added to GnuPG I'd definitely enable it (and probably set the resolution to P1D). The OP gave a very good use case when he started this thread, and we've seen other cases where a fake or lower-resolution timestamp would be useful. While I didn't see/read the ages-old thread that was mentioned before, you allegedly even agreed to implement something roughly equivalent in the past. -- 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 -- Q: Why is this email five sentences or less? A: http://five.sentenc.es From wk at gnupg.org Mon Jun 27 15:59:19 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Jun 2011 15:59:19 +0200 Subject: DH Key In-Reply-To: <4E039DC6.5000206@brooks.nu> (Lane Brooks's message of "Thu, 23 Jun 2011 14:10:46 -0600") References: <4E0357A9.8030105@gmail.com> <4E039DC6.5000206@brooks.nu> Message-ID: <8739ivml3c.fsf@vigenere.g10code.de> On Thu, 23 Jun 2011 22:10, lane at brooks.nu said: > Thanks for the reply. I don't know if a lot of people face this issue, > but if so, I would recommend putting it in the FAQ. It would Done. http://www.gnupg.org/faq/GnuPG-FAQ.html#what-are-dh-dss-keys Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jun 27 16:00:39 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Jun 2011 16:00:39 +0200 Subject: Error messages when generating new keys In-Reply-To: <4E03C16C.1040200@edpnet.be> (Olivier N.'s message of "Fri, 24 Jun 2011 00:42:52 +0200") References: <4E03C16C.1040200@edpnet.be> Message-ID: <87y60nl6go.fsf@vigenere.g10code.de> On Fri, 24 Jun 2011 00:42, onemailid4mailinglists at edpnet.be said: > > I'm a newbie GPG user. I'm using Linux and GPG2. > > When generating new keys, I get several error messages: Please describe exactly what you are doing and what versions of GnuPG are you using. Are you using a smartcard? Which one? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jun 27 16:08:39 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Jun 2011 16:08:39 +0200 Subject: gpg-agent asks for ssh passphrase, although the private key has no passphras set In-Reply-To: (gitter@safe-mail.net's message of "Sun, 26 Jun 2011 15:29:23 -0400") References: Message-ID: <87tybbl63c.fsf@vigenere.g10code.de> On Sun, 26 Jun 2011 21:29, gitter at Safe-mail.net said: > I am using gpg-agent to manage my one and only ssh key. I generate my > (private) ssh key via openpgp2ssh from my private gpg > key. Unfortunately, although my private gpg key is not password > protected, gpg-agent asks me for a passphrase (via a nice X dialog) > before I ssh to my server. Entering nothing works fine, and I the dialog should have asked you to protect your key in the GnuPG system - that is to enter a new passphrase. You have to give that passphrase. It is possible to change that passphrase but there is no direct command line interface for it. However, what you really want is something like ===== default-cache-ttl-ssh 7200 max-cache-ttl-ssh 86400 ===== in ~/.gnupg/gpg-agent.conf. This caches the passphrase for 2 hours if it is not used or even if used for not longer than a day. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From onemailid4mailinglists at edpnet.be Mon Jun 27 19:17:38 2011 From: onemailid4mailinglists at edpnet.be (Olivier N.) Date: Mon, 27 Jun 2011 19:17:38 +0200 Subject: Error messages when generating new keys In-Reply-To: <87y60nl6go.fsf@vigenere.g10code.de> References: <4E03C16C.1040200@edpnet.be> <87y60nl6go.fsf@vigenere.g10code.de> Message-ID: <4E08BB32.9030408@edpnet.be> > Please describe exactly what you are doing and what versions of GnuPG > are you using. Are you using a smartcard? Which one? Hi, What i did: 1. I installed gnupg2 [1] on my linux box [2] 2. I tried "$ gpg2 --gen-key", chose default options and entered my infos (email address, name,?) and I got: gpg: problem with the agent: Bad CA certificate gpg: problem with the agent: Invalid card gpg: Key generation canceled. Am I precise enough or do you need more info, log,?? Thanks in advance for your help! Olivier [1] $ gpg2 --version 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 [2] $ uname -a Linux my-desktop 2.6.38-2-686 #1 SMP Thu Apr 7 05:24:21 UTC 2011 i686 GNU/Linux From wk at gnupg.org Mon Jun 27 20:49:50 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Jun 2011 20:49:50 +0200 Subject: Error messages when generating new keys In-Reply-To: <4E08BB32.9030408@edpnet.be> (Olivier N.'s message of "Mon, 27 Jun 2011 19:17:38 +0200") References: <4E03C16C.1040200@edpnet.be> <87y60nl6go.fsf@vigenere.g10code.de> <4E08BB32.9030408@edpnet.be> Message-ID: <87sjqvjei9.fsf@vigenere.g10code.de> On Mon, 27 Jun 2011 19:17, onemailid4mailinglists at edpnet.be said: > 2. I tried "$ gpg2 --gen-key", chose default options > and entered my infos (email address, name,?) > and I got: > gpg: problem with the agent: Bad CA certificate > gpg: problem with the agent: Invalid card > gpg: Key generation canceled. You are either running a version of gpg-agent which is too old or gpg started that version of gpg-agent but expected another one. Or there is another daemon taking over the connection between gpg2 and gpg-agent. Seahorse as well as the gnome-keychain(?) used to do this (which is something they should not do). Adding the options "--verbose --debug 2048" to the command line may give you some more insight. Make sure all gpg-agent's are stopped. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gitter at Safe-mail.net Mon Jun 27 19:36:21 2011 From: gitter at Safe-mail.net (gitter at Safe-mail.net) Date: Mon, 27 Jun 2011 13:36:21 -0400 Subject: gpg-agent asks for ssh passphrase, although the private key has no passphras set Message-ID: > On Sun, 26 Jun 2011 21:29, gitter at Safe-mail.net said: > > > I am using gpg-agent to manage my one and only ssh key. I generate my > > (private) ssh key via openpgp2ssh from my private gpg > > key. Unfortunately, although my private gpg key is not password > > protected, gpg-agent asks me for a passphrase (via a nice X dialog) > > before I ssh to my server. Entering nothing works fine, and I > > the dialog should have asked you to protect your key in the GnuPG system > - that is to enter a new passphrase. You have to give that passphrase. Ah, that is right. > It is possible to change that passphrase but there is no direct command > line interface for it. However, what you really want is something like > > ===== > default-cache-ttl-ssh 7200 > max-cache-ttl-ssh 86400 > ===== > > in ~/.gnupg/gpg-agent.conf. This caches the passphrase for 2 hours if > it is not used or even if used for not longer than a day. I already use these long caching options for ssh. Actually what I want is not to enter a passphrase for my ssh key. I trust the applications that run on my system, so I do not want any passphrase. From wk at gnupg.org Tue Jun 28 09:06:13 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jun 2011 09:06:13 +0200 Subject: gpg-agent asks for ssh passphrase, although the private key has no passphras set In-Reply-To: (gitter@safe-mail.net's message of "Mon, 27 Jun 2011 13:36:21 -0400") References: Message-ID: <87k4c6juze.fsf@vigenere.g10code.de> On Mon, 27 Jun 2011 19:36, gitter at Safe-mail.net said: > I already use these long caching options for ssh. Actually what I want > is not to enter a passphrase for my ssh key. I trust the applications > that run on my system, so I do not want any passphrase. With the current stable version of GnuPG it is a bit complicated: You need to figure out the "keygrip" of the key. With GnuPG-2.1 it would be a simple $ gpg2 -K --with-keygrip alpha at example.net sec 1024D/68697734 1999-03-08 Keygrip = 76F7E2B35832976B50A27A282D9B87E44577EB66 uid Alfa Test (demo key) uid Alpha Test (demo key) uid Alice (demo key) ssb 1024g/46A871F8 1999-03-08 Keygrip = A0747D5F9425E6664F4FFBEED20FBCA79FDED2BD Which shows the keygrip for each key. Now if you know which key has been converted to ssh, you do this: gpg-connect-agent 'passwd 76F7E2B35832976B50A27A282D9B87E44577EB66' /bye and follow the prompt: Enter the old passphrase and then enter a empty passphrase. The last popup will ask you whether you really want an unprotected key and you confirm that. With any version of GnuPG you need to figure out the key by looking at the file "~/.gnupg/sshcontrol". This file has a line for each ssh key; ssh-add also adds a comment with the date the key was added to GnuPG. You will immediately spot the keygrip. Use this as described above. Note that for keys stored on a smartcard there will be no entry in the sshcontrol file. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jun 28 09:13:12 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jun 2011 09:13:12 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: (Jerome Baum's message of "Mon, 27 Jun 2011 15:31:56 +0200") References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161321.14462.mailinglisten@hauke-laging.de> <87fwnaory7.fsf@vigenere.g10code.de> <201106161627.13391.mailinglisten@hauke-laging.de> <87aad3mmr5.fsf@vigenere.g10code.de> Message-ID: <87fwmujunr.fsf@vigenere.g10code.de> On Mon, 27 Jun 2011 15:31, jerome at jeromebaum.com said: > While I didn't see/read the ages-old thread that was mentioned before, > you allegedly even agreed to implement something roughly equivalent in > the past. Did I? I only recall that once I changed the generation code to make sure the timestamp of the self-signatures, the primary key and the subkeys are all the same. GnuPG knows only about two notation data keys: preferred-email-encoding at pgp.com This does nothing except that an application is able to query it. We need to put it in GPG only so that it may be marked as criticial; there is no use for it in GPG proper; MUAs may need it though (and need to handle the critical flag then). pka-address at gnupg.org This is used by GPG for its PKA key retrieval/trust system Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jerome at jeromebaum.com Tue Jun 28 11:56:25 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Tue, 28 Jun 2011 11:56:25 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: <87fwmujunr.fsf@vigenere.g10code.de> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161321.14462.mailinglisten@hauke-laging.de> <87fwnaory7.fsf@vigenere.g10code.de> <201106161627.13391.mailinglisten@hauke-laging.de> <87aad3mmr5.fsf@vigenere.g10code.de> <87fwmujunr.fsf@vigenere.g10code.de> Message-ID: >> While I didn't see/read the ages-old thread that was mentioned before, >> you allegedly even agreed to implement something roughly equivalent in >> the past. > > Did I? ?I only recall that once I changed the generation code to make > sure the timestamp of the self-signatures, the primary key and the > subkeys are all the same. As I said, I didn't read the thread. How about the use cases I presented? Any problems with those? -- 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 -- Q: Why is this email five sentences or less? A: http://five.sentenc.es From wk at gnupg.org Tue Jun 28 15:36:55 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jun 2011 15:36:55 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: (Jerome Baum's message of "Tue, 28 Jun 2011 11:56:25 +0200") References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161321.14462.mailinglisten@hauke-laging.de> <87fwnaory7.fsf@vigenere.g10code.de> <201106161627.13391.mailinglisten@hauke-laging.de> <87aad3mmr5.fsf@vigenere.g10code.de> <87fwmujunr.fsf@vigenere.g10code.de> Message-ID: <87tybahybs.fsf@vigenere.g10code.de> On Tue, 28 Jun 2011 11:56, jerome at jeromebaum.com said: > How about the use cases I presented? Any problems with those? timestamp-interval at gnupg.org I assume. I tried to find the first reference of it, but several pages of mails indented so that they even don't show up on my screen without scrolling to the right inhinited that. In particular I don't known what you mean by P1D. So what about a simple option to create all created timestamps with a time of either 00:00:00 or the creation time of the key? I don't think that there is a point in having a flag indicating such a faked timestamp. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jerome at jeromebaum.com Tue Jun 28 15:43:46 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Tue, 28 Jun 2011 15:43:46 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: <87tybahybs.fsf@vigenere.g10code.de> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161321.14462.mailinglisten@hauke-laging.de> <87fwnaory7.fsf@vigenere.g10code.de> <201106161627.13391.mailinglisten@hauke-laging.de> <87aad3mmr5.fsf@vigenere.g10code.de> <87fwmujunr.fsf@vigenere.g10code.de> <87tybahybs.fsf@vigenere.g10code.de> Message-ID: > timestamp-interval at gnupg.org I assume. ?I tried to find the first > reference of it, but several pages of mails indented so that they even > don't show up on my screen without scrolling to the right inhinited > that. ?In particular I don't known what you mean by P1D. Well the notation, as you say, wouldn't need to be coded into gpg -- it already supports notations. This is more about choosing an arbitrary timestamp. > So what about a simple option to create all created timestamps with a > time of either 00:00:00 or the creation time of the key? ?I don't think > that there is a point in having a flag indicating such a faked timestamp. Why limit the choices to 0 and key creation time? How about just an option "--set-timestamp=" that sets the timestamp? Is that easy to do? -- 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 -- Q: Why is this email five sentences or less? A: http://five.sentenc.es From wk at gnupg.org Tue Jun 28 16:00:50 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 28 Jun 2011 16:00:50 +0200 Subject: timestamp notation @gnupg.org In-Reply-To: (Jerome Baum's message of "Tue, 28 Jun 2011 15:43:46 +0200") References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161321.14462.mailinglisten@hauke-laging.de> <87fwnaory7.fsf@vigenere.g10code.de> <201106161627.13391.mailinglisten@hauke-laging.de> <87aad3mmr5.fsf@vigenere.g10code.de> <87fwmujunr.fsf@vigenere.g10code.de> <87tybahybs.fsf@vigenere.g10code.de> Message-ID: <87liwmhx7x.fsf@vigenere.g10code.de> On Tue, 28 Jun 2011 15:43, jerome at jeromebaum.com said: > Why limit the choices to 0 and key creation time? How about just an > option "--set-timestamp=" that sets the timestamp? Is that easy > to do? It is some work because we need to figure out the lower limit for the timestamp for each sign operation. Consider that it is possible to sign with several keys and in that case we better use the same timestamp for each signature. And a signature should never be older than the key or newer than the expiration date. You may want to add a feature request to the BTS. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hugo.seifert at hushmail.com Tue Jun 28 20:13:48 2011 From: hugo.seifert at hushmail.com (Hugo Seifert) Date: Tue, 28 Jun 2011 18:13:48 +0000 Subject: Problem with faked-system-time option Message-ID: <20110628181348.E94D2A6E3C@smtp.hushmail.com> On Sun, 26 Jun 2011 13:40:10 +0000 Jerome Baum wrote: > On Sun, Jun 26, 2011 at 14:16, Hugo Seifert > wrote: > > Or is the agenda behind GnuPG to provide privacy but forget > about > or even prevent anonymity (...) > > Since when was it called "GNU Anonymity Guard"? Last time I > checked, > it was called "GNU Privacy Guard". What's in a name? GnuPG already cares about anonymity interests: On Fri, Aug 21 1998 18:14:44 CEST, Nimrod Zimerman wrote: : A GNUPG patch to enable anonymous encrypted messages : : Hello. : : Below is a patch to GNUPG that allows removing the keyid from encrypted : packets (such that one can't know who an encrypted packet is destinated : to), and, obviously, allows decrypting such packets (supplying the : appropriate userid on the command line). : : Why is this needed? Privacy. When sending an encrypted message via a named : channel (such as 'regular' e-mail), revealing the destination of the : message is something you can't really avoid, and hence the keyid on the : encrypted message doesn't matter. However, when sending a message via an : anonymous channel (through a remailer to a newsgroup, for example), adding : the keyid on the encrypted message is fairly counter productive. It might : not provide potential adversaries the ability to know who can read the : message - but it certainly helps, even if only by aiding in traffic : analysis. : : The solution is quite simple - avoid adding the keyid to encrypted messages : (packets in those messages). This is exactly what the patch does, using : the command-line switch '--throw-keyid'. : ... Won't you agree, that a method to alter signature timestamps is a perfect complement to the --throw-keyid option introduced back then? Therewith a correct signature timestamp can no longer counteract the random latency remailers add to the mail delivery time. Hugo S. From rjh at sixdemonbag.org Tue Jun 28 21:18:48 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 28 Jun 2011 12:18:48 -0700 Subject: Problem with faked-system-time option In-Reply-To: <20110628181348.E94D2A6E3C@smtp.hushmail.com> References: <20110628181348.E94D2A6E3C@smtp.hushmail.com> Message-ID: <676d76ceec34df49c6a965c9fc158af0@localhost> > What's in a name? GnuPG already cares about anonymity interests: Just because GnuPG has adopted some feature requests to facilitate anonymity does not mean GnuPG will, or even should, adopt other feature requests for the same. If I buy you a beer I'm not obligated to buy you dinner. Ultimately, if this is important to you then you have two choices: convince someone to write the patches for you, or else write the patches yourself. If you're unable to convince others to do it, then start teaching yourself C. From expires2011 at ymail.com Tue Jun 28 22:01:39 2011 From: expires2011 at ymail.com (MFPA) Date: Tue, 28 Jun 2011 21:01:39 +0100 Subject: timestamp notation @gnupg.org In-Reply-To: <87tybahybs.fsf@vigenere.g10code.de> References: <20110603193259.4C19B8C069@nym.dizum.nl> <201106161321.14462.mailinglisten@hauke-laging.de> <87fwnaory7.fsf@vigenere.g10code.de> <201106161627.13391.mailinglisten@hauke-laging.de> <87aad3mmr5.fsf@vigenere.g10code.de> <87fwmujunr.fsf@vigenere.g10code.de> <87tybahybs.fsf@vigenere.g10code.de> Message-ID: <455059136.20110628210139@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 28 June 2011 at 2:36:55 PM, in , Werner Koch wrote: > particular I don't known what you mean by P1D. ISO 8601 Data elements and interchange formats ? Information interchange ? Representation of dates and times P is the duration designator (historically called "period") placed at the start of the duration representation. D is the day designator that follows the value for the number of days. So YYYY-MM-DDThh:mm:ss/P1D is the period of one day starting from YYYY-MM-DDThh:mm:ss. See (for example) http://en.wikipedia.org/wiki/ISO_8601 > So what about a simple option to create all created > timestamps with a time of either 00:00:00 or the > creation time of the key? By "00:00:00" do you mean 00:00:00? I like that, as it doesn't broadcast detailed time management in the signature timestamps. Somebody in a time zone an hour behind the signer's might see 23:00:00, but that doesn't really matter IMHO. The creation time of the key as the signature timestamp looks a good option to me; simple and fairly obviously fake. > I don't think that there is > a point in having a flag indicating such a faked > timestamp. The user could indicate such with signature notations if they wished. "timestamp-interval at example.com = P1D" would seem to fit the "00:00:00" option. Maybe something like "fake-timestamp at example.com = key creation time" for that option. Or whatever they wanted, of course... - -- Best regards MFPA mailto:expires2011 at ymail.com Dreams come true on this side of the Rainbow too! -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJOCjNAnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pDgEEAKQj sqyJ/AbTbDAever5ygU5WfhzHyGycMLPFpK5QxdeF1FeTW7SPWLH5SyRMZQsXnps P7JMZnUdF06bg3G34pvsXnYXnAIvJvchuPsG4+29BcaZrLJKhmeGBLJLNBWHh/1A WYnYtPB0qUPiK0TAtI0pVUYz6cHAspvBkkEXJlRQ =u57j -----END PGP SIGNATURE----- From wk at gnupg.org Wed Jun 29 12:18:34 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jun 2011 12:18:34 +0200 Subject: [Announce] Libgcrypt 1.5.0 released Message-ID: <874o39hret.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.5.0. This is the new stable version of Libgcrypt and upward compatible with the 1.4 series. The 1.4 series will enter end of life state on 2012-12-31. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes between version 1.4.6 and 1.5.0: * New function gcry_kdf_derive implementing OpenPGP S2K algorithms and PBKDF2. * Support for WindowsCE. * Support for ECDH. * Support for OAEP and PSS methods as described by RFC-3447. * Fixed PKCS v1.5 code to always return the leading zero. * New format specifiers "%M" and "%u" for gcry_sexp_build. * Support opaque MPIs with "%m" and "%M" in gcry_sexp_build. * New functions gcry_pk_get_curve and gcry_pk_get_param to map ECC parameters to a curve name and to retrieve parameter values. * gcry_mpi_cmp applied to opaque values has a defined semantic now. * Uses the Intel AES-NI instructions if available. * The use of the deprecated Alternative Public Key Interface (gcry_ac_*) will now print compile time warnings. * *The module register subsystem has been deprecated.* This subsystem is not flexible enough and would always require ABI changes to extend the internal interfaces. It will eventually be removed. Please contact us on the gcrypt-devel mailing list to discuss whether you really need this feature or how it can be replaced by an internal plugin mechanism. * CTR mode may now be used with data chunks of arbitrary length. * Interface changes relative to the 1.4.6 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GCRY_PK_ECDH NEW. gcry_pk_get_curve NEW. gcry_pk_get_param NEW. GCRYCTL_DISABLE_HWF NEW. gcry_kdf_derive NEW. gcry_pk_encrypt EXTENDED: Support OAEP. gcry_pk_decrypt EXTENDED: Support OAEP. gcry_pk_sign EXTENDED: Support PSS. gcry_pk_verify EXTENDED: Support PSS. gcry_sexp_build EXTENDED: Add format specifiers M and u. Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signatures is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.bz2 (1400k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.gz (1698k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.gz.sig Due to a lot of changes regarding white spaces we don't provide a patch file against 1.4.6. The SHA-1 checksums are: e6508315b76eaf3d0df453f67371b106654bd4fe libgcrypt-1.5.0.tar.gz 3e776d44375dc1a710560b98ae8437d5da6e32cf libgcrypt-1.5.0.tar.bz2 For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. Improving Libgcrypt is costly, but you can help! We are looking for organizations that find Libgcrypt useful and wish to contribute back. You can contribute by reporting bugs, improve the software [2], order extensions or support or more general by donating money to the Free Software movement [3]. Commercial support contracts for Libgcrypt are available [4], and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company, is currently funding Libgcrypt development. We are always looking for interesting development projects. Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See . [2] Note that copyright assignments to the FSF are required. [3] For example see . [4] See the service directory at . -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 207 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From kloecker at kde.org Wed Jun 29 22:49:07 2011 From: kloecker at kde.org (Ingo =?iso-8859-1?q?Kl=F6cker?=) Date: Wed, 29 Jun 2011 22:49:07 +0200 Subject: GnuPG language setting In-Reply-To: <4DE4DBBA.6040801@iki.fi> References: <4DDD3BF6.9090402@iki.fi> <4DE407E2.9030907@gmail.com> <4DE4DBBA.6040801@iki.fi> Message-ID: <201106292249.08113@thufir.ingo-kloecker.de> On Tuesday 31 May 2011, Janne Inkil? wrote: > 31.5.2011 0:10, M.R. kirjoitti: > > I wish application developers would understand > > a simple fact: language choice can't be computer-wide, > > it must be *application specific*. > > In my case it is very hard to find the place where to change this > setting in os. I know I can override this with lang=en env setting. I > have checked all the settings in Windows 7 control panel and made > some digging in to the registry, but failed so far. Are you looking for the place where you can change environment variables? Did you try the quick search in Windows 7's start menu? Or are you looking for a different place? Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From Thomas.Chandler at gsprecision.com Thu Jun 30 18:56:13 2011 From: Thomas.Chandler at gsprecision.com (Chandler, Thomas) Date: Thu, 30 Jun 2011 12:56:13 -0400 Subject: outlook email help Message-ID: <0431A87C5C0DDF4FB0CC68DD49ABC5F7A8991303@mailman> I have two users that have Gpg4win installed on their machines and they are running into a problem when they rightclick on a file, choose send to, and then after they send the email, it goes into the outbox and stays there. I have also noticed that when you open the email in the outbox, the recipient field is empty, but once they put the recipient in a second time, and click send, the email will send. It is important as far as productivity goes that I can get these users to use the rightclick on a file, and send to functionality. I have done testing, and only the machines that have pgp4win on them are having this problem, nobody else is, so I have narrowed it down to pgp4win. Does anyone know what I can do to make this work? Thank you very much! It's outlook 2007 sp2 PGP4WIN version 2.0.4 Thomas Chandler Desktop Support Engineer G.S.Precision, Inc. 101 John Sietz Drive Brattleboro, VT. 05301 802.246.5451 Direct / 802.246.5456 Fax ________________________________ This communication and any files or attachments transmitted with it may contain information that is part of a confidential communication or may otherwise be privileged and exempt from disclosure under applicable law. It is intended solely for the use of the individual or entity to which it was addressed. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, or copying of this communication is prohibited by law. If you have received this communication in error, please delete it from your email system and notify us immediately at (802) 257-5200 x5450 or via email at NetAdmin at GSPrecision.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: