[Help-gnutls] Re: Failure to import an OpenPGP private key

[Simon Josefsson]

address@hidden (Ludovic Courtès) writes:

> Hi,
>
> Simon Josefsson <address@hidden> writes:
>
>> address@hidden (Ludovic Courtès) writes:
>>
>>> Hi,
>>>
>>> I tried importing the ASCII-armored OpenPGP secret key available under
>>> `src/openpgp/sec.asc' as follows:
>>>
>>>   err = gnutls_openpgp_privkey_import (privkey, &key_content,
>>>                                    GNUTLS_OPENPGP_FMT_BASE64,
>>>                                    "" /* empty passphrase */,
>>>                                    0 /* flags? */);
>>>
>>> It systematically returns `GNUTLS_E_OPENPGP_GETKEY_FAILED'.  This is
>>> actually the exact same problem that I reported a while back [0].  Could
>>> you please comment on this?
>>
>> Hi Ludovic, I'm sorry for the slow response.
>>
>> It is probably a bug in OpenCDK.  Your best bet is to debug this
>> further yourself, like using gdb to find where the error is triggered,
>> and possibly try to guess why it happens and how to fix it.
>
> Looking at `cdk_pkt_read ()' (which is used by
> `cdk_keydb_get_keyblock ()', which in turn is called by
> `gnutls_openpgp_privkey_import ()') allowed me to guess that CDK
> actually expects _binary_ private keys and not ASCII-armored keys.
>
> Thus, I tried passing it a private key produced by:
>
>   $ gpg --export-secret-key THE-KEY
>
> and importing it does indeed work.

Ah.  I have some vague recollection that this has been mentioned
before, so it may be a known bug.

> This can be seen as a GnuTLS bug since the FORMAT argument of
> `gnutls_openpgp_privkey_import' is not honored.  Does CDK provide a way
> to import ASCII-armored private keys?  Otherwise, `privkey_import'
> should return `UNIMPLEMENTED_FEATURE' when FORMAT is not `RAW'.

I agree.  There is code in OpenCDK to decode ASCII-armored data, so I
suspect there is some minor bug that prevents this from working.

Maybe you could single-step `gnutls_openpgp_privkey_import' to find
out why it doesn't work?  The function seem to eventually call
_gnutls_openpgp_raw_privkey_to_gkey, which in the docstring claims to
be able to read both BASE64 and RAW keys, so maybe you could even
start debugging that function.

> BTW, is there an API documentation for OpenCDK?  Some of the function
> names are self-explanatory, but some are not.  In particular, I don't
> understand the `keydb' in `cdk_keydb_get_keyblock'.

Have you seen
<http://www.gnu.org/software/gnutls/reference/gnutls-opencdk.html>?

Although that particular function doesn't seem to be documented
there...  The keydb seem to be the output parameter, compare code in
gnutls_openpgp.c:

  cdk_keydb_get_keyblock (out, &snode);
  if (!snode)
...

  pkt = cdk_kbnode_find_packet (snode, CDK_PKT_SECRET_KEY);
  if (!pkt)
...

I'm not an OpenCDK expert, so you might know as much as I do on this.
Please debug as much as possible and submit improved documentation
based on what you find out!

>> I don't think it has anything to do with remote servers, which you
>> suggested in your last post -- there is no such functionality in
>> GnuTLS/OpenCDK as far as I know.
>
> I was wondering what `GETKEY_FAILED' could really mean.  From my current
> understanding, it seems that `IMPORT_FAILED' would be more appropriate.

GETKEY_FAILED seem to be a general "no such key" error.

>> We could also consider if OpenCDK is the best option here, or whether
>> it is possible to somehow use GnuPG instead.  Using gpg might have
>> other good side effects, such as nice smart card integration, and
>> better web-of-trust management.  This approach might mean more work
>> initially, though.
>
> Yes, indeed.  I think Werner Koch had CC'd you the following message:
>
>   http://lists.gnupg.org/pipermail/gnupg-users/2006-August/029125.html
>
> In particular, the issues raised in the thread above were:
>
>   1. You don't necessarily want to store your private key in a file or
>      otherwise copy it in order to use it with GnuTLS.
>
>   2. Sometimes you can't even export your private key, for instance when
>      it's stored in a smartcard that doesn't provide this operation.

I agree with both.  The only problem is finding time and resources to
work on implementing a change...  If you have a strong interested in
this, feel free to contact me privately and I can offer a price quote
to work on achieving something in this area.  Of course, if you want
to work on this yourself, I'd be happy to discuss how to do this and
review and install patches.

/Simon