Re: Secret key transport

nagydani@epointsystem.org (Daniel A. Nagy) Tue, 18 April 2006 22:00 UTC

Date: Tue, 18 Apr 2006 23:41:55 +0200
To: Jon Callas <jon@callas.org>
Cc: OpenPGP <ietf-openpgp@imc.org>
Subject: Re: Secret key transport
Message-ID: <20060418214155.GA5012@epointsystem.org>
References: <20051214135609.GA22783@jabberwocky.com> <59A2A036-CFF5-4C28-9B84-9345BD5EBC0F@callas.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <59A2A036-CFF5-4C28-9B84-9345BD5EBC0F@callas.org>
User-Agent: Mutt/1.5.9i
From: nagydani@epointsystem.org
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk

On Tue, Apr 18, 2006 at 12:40:00PM -0700, Jon Callas wrote:
> On 14 Dec 2005, at 5:56 AM, David Shaw wrote about secret keys
> [snipped]
> Since no one has said anything in months, I'm declaring that the  
> answer is, "no, this is not something that needs a line or two of text."

I think, this problem merits a little bit of discussion, as there are some
interoperability issues at stake.

Firstly, I think that 5.5.1.3. should make it clear that secret key packets
are standardized for the purposes of exporting and importing secret key
material. As far as interoperability is concerned, fully OpenPGP-compliant
implementations may store private keys any way they like.

As for importing and exporting, a major player (namely WK's GnuPG) rejects
private key blocks that do not contain binding self-signatures for UIDs and
subkeys. Moreover, the required binding signatures bind the material in
question to the corresponding PUBLIC key, not the private one. I am not sure
why they chose to do it this way, but I am strongly opposed to mandating
this behavior in the standard, as it would make some other existing
implementations non-compliant. The semantics of a secret key packet is the
following: "Here's a public key and its (possibly encrypted) private
counterpart." That's it.

I agree with Jon that there is no point in defining secret key blocks in
the standard. Let implementations handle secret key packets as they see fit
(including not handling them at all -- after all, being able to import and
export private keys is an option, not a requirement).

-- 
Daniel