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

From: Jon Callas <[email-masked]>
Date: Sun, 22 Sep 2002 23:16:16 -0700

On 9/22/02 12:48 AM, "Bodo Moeller" <[email-masked]>
wrote:

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

In my scenario, I specifically want the key expiration. Really I do. Now you
may disagree with this, but it is what I want.

    Jon

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 23 Sep 2002 08:23:34 +0200

On Sun, Sep 22, 2002 at 11:16:16PM -0700, Jon Callas wrote:
> "Bodo Moeller" <[email-masked]>:

> may disagree with this, but it is what I want.

Please point out an advantage of *key* expiration over
*self-signature* expiration in that scenario.

-- 
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: Derek Atkins <[email-masked]>
Date: 23 Sep 2002 09:55:19 -0400

> *self-signature* expiration in that scenario.

A bad guy gets a copy of my private key..  If there is a key
expiration then they cannot keep it alive indefinitely.  Or is key
compromise not an attack you care about? ;)

-derek
-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 23 Sep 2002 16:01:02 +0200

> expiration then they cannot keep it alive indefinitely.

Yes he can -- this is exactly the problem [1] that I want to solve
with my suggested change to the specification.  The way Jon wants to
use key expiration, the bad guy can keep the key alive indefinitely.
I call this a protocol failure, he calls it a feature.

[1] http://www.imc.org/ietf-openpgp/mail-archive/msg02374.html

---

From: "Richie Laager" <[email-masked]>
Date: Mon, 23 Sep 2002 12:48:16 -0500

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bodo Moeller
> Sent: Monday, September 23, 2002 9:01 AM
> To: Derek Atkins
> Cc: Jon Callas; OpenPGP
> Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
> 

> with my suggested change to the specification.  The way Jon wants
> to use key expiration, the bad guy can keep the key alive
> indefinitely. I call this a protocol failure, he calls it a
> feature.

I've been following this thread somewhat, and I have the following
suggestion:

IIRC, key expirations are stored in the self-signature. So, a PGP
client could take all of the valid self-signatures, and compare
expiration dates. The oldest one would be honored.

This means that you cannot extend the key expiration. However, if you
don't want an attacker to be able to extend the key expiration if he
or she has the private key, this also means that the legitimate owner
of key cannot be allowed to extend the expiration date.

There is another large flaw with this plan. An attacker would only
need to revoke the self-signature, thus making it invalid. So, for
the meaning of this discussion, a "valid self-signature" would be one
that is correct in cryptographic terms, but revocations are ignored.

Deleting the other self-signatures would work, but since keyservers
only add to a key, synchronization with a keyserver could defeat this
attack method. However, if we ever implement the "no-modify" flag,
there is no reason the attacker (with possession of the private key)
couldn't send the key to the keyserver with the other signatures
deleted and the "no-modify" flag set. So, this may require that
keyservers maintain all self-signatures, even if the "no-modify" flag
is set.

So, to recap, if you ignore my implementation notes, the following
choice needs to be made:
1. Is extending a key expiration date by a key's owner a REQUIRED
action. If not, this is feasible. If so, I can't think of a way to do
it.

Richard Laager

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 23 Sep 2002 20:02:54 +0200

> suggestion: [...]

Did you read my original message from the mailing list archives?
There is a simple workaround for the protocol failure, which does
not have the problems of your proposal: whenever someone certifies
someone else's key, then if this key has an expiration time set, the
certification signature should get an expiration time too such that
the signature's validity period extends no longer into the future than
the key's validity period.

(Obviously if Alice specifically asks Bob to certify her key for a
longer period, he can do so, but we need a default for the typical
case that there is no out-of-band information on this.)

Of course the one problem we cannot avoid is that the legitimate owner
of the key cannot keep the key alive indefinitely.  This is because
this "problem" is exactly the security feature that me and Florian
Weimer and Derek Atkins want to have: we don't want the bad guy to be
able to unexpire the key if he gets hold of the secret key.

