Hi, Simon Josefsson <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (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. 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'. 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'. > 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. > 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. Thanks, Ludovic. _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
