Re: Secret key transport (Daniel A. Nagy) Tue, 18 April 2006 22:00 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FVyF7-0002bE-UO for; Tue, 18 Apr 2006 18:00:17 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1FVyF6-0000Ui-Ir for; Tue, 18 Apr 2006 18:00:17 -0400
Received: from (localhost []) by (8.13.5/8.13.5) with ESMTP id k3ILg6Wn027273; Tue, 18 Apr 2006 14:42:06 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.13.5/8.13.5/Submit) id k3ILg6Pr027272; Tue, 18 Apr 2006 14:42:06 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.13.5/8.13.5) with ESMTP id k3ILg3hA027257 for <>; Tue, 18 Apr 2006 14:42:06 -0700 (MST) (envelope-from
Received: by (Postfix, from userid 1001) id AC2D12CF3; Tue, 18 Apr 2006 23:41:55 +0200 (CEST)
Date: Tue, 18 Apr 2006 23:41:55 +0200
To: Jon Callas <>
Cc: OpenPGP <>
Subject: Re: Secret key transport
Message-ID: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.9i
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2

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