---

From: "Richie Laager" <[email-masked]>
Date: Mon, 23 Sep 2002 13:49:14 -0500

> From: Bodo Moeller [mailto:[email-masked]] 
> Sent: Monday, September 23, 2002 1:03 PM
> To: Richie Laager
> Cc: 'Derek Atkins'; 'Jon Callas'; 'OpenPGP'
> >> Yes he can -- this is exactly the problem [1] that I want to
> >> solve with my suggested change to the specification.  The way
> >> Jon wants to use key expiration, the bad guy can keep the key
> >> alive
> > I've been following this thread somewhat, and I have the
> > following suggestion: [...]
> 
> someone else's key, then if this key has an expiration time set,
> the certification signature should get an expiration time too such
> that the signature's validity period extends no longer into the
> future than the key's validity period.

How does this help? If a "bad guy" gets the private key, he can
simply resign everyone's key.

Richie

---

From: Len Sassaman <[email-masked]>
Date: Mon, 23 Sep 2002 11:53:04 -0700 (PDT)

> compromise not an attack you care about? ;)

Actually, in Jon's proposal, the bad guy can. If we do things Bodo's way,
he can't.

Bodo wants to make key expirations permanent and unalterable. This means
that even if a bad guy gets the private key, the key expiration cannot be
changed.

With Jon's way, key expirations are not a defense against key compromise,
because they can be extended indefinitely by the holder of the private
key.

The question I see is this: are key expiration dates a "mandate" or a
"suggestion" to third parties by the key owner?

In Mixmaster, we have key expiration dates that are not even tied to the
key by a signature -- they are just denoted in the key header field. The
intention here is to inform the user that the key will be deleted after
the expiration date, and in no way protects against the compromise of the
key. (Deleting the key does that -- the expiration date protects against
unreadable mail by the key holder).

One might argue that expirations in PGP are intended to be interpreted the
same way, and that the user should revoke the key if he is worried about
Bad Guys possessing it. I think this is how it must be interpreted if we
use Jon's system.

--Len.

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 23 Sep 2002 20:57:29 +0200

> simply resign everyone's key.

If the bad guy gets Alice's private key that has expired, he can renew
Alice's self-signature on the key, but he cannot renew Bob's
certification for Alice's key, which will have expired too according
to my proposal.  So no-one will believe it is still Alice's key.

Well, nearly no-one -- I can't speak for Jon :-)

---

From: "Michael Young" <[email-masked]>
Date: Mon, 23 Sep 2002 15:50:06 -0400

Subject: Expiration semantics (Re: draft-ietf-openpgp-rfc2440bis-06.txt)

From: "Derek Atkins" <[email-masked]>
> compromise not an attack you care about? ;)

No.

If you allow self-signatures to be rewritten with different
expiration times, then no, key COMPROMISE is NOT an attack
that the expiration time can ever mitigate.  Revocation
is the only option.

Now, it WOULD HAVE been reasonable to outright disallow multiple
self-signatures with different expiration times.  Then, the presence
of multiple expiration times could be taken as a clear sign of
compromise.  I would favor this approach, but others clearly do not,
and the spec has clearly allowed rewriting expiration times.

The usage pattern Jon Callas described does help deal with LOST keys,
though, preventing them from being used by legitimate clients.  In
the unlikely event that Jon loses his key, the flood of mail encrypted
to it will end at his most recently chosen expiration time :-).

This applies primarily to encryption.  I suppose it might also prevent
some fool from signing Jon's key (without asking him) after he has
lost it, but I feel no need to protect such fools.  So, I must admit
that I don't understand why Jon wants this to apply to main keys;
couldn't he update the expiration time in the binding signature for
his encryption keys?  If he has a "dead-man's switch" on all of his
subkeys, what more does he get from having the main key expire?

