-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE-----
From: shamrock@netcom.com (Lucky Green) At 15:45 1/6/96, Bill Frantz wrote:
Perhaps if keys could be made with expiration dates (certificates too), this problem might be reduced to managable proportions.
I would very much like to see expiration dates on public keys. Is PGP 3.0 offering this feature?
(it would be nice to know of anything that PGP 3 will be offering)
From: wlkngowl@unix.asb.com (Mutatis Mutantdis)
Keys should have built-in expiration dates (adjustable by the user manually the way one would change their user-id, passphrase, etc.)
I disagree, I think a key should be be given a specific lifetime. A master key, for example, might be given a life of 7-10 years, while a common-use key a life of, for example, 2-5 years.
PGP should give a warning when the key passes the expiration date. It should not prevent you from using it, but should remind you that the key is rather old, and that the owner may have moved, etc.
I disagree. I think that it's the key owners' responsibility to provide transitions to a new key. (it would be nice to have a mechanism to auto transfer signatures to a new key, but I can't see that being both safe and practical) I also would also like to see PGP/keyservers with more of a current-status paradigm, rather than a from-the-beginning-of-time model. A "my master key is foo" and "I'm master of: fiz, bar, baz" fields would encourage the emergant practice of having a secure master key, and a common key that is replaced more often. Not-Secure Systems are Not-Secure Systems, and there should be Not-Secure keys to be used on these ISP/multiuser/whatever systems, without resorting to multiple keys, mutually signed, that merely proclaim their properties in the key ID. I'm certainly not calling for Someone[tm] to code it up, only pleading that the paradigms be established conceptually, so that everyone knows (and hopefully agrees) where it's going. We have security (stealth pgp, if generally indistinguishable from random data, will ensure that, and prevent all but human betrayal or tremendously draconian outlawing of random data from taking that security from us) but we do not have seamlessness, and we do not have a PGP that fits how PGP is being used, and not knowing if these things have even been planned is distressing.
Users who want to extend the life of their keys should send special certificates (at least once a year or every other year?) that tell keyservers and those with copies of their public keys that the key is still being used, and to update the expiration time.
I can only this working elegantly if the expiration date, as a signed block, could be expunged and a new expiration date block put in. Signatures, of course, would have to authenticate the parts that don't change. If the expiration date is inside the _owner's_ authentication block, everything would still be attack-resistant. (Everything absolutely should be designed to resist spoofing, etc. I would like to see PGP _IGNORE_ key ID's that are not signed, and naturally default to signing key-IDs when being added.) I too would like would like to see expiration dates built into the keys. The PGP key has too much of a static-model, long life paradigm. IMHO, I see two problems. First, key signature are for the key/ID string pair. Every time someone changes email addresses, a clunky ID string addition is made to the key, and subsequent signatures are made to _that_ pair. I don't disagree that it should be this way, only suggest that a more integrated, conceptual view even, should be presented. While I'm presenting my wish list, it would also be nice for PGP to be able to extract keys that are in the Web Of Trust[tm] relative to an arbitrary key. I attempted to do something like this with by Web Of Nobody's keyring for those of you who didn't see my posts, that's what I called what I generated because the brute-force way I extracted it necessitated the signatures going the opposite direction than they should have, resulting in a great many nobody's and missing a few somebody's.) which reduced the then-5 meg keyring to 1 meg. (I am considering doing it again, since I still don't know enough PERL to generate a web of trust instead of a web of nobodies) A feature like this would, in my opinion, largely negate (or at least greatly delay) the need for a DNS-style key lookup. And, after all, what's the purpose in having a list of all keys in the world, why not just have a list of keys that are actually interrelated, extracted from the former. Perhaps even a batch-mode "copy all new and trusted keys from keyring X", THAT would help tremendously with a "locally-trusted" / "globally known" dual-use of PGP and its keys.
From: "Frank O'Dwyer" <fod@brd.ie> portion of the) web of trust was very large, you might find that the old key kept popping up and you kept getting mail ... It's just that PGP's certificates are particularly long-lived, and PGP's revocation is particularly broken. Luckily the data formats do allow for a validity time, and a revocation of a key's countersignature, so this can perhaps be fixed sometime. ... uploading their key with additional signatures. A practical solution might be for the key servers to automatically remove keys older than X years (or some time limit related to the key size). Ultimately though, what is needed is a new revocation model (maybe implementing the unused fields in the PGP certs is good enough to begin with).
This is all a me-too. As I said, I would like to see a current, how-it-is-now list, rather than having keys whose replacement's replacements' replacements have been revolked long ago.
On Sat, 6 Jan 1996 09:47:16 -0000, "Frank O'Dwyer" <fod@brd.ie> wrote:
The PGP formats do allow for a 'revocation' certificate, but PGP doesn't implement it (yet, I guess). In any case, it's not really strong enough, since what it says is "I retract all my previous statements that this key is related to this user". This'd mean that you'd have to visit everyone who'd ever signed your key and get them to issue this retraction. What would be needed for this problem is either an "anti-certificate" ("This key does not belong to this user"), or else some convention. For example, if two _trusted_ keys are found for the same uid, the most recent one could be chosen, and the earlier one be purged from keyservers, etc. This may be possible with current PGP. I haven't tried it, but since I have some keys which have fallen into disuse, I will need to do so sometime.).
I think this is a feature that would be good to have, not necessary for all signatory parties to retract sigs, but certainly for one or more of them to do so. I do think, however, that both should be kept (and not just one cancel another like a current-status model would) and that perhaps the two should default to not being displayed, but certainly PGP explain it as "X revokes signature, contact both parties for explanation" type of thing; let the human be the judge. Don PS: This message may be double-signed, don't think it unusual if it is. - - --- <don@cs.byu.edu> fRee cRyPTo! jOin the hUnt or BE tHe PrEY PGP key - http://students.cs.byu.edu/~don or PubKey servers (0x994b8f39) June 7&14, 1995: 1st amendment repealed. Junk mail to root@127.0.0.1 * This user insured by the Smith, Wesson, & Zimmermann insurance company * - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMO/FtsLa+QKZS485AQGcSwL/eyUiZ4YgKfLyQx94K+Vm/y2Jmsx1DnOm Anvv2EA98qY1wBxpg2HUCrV2NO97vafTPNJ5dcZsLUIDOnzjw3Pxj7ikNTnwL45Q 89NVqc6jHG3NCbIirDTPSN/q20N2yhEA =qRq9 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMO/FzcLa+QKZS485AQG8OQMAj9mDA9v7f68cKDl4z8JLieFsFo4EtzJb XDna9JXvYQj/tBd+AFuBNxhawzIgSn7ydIw/QtRcE/a9HbAY4eJDfuEANfoKZARb TpxLWpmGU1uDidEB9irGxGGZd4uen7Mz =Ku7l -----END PGP SIGNATURE-----