Re: Fixing the secret keys, and a small apology

Werner Koch <wk@gnupg.org> Wed, 05 September 2001 19:54 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 PAA20537 for <openpgp-archive@odin.ietf.org>; Wed, 5 Sep 2001 15:54:57 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85JkYf04938 for ietf-openpgp-bks; Wed, 5 Sep 2001 12:46:34 -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 f85JkQD04931 for <ietf-openpgp@imc.org>; Wed, 5 Sep 2001 12:46:26 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15ejXp-0002sd-00; Wed, 05 Sep 2001 22:45:09 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15eigt-0003Lo-00; Wed, 05 Sep 2001 21:50:27 +0200
To: Michael Young <mwy-opgp97@the-youngs.org>
Cc: ietf-openpgp@imc.org
Subject: Re: Fixing the secret keys, and a small apology
References: <p05100309b7baf2e20a43@[192.168.1.180]> <87y9nuw09p.fsf@alberti.gnupg.de> <005501c13633$e3734960$fac32609@transarc.ibm.com>
From: Werner Koch <wk@gnupg.org>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://wk@g10code.com
Date: Wed, 05 Sep 2001 21:50:27 +0200
In-Reply-To: <005501c13633$e3734960$fac32609@transarc.ibm.com> ("Michael Young"'s message of "Wed, 5 Sep 2001 13:55:02 -0400")
Message-ID: <873d61wh6k.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 Wed, 5 Sep 2001 13:55:02 -0400, Michael Young said:

> But this wouldn't be an OpenPGP format.  The OpenPGP secret key packet

Right. It is an implementation detail which would help to avoid
unprotecting and re-protecting when transferring keys.

> Personally, I find it unlikely that an implementation would cut off
> the public key parameters at all.  It would have to do so very

I know devices which do not have enough storage capacity for all
parameters. 

> public parts.  Lastly, it seems wise to perform consistency checks
> between the public/private parts even in the presence of an MDC.

I don't see a reason for this, if the MDC would not provide a sound
consistency check, what else would do?


   Werner

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