Re: draft-ietf-openpgp-rfc2440bis-06.txt

[Jon Callas <[e-mail]>]

Actually, this has digressed.

Key expirations are not "my" system. They're the way the OpenPGP works. If
you create a key with an expiration and hand it to Alice, she'll think if
expires at that time. Call it Ta. You can turn right around, and lop off
that user name, re-create the user name and self-sig with another expiration
time on it and hand it to Bob (call that Tb). This works today. It's the way
it works. We've even had discussions here for years about re-writing
self-sigs and what you should do, and how you should interpret them, and
what happens when you have things like a designated revoker.

Now, as Bodo has suggested, there's a potential ambiguity here. In short,
what does it mean if Alice signs your key with no expiration (or one that is
after Ta)? Bodo suggests that this is a flaw. I claim it is not. If Alice
had wished to time-limit her certification, she should have, and it's not
for us to tell her how to do it.

I further claim that while this may be somewhat counterintuitive, it is a
useful and desirable feature, for someone to have different expirations on a
key depending on situation. Lastly, I claim that if you want to kill a key,
there is a mechanism for that -- revocation.

Now it has also been claimed that if someone were to steal your private key,
they could re-write your self-signature, and even un-expire a key. Yeah.
They can do a lot worse, too. In the immortal words words of Julie Brown's
blonde, "So what?"

Discussing what someone can do with a purloined key loses track of the real
issue. When you design a security system, among the things you need to
consider are the security of the system, but also its safety and
reliability.

Security systems and reliability systems are not the same. In fact, they are
frequently at odds with each other. For example, if you build a building,
you might put bars on windows as part of security. But you might also make
it so they can be opened from the inside as a safety and reliability issue
-- as a way of battling fire. Note that improving the safety characteristics
of the building may be orthogonal to its security aspects, or they may be in
direct opposition to it.

Key expirations are a reliability feature. Revocations are a security
feature. If you think a key has been compromised, revoke it! Don't expire
it! We even have a nifty "reason for revocation" feature. Revoking a key
with a reason of key compromise is a drastic and perhaps ironically
irrevocable step. It means that nothing about the key can be relied upon.

However, the reliability aspects of PGP certificates are under-used, and
needed. There is, for example, a whole swarm of keys out there in some
unknown state. Some are in use, some aren't, some are in an unknown state. I
have at least of each, myself.

In the past, various people have discussed handing this issue by explicitly
or implicitly expiring them. Some people have asserted that one should never
create a key that doesn't have a reasonable expiration time on it.

The problem with that idea is many-fold. One is there's no good way to know
what a reasonable time is. One year? Two? More? Less? Worse, if you expire
your key, there's no good way to transfer your old certification information
to the new key. So all that work you went through to get your key signed by
cool people has to be redone.

Long ago, perhaps before we started OpenPGP, I was of the opinion that there
had to be an "I used to be" statement in the language. This is difficult to
do correctly. I never came up with a decent design for it. Part of what shut
me up on it was the realization that with V4 keys putting expiration into a
self-sig and not the key packet, you can use something I call "rolling
validity" where you keep extending the expiration of your key until you
decide not to, or revoke it. This solves all sorts of reliability issues in
OpenPGP. Yes, it does nothing for security. It's not supposed to, it's a
reliability feature, not a security one. It *does* however solve the problem
of someone creating a key, putting it on a public keyserver, and then losing
the password a day later.

It helps me manage which keys are active, by making it so that if I put too
short an expiry on my key, I don't lose that nifty Phil Zimmermann sig on
it. Laugh if you want, but it is that very issue (perhaps not with PRZ
himself, but the broader issue) that keeps people from putting time limits
on their keys. If you guess wrong, you hurt yourself.

Expiration is not revocation. Do not expect it to solve the problem of
revocation. Likewise, revocation is not expiration. Revocation is
irrevocable. Expiration can be undone. This is the design of the language of
the system. The present behavior is in my opinion the correct and desirable
one.

    Jon