headers
Jon Callas | 18 Apr 2006 21:40
Gravatar

Re: Secret key transport


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
(Continue reading)

Permalink | Reply |
headers
Daniel A. Nagy | 18 Apr 2006 23:41

Re: Secret key transport


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).
(Continue reading)

Permalink | Reply |
headers
David Shaw | 19 Apr 2006 00:56

Re: Secret key transport


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
(Continue reading)

Permalink | Reply |
headers
Daniel A. Nagy | 19 Apr 2006 12:35

Re: Secret key transport


On Tue, Apr 18, 2006 at 06:56:37PM -0400, David Shaw wrote:

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

Maybe. I will double-check.

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

I know.

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

I support this proposal.

--

-- 
Daniel
(Continue reading)

Permalink | Reply |
headers
Jon Callas | 19 Apr 2006 20:36
Gravatar

Re: Secret key transport


On 19 Apr 2006, at 3:35 AM, Daniel A. Nagy wrote:

>> 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.
>
> I support this proposal.
>

That's pretty much in bis16.

	Jon
Permalink | Reply |
headers
Jon Callas | 19 Apr 2006 01:12
Gravatar

Re: Secret key transport


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

	Jon
Permalink | Reply |

Gmane