Re: Retaining expired sigs
On Sat, Mar 19, 2005 at 01:24:13AM -0500, David Shaw wrote: On Sat, Mar 19, 2005 at 12:22:54AM -0500, Jason Harris wrote: c) Always keep the latest (valid) signature from a given issuer, even if it has expired. Remember that the original thing that spawned this thread was the desire to keep expired signatures from clogging keys. In the case where the latest signature is expired, you don't need to keep *any* signatures. Using your desired semantics (superceding), the most That is not very defensive. If an unsynchronized keyserver is used, a old copy of the key with only the unsuperceded sig(s) can be returned. Why open yourself to essentially a replay attack when you've already seen and can easily save certain strategic signatures from each issuer? Also, my desired semantics require keeping non-revocable sigs. (See below.) Per draft-ietf-openpgp-rfc2440bis-12.txt, section 5.2.3.3, I think the intent is clear that an expired selfsig on a userid is the same as a revoked selfsig on a userid. There is no reason for this not to apply to non-selfsigs as well. Keep reading to the end of 5.2.3.3. The draft, in fact, intentionally does not answer the question of multiple self-sigs. There is some advice about interpreting selfsigs as narrowly as possible, and biasing towards more recent, but An implementation that encounters multiple self-signatures on the same object may resolve the ambiguity in any way it sees fit means pretty much what it says. I'm not adverse to changing the code to implement superceding, but I don't think you can (or really need to) rationalize it from 2440bis. ... I think it is understood that pubkeys and subkeys cannot be unrevoked after being revoked and non-revocable signatures cannot be revoked after being created, but otherwise anything can be superceded. Remember that OpenPGP does not really specify validity semantics. Unfortunately (or fortunately depending on how you look at it), some semantics have crept into what is supposedly just a message format document. In fact, this is another grey area: subkeys can theoretically be unrevoked by issuing a new binding signature, just like user IDs can. GnuPG doesn't do this for simplicity, but that's an implementation choice, and not specified (either way) in the standard. Another quote from the document is in order, then: This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. I maintain that it misses its stated goals of leading to interoperable applications and avoiding security flaws insofar as it leaves the sub- jects of expired and superceded signatures untreated. The RFC fails to directly address the issue of a non-revocable sig. being superceded by a revocable one which is then revoked, however. In the strictest sense, non-revocable sigs cannot be undone, period, by any mechanism. This is certainly needed when a selfsig specifies a designated revoker, but I think it is good to treat all other non- revocable sigs as backups or fallbacks that can be superceded temporarily but always return as standing orders until superceded again. If this is not (to be) the case, then non-revocable sigs should really be called non-modifiable sigs. Grey area again. I happen to agree with part of what you say (non-revocable sigs can be superceded), but this is not specified in the standard anywhere. OK. Dragging the conversation out of the standard and into implementation details for a moment, I'm rather inclined to change the expired-sigs trimming code to implement the change (d) from above. It's consistent and safe from signature resurrection problems. [moved from above] d) When stripping a signature, strip all earlier signatures from that particular issuer. This will be safe iff the last (valid) sig. from a given issuer supercedes all previous sigs from that issuer, and, if expired, expires all previous sigs from that issuer, and, if a revocation signature, revokes all previous (even non-revocable) sigs from that issuer. (NB: Clearly, I don't think that last requirement can be met given even the most liberal interpretation of draft-ietf-openpgp-rfc2440bis-12.txt. Without meeting all these requirements, you have to at least keep the non-revocable sigs too.) Unless non-revocable userid cert. sigs are undone when newer revocable and/or expirable sigs that supercede them are undone (which neither of us agree with, correct?), you should keep the non-revocable sigs so they will take effect again
Re: Retaining expired sigs
On Sat, Mar 19, 2005 at 02:26:07PM -0500, David Shaw wrote: I agree. It's not just expired and superceded signatures. There are a good number of other semantic questions that are not covered in 2440 or 2440bis. For example, the so-called PGP trust model is not covered anywhere. This is historical: the original plan for the IETF group was that there would be multiple specifications (a message format document, a trust model document, etc). Unfortunately, only the message format document was written, and it became 2440. That explains a lot. Thanks. about the same thing. Given this case: non-revocable sig1-Jan-2000 revocable sig2-Jan-2000 revocation 3-Jan-2000 One way of looking at this is the end result is nothing. That is, the revocable sig of 2-Jan-2000 has superceded the non-revocable sig of 1-Jan-2000, and then the revocation has revoked the sig of 2-Jan-2000. There are no valid sigs left, and all three can be disregarded. This would be letting the non-revocable sig. be indirectly revoked, which I don't believe anyone is advocating. Another way of looking at this is that the revocable sig of 2-Jan-2000 has not superceded the non-revocable sig of 1-Jan-2000. The revocation of 3-Jan-2000 has revoked the sig of 2-Jan-2000, which leaves the non-revocable sig of 1-Jan-2000 as valid and usable. This is what I am advocating. Now try this case: non-revocable sig1-Jan-2000 expired sig 2-Jan-2000 (expired 3-Jan-2000) One answer here is that the expired sig of 2-Jan-2000 has superceded the nonrevocable sig of 1-Jan-2000. The end result is nothing and both sigs can be discarded. Another answer is that 2-Jan-2000 has expired, which leaves the sig of 1-Jan-2000 as valid and usable. What are you arguing for? The sig. of 1-Jan-2000 is valid and usable. It can only be ignored when superceded. Also, if multiple non-revocable sigs. exist, the latest (valid) one supercedes all others, which can be safely removed. -- Jason Harris | NIC: JH329, PGP: This _is_ PGP-signed, isn't it? [EMAIL PROTECTED] _|_ web: http://keyserver.kjsl.com/~jharris/ Got photons? (TM), (C) 2004 pgpVNg7i7cAO6.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Changing Home Directory of GPG - Was
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Servie Platon wrote: Hi Mr. Clizbe, --- John Clizbe [EMAIL PROTECTED] wrote: Thank you very much for the help. cd C:\GnuPG copy *.gpg %APPDATA%\GnuPG (Up to this step) copy gpg.conf %APPDATA%\GnuPG (Error here, it appears that gpg.conf is not present) exit If there is no gpg.conf file in your old home directory, C:\GnuPG, it could be under the old name 'options' or somethinf similar. It not, there are instructions on the Enigmail GnuG for Windows users page (http://enigmail.mozdev.org/gpgconf.html). C:\Documents and Settings\serviegpg --version gpg: error loading `iconv.dll': The specified module could not be found. Run the installer again and iconv.dll will be restored. or download it fron the GnuPG.org ftp site ftp://ftp.gnupg.org/gcrypt/binary/libiconv-1.9.1.dll.zip (644k) ftp://ftp.gnupg.org/gcrypt/binary/libiconv-1.9.1.dll.zip.sig Home: C:/Documents and Settings/servie/Application Data/GnuPG (Seems fine here except for the iconv.dll problem which I deleted before). Should I reconstruct again the iconv.dll file and restore all the entries as stated in the gpg.conf file? See above regarding iconv.dll. A starter gpg.conf would be: default-key 0xDecafBAD --- replace with YOUR key ID default-recipient-self keyserver random.sks.keyserver.penguin.de keyserver-options auto-key-retrieve include-subkeys include-revoked no-secmem-warning Again, thank you very much. You're most welcome. - -- John P. Clizbe Inet: John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10 what's the key to success?/ two words: good decisions. what's the key to good decisions? / one word: experience. how do i get experience? / two words: bad decisions. Just how do the residents of Haiku, Hawai'i hold conversations? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: When cryptography is outlawed, b25seSBvdXRsYXdzIHdpbGwgdXNlIG Comment: Be part of the £33t ECHELON -- Use Strong Encryption. Comment: It's YOUR right - for the time being. Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCPKv/HQSsSmCNKhARAtu1AJ44ansmufNYK4OADopFKL60p9g0sQCfe51g PFolzyTVGXFVZuITQjZQZxk= =sGSK -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Retaining expired sigs
On Sat, Mar 19, 2005 at 03:25:32PM -0500, Jason Harris wrote: about the same thing. Given this case: non-revocable sig1-Jan-2000 revocable sig2-Jan-2000 revocation 3-Jan-2000 One way of looking at this is the end result is nothing. That is, the revocable sig of 2-Jan-2000 has superceded the non-revocable sig of 1-Jan-2000, and then the revocation has revoked the sig of 2-Jan-2000. There are no valid sigs left, and all three can be disregarded. This would be letting the non-revocable sig. be indirectly revoked, which I don't believe anyone is advocating. Another way of looking at this is that the revocable sig of 2-Jan-2000 has not superceded the non-revocable sig of 1-Jan-2000. The revocation of 3-Jan-2000 has revoked the sig of 2-Jan-2000, which leaves the non-revocable sig of 1-Jan-2000 as valid and usable. This is what I am advocating. Good. Then we agree. What's more, there is nothing to change. GnuPG already effectively works this way (see below). Now try this case: non-revocable sig1-Jan-2000 expired sig 2-Jan-2000 (expired 3-Jan-2000) One answer here is that the expired sig of 2-Jan-2000 has superceded the nonrevocable sig of 1-Jan-2000. The end result is nothing and both sigs can be discarded. Another answer is that 2-Jan-2000 has expired, which leaves the sig of 1-Jan-2000 as valid and usable. What are you arguing for? The sig. of 1-Jan-2000 is valid and usable. It can only be ignored when superceded. I agree with your general idea here, but not the details, exactly. What GnuPG does in this case is to take the 1-Jan-2000 signature and ignore any that follow. I don't like the idea of a signature that is temporarily superceded. Either it is superceded (and can be removed) or it is not. It's a bit of a distinction without a difference, really. The end result is basically the same, but the rationale is different. Also, if multiple non-revocable sigs. exist, the latest (valid) one supercedes all others, which can be safely removed. Ok, I buy this. I'll change the unusable sig filter to remove earlier sigs in a series when filtering. It's a little different than the current implementation since this would allow a newly imported signature to cause older signatures already on the keyring to disappear (say, if an expired signature was imported that dated after all the signatures that were already present). David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
