Before you go putting words in my mouth...
There are two opposing forces here. On the one had I want to be able
to continue using my key indefinitely (re-keying is a PitA). On the
other hand, if it gets compromised I want to kill it (and make sure
the attacker cannot un-kill it). The third case is where the user
loses their private key.
To make all three of these work, I agree with Jon that you need to
separate out the "this key is alive" from "this key is dead". The
"Keepalives" are self-signatures with limited lifetimes. I don't mind
re-signing my own key every year (or whatever period I want to
re-assert myself). Note that this time period should not affect the
time period with which Alice asserts my key -- Alice should decide how
often they want to re-verify my key, I shouldn't dictate that to
Alice.
The "this key is dead" is necessarily a revocation. If you go under
the assumption that data can only be added to a key and never removed,
then once you see a revocation anything else doesn't matter. If the
attacker controls the keyserver and can remove revocations then
obviously this doesn't work, but I don't think an attacker can control
that many data points.
All I except from the system is that an attacker who gains access to
your private key cannot make it live longer than YOU want it to.
-derek
Bodo Moeller <moeller(_at_)cdc(_dot_)informatik(_dot_)tu-darmstadt(_dot_)de>
writes:
As I pointed out, you can use *self-signature* expiration (subpacket
type 3) for many purposes, and use *key* expiration (subpacket type 9)
for cases where you really want the key to expire in the sense that
Derek and others expect key expiration to work (namely such that the
bad guy cannot unexpire the key). What speaks against this?
For version 3 keys, key expiration carries over into certifications,
and many users expect similar security properties for version 4 keys.
Notably, even Derek expected this, and still you refuse to even
mention this bug/feature/misunderstanding in the Security
Considerations of the specification.
Lastly, I claim that if you want to kill a key,
there is a mechanism for that -- revocation. [...]
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.
I already commented on this:
< Compared with key expiry (and I mean final expiry that cannot simply
< be undone by anyone who has gotten hold of the secret key), revocation
< is somewhat of a kludge. In some situations it is the best you can
< do, but the problem is that the semantics is not monotonous. This may
< be fun for AI people, but security folks should be worried about the
< ramifications of denial of service attacks (nothing guarantees that
< the revocation reaches everyone who should know about it).
If it's not clear what I mean with this I should probably formalize
the concepts and write a paper about the issue unless someone has
already done something like that. Some keywords: formal proof
systems, default logic.
You say "revocation is irrevocable". This is true in a sense, but
revocation is not as reliable as expiration that cannot be undone.
You say "expiration can be undone", but we also need some kind of
expiration that cannot be undone. OpenPGP distinguishes between key
expiration and signature expiration, so we can use key expiration if
we want expiration that cannot be undone, and self-signature
expiration if we want expiration that can be undone.
A signing key has become invalid in the fullest sense only if you can
publish the corresponding secret key without causing any problems.
PKIs should offer entities a way to state that their keys are to be
considered invalid after some specific point of time. Revocation does
not do this job very well because revocation packets may be
suppressed, so the invalidity date must be covered by the
certifications instead.
--
Bodo Möller <moeller(_at_)cdc(_dot_)informatik(_dot_)tu-darmstadt(_dot_)de>
PGP
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
--
Derek Atkins
Computer and Internet Security Consultant
derek(_at_)ihtfp(_dot_)com www.ihtfp.com