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 once the sigs that supercede them become revoked/expired. -- 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
pgpX54fkvl90i.pgp
Description: PGP signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
