[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Tue, Sep 24, 2002 at 04:05:32PM -0700, Jon Callas wrote:
> Bodo Moeller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>:
>> 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
Bodo Möller <moeller@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036