On Sat, Mar 19, 2005 at 12:02:45PM -0500, Jason Harris wrote: > 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.)
This troubles me a bit, as it is getting into packet manipulation games. It's hard to say which packets an unsynchronized keyserver (or worse, an attacker) will suddenly resurrect. However, I do agree it does no harm to do this, and might help in some cases. Ok. > 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. 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. > > 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 once the sigs that supercede them become > revoked/expired. I'm not sure I agree with this. I was under the impression you were arguing for something else, so let me make sure we're both talking about the same thing. Given this case: non-revocable sig 1-Jan-2000 revocable sig 2-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. 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. Now try this case: non-revocable sig 1-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? David _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users