Re: Secret key transport

[David Shaw <[e-mail]>]

On Tue, Apr 18, 2006 at 11:41:55PM +0200, Daniel A. Nagy wrote:
> 
> 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.

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.

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

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

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