From: "Don M. Kitchen" <don@wero.cs.byu.edu>
Date: Sun, 7 Jan 1996 22:39:50 +0800
To: cypherpunks@toad.com
Subject: Key Expirations (was: Revoking Old Lost Keys)
Message-ID: <199601071308.GAA00421@wero.cs.byu.edu>
MIME-Version: 1.0
Content-Type: text/plain


-----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-----