Re: Diffs for next draft

Werner Koch <wk@gnupg.org> Sat, 25 August 2001 11:13 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09659 for <openpgp-archive@odin.ietf.org>; Sat, 25 Aug 2001 07:13:56 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id f7PAxmk21132 for ietf-openpgp-bks; Sat, 25 Aug 2001 03:59:48 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PAxiD21112 for <ietf-openpgp@imc.org>; Sat, 25 Aug 2001 03:59:45 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15ac2b-0004kd-00; Sat, 25 Aug 2001 13:55:53 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15abE4-0007Ae-00; Sat, 25 Aug 2001 13:03:40 +0200
To: ietf-openpgp@imc.org
Subject: Re: Diffs for next draft
References: <p05100303b7aaf65aff68@[192.168.1.180]> <008601c12c52$1b6181c0$c23fa8c0@transarc.ibm.com> <p0510031fb7ab945664e5@[192.168.1.180]>
From: Werner Koch <wk@gnupg.org>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://wk@g10code.com
Date: Sat, 25 Aug 2001 13:03:40 +0200
In-Reply-To: <p0510031fb7ab945664e5@[192.168.1.180]> (Jon Callas's message of "Fri, 24 Aug 2001 16:42:36 -0700")
Message-ID: <87lmk8l7ub.fsf@alberti.gnupg.de>
Lines: 26
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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>

On Fri, 24 Aug 2001 16:42:36 -0700, Jon Callas said:

> This is my point: I don't see an obvious best answer. Furthermore, 2440 is
> a data specification standard, not a user interface guide or software
> construction manual. It tells implementers the things they have to do to be

I really agree with you here.  There are already so many
implementation details in OpenPGP which frankly don't belong there but
can be justified due to the fact that OpenPGP is the specification of
a long standing de-facto standard.

Adding more of these implementation stuff will eventually make OpenPGP
as complicated and bloated as SET.  There are already a lot of concerns
on the complexity of OpenPGP saying that this won't increase security.

The secret key protection is a flaw in the standard and has to be
addressed. Well, the most simple way of addressing it is to say: an
implementation should never send a secret key packet without and
additonal layer of encryption. OTOH, we have the protection and we
should make sure that it this gives us a real protection.


-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus