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

Derek Atkins <> Tue, 24 September 2002 14:49 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id KAA00328 for <>; Tue, 24 Sep 2002 10:49:10 -0400 (EDT)
Received: (from majordomo@localhost) by (8.11.6/8.11.3) id g8OEbRl21753 for ietf-openpgp-bks; Tue, 24 Sep 2002 07:37:27 -0700 (PDT)
Received: from (PACIFIC-CARRIER-ANNEX.MIT.EDU []) by (8.11.6/8.11.3) with ESMTP id g8OEbQv21749 for <>; Tue, 24 Sep 2002 07:37:26 -0700 (PDT)
Received: from (CENTRAL-CITY-CARRIER-STATION.MIT.EDU []) by (8.9.2/8.9.2) with ESMTP id KAA00219; Tue, 24 Sep 2002 10:37:24 -0400 (EDT)
Received: from (MANAWATU-MAIL-CENTRE.MIT.EDU []) by (8.9.2/8.9.2) with ESMTP id KAA15537; Tue, 24 Sep 2002 10:37:12 -0400 (EDT)
Received: from (KIKKI.MIT.EDU []) by (8.9.2/8.9.2) with ESMTP id KAA26516; Tue, 24 Sep 2002 10:37:06 -0400 (EDT)
Received: (from warlord@localhost) by (8.9.3) id KAA13920; Tue, 24 Sep 2002 10:37:06 -0400 (EDT)
To: Bodo Moeller <>
Cc: Jon Callas <>, OpenPGP <>
From: Derek Atkins <>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
References: <> <> <>
Date: 24 Sep 2002 10:37:06 -0400
In-Reply-To: <>
Message-ID: <>
Lines: 99
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by id g8OEbQv21750
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
Content-Transfer-Encoding: 8bit

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

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.


Bodo Moeller <>; writes:

> 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. [...]
> > 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.
> 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.
> -- 
> Bodo Möller <>;
> * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
> * Tel. +49-6151-16-6628, Fax +49-6151-16-6036

       Derek Atkins
       Computer and Internet Security Consultant