Subject: Re: Secret key transport

From: Jon Callas <[email-masked]>
Date: Tue, 18 Apr 2006 12:40:00 -0700

On 14 Dec 2005, at 5:56 AM, David Shaw wrote:

>
> Well into comically late in the game here, but a question recently
> came up about the secret key transport format.  Namely, is there one?
> 2440bis has a public key transport format (the whole of section 10.1),
> and the format of secret key and secret subkey packets is defined, but
> there doesn't seem to be an analogue to section 10.1 for secret keys.
>
> For example, I've seen secret keys in this format:
>
>  - Secret key packet
>  - User ID packet
>  - Selfsig on user ID
>  - Secret subkey packet
>  - Selfsig on subkey
>
> I've also seen secret keys in this format:
>
>  - Secret key packet
>  - User ID packet
>  - Secret subkey packet
>
>  (i.e. missing the selfsigs).
>
> The first example strikes me as preferable as there is a mild benefit
> to having the secret key format parallel the public key format in that
> an implementation can extract the public key from the secret key
> automatically.  The second example requires a public key to be sent in
> addition to the secret key to get the selfsigs (while the selfsig on
> the user ID is optional, the one on the subkey isn't).
>
> Either way, though, 2440bis seems silent on this subject.  Is this
> something that needs a line or two of text?

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

	Jon

---

From: [email-masked] (Daniel A. Nagy)
Date: Tue, 18 Apr 2006 23:41:55 +0200

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]

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

---

From: David Shaw <[email-masked]>
Date: Tue, 18 Apr 2006 18:56:37 -0400

> implementations may store private keys any way they like.

I don't think anyone was arguing otherwise.  My original mail was
simply noting that there is not a single word in the standard of how
to export a secret key.  Export, not store.

> subkeys.

I think there is some misunderstanding here about what happens on
secret key import in GnuPG.  GnuPG, like PGP, tries to automatically
convert a secret key to a public key on import if the public key
doesn't already exist in the keyring.  They can do this because secret
key packets are essentially a public key packet with the secret data
stuck on the end.  This isn't mandated (or even mentioned) by the
standard, of course, but is a convenience.

The difference is that GnuPG prints a warning when it could not do
this automatic conversion because of missing self-signatures.  PGP is
(probably more appropriately) quiet.  I think you are interpreting
that warning message as a rejection.

> Moreover, the required binding signatures bind the material in
> implementations non-compliant.

All binding signatures bind to the public key.  There is no such thing
as a secret key binding signature.

Here's a minimal-change proposal:

Rename section 10.1 from "Transferable Public Keys" to "Transferable
Keys", and add to the end of the section:

    Secret keys may be transferred in the same manner and format as
    public keys by replacing any public key packets with the
    corresponding secret key packets and and public subkey packets with
    the corresponding secret subkey packets.

David

---

From: Jon Callas <[email-masked]>
Date: Tue, 18 Apr 2006 16:12:59 -0700

I found some suggested text that David gave me last year since  
sending that. I added it in.

	Jon

---

From: [email-masked] (Daniel A. Nagy)
Date: Wed, 19 Apr 2006 12:35:20 +0200

> that warning message as a rejection.

Maybe. I will double-check.
 
> as a secret key binding signature.

I know.
 
>     the corresponding secret subkey packets.

I support this proposal.

-- 
Daniel

---

From: Jon Callas <[email-masked]>
Date: Wed, 19 Apr 2006 11:36:30 -0700

>>     the corresponding secret subkey packets.

That's pretty much in bis16.

	Jon