[Top] [All Lists]

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

2002-09-25 04:05:51

On Tue, Sep 24, 2002 at 04:05:32PM -0700, Jon Callas wrote:
Bodo Moeller <moeller(_at_)cdc(_dot_)informatik(_dot_)tu-darmstadt(_dot_)de>:

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 [...] such that the
bad guy cannot unexpire the key.  What speaks against this?

They mean separate things. A signature expiration on a self-signature
expires the validity of that signature. If you have, for example, a key with
two user names, expiration of that signature effectively expires that user
id. They key expiration makes the whole key expire. If you did it with
signature expirations, you'd have to manage every user id separately.

Now it all fits together.  It turns out that you can have it your way
and I can have it mine.

In your scenario, you need to set key expiration times in *direct-key*
self-signatures, and you want key lifetime to be extensible by

In my scenario, if you want expiration that cannot be undone, you set
a key expiration time in each *certification* self-signature.

All the time, you were talking about key expiration time sub-packets
in direct-key signatures while I was talking about key expiration time
sub-packets in certification signatures.  It's only the latter type of
expiration that should carry over into certifications by others.

Earlier I described my proposal like this:

     When Bob signs a certificate for Alice's key (which presumably he
     does only when Alice has told him that she considers her key
     valid), he looks at all valid self-signatures and finds the one
     for with key expiry is the furthest away.  This determines is the
     maximum validity he should use for his certification (unless
     Alice tells him otherwise).

This procedure should be changed as follows.  To determine the maximum
validity for his certification, Bob takes into account any key
expiration times found in *certification* self-signatures for the
respective user ID; not the key expiration times found in *direct-key*
self-signatures (these are relevant only for determining if the key is
currently valid).

Bodo Möller <moeller(_at_)cdc(_dot_)informatik(_dot_)tu-darmstadt(_dot_)de>
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036