Subject: Rip Van Winkle awakes: meeting in Oslo?

From: "John W. Noerenberg" <[email-masked]>
Date: Wed, 7 Jul 1999 12:14:50 +0900

Rumor has it I'm waking up in Oslo this weekend.  I'll be recounting 
my dreams in the hotel bar, but in the meantime, a couple of folks 
have asked if there will be a WG meeting.  There are a few things to 
discuss:

1. PGP/MIME, PGP/MIME, Wherefore art thou, PGP/MIME?
   Del Torto and Roessler have a draft, reputedly close to the 2015. 
They would like to present it, I would like to tie this one up.

2. Keyserver Synchronization
There are two proposals being discussed.  Should a new WG be created?

3. Numerous revisions/enhancements/improvements to rfc2440 have been proposed
Jon Callas enumerated several items back in April.  Some of them have 
been discussed on the list recently (notably V5 sigs).  Is there 
interest in any of the others?

I'm negotiating with the agenda folks now about whether we can pull 
off a meeting.  I've got my ear to the wire to see if there's a 
chorus of "Yay!" or "Don't bother".  Let me know what you think.

best,

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   The man that can most truly be accounted brave is he who best
   knows the meaning of what is sweet in life and what is terrible,
   and then goes out undeterred to meet what is to come.
   -- Pericles, "Funeral Oration", 479 B.C.
   ----------------------------------------------------------------------

---

From: [email-masked] (Bodo Moeller)
Date: Thu, 8 Jul 1999 21:55:38 +0200 (CEST)

> interest in any of the others?

BTW, was this ever discussed:

5.2.3. Version 4 Signature Packet Format

5.2.3.5. Key expiration time

   (4 octet time field)

   The validity period of the key.  This is the number of seconds after
   the key creation time that the key expires.  If this is not present
   or has a value of zero, the key never expires. This is found only on
   a self-signature.

5.2.3.9. Signature expiration time

   (4 octet time field)

   The validity period of the signature.  This is the number of seconds
   after the signature creation time that the signature expires. If this
   is not present or has a value of zero, it never expires.

It should be mentioned (in the Security Considerations section, if not
in the specification text) that, when signing a certificate for a
signing key that has a key expiration time set in a self-signature, it
is unwise not to include a signature expiration time subpacket
defining a validity period that extends no longer into the future than
the key's validity period.

If this rule is not obeyed when certifying keys, then the key validity
period is effectively just a key usage period.  There's no difference
as far as encryption is concerned, but for signing keys the key
expiration time sub-packet would be rendered all but meaningless: you
could just as well simply stop using the key without declaring so in
advance.  The big problem is that if attackers learn the secret part
of the "expired" signing key, they can easily generate a new
self-signature with an adjusted validity period unless the original
validity period is duplicated in the key certificates.  (This
potential flaw does not apply to keys in version 3 public key packets,
because they have the validity period defined in the key packet
itself, not in a self-signature packet, which means that it is
automatically covered by all certificates.)

---

From: Jon Callas <[email-masked]>
Date: Thu, 8 Jul 1999 23:39:48 -0700

At 12:55 PM -0700 7/8/1999, Bodo Moeller said:

No, this has never been discussed.

I think you have a good point, but I also disagree at least a little.

One of the things that I'd like to see software do operationally is
something I call "rolling validity." I'd like to see keys have a relatively
short life that keeps getting pushed out, by being re-validated.

As an example, I might have my validity period be three months. Perhaps
then, today my OpenPGP software tells me that come August 1, my self-sig
will expire. Maybe I should re-validate now. I concur, retype my
passphrase, and the new expiration time is November. It sends my updated
key to any servers I need it to go to.

I think one of the major problems we have is lost keys dangling around
forever. If software used something like rolling validity, lost keys would
time out, people who don't use their keys much would be noticible.

Presently, since the UI doesn't let you unexpire a key, no one makes keys
with expiry, except for certain, limited uses (for example, where I work we
just put an expiration on a summer intern's key). But today a key with an
expiry is the exception. I'd rather see it be the rule. For it to be the
rule, there can't be a huge penalty for doing so.

	Jon

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 9 Jul 1999 14:44:02 +0200

On Thu, Jul 08, 1999 at 11:39:48PM -0700, Jon Callas wrote:

[...]
> short life that keeps getting pushed out, by being re-validated.

Me too.  I did not detail this in my previous message, but IMO the way
to go is to use short validity periods on your encryption keys (so
that if you let them expire, no-one will send you mail encrypted to
those keys any more; an additional advantage is that you can change
the cipher preferences etc. if you switch to newer software versions)
and a longer validity period for the signing key.  Also your signing
key could use a long _key_ validity period, but short _signature_
validity periods for the self-signatures; then the key validity
period, if defined, should be used by others who certify that key.
A signing key is really invalid only when publishing its secret part
cannot break anything (not that I recommend doing so ...).

> [...] today my OpenPGP software tells me that come August 1, my self-sig
> will expire.

The self-signature!  Not the whole key, unless you don't re-validate.
For this, a signature validity period should be used, not a key
validity period.

---

From: Werner Koch <[email-masked]>
Date: Fri, 9 Jul 1999 16:44:11 +0200

> For this, a signature validity period should be used, not a key

IIRC, I have never seen a direct key signature with an expiration date 
- so the only available expiration date is the one from the (latest)
self-signature on a user ID.

I have considered to add the expiration date to the key but there
is no strategy defined how to process multiple expiration dates.
I think this should be addressed in the next revision of OpenPGP along
with some other similar issues (e.g. can a revocation of a 
self-signature on a user ID been overridden by a newer
self-signature).

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013

---

From: Jon Callas <[email-masked]>
Date: Mon, 12 Jul 1999 09:55:04 +0100

At 5:44 AM -0700 7/9/1999, Bodo Moeller said:

We're in violent agreement here.

The problem is that "key expiration" in OpenPGP (well, actually in the V4
data structures) is in the self signature. If you look at the V3 key
packet, there's a key expiration. In the V4 structure, it is gone. It's in
the self-sig.

	Jon

---

From: [email-masked] (Bodo Moeller)
Date: Mon, 12 Jul 1999 22:51:08 +0200 (CEST)

> packet, there's a key expiration. In the V4 structure, it is gone. It's in

That's what I wrote in my previous message, isn't it?  The point here
is that the self-signature can define _two_ validity periods: A key
validity period (section 5.2.3.5), which should be evaluated by others
when certifying the key so that an expired key is guaranteed to be
considered invalid by those trusting the certficate, and a
self-signature validity period (section 5.2.3.9), which certainly can
be much shorter than the total key validity period.