I would ask that the spec include some language to the sections on
expiration times to remind the reader that they can be rewritten, and
that clients should abide by them but not depend on them to limit
compromise.  (The right to rewrite appears elsewhere, but its
consequences may not immediately occur to someone looking at the
expiration time description.)

[As for the Bodo Moeller's original question, I mostly side with Jon.
Certifications are statements about the ownership of a key, not its
lifetime; it should be legal to make a certification that will outlast
the key's (CURRENT) expiration time.  That said, I wouldn't
strenuously object to mentioning that clients might WANT to consider
the key expiration time when making a new certification.]

---

From: "Richie Laager" <[email-masked]>
Date: Mon, 23 Sep 2002 16:33:36 -0500

> Sent: Monday, September 23, 2002 1:57 PM
> To: Richie Laager
> Cc: 'OpenPGP'
> >> There is a simple workaround for the protocol failure, which
> >> does not have the problems of your proposal: whenever someone
> >> certifies someone else's key, then if this key has an expiration
> >> time set, the certification signature should get an expiration
> >> time too such that the signature's validity period extends no
> >> longer into the future than the key's validity period.
> 
> If the bad guy gets Alice's private key that has expired, he can
> renew Alice's self-signature on the key, but he cannot renew Bob's
> certification for Alice's key, which will have expired too
> according to my proposal.  So no-one will believe it is still
> Alice's key.

Okay. I get it now. Alice's key expires in 5 years from creating, for
example. Two years later, Bob signs Alice's. Bob's PGP client sets an
expiration date of 3 years in the future on Bob's signature on
Alice's key. That way, Bob's signature expires at the same time as
Alice's key. If an attacker gets Alice's private key and extends the
expiration, the attacker would have to regain all of the signatures.

The only flaw I can see is that if Alice sets an expiration date of
Never, gets a signature from Bob, and then sets her expiration time
to 5 years, Bob's signature will likely NOT have an expiration date.
So, an attacker could then exploit Bob's signature. In essence, this
means that someone can't shrink their key validity length (length as
in time) and still have these benefits. My proposal would allow this.
However, my proposal doesn't allow someone to extend his or her key
validity length. And, my proposal requires changes on the client side
of the recipient, while your proposal requires client side changes
for the key signer. Therefore, I'll agree that your proposal is the
best. I just wanted to contribute my thoughts and clarify my
understanding of the issue.

Richard Laager

---

From: "Michael Young" <[email-masked]>
Date: Mon, 23 Sep 2002 17:49:34 -0400

Subject: More on key expiration policy (Re:
draft-ietf-openpgp-rfc2440bis-06.txt)

From: "Len Sassaman" <[email-masked]>
> Actually, in Jon's proposal, the bad guy can. If we do things Bodo's way,

Bodo originally suggested that clients abide by expiration times when
creating new certifications.  That alone may not prevent a compromised
key from being misused.  Yes, it would work for certifications prior
to the compromise, and for new ones where the signer gets the key
*directly* from the owner, but that still doesn't cover all cases.

Consider this scenario...
    I steal Bob's key.
    I publish it, with an updated expiration time, to an
     out-of-the-way keyserver.
    Bob's new friend Alice gets his key from this keyserver.
    Alice verifies the fingerprint with Bob, and signs his key,
     in accordance with Bodo's rules.
    Alice sends her new signature to Bob, and/or publishes it
     at my keyserver, but I steal it enroute.
    I have a signature that will outlast Bob's intended expiration.

The problem is that fingerprints don't include the expiration time.

Now, Bob *could* insist on getting a copy of Alice's signature, and
check for a mismatched expiration time.  Together, Bob and Alice could
discover that I've compromised Bob.  But this would require more care
in the keysigning process than even some very cautious people apply.

Note that disallowing rewriting won't prevent this attack, as
that also depends on someone noticing a (different) mismatch.
(If I can completely keep people from seeing key updates,
then I can defeat revocations, too, but that's a much broader
attack.)

