[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Need new key signed (live in NYC)

On Mon, Dec 10, 2001 at 02:56:31PM -0800, martin f krafft wrote:
> also sprach Jimmy Kaplowitz <jimmy@debian.org> [2001.12.08.1859 -0800]:
> > Hi all. My GPG key expired in August, and I need another debian
> > developer to sign a new one. I can provide a new key (not yet
> > created) signed by the old one, and a request signed by both keys
> > for the new one to be signed by another DD. The old key is of course
> > in the Debian keyring, and once this is done I will submit the new
> > one to replace or augment it. If this is not secure enough, or
> > certain enough, for you, I can also meet you face-to-face if you can
> > get to New York City. Please reply via private mail, or if you must
> > reply to the list, be sure to CC me.

> uhm, why not just change the expiration date? from what i understand,
> the expiration is only applicable to a public key, the private key can
> be changed in terms of expiration... or am i wrong?

> actually, your signing key can be changed in terms of expiration, your
> encrypting key will expire, but that one is independent of
> signatures...

The expiration date on a key is part of the self-signature data; when
you change the expiration date w/ gpg, it deletes the old signature and
creates a new one.  For your local use, this is sufficient; but what is
to be considered correct behavior in the case of a public keyserver?  If
someone uploads their key to a keyserver that already has their key, and
the self-signatures differ, which one should take precedence?  The
newest one?  The one with the earliest expiration date?  Should both
signatures be attached to the key?  In which case the question becomes:
which signature should *clients* give precedence to when figuring key

In short: he tried that, and it didn't stick when he uploaded it to the
keyservers.  <shrug>

Steve Langasek
postmodern programmer

Attachment: pgpUbrVFfmJSz.pgp
Description: PGP signature

Reply to: