Re: Fixing the secret keys, and a small apology
"Michael Young" <mwy-opgp97@the-youngs.org> Wed, 05 September 2001 18:10 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 OAA13737 for <openpgp-archive@odin.ietf.org>; Wed, 5 Sep 2001 14:10:16 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85HvFG02382 for ietf-openpgp-bks; Wed, 5 Sep 2001 10:57:15 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85Hv8D02378 for <ietf-openpgp@imc.org>; Wed, 5 Sep 2001 10:57:14 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id NAA78282 for <ietf-openpgp@imc.org>; Wed, 5 Sep 2001 13:49:15 -0400 (EDT)
Received: from mwyoung (dhcp-195-50.transarc.ibm.com [9.38.195.250]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id NAA25957 for <ietf-openpgp@imc.org>; Wed, 5 Sep 2001 13:57:04 -0400 (EDT)
Message-ID: <005501c13633$e3734960$fac32609@transarc.ibm.com>
From: Michael Young <mwy-opgp97@the-youngs.org>
To: ietf-openpgp@imc.org
References: <p05100309b7baf2e20a43@[192.168.1.180]> <87y9nuw09p.fsf@alberti.gnupg.de>
Subject: Re: Fixing the secret keys, and a small apology
Date: Wed, 05 Sep 2001 13:55:02 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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: 7bit
-----BEGIN PGP SIGNED MESSAGE----- From: "Werner Koch" <wk@gnupg.org> > Another question is the format. Should we include only the public > parameters or more stuff in the MDC? A solution I would like to see > is to just hash the fingerprint of the key along with the secret I prefer hashing the full packet (v4-style, even for any v3 packets that use an MDC), but I could live with hashing the fingerprint. Old v3 fingerprints are slightly flawed (in that they don't hash the MPI sizes), but I suppose an exploit does seem unlikely here. Hashing the whole thing just feels more consistent. > think of putting the secet parameters on a hardware token and there > might be not enough space to store the public parameters - the But this wouldn't be an OpenPGP format. The OpenPGP secret key packet includes the public key material. Of course, an implementation can use its own internal key storage format (and associated protection). When such a hardware-token transformation cuts off the public key parameters, it can cut off the MDC (and add a new one if it sees fit). The spec need only deal with transmission among OpenPGP implementations. Personally, I find it unlikely that an implementation would cut off the public key parameters at all. It would have to do so very selectively, as many of them are necessary for private key operations as well. It also seems to me that you'd want the card to be able to verify past results from its own key, in which case it might want the public parts. Lastly, it seems wise to perform consistency checks between the public/private parts even in the presence of an MDC. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBO5Zm4WNDnIII+QUHAQHkZwgAlvxLPocVqq1y9sumbVszcSzh/0+tvvOs 3GljV627UlSEY8CnvZa2cCJEqj3W3ZcQJJODPnJg7ZYhD1BUngQi0aar7n0FaIwz OBybBNjKoMtiQeoCiUY/TqIUuLomWSA1cT0Z0AGSDwGCwiv3UJ+q4EyxYAIQZqu2 FFD9KufBmf+w0sFXhASVkgtMj1+9NA+WIdlMiYthOFAFmwhWzC1EgvhNm4ASVhUx 6llurDAN9JhJuaCdkctYJw3zhD80gUyMzhvQb2VN0zKI1bz2PuaGnOB/OwJkifig R7B16UDthP4sjB/CaAxUCzvH1dbuQesSCw+no/KNWeiL+kMZejQPIA== =Sg/T -----END PGP SIGNATURE-----
- Fixing the secret keys, and a small apology Jon Callas
- Re: Fixing the secret keys, and a small apology Michael Young
- Identifying revoked certificates Michael Young
- Re: Fixing the secret keys, and a small apology Florian Weimer
- Re: Fixing the secret keys, and a small apology Werner Koch
- Re: Fixing the secret keys, and a small apology Michael Young
- Re: Fixing the secret keys, and a small apology Michael Young
- Re: Fixing the secret keys, and a small apology Werner Koch
- Re: Fixing the secret keys, and a small apology Jon Callas
- Re: Identifying revoked certificates Jon Callas
- Re: Identifying revoked certificates David Shaw
- Re: Identifying revoked certificates Michael Young
- Re: Identifying revoked certificates Jon Callas
- Re: Identifying revoked certificates Jon Callas
- Re: Identifying revoked certificates Michael Young
- Re: Identifying revoked certificates Werner Koch
- Re: Identifying revoked certificates Michael Young
- Re: Identifying revoked certificates Werner Koch