This may be another fair argument for allowing rewriting.  If you
really wanted irrevocable expiration times, you'd want to hash them
into the fingerprint material, but it's way too late for that.

> "suggestion" to third parties by the key owner?

More precisely, are expiration times rewriteable?

I'm afraid that the answer has to be YES.  The specification has
clearly said so for a while now, and at least one implementation
(GnuPG) offers this capability.  If we change the rules now,
anyone who has taken advantage of it (or set a short expiration
time with the expectation that they can change it) will be
seriously disappointed.

---

From: Len Sassaman <[email-masked]>
Date: Mon, 23 Sep 2002 16:44:23 -0700 (PDT)

> *directly* from the owner, but that still doesn't cover all cases.

Wasn't the original suggestion that keys expire at the earliest expiration
time, and later expiration dates be ignored? That would address the
problem.

Jon's request is also solved, too, by using signature expirations as long
as keys without self-signatures are treated as invalid keys.

> The problem is that fingerprints don't include the expiration time.

I agree this is a problem.

> into the fingerprint material, but it's way too late for that.

I think there are several things that are put into self-sig rather than
the key that shouldn't be. I also think that having the "signing only" and
"encrypt only" flags in the self sig, and not in the key, is also a
mistake. (I feel guilty about this, since I think I was the one who
suggested PGP 7 do things as the spec recommends. I now think that's
broken.) :(

Attributes of the key that intended to be permanent really should be so.

> time with the expectation that they can change it) will be

In that case, expiration dates don't seem to mean what everyone thinks
they mean.

---

From: Jon Callas <[email-masked]>
Date: Mon, 23 Sep 2002 22:29:07 -0700

Actually, this has digressed.

Key expirations are not "my" system. They're the way the OpenPGP works. If
you create a key with an expiration and hand it to Alice, she'll think if
expires at that time. Call it Ta. You can turn right around, and lop off
that user name, re-create the user name and self-sig with another expiration
time on it and hand it to Bob (call that Tb). This works today. It's the way
it works. We've even had discussions here for years about re-writing
self-sigs and what you should do, and how you should interpret them, and
what happens when you have things like a designated revoker.

Now, as Bodo has suggested, there's a potential ambiguity here. In short,
what does it mean if Alice signs your key with no expiration (or one that is
after Ta)? Bodo suggests that this is a flaw. I claim it is not. If Alice
had wished to time-limit her certification, she should have, and it's not
for us to tell her how to do it.

I further claim that while this may be somewhat counterintuitive, it is a
useful and desirable feature, for someone to have different expirations on a
key depending on situation. Lastly, I claim that if you want to kill a key,
there is a mechanism for that -- revocation.

Now it has also been claimed that if someone were to steal your private key,
they could re-write your self-signature, and even un-expire a key. Yeah.
They can do a lot worse, too. In the immortal words words of Julie Brown's
blonde, "So what?"

Discussing what someone can do with a purloined key loses track of the real
issue. When you design a security system, among the things you need to
consider are the security of the system, but also its safety and
reliability.

Security systems and reliability systems are not the same. In fact, they are
frequently at odds with each other. For example, if you build a building,
you might put bars on windows as part of security. But you might also make
it so they can be opened from the inside as a safety and reliability issue
-- as a way of battling fire. Note that improving the safety characteristics
of the building may be orthogonal to its security aspects, or they may be in
direct opposition to it.

Key expirations are a reliability feature. Revocations are a security
feature. If you think a key has been compromised, revoke it! Don't expire
it! We even have a nifty "reason for revocation" feature. Revoking a key
with a reason of key compromise is a drastic and perhaps ironically
irrevocable step. It means that nothing about the key can be relied upon.

However, the reliability aspects of PGP certificates are under-used, and
needed. There is, for example, a whole swarm of keys out there in some
unknown state. Some are in use, some aren't, some are in an unknown state. I
have at least of each, myself.

