encrypting to expired keys (was Re: Expire-date of subkey problem)

David Shaw dshaw at jabberwocky.com
Fri Aug 22 06:50:02 CEST 2003


On Thu, Aug 21, 2003 at 04:48:43PM -0400, Jason Harris wrote:
> On Wed, Aug 20, 2003 at 05:53:09PM -0400, David Shaw wrote:
> 
> > I'll admit to a certain curiosity as to why someone would want to do
> > such a thing.  This key is no more.  It has ceased to be.  It's
> > *expired*.
> 
> > Using it after expiration is against the express wishes of the person
> > who put the key out there in the first place - the key owner.
> 
> Assuming the keyholder can figure out their software and can easily
> transmit key updates to those who would use the otherwise-expired key,
> then yes.  But, just as one can use a telephone to verify the finger-
> print of a new key, one should also be able to say: "Use my existing key
> for another week, I'm unable to create and transmit a new one right now."
> Why preclude this?

The protocol doesn't preclude this, of course, but then again, the
protocol doesn't preclude nearly anything.

There are many things that could theoretically be overridden by a
smart user who "knows better".  Unrevoke keys, unexpire user IDs or
subkeys, change key flags (turn a sign-only key into an encryption
key, etc) and so on.  In general, I'm somewhat against this sort of
thing unless there is a pretty concrete example of it being needed in
the field.  It's always possible to construct a reason why a
particular validation needs to be overridden ("Oops, I didn't mean to
revoke my key - it's okay, go ahead and use it anyway" or "I don't
have time to sign Joe's key right now, but go ahead and use it as if I
had signed it."), but every override gives additional complexity to
GnuPG and is an additional place where the wrong thing can happen (How
sure are you that you spoke to the right person on the phone?  Are you
sure that the "Joe" key that is being authorized is the same "Joe"
that you have a copy of?)

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 268 bytes
Desc: not available
Url : /pipermail/attachments/20030822/1bf6f2f5/attachment.bin


More information about the Gnupg-devel mailing list