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

[[e-mail] (Bodo Moeller)]

Jon Callas <[e-mail]>:
> "Bodo Moeller" <[e-mail]>:

>> And assuming there *is* some point in doing self-signature updates
>> like this, whatever it may be, you should use signature expiration
>> time sub-packets, not key expiration sub-packets: it's just the
>> self-signatures that you want to expire, not the key.  So there is no
>> conflict with the proposed workaround for the key expiration protocol
>> failure.

> What I want is something of a dead-man's switch on my own key (and on other
> people's -- Werner is correct in noting that this requires client work,
> server work, and there are a lot of cool features you can load on this). If
> someone stops using their key, then it expires after some reasonable time,
> whether that reasonable time is measured in hours, days, or months.

So use *signature* expiration on the self-signatures for this.  In
your scenario, you specifically don't want the key to finally expire
if someone stops updating it, you just want to avoid having valid
self-signatures present.

> On the flip side of this, let's imagine that I certify Alice's key. When I
> certify it, I'm stating that I believe it belongs to her. If she has a
> dead-woman's switch on her key, it doesn't change my statement. If I wanted
> to limit the duration of my statement, that option was available to me. If
> Alice permits her key to expire, I still believe it's her key!

It might have become someone else's key too, that's the problem with
this: one reason for setting an expiry date is the expectation that
the key may no longer be secure after some time, be it because of
worries about keylengths or because you don't want to keep the
hard-disks of your old computers in a safe forever.

>                                                                It may be
> expired, but it's still her key. She could always un-expire it by putting a
> new self-sig on it. If I don't like all of this, I always have the option of
> revoking my signature, as well.

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).


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]