In the past, various people have discussed handing this issue by explicitly
or implicitly expiring them. Some people have asserted that one should never
create a key that doesn't have a reasonable expiration time on it.

The problem with that idea is many-fold. One is there's no good way to know
what a reasonable time is. One year? Two? More? Less? Worse, if you expire
your key, there's no good way to transfer your old certification information
to the new key. So all that work you went through to get your key signed by
cool people has to be redone.

Long ago, perhaps before we started OpenPGP, I was of the opinion that there
had to be an "I used to be" statement in the language. This is difficult to
do correctly. I never came up with a decent design for it. Part of what shut
me up on it was the realization that with V4 keys putting expiration into a
self-sig and not the key packet, you can use something I call "rolling
validity" where you keep extending the expiration of your key until you
decide not to, or revoke it. This solves all sorts of reliability issues in
OpenPGP. Yes, it does nothing for security. It's not supposed to, it's a
reliability feature, not a security one. It *does* however solve the problem
of someone creating a key, putting it on a public keyserver, and then losing
the password a day later.

It helps me manage which keys are active, by making it so that if I put too
short an expiry on my key, I don't lose that nifty Phil Zimmermann sig on
it. Laugh if you want, but it is that very issue (perhaps not with PRZ
himself, but the broader issue) that keeps people from putting time limits
on their keys. If you guess wrong, you hurt yourself.

Expiration is not revocation. Do not expect it to solve the problem of
revocation. Likewise, revocation is not expiration. Revocation is
irrevocable. Expiration can be undone. This is the design of the language of
the system. The present behavior is in my opinion the correct and desirable
one.

    Jon

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 24 Sep 2002 10:38:26 +0200

On Mon, Sep 23, 2002 at 10:29:07PM -0700, Jon Callas wrote:

> key depending on situation.

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 in the sense that
Derek and others expect key expiration to work (namely such that the
bad guy cannot unexpire the key).  What speaks against this?

For version 3 keys, key expiration carries over into certifications,
and many users expect similar security properties for version 4 keys.

Notably, even Derek expected this, and still you refuse to even
mention this bug/feature/misunderstanding in the Security
Considerations of the specification.

>                             Lastly, I claim that if you want to kill a key,
> there is a mechanism for that -- revocation. [...]

I already commented on this:

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

If it's not clear what I mean with this I should probably formalize
the concepts and write a paper about the issue unless someone has
already done something like that.  Some keywords: formal proof
systems, default logic.

You say "revocation is irrevocable".  This is true in a sense, but
revocation is not as reliable as expiration that cannot be undone.

You say "expiration can be undone", but we also need some kind of
expiration that cannot be undone.  OpenPGP distinguishes between key
expiration and signature expiration, so we can use key expiration if
we want expiration that cannot be undone, and self-signature
expiration if we want expiration that can be undone.

A signing key has become invalid in the fullest sense only if you can
publish the corresponding secret key without causing any problems.
PKIs should offer entities a way to state that their keys are to be
considered invalid after some specific point of time.  Revocation does
not do this job very well because revocation packets may be
suppressed, so the invalidity date must be covered by the
certifications instead.

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 24 Sep 2002 10:58:38 +0200

On Mon, Sep 23, 2002 at 05:49:34PM -0400, Michael Young wrote:
> "Len Sassaman" <[email-masked]>:

> time with the expectation that they can change it) will be

Actually, they won't!

My proposal was: 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).

So if your key has a short expiration time, you can extend it, and new
certifications will use the new expiration time.

You mentioned GnuPG.  Note that GnuPG apparently already handles key
expiration in a safe way during certification:

< From: Werner Koch <[email-masked]>
< To: Jon Callas <[email-masked]>
< Cc: Bodo Moeller <[email-masked]>,
< 	OpenPGP <[email-masked]>
< Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
< Date: Sat, 21 Sep 2002 11:59:22 +0200

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

