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

From: Bodo Moeller <[email-masked]>
Date: Fri, 20 Sep 2002 15:40:36 +0200

Here's the yearly reminder on the OpenPGP key expiration protocol failure.

http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html
http://www.imc.org/ietf-openpgp/mail-archive/msg02848.html
http://www.imc.org/ietf-openpgp/mail-archive/msg03693.html

-- 
Bodo Möller <[email-masked]>
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

---

From: Jon Callas <[email-masked]>
Date: Fri, 20 Sep 2002 23:09:23 -0700

> http://www.imc.org/ietf-openpgp/mail-archive/msg03693.html

My opinion (still) is that it isn't a bug, it's a feature. I want someday to
make keys that have short-lived self-signatures on them that are regularly
renewed, and don't want to require the entire PKI to regenerate itself every
week, or day, or month. I think it's horribly limiting to require all the
dates to match up, and ruins a lot of interesting possibilities.

    Jon

---

From: Werner Koch <[email-masked]>
Date: Sat, 21 Sep 2002 11:59:22 +0200

> make keys that have short-lived self-signatures on them that are regularly

I fully agree.  Furthermore, due to the possibility to set an
expiration date on a key signatature, a "CA" gains the same effect as
with an expiration date on the key.  It is about what a trusted
authority sees as a sound expiration date.  This may either be a key
signator by using the signature expiration time or the key owner by
setting the expiration date on his key signatures (self-signature).

PGP has the tradtion to to let the user decide and not some other
entity.  With the OpenPGP model the user is even free to ask a CA to
set an expiration date on their key signature.  

By default GnuPG uses the expiration date of the self-signature as the
one for a key signature.  This is on Florian Weimer's request and afaik
is sufficient for him and his use of the PGP PKI.

Salam-Shalom,

   Werner

---

From: [email-masked] (Bodo Moeller)
Date: Sat, 21 Sep 2002 13:11:23 +0200 (CEST)

Jon Callas <[email-masked]>:
> "Bodo Moeller" <[email-masked]>:

> renewed, [...]

You are talking about subkeys (encryption subkeys, presumably -- in
the case of signature keys, you can simply stop using them without
having announced so in advance).  If you want to regularly renew your
subkeys, then set appropriate expiration times for these subkeys.

I am talking about main keys, not subkeys.  Simply don't set an
expiration time for the signing key if you want to be able to continue
to use it indefinitely.

---

From: [email-masked] (Bodo Moeller)
Date: Sat, 21 Sep 2002 13:28:44 +0200 (CEST)

Werner Koch <[email-masked]>:
> Jon Callas:

>> My opinion (still) is that it isn't a bug, it's a feature.

> I fully agree.  [...]

> is sufficient for him and his use of the PGP PKI.

is exactly what I was asking for -- except that I want this to be
recommended in the specification [1][2] so that Florian won't have to
contact all the implementors individually [3].

[1] http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html
[2] http://www.imc.org/ietf-openpgp/mail-archive/msg03693.html
[3] http://lists.gnupg.org/pipermail/gnupg-devel/2001-July/006196.html

---

From: Jon Callas <[email-masked]>
Date: Sat, 21 Sep 2002 11:20:49 -0700

> expiration time for the signing key if you want to be able to continue

So am I. I'm talking about main keys.

I have a vision where my program might (for example) re-create my
self-signature every day with a 48-hour expiration, and upload it to the
server.

OpenPGP has a policy that in the base specification, we permit a variety of
trust models and do not require one; we provide a language that is robust
enough to support all these trust models.

    Jon

---

From: Bodo Moeller <[email-masked]>
Date: Sat, 21 Sep 2002 22:20:53 +0200

> self-signature every day with a 48-hour expiration, and upload it to the

But why would you want to do this?!  This key "expiration" does not
provide any security.  You can just as well submit a key without an
expiration date; instead of stopping to send updated self-signatures,
you just stop to use the key.

---

From: Werner Koch <[email-masked]>
Date: Sat, 21 Sep 2002 22:52:14 +0200

> self-signature every day with a 48-hour expiration, and upload it to the

Aihhh, this needs some work on the keyserver side of the story and I
can think of neat features to be implemented on the client side. ;-)

Shalom-Salam,

   Werner

---

From: Bodo Moeller <[email-masked]>
Date: Sat, 21 Sep 2002 23:54:51 +0200

> you just stop to use the key.

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.

---

From: Jon Callas <[email-masked]>
Date: Sat, 21 Sep 2002 15:53:25 -0700

> conflict with the proposed workaround for the key expiration protocol

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.

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

    Jon

---

From: [email-masked] (Bodo Moeller)
Date: Sun, 22 Sep 2002 09:48:51 +0200 (CEST)

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

> 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

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