Retaining expired sigs

[Jason Harris]

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?
jharris at widomaker.com _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 309 bytes
Desc: not available
Url : /pipermail/attachments/20050319/cf99fb82/attachment.pgp