On Fri, Mar 18, 2005 at 02:37:33PM -0500, David Shaw wrote: > On Fri, Mar 18, 2005 at 02:06:46PM -0500, Jason Harris wrote:
> > My point is that once GPG sees a newer signature that overrides an > > older one, it can safely remove the older one, in all cases, in the > > interest of keeping keys clean. (Of course, the newest sig. should > > be valid, and the older sigs should be checked for validity as well, > > lest we run into a long keyid collision.) > > I don't disagree with this. It's not unreasonable to remove them, but > it doesn't happen that way today. The problem at hand was expired > sigs, so that is what I addressed. > > Removing superceded signatures, however, re-raises the semantic > questions I asked in my last mail. What algorithm runs first: the > "remove superceded" or "remove expired"? Depending on which runs > first, you can get a different result. Indeed, why is why the correct answer is: c) Always keep the latest (valid) signature from a given issuer, even if it has expired. Sigs (esp. revocations) with targets should always be kept, too, lest their targets resurface alone and therefore unmodified. > > > It gets messy very fast: if I sign a key with no expiration, then sign > > > it again with an expiration, then the second signature expires - is my > > > original signature still valid? Maybe I actually revoked the first > > > > By your own explanation above, no. > > But should it be? My point is not to say that such-and-such is the > answer. My point is to say that it is not at all clear what the > answer should be. I may take some time this weekend and run a few > test cases against other OpenPGP implementations to see what they do. Hopefully they will behave as I describe above. > > Therein lies the problem: GPG, by removing expired signatures > > (at all), is removing history. As you point out, this can lead > > to problems when the expired signatures are no longer available > > to supercede earlier, unexpired signatures. > > Only if the right behavior is that expired signatures *should* > supercede earlier, unexpired signatures. 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. Section "0x30: Certification revocation signature" mentions (non- targetted) 0x30 revocations as applying to "an earlier" sig. It also says: "The signature should have a later creation date than the signature it revokes." I believe it is generally understood that "all earlier" sigs are affected by non-targetted 0x30 sigs. Section 5.2.3.12 (non-revocable flag/subpacket) is very specific that no revocations apply to non-revocable signatures. However, it mentions nothing of non-revocable sigs being superceded. (Gah! "key holder" and "keyholder" are both used in the draft.) > If the answer is that expired signatures should supercede, then the > current implementation of the expired sigs filter is insufficient - it > needs to remove the earlier sigs as well to avoid re-awakening an old Actually, GPG needs to retain the latest valid sig., even if it has expired, so that it will be around to take precedence over older sigs. > signature. If the answer is that expired signatures should not > supercede, then the current implementation is correct. > > Which do you favor (and why)? Does every sig stand alone, or can sigs > only be interpreted in terms of a series? > > I vaguely lean towards the idea that expired signatures should not > supercede earlier unexpired signatures (the "sigs stand alone" > answer), but only vaguely. I find the simplicity of it attractive. > Interpreting sigs in a series raises a number of dangerous problems, > like what happens when a sig is "unrevoked" by an attacker by removing > packets from the key. 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. 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. -- 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
pgpWu7Sf3nFzT.pgp
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users