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

Derek Atkins <derek@ihtfp.com> Tue, 24 September 2002 14:49 UTC

Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00328 for <openpgp-archive@lists.ietf.org>; Tue, 24 Sep 2002 10:49:10 -0400 (EDT)
Received: (from majordomo@localhost) by above.proper.com (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 (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g8OEbQv21749 for <ietf-openpgp@imc.org>; Tue, 24 Sep 2002 07:37:26 -0700 (PDT)
Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (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 (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA15537; Tue, 24 Sep 2002 10:37:12 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA26516; Tue, 24 Sep 2002 10:37:06 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA13920; Tue, 24 Sep 2002 10:37:06 -0400 (EDT)
To: Bodo Moeller <moeller@cdc.informatik.tu-darmstadt.de>
Cc: Jon Callas <jon@callas.org>, OpenPGP <ietf-openpgp@imc.org>
From: Derek Atkins <derek@ihtfp.com>
Subject: Re: draft-ietf-openpgp-rfc2440bis-06.txt
References: <Pine.LNX.4.30.QNWS.0209231142100.22100-100000@thetis.deor.org> <B9B54633.9809%jon@callas.org> <20020924103826.D3563@cdc.informatik.tu-darmstadt.de>
Date: 24 Sep 2002 10:37:06 -0400
In-Reply-To: <20020924103826.D3563@cdc.informatik.tu-darmstadt.de>
Message-ID: <sjmsmzzmp2l.fsf@kikki.mit.edu>
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 above.proper.com id g8OEbQv21750
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
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
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

Bodo Moeller <moeller@cdc.informatik.tu-darmstadt.de>; 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 <moeller@cdc.informatik.tu-darmstadt.de>;
> 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

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek@ihtfp.com             www.ihtfp.com