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 expirations? In short: he tried that, and it didn't stick when he uploaded it to the keyservers. <shrug> Steve Langasek postmodern programmer
Attachment:
pgpI2VNtnQ4MC.pgp
Description: PGP signature