gpg 1.0.5: unusable secret key

[David Champion]

On 2001.06.14, in <874rtjccf0.fsf@alberti.gnupg.de>,
	"Werner Koch" <wk@gnupg.org> wrote:
> 
> No.  It is just that v3 keys are deprecated anyway and the solution
> for v4 keys is much simpler: just change the expiration time of the
> key. 
> 
> I don't think that there so many expired v3 keys out that it is worth
> to add option/command 166 to gpg ....

I think you have a point, if that's true.  I'm just not certain that it
is -- I found two in the course of examining this issue, and one isn't
mine.


> Hmmm, we have --ignore-time-conflict and other strange options.
> So in this light my arguments are not so sound. Okay, what about
> --allow-expired-keys ?

Sounds fine to me, but are there any other invalid key situations that
should be allowed, and can be covered with a single option?


OK, so now that's over with, I have a complication to throw in.  After
you mentioned that this is a v3 key issue, it took me a little while to
catch on that you were saying that I had a v3 key.  That sounded wrong
to me, so:

$ gpg --export AB61503F | gpg --list-packets | grep version
        version 4, algo 17, created 944718693, expires 0
        version 4, created 963829115, md5len 0, sigclass 10
        version 4, created 963829282, md5len 0, sigclass 10
        version 4, created 963829325, md5len 0, sigclass 13
        version 4, created 963829373, md5len 0, sigclass 10
        version 4, created 944718693, md5len 0, sigclass 13
        version 4, algo 16, created 944718806, expires 0
        version 4, created 964132837, md5len 0, sigclass 18

AB61503F is the key I've been talking about.  It's a v4 key.

smack (++umail) pts/4 11:04:43 dgc [406/0]: gpg-1.0.6 --edit-key AB61503F
...
gpg: key AB61503F.59: expired at Wed Jan 31 23:51:33 2001 CST
pub  1024D/AB61503F  created: 1999-12-09 expires: 2001-02-01 trust: m/e
sub  1024g/07D6E6DD  created: 1999-12-09 expires: never     
...

smack (++umail) pts/4 11:05:03 dgc [407/0]: gpg-1.0.3 --edit-key AB61503F
...
pub  1024D/AB61503F  created: 1999-12-09 expires: never      trust: m/u
sub  1024g/07D6E6DD  created: 1999-12-09 expires: never     
...

I can change the expiration time on the key, but is that really
useful?  If I understand things, I can't resubmit it to a keyserver, so
for everyone else in the world who I don't send the updated key to
myself, the key will remain expired.  It seems that I should change the
expiration just enough to generate and release a new key.  Does anyone
disagree with that?

... or is this a different kind of problem?  (I'm not sure why you
assumed it was v3 -- whether I misunderstood something in the context
of the original message in this thread, or whether there might be some
other issue involved.)

Thanks.

-- 
 -D.	dgc@uchicago.edu	NSIT	University of Chicago