I hope Werner meant the *key* expiration date from the self-signature,
not the *signature* expiration date from the self-signature.  These
are different packet types.  Key expiration dates may be present only
in self-signatures according to the OpenPGP specification, so they
should be translated into signature expiration dates when certifying
keys; see Florians request at
<URL:http://lists.gnupg.org/pipermail/gnupg-devel/2001-July/006196.html>:

< [My patch] is a bit more complicated because it also works around the
< protocol error in RFC 2440 related to V4 key expiration (V4 key
< expiration time is not covered by certificates because it is only
< contained in the self signature, not in the key material, in contrast
< to V3 keys): If the key to be signed is a V4 key with an expiration
< time set, a V4 signature is made which expires at that time, too (or
< even earlier).

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 24 Sep 2002 11:21:28 +0200

On Mon, Sep 23, 2002 at 04:44:23PM -0700, Len Sassaman wrote:

> time, and later expiration dates be ignored?

No, that was not my proposal.  This was a suggestion by Richie Laager,
but actually it's incompatible with some details of my proposal:
it's okay for me to let key lifetime be extensible, it's just that
certifications should be valid only for the currently defined lifetime
of the key (during certification) so that all certifications become
worthless if the user lets the key expire.

It would be safer to have a fixed key expiry date as in version 3 keys
(but to have it covered by the fingerprint, unlike version 3).
However, I want compatibility with the version 4 format, and this
makes extensible key lifetime acceptable within my proposal.

>                                              That would address the

But not actually solve it: in general you cannot rely on seeing all
packets that are available on some keyserver, or that someone tries to
send to some keyserver (cf. my remarks on non-monotonous proof systems
elsewhere in this thread; this is essentially the same problem as with
revocation).  The "earliest expiration time" according to your keyring
may not be the actual earliest expiration time.

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 24 Sep 2002 13:18:57 +0200

On Mon, Sep 23, 2002 at 03:50:06PM -0400, Michael Young wrote:

> the key's (CURRENT) expiration time.

Legal?  Of course; the signer may have out-of-band information that a
long certification validity period is OK.  But by default, the current
key expiration time should not be exceeded.

---

From: David Shaw <[email-masked]>
Date: Tue, 24 Sep 2002 09:02:36 -0400

> <URL:http://lists.gnupg.org/pipermail/gnupg-devel/2001-July/006196.html>:

It is the key expiration date (i.e. subpacket 9, not subpacket 3).  I
want to point out that this is not something that GnuPG forces on the
user.  If a key has an expiration date, GnuPG prompts the user "This
key is due to expire on x/x/x.  Do you want your signature do expire
at the same time? (Y/n)".  If the signing user says "yes" (the
default), then that happens.  If the signing user says no, then they
are free to pick any expiration time, or none at all.  I think that is
the most appropriate solution here as the signer is still free to do
whatever they like.

In an ideal world (which we are not in), I think that a solution that
would solve all the concerns here is to define a v5 key format.  It
could contain an expiration date as part of the key, just like in v3
keys.  The expiration date in the key is the "hard" expiration.  The
user can shorten, but not extend, this via the "soft" expiration date
given in the self-signature.  (Incidentally, this is what GnuPG does
when it encounters v3 keys with v4 self-signatures.)  Of course, a new
key format would be brutal for interoperability, so is not a good
solution.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

---

From: Derek Atkins <[email-masked]>
Date: 24 Sep 2002 10:37:06 -0400

Before you go putting words in my mouth...

There are two opposing forces here. On the one had I want to be able
to continue using my key indefinitely (re-keying is a PitA).  On the
other hand, if it gets compromised I want to kill it (and make sure
the attacker cannot un-kill it).  The third case is where the user
loses their private key.

