Despite "no-include-revoked" revoked still included

David Shaw
Tue Dec 10 21:17:02 2002

On Tue, Dec 10, 2002 at 07:34:07PM -0000, Dick Gevers wrote:
> Hash: SHA1
> Hi David and others,
> On Tuesday, 10 December 2002 at 12:53 h, David Shaw wrote about
> "Re: Despite "no-include-revoked" revoked still included":
> >This involves keeping the actual data around and just hiding it 
> from
> >the user which GnuPG already does (in some places anyway).  That's
> >why a revoked user ID doesn't show up in --list-keys.  The same 
> idea
> >could be used to hide revoked subkeys, etc.
> Sorry, no, that's not what I meant. I just want to cut the
> 'deadwood' of revoked and expired userID's and signatures from my
> current pubring and upon either --refresh-keys I wouldn't (again)
> receive revoked and expired data for the current keys in my ring and
> in case of --recv-keys I would get only current data, exclusive of
> revoked & expired IDs and signatures.

I see what you mean, but there are some odd corner cases there - for
example, lets say that a user had a signing subkey, used it for a year
and then revoked it and made another.  Should this subkey be deleted?
If it is you can't verify any of the signatures issued during that

What I was suggesting (and perhaps did not explain well) is a feature
for GnuPG where it simply never shows you revoked subkeys, revoked
user IDs, etc. during a --list-keys.  They may be there, but you won't
see them so the effective result is the same as if they were deleted.

GnuPG already does this for user IDs.  It would just mean extending
the same idea for other objects.


   David Shaw  |  |  WWW
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson