On Mon, Sep 23, 2002 at 10:29:07PM -0700, Jon Callas wrote:
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.
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