To make all three of these work, I agree with Jon that you need to
separate out the "this key is alive" from "this key is dead".  The
"Keepalives" are self-signatures with limited lifetimes.  I don't mind
re-signing my own key every year (or whatever period I want to
re-assert myself).  Note that this time period should not affect the
time period with which Alice asserts my key -- Alice should decide how
often they want to re-verify my key, I shouldn't dictate that to
Alice.

The "this key is dead" is necessarily a revocation.  If you go under
the assumption that data can only be added to a key and never removed,
then once you see a revocation anything else doesn't matter.  If the
attacker controls the keyserver and can remove revocations then
obviously this doesn't work, but I don't think an attacker can control
that many data points.

All I except from the system is that an attacker who gains access to
your private key cannot make it live longer than YOU want it to.

-derek

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 24 Sep 2002 17:08:20 +0200

I didn't.  You wrote:

From: Derek Atkins <[email-masked]>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt

A bad guy gets a copy of my private key..  If there is a key
expiration then they cannot keep it alive indefinitely.  Or is key
compromise not an attack you care about? ;)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

So apparently you think that key expiration should be final while
self-signature expiration is not.  If you have a different
interpretation of what you wrote, I'd like to hear it.

> [...]                            I agree with Jon that you need to
> "Keepalives" are self-signatures with limited lifetimes.

This is exactly what I am saying: use self-signatures with limited
lifetime (subpacket type 3) if you want to be able to keep the key
alive by re-signing later.  And use self-signatures with a key
expiration time (subpacket type 9) only if you want the key to finally
expire by then.

We have these two different subpacket types, so why not use them?!

---

From: "Michael Young" <[email-masked]>
Date: Tue, 24 Sep 2002 13:44:02 -0400

>Key expirations are not "my" system. They're the way the OpenPGP works. If
I agree with Jon's analysis.  Certainly, key expirations as they
are defined now are rewriteable.  His example (periodically
pushing the expiration out to account for possible LOSS) is
quite reasonable.  It MIGHT HAVE been reasonable to include
a form of irrevocable expiration that acts as an automatic
revocation (possibly in addition to the revocable, advisory
kind), but that's just not the way it works now.

Given that this is how they work, I'd really like to see language
in the expiration time section noting that they may be rewritten,
and that as such, they do not have any revocation-like effects.
Yes, this appears elsewhere, but someone reading the spec may
not put the pieces together, and make assumptions on how
expirations work (based on other systems or their intuition).
I can draft something if you'd like.

> We've even had discussions here for years about re-writing

This is another digression, but...

While I strongly believe in the ability to rewrite self-signatures, I
wouldn't go as far as to require that *all* subpackets be treated the
same in this regard.  For some, it might make sense for new values to
replace the old (preferences); here, I have argued that the old
self-signature should be revoked, but that didn't seem to catch on.
For some, new values may be additive; revocation keys have this
flavor -- they make no sense if they can be removed.
My point is simply that we shouldn't take the rewriting behavior
for key expiration as a general principle, or vice versa.

---

From: Len Sassaman <[email-masked]>
Date: Tue, 24 Sep 2002 11:40:53 -0700 (PDT)

> I can draft something if you'd like.

This is what I was asking for in my previous message. In the case that
expired keys can be brought back from the dead, (which is the current
behavior), we need to make it clear that expirations are merely an
indication that the key may no longer be in use, and have no security
properties.

---

From: Adrian von Bidder <[email-masked]>
Date: 25 Sep 2002 11:27:43 +0200

On Tue, 2002-09-24 at 16:37, Derek Atkins wrote:
> [...]If the

Depending on the attack scenario, it might suffice when one person does
not see a revocation certificate during a limited timeframe (while they
send some vital documents encrypted to the compromised key).

This only requires control of the network connection of one machine for
a specific time. Absolutely feasible.

cheers
-- vbi

-- 
secure email with gpg                           http://fortytwo.ch/gpg

NOTICE: subkey signature! request key 92082481 from keyserver.kjsl.com