From jberkman at novell.com  Mon Apr  9 18:51:02 2007
From: jberkman at novell.com (Jacob Berkman)
Date: Mon, 09 Apr 2007 12:51:02 -0400
Subject: [gnutls-dev] sign callback for certificate authentication
Message-ID: <461A36B7020000960002E069@mcclure.wal.novell.com>

Hello,

I've attached a patch to gnutls which adds a callback for the signing
step of certificate-based authentication.  This was needed because
some smart card policies do not allow private keys to be read/exported
from them.  They implement signing directly on the card.

With this patch, the application can return a NULL private key, and if
they implement the signing callback, can sign the data themselves.

I developed this patch against gnutls 1.4.4, but it patches and builds
cleanly against 1.7.7.  Please let me know if any changes are
required.

Thanks,
 -- jacob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-1.7.7-sign-callback.patch
Type: application/octet-stream
Size: 4669 bytes
Desc: not available
URL: </pipermail/attachments/20070409/3ccfd778/attachment.obj>

From ludo at chbouib.org  Mon Apr  9 23:16:14 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 09 Apr 2007 23:16:14 +0200
Subject: [gnutls-dev] Buglet in `gnutls_certificate_set_openpgp_key ()'
Message-ID: <87tzvpjlk1.fsf@chbouib.org>

Hi,

The patch below fixes a (funny) bug in
`gnutls_certificate_set_openpgp_key ()'.

Thanks,
Ludovic.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ,openpgp.diff
Type: text/x-patch
Size: 552 bytes
Desc: The patch
URL: </pipermail/attachments/20070409/d7e5fe00/attachment.bin>

From simon at josefsson.org  Tue Apr 10 11:57:17 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 10 Apr 2007 11:57:17 +0200
Subject: [gnutls-dev] Buglet in `gnutls_certificate_set_openpgp_key ()'
In-Reply-To: <87tzvpjlk1.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Mon\, 09 Apr 2007 23\:16\:14 +0200")
References: <87tzvpjlk1.fsf@chbouib.org>
Message-ID: <87lkh0tuv6.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> Hi,
>
> The patch below fixes a (funny) bug in
> `gnutls_certificate_set_openpgp_key ()'.

Hi!  Looks correct to me (the old code never worked at all, right?).
Installed.

Thanks,
Simon

> Thanks,
> Ludovic.
>
> --- orig/libextra/gnutls_openpgp.c
> +++ mod/libextra/gnutls_openpgp.c
> @@ -1257,7 +1257,13 @@ gnutls_certificate_set_openpgp_key (gnut
>        return GNUTLS_E_MEMORY_ERROR;
>      }
>  
> -  res->cert_list[res->ncerts] = NULL;	/* for realloc */
> +  res->cert_list[res->ncerts] = gnutls_calloc (1, sizeof (gnutls_cert));
> +  if (res->cert_list[res->ncerts] == NULL)
> +    {
> +      gnutls_assert ();
> +      return GNUTLS_E_MEMORY_ERROR;
> +    }
> +
>    res->cert_list_length[res->ncerts] = 1;
>  
>    ret = _gnutls_openpgp_key_to_gcert (res->cert_list[res->ncerts], key);
>
> _______________________________________________
> Gnutls-dev mailing list
> Gnutls-dev at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-dev



From simon at josefsson.org  Tue Apr 10 12:01:33 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 10 Apr 2007 12:01:33 +0200
Subject: [gnutls-dev] sign callback for certificate authentication
In-Reply-To: <461A36B7020000960002E069@mcclure.wal.novell.com> (Jacob
	Berkman's message of "Mon\, 09 Apr 2007 12\:51\:02 -0400")
References: <461A36B7020000960002E069@mcclure.wal.novell.com>
Message-ID: <87hcrotuo2.fsf@mocca.josefsson.org>

"Jacob Berkman" <jberkman at novell.com> writes:

> Hello,
>
> I've attached a patch to gnutls which adds a callback for the signing
> step of certificate-based authentication.  This was needed because
> some smart card policies do not allow private keys to be read/exported
> from them.  They implement signing directly on the card.
>
> With this patch, the application can return a NULL private key, and if
> they implement the signing callback, can sign the data themselves.
>
> I developed this patch against gnutls 1.4.4, but it patches and builds
> cleanly against 1.7.7.  Please let me know if any changes are
> required.

Hi!  This seems quite useful.  Ultimately, we probably should support
protocols like PKCS#11 to externalize the signing requests, and I have
been planning to work on this.  It may be that your APIs need to
modified slightly to better integrate with that.  Anyway, I'm rather
busy now, and won't be able to work on the PKCS#11 stuff in the next
1-2 weeks.  If your patch works now, we should install it rather than
wait.  To be able to install your patch, however, we need an
assignment of the copyright to the FSF.  Is this a problem?  Let me
know privately and I'll send it to you.

/Simon



From ludovic.courtes at laas.fr  Tue Apr 10 18:26:09 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 10 Apr 2007 18:26:09 +0200
Subject: [gnutls-dev] Buglet in `gnutls_certificate_set_openpgp_key ()'
References: <87tzvpjlk1.fsf@chbouib.org> <87lkh0tuv6.fsf@mocca.josefsson.org>
Message-ID: <87y7l02o2m.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Hi!  Looks correct to me (the old code never worked at all, right?).

I don't think the old code could have ever worked.  ;-)  I wonder what
the `/* for realloc */' comment was about, though.

Thanks,
Ludovic.




From simon at josefsson.org  Wed Apr 11 09:35:29 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 11 Apr 2007 09:35:29 +0200
Subject: [gnutls-dev] Buglet in `gnutls_certificate_set_openpgp_key ()'
In-Reply-To: <87y7l02o2m.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Tue\, 10
	Apr 2007 18\:26\:09 +0200")
References: <87tzvpjlk1.fsf@chbouib.org> <87lkh0tuv6.fsf@mocca.josefsson.org>
	<87y7l02o2m.fsf@laas.fr>
Message-ID: <87ejmrmkhq.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Hi!  Looks correct to me (the old code never worked at all, right?).
>
> I don't think the old code could have ever worked.  ;-)  I wonder what
> the `/* for realloc */' comment was about, though.

Perhaps older code did realloc, or the intention was to realloc, the
pointer if it wasn't already allocated, but I cannot find this realloc
in the current code.

Thanks,
Simon



From ametzler at downhill.at.eu.org  Sun Apr 15 13:43:11 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 15 Apr 2007 13:43:11 +0200
Subject: [gnutls-dev] Trivial patch - compiler warnings about uninitialized
	variables
Message-ID: <20070415114311.GB3803@downhill.g.la>

Hello,

attached a trivial patch to get rid of a couple of compiler warnings a
la "warning: 'i' may be used uninitialized in this function" in 1.7.7.

If you think this would need a copyright assignment you can easily
reconstruct the needed code changes from the attached compilelog.diff.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: somewarnings.diff
Type: text/x-diff
Size: 3044 bytes
Desc: not available
URL: </pipermail/attachments/20070415/9f182b89/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: buildlog.diff
Type: text/x-diff
Size: 9455 bytes
Desc: not available
URL: </pipermail/attachments/20070415/9f182b89/attachment-0001.diff>

From ludovic.courtes at laas.fr  Mon Apr 16 14:15:22 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 16 Apr 2007 14:15:22 +0200
Subject: [gnutls-dev] sign callback for certificate authentication
References: <461A36B7020000960002E069@mcclure.wal.novell.com>
Message-ID: <87hcrgseg5.fsf@laas.fr>

Hi,

"Jacob Berkman" <jberkman at novell.com> writes:

> I've attached a patch to gnutls which adds a callback for the signing
> step of certificate-based authentication.  This was needed because
> some smart card policies do not allow private keys to be read/exported
> from them.  They implement signing directly on the card.

I think this is a very good idea.

However, in your patch, you defined signing functions as:

  typedef int gnutls_certificate_client_sign_function (gnutls_session_t session,
                                                       gnutls_datum_t * cert,
                                                       gnutls_certificate_type_t cert_type,
                                                       const gnutls_datum_t *hash_concat,
                                                       gnutls_datum_t *
                                                       signature);

I think this suffers from the same shortcomings as most call-backs
defined in GnuTLS: one cannot attach additional data to be passed along
to the sign function.

Thus, I would instead recommend adding a `void *' parameter to
`gnutls_certificate_client_sign_function'; the
`gnutls_certificate_client_set_sign_function ()' needs to be modified
accordingly:

  void gnutls_certificate_client_set_sign_function
    (gnutls_certificate_credentials_t cred,
     gnutls_certificate_client_sign_function * func,
     void *user_data);

This way, USER_DATA would be passed as the last argument of FUNC each
time it is called.


Call-back APIs that fail to provide this make it hard to communicate
information to call-backs in a "safe" way: one has to resort to global
variables or some such, which makes code harder to read and is not
recommended in multi-threaded applications.  Likewise, it makes it hard
to implement bindings for higher-level languages.

Thanks,
Ludovic.




From simon at josefsson.org  Mon Apr 16 15:06:35 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Apr 2007 15:06:35 +0200
Subject: [gnutls-dev] Trivial patch - compiler warnings about
	uninitialized variables
In-Reply-To: <20070415114311.GB3803@downhill.g.la> (Andreas Metzler's message
	of "Sun\, 15 Apr 2007 13\:43\:11 +0200")
References: <20070415114311.GB3803@downhill.g.la>
Message-ID: <87ps645uzo.fsf@mocca.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> Hello,
>
> attached a trivial patch to get rid of a couple of compiler warnings a
> la "warning: 'i' may be used uninitialized in this function" in 1.7.7.

Hi!  Thanks, installed.

> If you think this would need a copyright assignment you can easily
> reconstruct the needed code changes from the attached compilelog.diff.

I think these were trivial..

/Simon



From simon at josefsson.org  Mon Apr 16 15:10:44 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Apr 2007 15:10:44 +0200
Subject: [gnutls-dev] sign callback for certificate authentication
In-Reply-To: <87hcrgseg5.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Mon\, 16
	Apr 2007 14\:15\:22 +0200")
References: <461A36B7020000960002E069@mcclure.wal.novell.com>
	<87hcrgseg5.fsf@laas.fr>
Message-ID: <87lkgs5usr.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> However, in your patch, you defined signing functions as:
>
>   typedef int gnutls_certificate_client_sign_function (gnutls_session_t session,
>                                                        gnutls_datum_t * cert,
>                                                        gnutls_certificate_type_t cert_type,
>                                                        const gnutls_datum_t *hash_concat,
>                                                        gnutls_datum_t *
>                                                        signature);
>
> I think this suffers from the same shortcomings as most call-backs
> defined in GnuTLS: one cannot attach additional data to be passed along
> to the sign function.
>
> Thus, I would instead recommend adding a `void *' parameter to
> `gnutls_certificate_client_sign_function'; the
> `gnutls_certificate_client_set_sign_function ()' needs to be modified
> accordingly:
>
>   void gnutls_certificate_client_set_sign_function
>     (gnutls_certificate_credentials_t cred,
>      gnutls_certificate_client_sign_function * func,
>      void *user_data);
>
> This way, USER_DATA would be passed as the last argument of FUNC each
> time it is called.
>
>
> Call-back APIs that fail to provide this make it hard to communicate
> information to call-backs in a "safe" way: one has to resort to global
> variables or some such, which makes code harder to read and is not
> recommended in multi-threaded applications.  Likewise, it makes it hard
> to implement bindings for higher-level languages.

In general, I agree, and we should make it easier to use callbacks.

However, what do you think about doing this via the 'session'
parameter, rather than having to change the signatures of the
callback-related functions?  I'm thinking:

void
gnutls_session_set_appdata (gnutls_session_t session, void *p);
void *p
gnutls_session_get_appdata (gnutls_session_t session);

Perhaps more than one such pointer is necessary, and if so, how about:

void
gnutls_session_set_appdata (gnutls_session_t session, void *p, size_t n);
void *p
gnutls_session_get_appdata (gnutls_session_t session, size_t n);

What do you think?

The advantage with this approach is that it should be possible to use
in existing callbacks, and consistency between various callbacks is
good.

/Simon



From simon at josefsson.org  Mon Apr 16 15:25:51 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Apr 2007 15:25:51 +0200
Subject: [gnutls-dev] sign callback for certificate authentication
In-Reply-To: <87lkgs5usr.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon\, 16 Apr 2007 15\:10\:44 +0200")
References: <461A36B7020000960002E069@mcclure.wal.novell.com>
	<87hcrgseg5.fsf@laas.fr> <87lkgs5usr.fsf@mocca.josefsson.org>
Message-ID: <87abx85u3k.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> void
> gnutls_session_set_appdata (gnutls_session_t session, void *p);
> void *p
> gnutls_session_get_appdata (gnutls_session_t session);

I just noticed we already have these:

  void gnutls_session_set_ptr (gnutls_session_t session, void *ptr);
  void *gnutls_session_get_ptr (gnutls_session_t session);

So the previous interface is already covered.

For the transport callbacks we have:

  void gnutls_transport_set_ptr (gnutls_session_t session,
				 gnutls_transport_ptr_t ptr);
  void gnutls_transport_set_ptr2 (gnutls_session_t session,
				  gnutls_transport_ptr_t recv_ptr,
				  gnutls_transport_ptr_t send_ptr);

  gnutls_transport_ptr_t gnutls_transport_get_ptr (gnutls_session_t session);
  void gnutls_transport_get_ptr2 (gnutls_session_t session,
				  gnutls_transport_ptr_t * recv_ptr,
				  gnutls_transport_ptr_t * send_ptr);

/Simon



From ludovic.courtes at laas.fr  Mon Apr 16 16:14:41 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 16 Apr 2007 16:14:41 +0200
Subject: [gnutls-dev] sign callback for certificate authentication
References: <461A36B7020000960002E069@mcclure.wal.novell.com>
	<87hcrgseg5.fsf@laas.fr> <87lkgs5usr.fsf@mocca.josefsson.org>
Message-ID: <87ejmko17y.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> void
> gnutls_session_set_appdata (gnutls_session_t session, void *p);
> void *p
> gnutls_session_get_appdata (gnutls_session_t session);

`gnutls_session_set_ptr ()' is session-global, making it inconvenient,
at best.  For instance, one call-back may need a specific type of
information, while another needs something completely different.  In
some cases, it might be possible to devise a big structure that
encompasses all these needs and pass this to `gnutls_session_set_ptr ()'.
Call-backs would then `get_ptr ()' and extract the relevant
information.

However, that leads to complex code where all call-backs have to be
aware of each other.  Or there must be an indirection hiding that.
Overall, it may prove inconvenient

> Perhaps more than one such pointer is necessary, and if so, how about:
>
> void
> gnutls_session_set_appdata (gnutls_session_t session, void *p, size_t n);
> void *p
> gnutls_session_get_appdata (gnutls_session_t session, size_t n);
>
> What do you think?
>
> The advantage with this approach is that it should be possible to use
> in existing callbacks, and consistency between various callbacks is
> good.

Yes, this approach is nicer, and avoiding breaking the API/ABI is always
cool.  ;-)

I'd suggest something like this:

  /* Attributes.  In practice, they could be indices into a `void *'
     array.  */
  typedef void *gnutls_object_attribute_t;

  /* Return a new attribute for SESSION.  */
  extern gnutls_object_attribute_t
  gnutls_session_allocate_attribute (gnutls_session_t SESSION);

  /* Store P as attribute ATTR of SESSION.  */
  extern int
  gnutls_session_set_attribute (gnutls_session_t session,
                                gnutls_object_attribute_t attr,
                                void *p);

  /* Retrieve in P the value of attribute ATTR of SESSION.  */
  extern int
  gnutls_session_get_attribute (gnutls_session_t session,
                                gnutls_object_attribute_t attr,
                                void **p);
  

The issue is that, for instance, the proposed sign call-back is attached
to a certificate, not a session.  Thus, a similar API would need to be
provided for `gnutls_certificate_t' as well, and potentially for all
other types where call-backs may be used (maybe there aren't so many of
them, though).

(If we were to start from scratch, I'd prefer the classic approach
outlined in my previous message.)

Thanks,
Ludovic.




From simon at josefsson.org  Mon Apr 16 16:33:49 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Apr 2007 16:33:49 +0200
Subject: [gnutls-dev] GnuTLS 1.7.8
Message-ID: <87mz184cdu.fsf@mocca.josefsson.org>

A long overdue release...  Remember, the GnuTLS 1.7.x branch is NOT
what you want for your stable system.  It is intended for developers
and experienced users.

* Version 1.7.8 (released 2007-04-16)

** Added examples for the authorization extension.
See doc/examples/ex-client-authz.c and doc/examples/ex-serv-authz.c.

** The examples only use gnutls_set_default_priority().
The exception is when DH_ANON is needed.

** Improve gnutls_set_default_priority() priorities.
The new approach is for it to try and negotiate all secure and
standard mechanisms available.  Currently, DH_ANON ciphersuites and
LZO compressions are not enabled by default, because they are,
respectively, insecure and non-standardized.  Note that TLS 1.2 will
not be enabled by default in non-experimental release until it has
been approved by the IETF.

** gnutls-cli and gnutls-serv now uses the library's default priorities.
This means that to get DH_ANON and LZO compression, you'll need to
specify that manually using '--kx anon' or '--comp lzo'.

** Minor fixes to the human display format of X.509 certificates.

** New APIs to extract Distinguished Name's from X.509 certificates.
Based on patch from Howard Chu <hyc at symas.com>.

** Improved library searching for opencdk.
It will now add the appropriate -R or -Wl,-rpath flags as necessary.
The deprecated opencdk.m4 is no longer used.

** New APIs to list supported algorithms in the library.
The APIs are gnutls_cipher_list, gnutls_mac_list,
gnutls_compression_list, gnutls_protocol_list,
gnutls_certificate_type_list, gnutls_kx_list, and
gnutls_cipher_suite_info.  Suggested by Howard Chu <hyc at symas.com>.

** The gnutls_x509_crt_get_key_id API now handle non-RSA/DSA keys.

** New configure option --disable-tls-authorization to disable tls-authz.

** Fix prototype for `gnutls_psk_set_client_credentials'.
The last parameter was renamed from 'flags' to 'format' and the type
changed from 'unsigned int' to 'gnutls_psk_key_flags' (an enum type),
which shouldn't cause any ABI changes.  Reported by ludo at chbouib.org
(Ludovic Court?s).

** API and ABI modifications:
gnutls_x509_dn_t: ADD.
gnutls_x509_ava_st: ADD.
gnutls_x509_crt_get_subject,
gnutls_x509_crt_get_issuer: ADD.
gnutls_x509_dn_get_rdn_ava: ADD.
gnutls_cipher_list: ADD.
gnutls_mac_list: ADD.
gnutls_compression_list: ADD.
gnutls_protocol_list: ADD.
gnutls_certificate_type_list: ADD.
gnutls_kx_list: ADD.
gnutls_cipher_suite_info: ADD.

Here are the compressed sources (4.3MB):
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.8.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-1.7.8.tar.bz2

Here are GPG detached signatures signed using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.7.8.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-1.7.8.tar.bz2.sig

Here are the SHA-1 and SHA-224 checksums:

9ac5719cf96061203be7e8c1c475bc871da4c67c  gnutls-1.7.8.tar.bz2
f6ed3fd8723c270bf304991d5db093772f781a7d  gnutls-1.7.8.tar.bz2.sig

9b2ecd4416b73d758f0f63eaa8bc5e083d62dc3eef8ea721cb4ca678  gnutls-1.7.8.tar.bz2
bc4a79862d00fe6ed15b1da540a86ef8b78bb65199fdfe0017dff4b6  gnutls-1.7.8.tar.bz2.sig

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, or donate
money or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20070416/b17d68ef/attachment.pgp>

From simon at josefsson.org  Mon Apr 16 16:48:46 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Apr 2007 16:48:46 +0200
Subject: [gnutls-dev] GnuTLS 1.7.8 for Windows
Message-ID: <87fy704box.fsf@mocca.josefsson.org>

I updated the Windows installer for GnuTLS 1.7.8, you can find it at:

http://josefsson.org/gnutls4win/

/Simon



From ludovic.courtes at laas.fr  Mon Apr 16 17:31:00 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 16 Apr 2007 17:31:00 +0200
Subject: [gnutls-dev] GnuTLS 1.7.8
References: <87mz184cdu.fsf@mocca.josefsson.org>
Message-ID: <87d524l4jv.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> A long overdue release...  Remember, the GnuTLS 1.7.x branch is NOT
> what you want for your stable system.  It is intended for developers
> and experienced users.
>
> * Version 1.7.8 (released 2007-04-16)

I think you forgot to mention the bug fix for
`gnutls_certificate_set_openpgp_key ()' but it seems to be committed
anyway.

Thanks!

Ludo'.




From simon at josefsson.org  Tue Apr 17 10:50:32 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 17 Apr 2007 10:50:32 +0200
Subject: [gnutls-dev] GnuTLS 1.7.8
In-Reply-To: <87d524l4jv.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Mon\, 16
	Apr 2007 17\:31\:00 +0200")
References: <87mz184cdu.fsf@mocca.josefsson.org> <87d524l4jv.fsf@laas.fr>
Message-ID: <87tzvf1j1j.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> A long overdue release...  Remember, the GnuTLS 1.7.x branch is NOT
>> what you want for your stable system.  It is intended for developers
>> and experienced users.
>>
>> * Version 1.7.8 (released 2007-04-16)
>
> I think you forgot to mention the bug fix for
> `gnutls_certificate_set_openpgp_key ()' but it seems to be committed
> anyway.

Sorry about that, I added it to the NEWS file now, so it will be
correct in future releases (too late to change 1.7.8).  It is
mentioned in ChangeLog though.

/Simon



From ludo at chbouib.org  Tue Apr 17 21:06:35 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 17 Apr 2007 21:06:35 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
Message-ID: <87tzve2538.fsf@chbouib.org>

Hi,

The patch below attempts to fix import of OpenPGP keyrings.  This
currently doesn't work at all AFAICT (in fact, I wonder how the current
code relates to the intent ;-)).

The patch is kludgey: since `cdk_keydb_new ()' only supports the raw
format, it changes `gnutls_openpgp_keyring_import ()' so that it returns
an error when asked for a base64 import.

Fixing this would require one of the following:

  1. fixing `cdk_keydb_new ()' so that one can pass an additional
     argument indicating the format.

  2. providing a new function, say `cdk_keydb_from_stream ()', where one
     can pass an arbitrary stream as the keyring source.

Solution (2) seems more flexible and cleaner.  One could pass
`cdk_keydb_from_stream ()' a stream with or without the armor flag set,
thereby fixing our problem.  It would also have the advantage of not
breaking OpenCDK's ABI.  `cdk_keydb_new ()' could then be rewritten in
terms of it.

I'm not familiar with OpenCDK so I may well have missed something.
Any thoughts?

Just in case: is copyright assignment needed for OpenCDK?

Thanks,
Ludovic.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ,,keyring-import.diff
Type: text/x-patch
Size: 846 bytes
Desc: Fixing `gnutls_openpgp_keyring_import ()'
URL: </pipermail/attachments/20070417/551f052b/attachment.bin>

From simon at josefsson.org  Tue Apr 17 21:47:10 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 17 Apr 2007 21:47:10 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <87tzve2538.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Tue\, 17 Apr 2007 21\:06\:35 +0200")
References: <87tzve2538.fsf@chbouib.org>
Message-ID: <87irbug4w1.fsf@mocca.josefsson.org>

ludo at chbouib.org (Ludovic Court?s) writes:

> Hi,
>
> The patch below attempts to fix import of OpenPGP keyrings.  This
> currently doesn't work at all AFAICT (in fact, I wonder how the current
> code relates to the intent ;-)).

I'm not surprised. :)

> The patch is kludgey: since `cdk_keydb_new ()' only supports the raw
> format, it changes `gnutls_openpgp_keyring_import ()' so that it returns
> an error when asked for a base64 import.

If the current code never worked, your patch is an improvement,
though.

> Fixing this would require one of the following:
>
>   1. fixing `cdk_keydb_new ()' so that one can pass an additional
>      argument indicating the format.
>
>   2. providing a new function, say `cdk_keydb_from_stream ()', where one
>      can pass an arbitrary stream as the keyring source.
>
> Solution (2) seems more flexible and cleaner.  One could pass
> `cdk_keydb_from_stream ()' a stream with or without the armor flag set,
> thereby fixing our problem.  It would also have the advantage of not
> breaking OpenCDK's ABI.  `cdk_keydb_new ()' could then be rewritten in
> terms of it.

Yeah, I'd go with 2) or

3) Create cdk_keydb_new_base64 that works like cdk_keydb_new but takes
a text keydb.

> I'm not familiar with OpenCDK so I may well have missed something.
> Any thoughts?

I think you know more than I do... however, Timo (the original author)
has been busy the last few days to rewrite a lot of OpenCDK.  I have
not had a chance to look at the code, but it is possible that he
solves this problem in some other way.

Timo's recent work break the API/ABI though, so I'm not sure how soon
GnuTLS will start to use the new OpenCDK APIs, or how the migration
will happen.  We'll probably should discuss that here.

> Just in case: is copyright assignment needed for OpenCDK?

No, for now let's consider OpenCDK a part of GnuTLS, so it falls under
your GnuTLS assignment.

/Simon



From ludovic.courtes at laas.fr  Wed Apr 18 09:41:48 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 18 Apr 2007 09:41:48 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
References: <87tzve2538.fsf@chbouib.org> <87irbug4w1.fsf@mocca.josefsson.org>
Message-ID: <87bqhm3z9f.fsf@laas.fr>

Hi!

Simon Josefsson <simon at josefsson.org> writes:

> If the current code never worked, your patch is an improvement,
> though.

Yeah, probably worth installing.

>> Fixing this would require one of the following:
>>
>>   1. fixing `cdk_keydb_new ()' so that one can pass an additional
>>      argument indicating the format.
>>
>>   2. providing a new function, say `cdk_keydb_from_stream ()', where one
>>      can pass an arbitrary stream as the keyring source.
>>
>> Solution (2) seems more flexible and cleaner.  One could pass
>> `cdk_keydb_from_stream ()' a stream with or without the armor flag set,
>> thereby fixing our problem.  It would also have the advantage of not
>> breaking OpenCDK's ABI.  `cdk_keydb_new ()' could then be rewritten in
>> terms of it.
>
> Yeah, I'd go with 2) or
>
> 3) Create cdk_keydb_new_base64 that works like cdk_keydb_new but takes
> a text keydb.

I'd be more in favor of (2) (looks more consistent IMO).

> Timo's recent work break the API/ABI though, so I'm not sure how soon
> GnuTLS will start to use the new OpenCDK APIs, or how the migration
> will happen.  We'll probably should discuss that here.

Then, should we consider the transition to be a long-term goal and hack
our own version of OpenCDK in the meantime?  Or should we just switch
ASAP, if at all possible?

Thanks,
Ludovic.




From twoaday at gmx.net  Wed Apr 18 09:03:10 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Wed, 18 Apr 2007 09:03:10 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <87irbug4w1.fsf@mocca.josefsson.org>
References: <87tzve2538.fsf@chbouib.org> <87irbug4w1.fsf@mocca.josefsson.org>
Message-ID: <4625C2AE.2080402@gmx.net>

Simon Josefsson wrote:

> 
> Yeah, I'd go with 2) or
> 
> 3) Create cdk_keydb_new_base64 that works like cdk_keydb_new but takes
> a text keydb.

I've to admit that I did not look in the code for a lot of time (gnutls
openpgp). If the code uses a buffer and thus CDK_DBTYPE_DATA, it is true
that no base64 decoding is done. I guess the best solution is to add
this feature to the keydb.c code. This would not break any existing
interfaces. I will do it and backport the changes to 0.5.13.
Is this ok for you?


> Timo's recent work break the API/ABI though, so I'm not sure how soon
> GnuTLS will start to use the new OpenCDK APIs, or how the migration
> will happen.  We'll probably should discuss that here.

Actually not that much changed and most of the changes were for other
operations (bulk encryption, ...). I know it's bad to break existing
API's but it needed to be done eventually and I thought sooner would
be better.


But I've agree that we should discuss how to do the migration. On the
other hand it's a lot of work to backport patches or to merge them with
HEAD. Plus I fixed a lot of minor problems and mem leaks and thus I
think it would be a good idea to start the migration soon as possible.
Of course it's up to you to decide this, but this is my suggestion.


	Timo




From twoaday at gmx.net  Wed Apr 18 08:57:11 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Wed, 18 Apr 2007 08:57:11 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <87tzve2538.fsf@chbouib.org>
References: <87tzve2538.fsf@chbouib.org>
Message-ID: <4625C147.6000401@gmx.net>

Ludovic Court?s wrote:

> The patch is kludgey: since `cdk_keydb_new ()' only supports the raw
> format, it changes `gnutls_openpgp_keyring_import ()' so that it returns
> an error when asked for a base64 import.

Actually that's not true, maybe the code does not work in the used
CDK release, but the keydb code has the ability to automatically
decode base64 files which are used as
	CDK_DBTYPE_PK_KEYRING.

As Simon pointed out, I re-wrote lots of the opencdk code and I
added a lot of tests to make sure all changes really work as expected.
I also write a test to use a base64 file as a keyring and I succeeded
to search for a key by keyid or by pattern.


> Fixing this would require one of the following:
> 
>   1. fixing `cdk_keydb_new ()' so that one can pass an additional
>      argument indicating the format.

As I said before, this is usually not needed. The both format which
are possible: raw, base64 should be supported.
If the opencdk version gnutls currently uses, does not support to
push the de-armor filter automatically, I guess it's the best idea to
fix it in keydb.c.


>   2. providing a new function, say `cdk_keydb_from_stream ()', where one
>      can pass an arbitrary stream as the keyring source.

This might be a useful function and I will consider it.


> thereby fixing our problem.  It would also have the advantage of not
> breaking OpenCDK's ABI.  `cdk_keydb_new ()' could then be rewritten in

..if the only reason for the new code is that base64 data is not supported,



	Timo




From ludovic.courtes at laas.fr  Wed Apr 18 12:40:53 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 18 Apr 2007 12:40:53 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
References: <87tzve2538.fsf@chbouib.org> <4625C147.6000401@gmx.net>
Message-ID: <87wt0a0xu2.fsf@laas.fr>

Hi,

Timo Schulz <twoaday at gmx.net> writes:

> Actually that's not true, maybe the code does not work in the used
> CDK release, but the keydb code has the ability to automatically
> decode base64 files which are used as
> 	CDK_DBTYPE_PK_KEYRING.

Yes, but my patch uses `CDK_DBTYPE_PK_DATA' because the data comes from
a user-provided buffer, not from a file.  In this case,
`cdk_keydb_new ()' just creates a temporary stream from the user buffer,
without leaving the opportunity set/clear that stream's armor flag.

> As I said before, this is usually not needed. The both format which
> are possible: raw, base64 should be supported.
> If the opencdk version gnutls currently uses, does not support to
> push the de-armor filter automatically, I guess it's the best idea to
> fix it in keydb.c.

It would be best to at least have the ability to not rely on automatic
detection of the format, especially since callers pass a FORMAT
argument.

>>   2. providing a new function, say `cdk_keydb_from_stream ()', where one
>>      can pass an arbitrary stream as the keyring source.
>
> This might be a useful function and I will consider it.

That would allow `gnutls_openpgp_keyring_import ()' to support both
base64 and raw in a straightforward way.

Are you considering implementing it in a future version?

>> thereby fixing our problem.  It would also have the advantage of not
>> breaking OpenCDK's ABI.  `cdk_keydb_new ()' could then be rewritten in
>
> ..if the only reason for the new code is that base64 data is not supported,

Then what?  :-)

It seems that your message got somehow stripped.

Thanks,
Ludovic.




From twoaday at gmx.net  Wed Apr 18 13:06:34 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Wed, 18 Apr 2007 13:06:34 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <87wt0a0xu2.fsf@laas.fr>
References: <87tzve2538.fsf@chbouib.org> <4625C147.6000401@gmx.net>
	<87wt0a0xu2.fsf@laas.fr>
Message-ID: <4625FBBA.6040107@gmx.net>

Ludovic Court?s wrote:

> Yes, but my patch uses `CDK_DBTYPE_PK_DATA' because the data comes from
> a user-provided buffer, not from a file.  In this case,
> `cdk_keydb_new ()' just creates a temporary stream from the user buffer,
> without leaving the opportunity set/clear that stream's armor flag.

OK, I fixed it in the CVS. The backport is pretty easy and just two
lines.


> It would be best to at least have the ability to not rely on automatic
> detection of the format, especially since callers pass a FORMAT

Actually this is a format for the structure, not the data itself.
Format: file, stream, buffer. Maybe I did not describe this very well :-(.

The idea was to auto detect base64 data and decode it. With the
new code, cdk_keydb_new_from_stream () no decoding is done.


> That would allow `gnutls_openpgp_keyring_import ()' to support both
> base64 and raw in a straightforward way.

OK, the stream version is also available in the CVS.
Just for clarification, I change/patch the code in HEAD, not the
nmvav-0-5-x branch GnuTLS currently uses.

> Are you considering implementing it in a future version?

As I said, it's done. Actually the new release 0.6.0, is not released
yet but the code is in the CVS. I will wait until the discussion is
done so I definitely know what to add/change in OpenCDK.


>>> thereby fixing our problem.  It would also have the advantage of not
>>> breaking OpenCDK's ABI.  `cdk_keydb_new ()' could then be rewritten in
>> ..if the only reason for the new code is that base64 data is not supported,
> 
> Then what?  :-)

Sorry. It should be "if this is the only reason for the new code". IMHO
the issue is fixed with the armor support for CDK_DBTYPE_DATA and the
new cdk_keydb_new_from_stream() function.

As I said, the backport is pretty easy. But I would suggest to think of
a migration strategy because I fixed a lot of other stuff and GnuTLS
would definitely benefit of the new code.


	Timo



From simon at josefsson.org  Wed Apr 18 14:42:20 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 18 Apr 2007 14:42:20 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <4625C2AE.2080402@gmx.net> (Timo Schulz's message of "Wed\, 18 Apr
	2007 09\:03\:10 +0200")
References: <87tzve2538.fsf@chbouib.org> <87irbug4w1.fsf@mocca.josefsson.org>
	<4625C2AE.2080402@gmx.net>
Message-ID: <87slaxkg5v.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Simon Josefsson wrote:
>
>> 
>> Yeah, I'd go with 2) or
>> 
>> 3) Create cdk_keydb_new_base64 that works like cdk_keydb_new but takes
>> a text keydb.
>
> I've to admit that I did not look in the code for a lot of time (gnutls
> openpgp). If the code uses a buffer and thus CDK_DBTYPE_DATA, it is true
> that no base64 decoding is done. I guess the best solution is to add
> this feature to the keydb.c code. This would not break any existing
> interfaces. I will do it and backport the changes to 0.5.13.
> Is this ok for you?

Maybe you could post the patch?  I think it would be fine.

>> Timo's recent work break the API/ABI though, so I'm not sure how soon
>> GnuTLS will start to use the new OpenCDK APIs, or how the migration
>> will happen.  We'll probably should discuss that here.
>
> Actually not that much changed and most of the changes were for other
> operations (bulk encryption, ...). I know it's bad to break existing
> API's but it needed to be done eventually and I thought sooner would
> be better.
>
>
> But I've agree that we should discuss how to do the migration. On the
> other hand it's a lot of work to backport patches or to merge them with
> HEAD. Plus I fixed a lot of minor problems and mem leaks and thus I
> think it would be a good idea to start the migration soon as possible.
> Of course it's up to you to decide this, but this is my suggestion.

Yes, I agree that gnutls should use your opencdk.  Maybe you could
summarize your changes?

Also, I don't think I will have time to develop the patches for gnutls
required to do this, so I'm hoping that you will take the lead on that
and propose some patches for gnutls.

Thanks,
Simon



From ludovic.courtes at laas.fr  Wed Apr 18 15:00:54 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 18 Apr 2007 15:00:54 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
References: <87tzve2538.fsf@chbouib.org> <4625C147.6000401@gmx.net>
	<87wt0a0xu2.fsf@laas.fr> <4625FBBA.6040107@gmx.net>
Message-ID: <87odllzvjt.fsf@laas.fr>

Hi,

Timo Schulz <twoaday at gmx.net> writes:

> Ludovic Court?s wrote:
>
>> Yes, but my patch uses `CDK_DBTYPE_PK_DATA' because the data comes from
>> a user-provided buffer, not from a file.  In this case,
>> `cdk_keydb_new ()' just creates a temporary stream from the user buffer,
>> without leaving the opportunity set/clear that stream's armor flag.
>
> OK, I fixed it in the CVS. The backport is pretty easy and just two
> lines.

Ok, cool, this is good news!

(BTW, I'd appreciate a bit more documentation while you're at it.  :-))

> Sorry. It should be "if this is the only reason for the new code". IMHO
> the issue is fixed with the armor support for CDK_DBTYPE_DATA and the
> new cdk_keydb_new_from_stream() function.
>
> As I said, the backport is pretty easy. But I would suggest to think of
> a migration strategy because I fixed a lot of other stuff and GnuTLS
> would definitely benefit of the new code.

I guess it's up to Simon to decide whether to backport or to migrate.
It probably depends on the level of (in)compatibility between the
current and the new OpenCDK.

Thanks!

Ludovic.




From twoaday at gmx.net  Wed Apr 18 14:59:02 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Wed, 18 Apr 2007 14:59:02 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <87slaxkg5v.fsf@mocca.josefsson.org>
References: <87tzve2538.fsf@chbouib.org>
	<87irbug4w1.fsf@mocca.josefsson.org>	<4625C2AE.2080402@gmx.net>
	<87slaxkg5v.fsf@mocca.josefsson.org>
Message-ID: <46261616.7050407@gmx.net>

Simon Josefsson wrote:

>> this feature to the keydb.c code. This would not break any existing
>> interfaces. I will do it and backport the changes to 0.5.13.
>> Is this ok for you?
> 
> Maybe you could post the patch?  I think it would be fine.

So I won't send the wrong patch.

We decided that opencdk base64 decodes the CDK_DBTYPE_DATA object,
right? I could also post the cdk_keydb_new_from_stream but then some
other files needed to be patched also and maybe it is easier if I
commit the changes directly in the nmav-0-5-x branch?


> Yes, I agree that gnutls should use your opencdk.  Maybe you could
> summarize your changes?

OK.

Most of the things I changed are not visible, adjustments for the
latest openpgp draft, bug fixes for mem leaks. The most visible change
is, that I dropped the cdk_mpi_t object and now we use gcrypt_mpi_t
objects directly. Minor things need to be changed in the gnutls openpgp
code.

I cleaned up the passphrase interface, which should also no problem
because, IIRC, gnutls do not unprotect secret keys via opencdk.

Some functions now have an additional or fewer parameters. But most of
the changes are related to bulk encryption. The external interface of
the key conversion/management API is pretty much the same.


> Also, I don't think I will have time to develop the patches for gnutls
> required to do this, so I'm hoping that you will take the lead on that
> and propose some patches for gnutls.

Of course. I wrote part of the last openpgp gnutls code and it should be
not too difficult for me to adjust the code for the new opencdk version.
But FYI, I don't think that much time is needed to finish the migration.
This is at least what I believe ;-).


	Timo



From simon at josefsson.org  Wed Apr 18 17:24:15 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 18 Apr 2007 17:24:15 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <46261616.7050407@gmx.net> (Timo Schulz's message of "Wed\, 18 Apr
	2007 14\:59\:02 +0200")
References: <87tzve2538.fsf@chbouib.org> <87irbug4w1.fsf@mocca.josefsson.org>
	<4625C2AE.2080402@gmx.net> <87slaxkg5v.fsf@mocca.josefsson.org>
	<46261616.7050407@gmx.net>
Message-ID: <87bqhlk8o0.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Simon Josefsson wrote:
>
>>> this feature to the keydb.c code. This would not break any existing
>>> interfaces. I will do it and backport the changes to 0.5.13.
>>> Is this ok for you?
>> 
>> Maybe you could post the patch?  I think it would be fine.
>
> So I won't send the wrong patch.
>
> We decided that opencdk base64 decodes the CDK_DBTYPE_DATA object,
> right?

Yeah, I think so. (Ludovic, correct me if I'm wrong.)

> I could also post the cdk_keydb_new_from_stream but then some other
> files needed to be patched also

I think it may better not to back-port this stuff to the nmav branch.
Let's aim for GnuTLS changing to use OpenCDK HEAD instead.

> and maybe it is easier if I commit the changes directly in the
> nmav-0-5-x branch?

Sure, although please don't change any API/ABI without discussing it
first.  Since we are talking about a big API/ABI break with moving to
OpenCDK HEAD, I think an addition API/ABI break is a no-no, but it
could be discussed.

>> Yes, I agree that gnutls should use your opencdk.  Maybe you could
>> summarize your changes?
>
> OK.
>
> Most of the things I changed are not visible, adjustments for the
> latest openpgp draft, bug fixes for mem leaks. The most visible change
> is, that I dropped the cdk_mpi_t object and now we use gcrypt_mpi_t
> objects directly. Minor things need to be changed in the gnutls openpgp
> code.
>
> I cleaned up the passphrase interface, which should also no problem
> because, IIRC, gnutls do not unprotect secret keys via opencdk.
>
> Some functions now have an additional or fewer parameters. But most of
> the changes are related to bulk encryption. The external interface of
> the key conversion/management API is pretty much the same.

Thanks.

>> Also, I don't think I will have time to develop the patches for gnutls
>> required to do this, so I'm hoping that you will take the lead on that
>> and propose some patches for gnutls.
>
> Of course. I wrote part of the last openpgp gnutls code and it should be
> not too difficult for me to adjust the code for the new opencdk version.
> But FYI, I don't think that much time is needed to finish the migration.
> This is at least what I believe ;-).

Sounds good...  since 1.7.8 was just released, if your changes are
relatively safe you could install your fixes to GnuTLS on HEAD right
now, and we can aim for 1.7.9 to mostly just do the OpenCDK upgrade.
I do want to have HEAD in a buildable stage for most of the time, so
if you think you'll need more than a few days of time to finish the
migration, let's create a branch for it.  What do you think?

/Simon



From twoaday at gmx.net  Wed Apr 18 19:49:43 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Wed, 18 Apr 2007 19:49:43 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <87bqhlk8o0.fsf@mocca.josefsson.org>
References: <87tzve2538.fsf@chbouib.org>
	<87irbug4w1.fsf@mocca.josefsson.org>	<4625C2AE.2080402@gmx.net>
	<87slaxkg5v.fsf@mocca.josefsson.org>	<46261616.7050407@gmx.net>
	<87bqhlk8o0.fsf@mocca.josefsson.org>
Message-ID: <46265A37.7010005@gmx.net>

Simon Josefsson wrote:

>> We decided that opencdk base64 decodes the CDK_DBTYPE_DATA object,
>> right?
> 
> Yeah, I think so. (Ludovic, correct me if I'm wrong.)

OK, I will post the patch then.


> I think it may better not to back-port this stuff to the nmav branch.
> Let's aim for GnuTLS changing to use OpenCDK HEAD instead.

That's exactly my position. This avoids to double mantain two branches
and it probably fixes other problems.


> Sure, although please don't change any API/ABI without discussing it
> first.  Since we are talking about a big API/ABI break with moving to
> OpenCDK HEAD, I think an addition API/ABI break is a no-no, but it

I agree with it. All patches I would commit were just bug fixes and
wouldn't change any existing interface. That's why I want to discuss
the migration. Then we know what functions are missing or need to be
changed and we can do the migration and new code in a row.


> Sounds good...  since 1.7.8 was just released, if your changes are
> relatively safe you could install your fixes to GnuTLS on HEAD right

At least the CDK_DBTYPE_DATA patch is safe.


> now, and we can aim for 1.7.9 to mostly just do the OpenCDK upgrade.
> I do want to have HEAD in a buildable stage for most of the time, so
> if you think you'll need more than a few days of time to finish the
> migration, let's create a branch for it.  What do you think?

Hmm, first I need to check how much code I would need to change and how
fast I can test the changes. But I don't think it will take longer than
2-3 days. I actually hope <= 2 days but I need to check the code first.


	Timo

p.s.
I attached the patch, but if we do the upgrade now (or better soon as
possible), it is not needed because the OpenCDK HEAD fixes the problem.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: keydb.c.diff
Type: text/x-patch
Size: 318 bytes
Desc: not available
URL: </pipermail/attachments/20070418/269bd95c/attachment.bin>

From twoaday at gmx.net  Wed Apr 18 20:01:37 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Wed, 18 Apr 2007 20:01:37 +0200
Subject: [gnutls-dev] OpenPGP Keys
Message-ID: <46265D01.9070503@gmx.net>

Hi,

I forgot to mention that the opencdk interface for retrieving
the validity and the ownertrust of the the key is no longer
available. Now the question is how to handle the issue.

I've seen that at least cdk_trustdb_get_ownertrust() is used
in the signature verification code.

The problem is, that ownertrust is a value each openpgp application
associates to a key and I do not think it is a good idea to let the
gnutls server use the values of some user from existing gpg files.

Frankly, I'm not sure how to implement this. Maybe we should have our
own 'key trust' file which stores the ownertrust of the keys. But the
question is if these values are really used by the openpgp
authentication at all.

Any comments?


	Timo



From ludovic.courtes at laas.fr  Thu Apr 19 09:50:07 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 19 Apr 2007 09:50:07 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
References: <87tzve2538.fsf@chbouib.org> <87irbug4w1.fsf@mocca.josefsson.org>
	<4625C2AE.2080402@gmx.net> <87slaxkg5v.fsf@mocca.josefsson.org>
	<46261616.7050407@gmx.net> <87bqhlk8o0.fsf@mocca.josefsson.org>
Message-ID: <87ejmgiz0w.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Timo Schulz <twoaday at gmx.net> writes:
>
>> Simon Josefsson wrote:
>>
>>>> this feature to the keydb.c code. This would not break any existing
>>>> interfaces. I will do it and backport the changes to 0.5.13.
>>>> Is this ok for you?
>>> 
>>> Maybe you could post the patch?  I think it would be fine.
>>
>> So I won't send the wrong patch.
>>
>> We decided that opencdk base64 decodes the CDK_DBTYPE_DATA object,
>> right?
>
> Yeah, I think so. (Ludovic, correct me if I'm wrong.)

Actually no---otherwise, I could have done it myself.  ;-)

Currently, when TYPE is `CDK_DBTYPE_DATA', `cdk_keydb_new ()'
raw-decodes the given buffer.  My suggestion was to _keep this behavior_
(for compatibility).  I would also suggest documenting this behavior.

To support base64-decoding, I suggested introducing a new function,
`cdk_keydb_new_from_stream ()', that would allow base64-decoding to be
implemented in a straightforward way (by setting the armor flag on the
input stream).

Does it sound reasonable?

Thanks,
Ludovic.




From twoaday at gmx.net  Thu Apr 19 10:09:23 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Thu, 19 Apr 2007 10:09:23 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <87ejmgiz0w.fsf@laas.fr>
References: <87tzve2538.fsf@chbouib.org>
	<87irbug4w1.fsf@mocca.josefsson.org>	<4625C2AE.2080402@gmx.net>
	<87slaxkg5v.fsf@mocca.josefsson.org>	<46261616.7050407@gmx.net>
	<87bqhlk8o0.fsf@mocca.josefsson.org> <87ejmgiz0w.fsf@laas.fr>
Message-ID: <462723B3.3050800@gmx.net>

Ludovic Court?s wrote:

> Currently, when TYPE is `CDK_DBTYPE_DATA', `cdk_keydb_new ()'
> raw-decodes the given buffer.  My suggestion was to _keep this behavior_
> (for compatibility).  I would also suggest documenting this behavior.

Hmm, probably a good idea. In any case it should be documented.


> To support base64-decoding, I suggested introducing a new function,
> `cdk_keydb_new_from_stream ()', that would allow base64-decoding to be
> implemented in a straightforward way (by setting the armor flag on the

Ah, OK. Actually I already implemented the _from_stream version. So the
issue should be solved.


Thanks for the clarification.


	Timo



From ludovic.courtes at laas.fr  Thu Apr 19 10:06:34 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 19 Apr 2007 10:06:34 +0200
Subject: [gnutls-dev] OpenPGP Keys
References: <46265D01.9070503@gmx.net>
Message-ID: <87ps60hjp1.fsf@laas.fr>

Hi,

Timo Schulz <twoaday at gmx.net> writes:

> I forgot to mention that the opencdk interface for retrieving
> the validity and the ownertrust of the the key is no longer
> available. Now the question is how to handle the issue.
>
> I've seen that at least cdk_trustdb_get_ownertrust() is used
> in the signature verification code.

Actually, I don't quite understand what "trustdbs" are about in GnuTLS
(and OpenCDK).  Does it refer to RFC 2440 "trust packets"?  Or does it
refer to "signature packets" as found in a "transferable public key"?
How does it differ from a "keyring"?

Then, what is "ownertrust" in RFC 2440 terms?

Thanks (and sorry for not being more helpful ;-)),
Ludovic.




From twoaday at gmx.net  Thu Apr 19 11:02:14 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Thu, 19 Apr 2007 11:02:14 +0200
Subject: [gnutls-dev] OpenPGP Keys
In-Reply-To: <87ps60hjp1.fsf@laas.fr>
References: <46265D01.9070503@gmx.net> <87ps60hjp1.fsf@laas.fr>
Message-ID: <46273016.10503@gmx.net>

Ludovic Court?s wrote:

> refer to "signature packets" as found in a "transferable public key"?
> How does it differ from a "keyring"?

The trust db stores just the information how much you trust a key or
better its owner. It does not contain any key data. OpenPGP applications
might also store this _in_ the keyring and there is no extra file for it.


> Then, what is "ownertrust" in RFC 2440 terms?

See above. In GPG it is a value from 1 to 5 to the question:

"how far you trust the owner of the key to correctly verify other keys"

1 = don't know or won't say
2 = do not trust
3 = trust marginally
4 = trust fully
5 = trust ultimate

(5 is mostly useful for key pairs, other applications call it
 "implicit trust")


I hope this explains the concept a little.

And I'm not exactly sure how the value is used in the openpgp
implementation of GnuTLS. Probably a generic check to verify
we have at least marginal trust for the peer key.


	Timo



From simon at josefsson.org  Thu Apr 19 11:16:05 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Apr 2007 11:16:05 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <46265A37.7010005@gmx.net> (Timo Schulz's message of "Wed\, 18 Apr
	2007 19\:49\:43 +0200")
References: <87tzve2538.fsf@chbouib.org> <87irbug4w1.fsf@mocca.josefsson.org>
	<4625C2AE.2080402@gmx.net> <87slaxkg5v.fsf@mocca.josefsson.org>
	<46261616.7050407@gmx.net> <87bqhlk8o0.fsf@mocca.josefsson.org>
	<46265A37.7010005@gmx.net>
Message-ID: <87ejmgiv1m.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

>> I think it may better not to back-port this stuff to the nmav branch.
>> Let's aim for GnuTLS changing to use OpenCDK HEAD instead.
>
> That's exactly my position. This avoids to double mantain two branches
> and it probably fixes other problems.

Agreed.

>> now, and we can aim for 1.7.9 to mostly just do the OpenCDK upgrade.
>> I do want to have HEAD in a buildable stage for most of the time, so
>> if you think you'll need more than a few days of time to finish the
>> migration, let's create a branch for it.  What do you think?
>
> Hmm, first I need to check how much code I would need to change and how
> fast I can test the changes. But I don't think it will take longer than
> 2-3 days. I actually hope <= 2 days but I need to check the code first.

Great, feel free to install on GnuTLS HEAD.  I don't expect 1.7.9 to
take as long as 1.7.8 was to release, but I'm thinking maybe one month
at most.

> I attached the patch, but if we do the upgrade now (or better soon as
> possible), it is not needed because the OpenCDK HEAD fixes the problem.
>
> --- /tmp/keydb.c	2007-04-18 19:40:43.000000000 +0200
> +++ keydb.c	2007-04-18 19:42:31.000000000 +0200
> @@ -263,6 +263,8 @@
>              cdk_free( hd );
>              return CDK_Out_Of_Core;
>          }
> +	if( cdk_armor_filter_use( hd->buf ) )
> +	    cdk_stream_set_armor_flag( hd->buf, 0 );	
>          break;
>  
>      default:

Ludovic, would you like to see this go in now, so you can continue
working without a patched GnuTLS?  Assuming of course that you believe
the patch will solve your problem.

Alternatively, wait for Timo's gnutls-changes to use the new OpenCDK
(and possibly run into new bugs).

/Simon



From simon at josefsson.org  Thu Apr 19 11:21:13 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Apr 2007 11:21:13 +0200
Subject: [gnutls-dev] OpenPGP Keys
In-Reply-To: <46265D01.9070503@gmx.net> (Timo Schulz's message of "Wed\, 18 Apr
	2007 20\:01\:37 +0200")
References: <46265D01.9070503@gmx.net>
Message-ID: <877is8iut2.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Hi,
>
> I forgot to mention that the opencdk interface for retrieving
> the validity and the ownertrust of the the key is no longer
> available. Now the question is how to handle the issue.
>
> I've seen that at least cdk_trustdb_get_ownertrust() is used
> in the signature verification code.
>
> The problem is, that ownertrust is a value each openpgp application
> associates to a key and I do not think it is a good idea to let the
> gnutls server use the values of some user from existing gpg files.
>
> Frankly, I'm not sure how to implement this. Maybe we should have our
> own 'key trust' file which stores the ownertrust of the keys. But the
> question is if these values are really used by the openpgp
> authentication at all.
>
> Any comments?

I'm thinking that the trustdb file will be the GnuTLS-specific
trustdb, and thus OpenCDK can depend on the trust information in that
file.  Wouldn't that work?

Thus, it would be a bad idea to run a server with your personal
~/.gnupg/trustdb.gpg, and you would rather create a separate
trustdb.gpg for the GnuTLS server.

However, I'm not really familiar with these aspects of OpenPGP/GnuPG.
It strikes me as a bad idea to rely on GnuPG-specific files (which is
what we are doing, or?) so if it is possible to have a text file with
OpenPGP key identifiers in it that the server should trust, that seems
like a better choice.  Is there any other information in the trustdb
that GnuTLS/OpenCDK needs?

Sorry for not being that familiar with this code and the design...
I'm trying to think about it conceptually.

/Simon



From simon at josefsson.org  Thu Apr 19 12:25:33 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Apr 2007 12:25:33 +0200
Subject: [gnutls-dev] OpenPGP Keys
In-Reply-To: <46273016.10503@gmx.net> (Timo Schulz's message of "Thu\, 19 Apr
	2007 11\:02\:14 +0200")
References: <46265D01.9070503@gmx.net> <87ps60hjp1.fsf@laas.fr>
	<46273016.10503@gmx.net>
Message-ID: <87tzvchd9e.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Ludovic Court?s wrote:
>
>> refer to "signature packets" as found in a "transferable public key"?
>> How does it differ from a "keyring"?
>
> The trust db stores just the information how much you trust a key or
> better its owner. It does not contain any key data. OpenPGP applications
> might also store this _in_ the keyring and there is no extra file for it.
>
>
>> Then, what is "ownertrust" in RFC 2440 terms?
>
> See above. In GPG it is a value from 1 to 5 to the question:
>
> "how far you trust the owner of the key to correctly verify other keys"
>
> 1 = don't know or won't say
> 2 = do not trust
> 3 = trust marginally
> 4 = trust fully
> 5 = trust ultimate
>
> (5 is mostly useful for key pairs, other applications call it
>  "implicit trust")
>
>
> I hope this explains the concept a little.

I still do not understand if this is a OpenPGP or GnuPG concept.  If
it is a GnuPG concept, and there is no equivalent OpenPGP concept to
solve the same problem, I'm not sure we should use it.

However, maybe OpenCDK is already too GnuPG-specific so that we can't
really make OpenCDK non-GnuPG-specific anyway?  Having more
documentation on the file formats that OpenCDK use would really help
me here.

> And I'm not exactly sure how the value is used in the openpgp
> implementation of GnuTLS. Probably a generic check to verify
> we have at least marginal trust for the peer key.

This relates to the current discussion on help-gnutls too, and it
seems safe to say that we don't know for sure what the solution will
be yet.

/Simon



From ludovic.courtes at laas.fr  Thu Apr 19 13:52:55 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 19 Apr 2007 13:52:55 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
References: <87tzve2538.fsf@chbouib.org> <87irbug4w1.fsf@mocca.josefsson.org>
	<4625C2AE.2080402@gmx.net> <87slaxkg5v.fsf@mocca.josefsson.org>
	<46261616.7050407@gmx.net> <87bqhlk8o0.fsf@mocca.josefsson.org>
	<46265A37.7010005@gmx.net> <87ejmgiv1m.fsf@mocca.josefsson.org>
Message-ID: <87r6qgbmy0.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Timo Schulz <twoaday at gmx.net> writes:

>> I attached the patch, but if we do the upgrade now (or better soon as
>> possible), it is not needed because the OpenCDK HEAD fixes the problem.
>>
>> --- /tmp/keydb.c	2007-04-18 19:40:43.000000000 +0200
>> +++ keydb.c	2007-04-18 19:42:31.000000000 +0200
>> @@ -263,6 +263,8 @@
>>              cdk_free( hd );
>>              return CDK_Out_Of_Core;
>>          }
>> +	if( cdk_armor_filter_use( hd->buf ) )
>> +	    cdk_stream_set_armor_flag( hd->buf, 0 );	
>>          break;
>>  
>>      default:
>
> Ludovic, would you like to see this go in now, so you can continue
> working without a patched GnuTLS?  Assuming of course that you believe
> the patch will solve your problem.

Not really.  I'd prefer either the patch I posted at the beginning of
this thread or wait for Timo's updates.  In any case, there's no rush: I
can wait until Timo's changes are ready or 1.7.9 is out, whichever comes
first.

Thanks,
Ludo'.




From simon at josefsson.org  Thu Apr 19 14:26:34 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Apr 2007 14:26:34 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <87r6qgbmy0.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Thu\, 19
	Apr 2007 13\:52\:55 +0200")
References: <87tzve2538.fsf@chbouib.org> <87irbug4w1.fsf@mocca.josefsson.org>
	<4625C2AE.2080402@gmx.net> <87slaxkg5v.fsf@mocca.josefsson.org>
	<46261616.7050407@gmx.net> <87bqhlk8o0.fsf@mocca.josefsson.org>
	<46265A37.7010005@gmx.net> <87ejmgiv1m.fsf@mocca.josefsson.org>
	<87r6qgbmy0.fsf@laas.fr>
Message-ID: <87wt08ft39.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Timo Schulz <twoaday at gmx.net> writes:
>
>>> I attached the patch, but if we do the upgrade now (or better soon as
>>> possible), it is not needed because the OpenCDK HEAD fixes the problem.
>>>
>>> --- /tmp/keydb.c	2007-04-18 19:40:43.000000000 +0200
>>> +++ keydb.c	2007-04-18 19:42:31.000000000 +0200
>>> @@ -263,6 +263,8 @@
>>>              cdk_free( hd );
>>>              return CDK_Out_Of_Core;
>>>          }
>>> +	if( cdk_armor_filter_use( hd->buf ) )
>>> +	    cdk_stream_set_armor_flag( hd->buf, 0 );	
>>>          break;
>>>  
>>>      default:
>>
>> Ludovic, would you like to see this go in now, so you can continue
>> working without a patched GnuTLS?  Assuming of course that you believe
>> the patch will solve your problem.
>
> Not really.  I'd prefer either the patch I posted at the beginning of
> this thread or wait for Timo's updates.  In any case, there's no rush: I
> can wait until Timo's changes are ready or 1.7.9 is out, whichever comes
> first.

I applied your initial patch now.

Thanks,
Simon



From ludovic.courtes at laas.fr  Thu Apr 19 14:32:22 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 19 Apr 2007 14:32:22 +0200
Subject: [gnutls-dev] OpenPGP Keys
References: <46265D01.9070503@gmx.net> <87ps60hjp1.fsf@laas.fr>
	<46273016.10503@gmx.net>
Message-ID: <877is8a6jt.fsf@laas.fr>

Hi,

Timo Schulz <twoaday at gmx.net> writes:

> See above. In GPG it is a value from 1 to 5 to the question:
>
> "how far you trust the owner of the key to correctly verify other keys"
>
> 1 = don't know or won't say
> 2 = do not trust
> 3 = trust marginally
> 4 = trust fully
> 5 = trust ultimate
>
> (5 is mostly useful for key pairs, other applications call it
>  "implicit trust")

Simon Josefsson <simon at josefsson.org> writes:

> I still do not understand if this is a OpenPGP or GnuPG concept.  If
> it is a GnuPG concept, and there is no equivalent OpenPGP concept to
> solve the same problem, I'm not sure we should use it.

This seems to be a GnuPG feature [0], not an OpenPGP thing.

It tells whether you consider the owner of the public key to be a
"trusted introducer", i.e., someone who makes careful key ownership
verifications before signing somebody else's key.

This is used to estimate the trustworthiness of a certificate based on
the signatures it contains, in a pure web-of-trust fashion (see the
example in [1]).

RFC 2440 defines no such thing AFAICS.  Nevertheless, this may be a
useful tool for GnuTLS, too (see the discussion on `help-gnutls').

Thanks,
Ludovic.

[0] http://www.gnupg.org/gph/en/manual.html#AEN346
[1] http://www.gnupg.org/gph/en/manual.html#AEN385




From simon at josefsson.org  Thu Apr 19 15:41:42 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Apr 2007 15:41:42 +0200
Subject: [gnutls-dev] OpenPGP Keys
In-Reply-To: <877is8a6jt.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Thu\, 19
	Apr 2007 14\:32\:22 +0200")
References: <46265D01.9070503@gmx.net> <87ps60hjp1.fsf@laas.fr>
	<46273016.10503@gmx.net> <877is8a6jt.fsf@laas.fr>
Message-ID: <878xcofpm1.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Hi,
>
> Timo Schulz <twoaday at gmx.net> writes:
>
>> See above. In GPG it is a value from 1 to 5 to the question:
>>
>> "how far you trust the owner of the key to correctly verify other keys"
>>
>> 1 = don't know or won't say
>> 2 = do not trust
>> 3 = trust marginally
>> 4 = trust fully
>> 5 = trust ultimate
>>
>> (5 is mostly useful for key pairs, other applications call it
>>  "implicit trust")
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> I still do not understand if this is a OpenPGP or GnuPG concept.  If
>> it is a GnuPG concept, and there is no equivalent OpenPGP concept to
>> solve the same problem, I'm not sure we should use it.
>
> This seems to be a GnuPG feature [0], not an OpenPGP thing.

Thanks.  If this information is stored in binary-only non-standardized
GnuPG-defined formats, I don't think OpenCDK should be reading these
files at all, at least not without more syncing with the GnuPG people.

> It tells whether you consider the owner of the public key to be a
> "trusted introducer", i.e., someone who makes careful key ownership
> verifications before signing somebody else's key.
>
> This is used to estimate the trustworthiness of a certificate based on
> the signatures it contains, in a pure web-of-trust fashion (see the
> example in [1]).
>
> RFC 2440 defines no such thing AFAICS.  Nevertheless, this may be a
> useful tool for GnuTLS, too (see the discussion on `help-gnutls').

Yup, GnuTLS probably needs something like it, but it could be a simple
text file.

Is it possible to export the trust information in GnuPG easily?  Then
we could write a script to export it from GnuPG databases if people
need that functionality.

/Simon



From twoaday at gmx.net  Thu Apr 19 20:34:04 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Thu, 19 Apr 2007 20:34:04 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <87ejmgiv1m.fsf@mocca.josefsson.org>
References: <87tzve2538.fsf@chbouib.org>
	<87irbug4w1.fsf@mocca.josefsson.org>	<4625C2AE.2080402@gmx.net>
	<87slaxkg5v.fsf@mocca.josefsson.org>	<46261616.7050407@gmx.net>
	<87bqhlk8o0.fsf@mocca.josefsson.org>	<46265A37.7010005@gmx.net>
	<87ejmgiv1m.fsf@mocca.josefsson.org>
Message-ID: <4627B61C.9030100@gmx.net>

Simon Josefsson wrote:

> Great, feel free to install on GnuTLS HEAD.  I don't expect 1.7.9 to
> take as long as 1.7.8 was to release, but I'm thinking maybe one month

Oh, that's more than enough. I will port and test my changes first
before I commit it to the HEAD branch.


> Alternatively, wait for Timo's gnutls-changes to use the new OpenCDK
> (and possibly run into new bugs).

I'm not sure when I will do the first patch. My idea is to minimize
the transition time.


	Timo




From twoaday at gmx.net  Thu Apr 19 20:37:48 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Thu, 19 Apr 2007 20:37:48 +0200
Subject: [gnutls-dev] OpenPGP Keys
In-Reply-To: <877is8iut2.fsf@mocca.josefsson.org>
References: <46265D01.9070503@gmx.net> <877is8iut2.fsf@mocca.josefsson.org>
Message-ID: <4627B6FC.50609@gmx.net>

Simon Josefsson wrote:

> I'm thinking that the trustdb file will be the GnuTLS-specific
> trustdb, and thus OpenCDK can depend on the trust information in that
> file.  Wouldn't that work?

That would work.


> Thus, it would be a bad idea to run a server with your personal
> ~/.gnupg/trustdb.gpg, and you would rather create a separate
> trustdb.gpg for the GnuTLS server.

This is also my opinion. Plus the trustdb.gpg file has a non-public
format and can change any time. This time it was a workaround but
never changed.


> what we are doing, or?) so if it is possible to have a text file with
> OpenPGP key identifiers in it that the server should trust, that seems
> like a better choice.  Is there any other information in the trustdb
> that GnuTLS/OpenCDK needs?

Yes, a text file is possible and probably easier to parse than binary
files. And no other information is needed. I probably need to read the
newest OpenPGP GnuTLS draft to find out what the requirements are.


	Timo




From twoaday at gmx.net  Thu Apr 19 20:39:20 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Thu, 19 Apr 2007 20:39:20 +0200
Subject: [gnutls-dev] OpenPGP Keys
In-Reply-To: <878xcofpm1.fsf@mocca.josefsson.org>
References: <46265D01.9070503@gmx.net>
	<87ps60hjp1.fsf@laas.fr>	<46273016.10503@gmx.net>
	<877is8a6jt.fsf@laas.fr> <878xcofpm1.fsf@mocca.josefsson.org>
Message-ID: <4627B758.5080103@gmx.net>

Simon Josefsson wrote:

> Is it possible to export the trust information in GnuPG easily?  Then
> we could write a script to export it from GnuPG databases if people

gpg --export-ownertrust

It's a very simple output, just the fingerprint and the ownertrust value.

Example: gpg --export-ownertrust (stripped)
1D7581085BC9D9FBE78B2078ED4681C9BF3DF9B4:6:


	Timo





From simon at josefsson.org  Thu Apr 19 21:03:53 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Apr 2007 21:03:53 +0200
Subject: [gnutls-dev] OpenPGP Keys
In-Reply-To: <4627B758.5080103@gmx.net> (Timo Schulz's message of "Thu\, 19 Apr
	2007 20\:39\:20 +0200")
References: <46265D01.9070503@gmx.net> <87ps60hjp1.fsf@laas.fr>
	<46273016.10503@gmx.net> <877is8a6jt.fsf@laas.fr>
	<878xcofpm1.fsf@mocca.josefsson.org> <4627B758.5080103@gmx.net>
Message-ID: <87odlkchk6.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Simon Josefsson wrote:
>
>> Is it possible to export the trust information in GnuPG easily?  Then
>> we could write a script to export it from GnuPG databases if people
>
> gpg --export-ownertrust
>
> It's a very simple output, just the fingerprint and the ownertrust value.
>
> Example: gpg --export-ownertrust (stripped)
> 1D7581085BC9D9FBE78B2078ED4681C9BF3DF9B4:6:

Using something like that seems much simpler than reading binary
non-standard files, so I think we have agreement on this.

/Simon



From twoaday at gmx.net  Thu Apr 19 22:38:24 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Thu, 19 Apr 2007 22:38:24 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <87r6qgbmy0.fsf@laas.fr>
References: <87tzve2538.fsf@chbouib.org>
	<87irbug4w1.fsf@mocca.josefsson.org>	<4625C2AE.2080402@gmx.net>
	<87slaxkg5v.fsf@mocca.josefsson.org>	<46261616.7050407@gmx.net>
	<87bqhlk8o0.fsf@mocca.josefsson.org>	<46265A37.7010005@gmx.net>
	<87ejmgiv1m.fsf@mocca.josefsson.org> <87r6qgbmy0.fsf@laas.fr>
Message-ID: <4627D340.3030001@gmx.net>

Ludovic Court?s wrote:

> this thread or wait for Timo's updates.  In any case, there's no rush: I
> can wait until Timo's changes are ready or 1.7.9 is out, whichever comes

My first test with the code was successful. But it still need some
cleanups and tests. I'm very confident to commit the new code into
the HEAD branch soon.

But because Simon said we have about ~4 weeks, I think it's better to
take some time for testing to avoid to introduce new bugs. On the other
hand I don't think the migration will take more than a few days.


	Timo



From twoaday at gmx.net  Fri Apr 20 10:43:51 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 20 Apr 2007 10:43:51 +0200
Subject: [gnutls-dev] OpenPGP Keys
In-Reply-To: <87ejmf1obm.fsf@laas.fr>
References: <46265D01.9070503@gmx.net>
	<87ps60hjp1.fsf@laas.fr>	<46273016.10503@gmx.net>
	<877is8a6jt.fsf@laas.fr>	<4627B59E.6030107@gmx.net>
	<87ejmf1obm.fsf@laas.fr>
Message-ID: <46287D47.7050005@gmx.net>

Hi,

> (You directed the mail to `gnutls-dev-bounces' instead of `gnutls-dev'

Oops, I blame the mailer. Of course it should be go to gnutls-dev. Thanks.


> This is only used when traversing the certification graph ("web of
> trust") to determine the "loss of trustworthiness" yielded when
> following an edge.  (Wow, what a fancy sentence! ;-))

I'm not sure about the current documentation, I remember that I've
seen some pictures of the WoT as examples. But if there is so much
confusion about this topic, I guess it's the best idea to explain
this in details (again).


> key-user ID binding?"  And, as discussed on `help-gnutls', it takes more
> than this to implement a server-side authorization scheme.  Thus,
> trustdbs in GnuTLS would only be a building block for people who want to
> implement authorization schemes based on user IDs, for instance.

I agree. A trustdb would involve more than just a simple trust to key
association. And right now there is no code in opencdk to calculate the
validity of a key based on the signatures and ownertrust values.

And to my surprise, the new code works even with the dummy stubs of the
trustdb code. So I ask me where the trustdb is really involved in the
handshake or authentication steps.


	Timo



From simon at josefsson.org  Fri Apr 20 11:32:51 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 20 Apr 2007 11:32:51 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <4627D340.3030001@gmx.net> (Timo Schulz's message of "Thu\, 19 Apr
	2007 22\:38\:24 +0200")
References: <87tzve2538.fsf@chbouib.org> <87irbug4w1.fsf@mocca.josefsson.org>
	<4625C2AE.2080402@gmx.net> <87slaxkg5v.fsf@mocca.josefsson.org>
	<46261616.7050407@gmx.net> <87bqhlk8o0.fsf@mocca.josefsson.org>
	<46265A37.7010005@gmx.net> <87ejmgiv1m.fsf@mocca.josefsson.org>
	<87r6qgbmy0.fsf@laas.fr> <4627D340.3030001@gmx.net>
Message-ID: <87wt07bdbw.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Ludovic Court?s wrote:
>
>> this thread or wait for Timo's updates.  In any case, there's no rush: I
>> can wait until Timo's changes are ready or 1.7.9 is out, whichever comes
>
> My first test with the code was successful. But it still need some
> cleanups and tests. I'm very confident to commit the new code into
> the HEAD branch soon.

Nice!

> But because Simon said we have about ~4 weeks, I think it's better to
> take some time for testing to avoid to introduce new bugs. On the other
> hand I don't think the migration will take more than a few days.

Maybe I was unclear: the next release will be in ~4 weeks, and my hope
is that your OpenCDK changes is included in that release.  So if you
install your changes in the next few days, having a few weeks to test
and debug it seems appropriate.

/Simon



From twoaday at gmx.net  Fri Apr 20 13:18:05 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 20 Apr 2007 13:18:05 +0200
Subject: [gnutls-dev] Fixing OpenPGP keyring import
In-Reply-To: <87wt07bdbw.fsf@mocca.josefsson.org>
References: <87tzve2538.fsf@chbouib.org>
	<87irbug4w1.fsf@mocca.josefsson.org>	<4625C2AE.2080402@gmx.net>
	<87slaxkg5v.fsf@mocca.josefsson.org>	<46261616.7050407@gmx.net>
	<87bqhlk8o0.fsf@mocca.josefsson.org>	<46265A37.7010005@gmx.net>
	<87ejmgiv1m.fsf@mocca.josefsson.org>	<87r6qgbmy0.fsf@laas.fr>
	<4627D340.3030001@gmx.net> <87wt07bdbw.fsf@mocca.josefsson.org>
Message-ID: <4628A16D.5000808@gmx.net>

Simon Josefsson wrote:

> Maybe I was unclear: the next release will be in ~4 weeks, and my hope
> is that your OpenCDK changes is included in that release.  So if you

No, I understood that but it seems it was too late for me to type an
appropriate answer. Sorry.


> install your changes in the next few days, having a few weeks to test
> and debug it seems appropriate.

That's also my plan. I will hopefully finish the commit and the
migration of the code, on Sunday.


	Timo



From twoaday at gmx.net  Fri Apr 20 13:44:36 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 20 Apr 2007 13:44:36 +0200
Subject: [gnutls-dev] autoconf version handling
Message-ID: <4628A7A4.8090104@gmx.net>

Hi!

Is it correct that the current configure.in
version does not check for required third party
library versions?

I mean how do we differ between 0.5.13 and
the new 0.6.0 lib?

I tried to find a 'AM_PATH_GPG_ERROR' like macro or
'AC_CHECK_PTH' like macro but I did not find anything.


The changes are ready to commit. The code currently
depends on the unreleased 0.6.0 version of opencdk.
When we are sure that the openpgp code in GnuTLS does
not need more interfaces/functions, I will release 0.6.0.
Of course the newest opencdk code is available via the CVS.


My test to check the code was:
./gnutls-cli --debug 6 --ctypes openpgp \
             --pgpcertfile openpgp/cli_pub.asc \
	     --pgpkeyfile openpgp/cli_sec.asc \
	     -p 5556 test.gnutls.org

Is there anything I can try to test the code?


	Timo



From simon at josefsson.org  Fri Apr 20 14:20:42 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 20 Apr 2007 14:20:42 +0200
Subject: [gnutls-dev] autoconf version handling
In-Reply-To: <4628A7A4.8090104@gmx.net> (Timo Schulz's message of "Fri\, 20 Apr
	2007 13\:44\:36 +0200")
References: <4628A7A4.8090104@gmx.net>
Message-ID: <878xcn9qzp.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Hi!
>
> Is it correct that the current configure.in
> version does not check for required third party
> library versions?
>
> I mean how do we differ between 0.5.13 and
> the new 0.6.0 lib?
>
> I tried to find a 'AM_PATH_GPG_ERROR' like macro or
> 'AC_CHECK_PTH' like macro but I did not find anything.

A better solution is to test for features and not version numbers.
Did you add some new externally visible API in 0.6, that the updated
GnuTLS code would need?  Then check for that, using something like:

  AC_LIB_HAVE_LINKFLAGS(opencdk,, [
#include <stddef.h> /* opencdk <= 0.5.13 uses size_t without this include */
#include <opencdk.h>], [cdk_new_function_foobar;])

Btw, I think we should add something like what's in gnutls.h into
opencdk.h:

#define LIBGNUTLS_VERSION_MAJOR 1
#define LIBGNUTLS_VERSION_MINOR 7
#define LIBGNUTLS_VERSION_PATCH 9

This allows M4 tests to do version-based testing, if someone prefers
to use that in some situation.  It should go into opencdk.h.in, and be
substituted, of course.

> The changes are ready to commit. The code currently
> depends on the unreleased 0.6.0 version of opencdk.
> When we are sure that the openpgp code in GnuTLS does
> not need more interfaces/functions, I will release 0.6.0.
> Of course the newest opencdk code is available via the CVS.

Sounds good!  Maybe you could post the patch for easier review?

> My test to check the code was:
> ./gnutls-cli --debug 6 --ctypes openpgp \
>              --pgpcertfile openpgp/cli_pub.asc \
> 	     --pgpkeyfile openpgp/cli_sec.asc \
> 	     -p 5556 test.gnutls.org
>
> Is there anything I can try to test the code?

'make check'?  If there are no self-tests for OpenPGP, which I guess
there aren't, write a self-test and test it with the old/new code.
See pskself.c, anonself.c etc.

/Simon



From simon at josefsson.org  Fri Apr 20 14:42:53 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 20 Apr 2007 14:42:53 +0200
Subject: [gnutls-dev] OpenCDK comments
Message-ID: <87zm538bea.fsf@mocca.josefsson.org>

I looked over OpenCDK HEAD and some comments:

* Can't we officially deprecate keygen.c and its interfaces, in the
  same way that the trustdb.c interfaces have been deprecated?  I'd
  rather recommend people to use GnuPG to generate OpenPGP keys,
  especially since GnuTLS doesn't have a command-line interface for
  OpenCDK to generate keys.

* Is the keyserver stuff needed?  It seems limited compared to the new
  GnuPG keyserver stuff.  I'm not sure GnuTLS ever needs this
  functionality.  I think the best solution is to use GnuPG's
  keyserver infrastructure instead.  I think we could deprecate this
  too.

* I'd recomment that we use gnulib for CRC, Base64, several misc.c
  functions, etc.

* Does keydb.c implement some disk-format for key databases?  Is it
  the GnuPG format?

* We probably should review the libgcrypt init code to make sure it
  doesn't conflict with how GnuTLS initialize libgcrypt.

* Where is stream-socket.c used?  keyservers?  Maybe it could be
  removed too, if keyserver stuff is removed.

/Simon



From twoaday at gmx.net  Fri Apr 20 14:48:32 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 20 Apr 2007 14:48:32 +0200
Subject: [gnutls-dev] new openpgp code available
Message-ID: <4628B6A0.4060303@gmx.net>


Hi!

I just committed the first bunch of adjustments. I was
careful not to destroy any previous patches.

Is there a bug tracker or bug list so I can check that
all resolved bugs are not re-introduced again?


	Timo

p.s.
The cleanup (the final state of the migration) is not
100% finished yet. But the API migration is finished.




From twoaday at gmx.net  Fri Apr 20 14:36:47 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 20 Apr 2007 14:36:47 +0200
Subject: [gnutls-dev] autoconf version handling
In-Reply-To: <878xcn9qzp.fsf@mocca.josefsson.org>
References: <4628A7A4.8090104@gmx.net> <878xcn9qzp.fsf@mocca.josefsson.org>
Message-ID: <4628B3DF.4000404@gmx.net>

Simon Josefsson wrote:

> A better solution is to test for features and not version numbers.
> Did you add some new externally visible API in 0.6, that the updated
> GnuTLS code would need?  Then check for that, using something like:

I need to check this, but to make sure that the right opencdk version
is used, I will add a check for a function which is new in 0.6.0.


> Btw, I think we should add something like what's in gnutls.h into
> opencdk.h:
> 
> #define LIBGNUTLS_VERSION_MAJOR 1
> #define LIBGNUTLS_VERSION_MINOR 7
> #define LIBGNUTLS_VERSION_PATCH 9
> 
> This allows M4 tests to do version-based testing, if someone prefers
> to use that in some situation.  It should go into opencdk.h.in, and be

You mean in the included version of opencdk in gnutls?

And BTW, I'm not sure if this is the intended purpose, but the
preference for the opencdk.h header is always libextra/opencdk.h a
not /usr/include/opencdk.h.


> Sounds good!  Maybe you could post the patch for easier review?

Sure, I will commit it in a few minutes.


> 'make check'?  If there are no self-tests for OpenPGP, which I guess
> there aren't, write a self-test and test it with the old/new code.
> See pskself.c, anonself.c etc.

I'm not sure if there are any self tests. I will look and if there are
no test, I will at least write a very basic one.


	Timo



From twoaday at gmx.net  Fri Apr 20 15:00:37 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 20 Apr 2007 15:00:37 +0200
Subject: [gnutls-dev] OpenCDK comments
In-Reply-To: <87zm538bea.fsf@mocca.josefsson.org>
References: <87zm538bea.fsf@mocca.josefsson.org>
Message-ID: <4628B975.8040103@gmx.net>

Simon Josefsson wrote:

> * Can't we officially deprecate keygen.c and its interfaces, in the
>   same way that the trustdb.c interfaces have been deprecated?  I'd

I'm not sure if we share the same opinion or if we even talk about
the same thing. OpenCDK is a general library and not only for the use
in GnuTLS. At least that's what I planned. I'm not sure if it is used
in the real world, but I plan to make a public release soon.

The keygen API is not used in GnuTLS and it never was.


> * Is the keyserver stuff needed?  It seems limited compared to the new
>   GnuPG keyserver stuff.  I'm not sure GnuTLS ever needs this
>   functionality.  I think the best solution is to use GnuPG's

There is a callback for key receiving and it is used right now. At
least when some flags are enabled. And yes, it is very limited but
it might be useful for people who just want to download a key via
HKP.


> * I'd recomment that we use gnulib for CRC, Base64, several misc.c
>   functions, etc.

For the mingw32 build the gnulib would be linked static? Right now
opencdk depends on gcrypt, gpg-error and 'z' and to increase the
amount of libs can be burdensome for the w32 port. My idea was to
keep the library tight and small to avoid too much dependies.

We could use ligcrypt for the CRC stuff. The base64 code is IMHO
not that much and there are also very limited misc functions.
You might have seen I removed the vasprintf code. Now it's only
a case in-sensitive version of strstr.


> * Does keydb.c implement some disk-format for key databases?  Is it
>   the GnuPG format?

It just stores the openpgp packet in a sequence. Basically this is
what GPG also does.


> * We probably should review the libgcrypt init code to make sure it
>   doesn't conflict with how GnuTLS initialize libgcrypt.

That's true. The only code I currently use is the secure memory allocation.


> * Where is stream-socket.c used?  keyservers?  Maybe it could be
>   removed too, if keyserver stuff is removed.

I might have the impression, that you think of opencdk as a library
which is *only* used for GnuTLS. It is a problem that OpenCDK is a
general library and also provides interfaces which are not used by GnuTLS?


	Timo



From simon at josefsson.org  Fri Apr 20 15:01:07 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 20 Apr 2007 15:01:07 +0200
Subject: [gnutls-dev] autoconf version handling
In-Reply-To: <4628B3DF.4000404@gmx.net> (Timo Schulz's message of "Fri\, 20 Apr
	2007 14\:36\:47 +0200")
References: <4628A7A4.8090104@gmx.net> <878xcn9qzp.fsf@mocca.josefsson.org>
	<4628B3DF.4000404@gmx.net>
Message-ID: <87r6qf8ajw.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Simon Josefsson wrote:
>
>> A better solution is to test for features and not version numbers.
>> Did you add some new externally visible API in 0.6, that the updated
>> GnuTLS code would need?  Then check for that, using something like:
>
> I need to check this, but to make sure that the right opencdk version
> is used, I will add a check for a function which is new in 0.6.0.

Sounds good.

>> Btw, I think we should add something like what's in gnutls.h into
>> opencdk.h:
>> 
>> #define LIBGNUTLS_VERSION_MAJOR 1
>> #define LIBGNUTLS_VERSION_MINOR 7
>> #define LIBGNUTLS_VERSION_PATCH 9
>> 
>> This allows M4 tests to do version-based testing, if someone prefers
>> to use that in some situation.  It should go into opencdk.h.in, and be
>
> You mean in the included version of opencdk in gnutls?

No, in opencdk CVS, I'm think you should add to opencdk.h.in:

#define OPENCDK_VERSION_MAJOR @MAJOR_VERSION@
#define OPENCDK_VERSION_MINOR @MINOR_VERSION@
#define OPENCDK_VERSION_PATCH @PATCH_VERSION@

and the related mechanism in configure.ac.

> And BTW, I'm not sure if this is the intended purpose, but the
> preference for the opencdk.h header is always libextra/opencdk.h a
> not /usr/include/opencdk.h.

That should be fixed, I think.

>> 'make check'?  If there are no self-tests for OpenPGP, which I guess
>> there aren't, write a self-test and test it with the old/new code.
>> See pskself.c, anonself.c etc.
>
> I'm not sure if there are any self tests. I will look and if there are
> no test, I will at least write a very basic one.

Yes, I think that will be good.  We can't really talk about
regressions unless there are self-tests for things we care about.

/Simon



From twoaday at gmx.net  Fri Apr 20 15:15:28 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Fri, 20 Apr 2007 15:15:28 +0200
Subject: [gnutls-dev] autoconf version handling
In-Reply-To: <87r6qf8ajw.fsf@mocca.josefsson.org>
References: <4628A7A4.8090104@gmx.net>
	<878xcn9qzp.fsf@mocca.josefsson.org>	<4628B3DF.4000404@gmx.net>
	<87r6qf8ajw.fsf@mocca.josefsson.org>
Message-ID: <4628BCF0.3060002@gmx.net>

Simon Josefsson wrote:

> No, in opencdk CVS, I'm think you should add to opencdk.h.in:
> 
> #define OPENCDK_VERSION_MAJOR @MAJOR_VERSION@
> #define OPENCDK_VERSION_MINOR @MINOR_VERSION@
> #define OPENCDK_VERSION_PATCH @PATCH_VERSION@
> 
> and the related mechanism in configure.ac.

Oh, sorry I was confused. Yes, this is a good idea.


	Timo





From simon at josefsson.org  Sun Apr 22 09:37:45 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 22 Apr 2007 09:37:45 +0200
Subject: [gnutls-dev] new openpgp code available
In-Reply-To: <4628B6A0.4060303@gmx.net> (Timo Schulz's message of "Fri\, 20 Apr
	2007 14\:48\:32 +0200")
References: <4628B6A0.4060303@gmx.net>
Message-ID: <87slas7tbq.fsf@mocca.josefsson.org>

Btw, I'd really appreciate a list of API/ABIs that were
changed/added/removed between OpenCDK 0.5.x and 0.6.0.  I think that
could go into the OpenCDK NEWS file.

/Simon



From simon at josefsson.org  Sun Apr 22 09:28:20 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 22 Apr 2007 09:28:20 +0200
Subject: [gnutls-dev] autoconf version handling
In-Reply-To: <4628B3DF.4000404@gmx.net> (Timo Schulz's message of "Fri\, 20 Apr
	2007 14\:36\:47 +0200")
References: <4628A7A4.8090104@gmx.net> <878xcn9qzp.fsf@mocca.josefsson.org>
	<4628B3DF.4000404@gmx.net>
Message-ID: <87647o98bv.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Simon Josefsson wrote:
>
>> A better solution is to test for features and not version numbers.
>> Did you add some new externally visible API in 0.6, that the updated
>> GnuTLS code would need?  Then check for that, using something like:
>
> I need to check this, but to make sure that the right opencdk version
> is used, I will add a check for a function which is new in 0.6.0.

Building GnuTLS CVS doesn't detect that the system OpenCDK is out of
date:

checking whether to disable OpenPGP Certificate authentication support... no
checking for libopencdk... yes
checking how to link with libopencdk... -lopencdk
checking whether to use the included opencdk... no

It then fails when building the code that uses OpenCDK:

make[3]: Entering directory `/home/jas/src/gnutls/libextra/openpgp'
/bin/sh ../../libtool --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..  -I../../lgl -I../../lgl -I../../crypto -I../../lib -I../../includes -I../../includes -I../../libextra/opencdk -I../../lib/minitasn1    -D_REENTRANT -D_THREAD_SAFE -g -Wall -Wcast-align -W -Wpointer-arith -Wchar-subscripts -Wformat-security -Wno-format-y2k -Wmissing-braces -Winline -Wstrict-prototypes -Wno-unused-parameter -Wno-pointer-sign -pipe -I/usr/local/include  -I/usr/local/include -MT pgp.lo -MD -MP -MF .deps/pgp.Tpo -c -o pgp.lo pgp.c
 gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lgl -I../../lgl -I../../crypto -I../../lib -I../../includes -I../../includes -I../../libextra/opencdk -I../../lib/minitasn1 -D_REENTRANT -D_THREAD_SAFE -g -Wall -Wcast-align -W -Wpointer-arith -Wchar-subscripts -Wformat-security -Wno-format-y2k -Wmissing-braces -Winline -Wstrict-prototypes -Wno-unused-parameter -Wno-pointer-sign -pipe -I/usr/local/include -I/usr/local/include -MT pgp.lo -MD -MP -MF .deps/pgp.Tpo -c pgp.c  -fPIC -DPIC -o .libs/pgp.o
pgp.c: In function 'gnutls_openpgp_key_import':
pgp.c:99: error: too many arguments to function 'cdk_stream_tmp_from_mem'
pgp.c:99: warning: assignment makes integer from pointer without a cast
pgp.c: In function 'gnutls_openpgp_key_export':
pgp.c:165: warning: implicit declaration of function 'cdk_armor_encode_buffer'
make[3]: *** [pgp.lo] Error 1
make[3]: Leaving directory `/home/jas/src/gnutls/libextra/openpgp'

I installed this patch:

Index: configure.in
===================================================================
RCS file: /cvs/gnutls/gnutls/configure.in,v
retrieving revision 2.495
retrieving revision 2.496
diff -u -p -r2.495 -r2.496
--- configure.in	16 Apr 2007 14:34:23 -0000	2.495
+++ configure.in	22 Apr 2007 07:21:55 -0000	2.496
@@ -396,8 +396,7 @@ if test x$ac_enable_openpgp = xyes; then
 		ac_enable_included_opencdk=no)
  if test x$ac_enable_included_opencdk = xno;then 
   AC_LIB_HAVE_LINKFLAGS(opencdk,, [
-#include <stddef.h> /* opencdk <= 0.5.13 uses size_t without this include */
-#include <opencdk.h>], [cdk_check_version (OPENCDK_VERSION);])
+#include <opencdk.h>], [cdk_armor_encode_buffer (NULL, 0, NULL, 0, NULL, 0);])
   if test "$ac_cv_libopencdk" != yes; then
    ac_enable_included_opencdk=yes
    AC_MSG_WARN([[

We should update the included OpenCDK version in GnuTLS with 0.6.0
too..  And test how well older GnuTLS releases deals with OpenCDK
0.6.0.

/Simon



From simon at josefsson.org  Sun Apr 22 09:36:47 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 22 Apr 2007 09:36:47 +0200
Subject: [gnutls-dev] OpenCDK comments
In-Reply-To: <4628B975.8040103@gmx.net> (Timo Schulz's message of "Fri\, 20 Apr
	2007 15\:00\:37 +0200")
References: <87zm538bea.fsf@mocca.josefsson.org> <4628B975.8040103@gmx.net>
Message-ID: <87wt047tdc.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Simon Josefsson wrote:
>
>> * Can't we officially deprecate keygen.c and its interfaces, in the
>>   same way that the trustdb.c interfaces have been deprecated?  I'd
>
> I'm not sure if we share the same opinion or if we even talk about
> the same thing. OpenCDK is a general library and not only for the use
> in GnuTLS. At least that's what I planned. I'm not sure if it is used
> in the real world, but I plan to make a public release soon.

Ok, I understand.  Still, the comment in keygen.c says:

/* WARNING: The key generation code is very old and probably needs
            a lot of adjustments and changes. Please avoid it for now
            if possible. */

That doesn't inspire confidence in the code...

>> * I'd recomment that we use gnulib for CRC, Base64, several misc.c
>>   functions, etc.
>
> For the mingw32 build the gnulib would be linked static? Right now
> opencdk depends on gcrypt, gpg-error and 'z' and to increase the
> amount of libs can be burdensome for the w32 port. My idea was to
> keep the library tight and small to avoid too much dependies.
>
> We could use ligcrypt for the CRC stuff. The base64 code is IMHO
> not that much and there are also very limited misc functions.
> You might have seen I removed the vasprintf code. Now it's only
> a case in-sensitive version of strstr.

Gnulib isn't an external dependency, it is included in gl/, see the
0.5.x branch of OpenCDK and <http://www.gnu.org/software/gnulib/>.  It
can help with many portability problems, especially on mingw32.  It is
good to remove vasprintf etc, but some things may still be required.

>> * Where is stream-socket.c used?  keyservers?  Maybe it could be
>>   removed too, if keyserver stuff is removed.
>
> I might have the impression, that you think of opencdk as a library
> which is *only* used for GnuTLS. It is a problem that OpenCDK is a
> general library and also provides interfaces which are not used by GnuTLS?

No, it shouldn't be.  Perhaps the copy of OpenCDK inside GnuTLS can be
made smaller, without e.g. the keyserver files, because those have
caused compilation problems in the past.  I'll look into that.

/Simon



From simon at josefsson.org  Sun Apr 22 09:29:22 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 22 Apr 2007 09:29:22 +0200
Subject: [gnutls-dev] new openpgp code available
In-Reply-To: <4628B6A0.4060303@gmx.net> (Timo Schulz's message of "Fri\, 20 Apr
	2007 14\:48\:32 +0200")
References: <4628B6A0.4060303@gmx.net>
Message-ID: <871wic98a5.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Hi!
>
> I just committed the first bunch of adjustments. I was
> careful not to destroy any previous patches.
>
> Is there a bug tracker or bug list so I can check that
> all resolved bugs are not re-introduced again?

There is the mailing list archives...

/Simon



From twoaday at gmx.net  Sun Apr 22 12:35:05 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 22 Apr 2007 12:35:05 +0200
Subject: [gnutls-dev] OpenCDK comments
In-Reply-To: <87wt047tdc.fsf@mocca.josefsson.org>
References: <87zm538bea.fsf@mocca.josefsson.org> <4628B975.8040103@gmx.net>
	<87wt047tdc.fsf@mocca.josefsson.org>
Message-ID: <462B3A59.7070204@gmx.net>

Simon Josefsson wrote:

> Ok, I understand.  Still, the comment in keygen.c says:
> 
> /* WARNING: The key generation code is very old and probably needs
>             a lot of adjustments and changes. Please avoid it for now
>             if possible. */
> 
> That doesn't inspire confidence in the code...

And that's right. I wrote it at the begin and since then I never changed
or corrected any code. I did some cleanups and now it should produce at
least valid keys.



> Gnulib isn't an external dependency, it is included in gl/, see the
> 0.5.x branch of OpenCDK and <http://www.gnu.org/software/gnulib/>.  It

Ah, I see.


> can help with many portability problems, especially on mingw32.  It is
> good to remove vasprintf etc, but some things may still be required.

OK. I will think about it.


> No, it shouldn't be.  Perhaps the copy of OpenCDK inside GnuTLS can be
> made smaller, without e.g. the keyserver files, because those have
> caused compilation problems in the past.  I'll look into that.

That would be perfectly OK for me. We could even strip the keygen.c file
and maybe more which is not needed. IMHO we just need the code parser
code and the public key (management) related functions.


	Timo




From twoaday at gmx.net  Sun Apr 22 12:39:46 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 22 Apr 2007 12:39:46 +0200
Subject: [gnutls-dev] new openpgp code available
In-Reply-To: <87slas7tbq.fsf@mocca.josefsson.org>
References: <4628B6A0.4060303@gmx.net> <87slas7tbq.fsf@mocca.josefsson.org>
Message-ID: <462B3B72.4020809@gmx.net>

Simon Josefsson wrote:
> Btw, I'd really appreciate a list of API/ABIs that were
> changed/added/removed between OpenCDK 0.5.x and 0.6.0.  I think that
> could go into the OpenCDK NEWS file.

I guess this would be very useful. I will do it and put it
in the NEWS file.


Thanks,

	Timo




From twoaday at gmx.net  Sun Apr 22 12:37:58 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 22 Apr 2007 12:37:58 +0200
Subject: [gnutls-dev] autoconf version handling
In-Reply-To: <87647o98bv.fsf@mocca.josefsson.org>
References: <4628A7A4.8090104@gmx.net>
	<878xcn9qzp.fsf@mocca.josefsson.org>	<4628B3DF.4000404@gmx.net>
	<87647o98bv.fsf@mocca.josefsson.org>
Message-ID: <462B3B06.4060709@gmx.net>

Simon Josefsson wrote:

> -#include <stddef.h> /* opencdk <= 0.5.13 uses size_t without this include */
> -#include <opencdk.h>], [cdk_check_version (OPENCDK_VERSION);])
> +#include <opencdk.h>], [cdk_armor_encode_buffer (NULL, 0, NULL, 0, NULL, 0);])
>    if test "$ac_cv_libopencdk" != yes; then
>     ac_enable_included_opencdk=yes
>     AC_MSG_WARN([[

Ah, thanks. I forgot to commit this myself. And because
cdk_armor_encode_buffer is not available in other versions,
this quick patch should work on all systems.


> We should update the included OpenCDK version in GnuTLS with 0.6.0
> too..

True.


>  And test how well older GnuTLS releases deals with OpenCDK 0.6.0.

Probably not very good due to some changed prototypes. But IMHO it
should be no problem that older releases use the so lib version 8 (or
better 9 for a more recent version) and the newest gnutls will use
version 10. Correct me if I'm wrong.


	Timo






From twoaday at gmx.net  Sun Apr 22 12:39:10 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 22 Apr 2007 12:39:10 +0200
Subject: [gnutls-dev] new openpgp code available
In-Reply-To: <871wic98a5.fsf@mocca.josefsson.org>
References: <4628B6A0.4060303@gmx.net> <871wic98a5.fsf@mocca.josefsson.org>
Message-ID: <462B3B4E.3010703@gmx.net>

Simon Josefsson wrote:

>> Is there a bug tracker or bug list so I can check that
>> all resolved bugs are not re-introduced again?
> 
> There is the mailing list archives...

OK. IMHO the archive is not searchable, so maybe
somebody has a hint (year, month)?


	Timo




From twoaday at gmx.net  Sun Apr 22 13:06:17 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 22 Apr 2007 13:06:17 +0200
Subject: [gnutls-dev] OpenCDK comments
In-Reply-To: <87wt047tdc.fsf@mocca.josefsson.org>
References: <87zm538bea.fsf@mocca.josefsson.org> <4628B975.8040103@gmx.net>
	<87wt047tdc.fsf@mocca.josefsson.org>
Message-ID: <462B41A9.5050806@gmx.net>

Simon Josefsson wrote:

> No, it shouldn't be.  Perhaps the copy of OpenCDK inside GnuTLS can be
> made smaller, without e.g. the keyserver files, because those have
> caused compilation problems in the past.  I'll look into that.

I forgot to mention that right now there is a callback which uses
the keyserver code. Probably it would be the best idea to remove
them first. I'm not sure if 'auto' key retrieval is a general feature in
GnuTLS so the code must be probably changed at a higher level.



From twoaday at gmx.net  Sun Apr 22 13:55:17 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 22 Apr 2007 13:55:17 +0200
Subject: [gnutls-dev] build-in opencdk version
Message-ID: <462B4D25.60707@gmx.net>

Hi!

I updated the included version of opencdk.
For a simple test, I build the source
with ./configure --with-included-opencdk

No problems so far. I did *not* include files
which are not needed by the GnuTLS API. I included
a file, dummy.c, which includes all the prototypes
needed to build the lib successfully.


	Timo



From simon at josefsson.org  Sun Apr 22 14:27:16 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 22 Apr 2007 14:27:16 +0200
Subject: [gnutls-dev] RFC: PKCS#11 plans
Message-ID: <87abx061cr.fsf@mocca.josefsson.org>

Hi!  I've started experimenting with PKCS#11 support in GnuTLS, and it
seems possible to do it.  This e-mail provides a starting point for
discussions.  I'm not at all sure how to implement this, so your
thoughts and ideas are very much appreciated!

I've created a new branch gnutls_1_7_8_with_pkcs11 that will contain
these experiments.  If they are successful, they will be integrated
into the 1.7.x branch and become part of the next stable release
(which I hope to get out before or during the summer).

There are several ways to support PKCS#11 in GnuTLS, I can think of at
least three:

1) Build-time linking to a particular PKCS#11 implementation.

   Applications would likely have to call a new API, and my initial
   guess at what it would look would be:

   int gnutls_certificate_set_pkcs11 (gnutls_certificate_credentials_t res,
                                      const char *key_id);

   where KEY_ID would be an optional string denoting the Key ID of the
   key to use as the private key.  If KEY_ID is NULL, it would use any
   private key it finds.

   This is easy to use and program for, but offers limited
   flexibility.

   Refinement
   ----------

   One way to make this more flexible would be to place the API in a
   special library: libgnutls_pkcs11_foo where foo is the PKCS#11
   library it uses.  In other words, there could be:

   libgnutls_pkcs11_scute.so     uses the GnuPG 2.x PKCS#11 module
   libgnutls_pkcs11_seahorse.so  uses the GNOME SeaHorse PKCS#11 plugin
   libgnutls_pkcs11_nss.so       uses the Mozilla NSS PKCS#11 module
   ...

   Each of those libraries would be directly linked to the particular
   PKCS#11 library.  Applications, if they need PKCS#11 functionality,
   would have to link to one of these libraries.  They are mutually
   exclusive, so you can't use both seahorse and scute, which is a
   serious disadvantage.  Still, sometimes it may be sufficient.

2) Runtime linking to a application-chosen PKCS#11 implementation.

   This would likely use dlopen(), and applications would need to
   specify the path to the PKCS#11 plugin.  You'll need a new API for
   this as well, I'm thinking something like this:

   int gnutls_certificate_set_pkcs11 (gnutls_certificate_credentials_t res,
                                      const char *library,
                                      const char *key_id);

   This would dlopen() LIBRARY and search for KEY_ID, which may be
   NULL to indicate that any private key is fine.

   Applications can support more than one PKCS#11 plugin with this
   approach.  For example, it can do two calls:

     gnutls_certificate_set_pkcs11 (res, "/usr/lib/libscute.so", NULL);
     gnutls_certificate_set_pkcs11 (res, "/usr/lib/libnss.so", NULL);

   This seems like a nice approach, although it seems sub-optimal that
   applications have to provide library paths.  Applications shouldn't
   have to care about such details.

   Refinement
   ----------

   If LIBRARY is NULL, GnuTLS could use a static list of known
   PKCS#11-providers, or it could read the list from a
   /etc/gnutls-pkcs11.conf, ~/.gnutls-pkcs11.conf, GNUTLS_PKCS11
   environment variable, or similar.

3) IPC to a gnutls-daemon that is responsible for the PKCS#11 management.

   Here there is no linkage to any PKCS#11 plugin at all, which I
   consider a major advantage -- I would not want buffer-overflow
   attacks in PKCS#11 plugins to cause problems in the GnuTLS library.

   The gnutls-daemon is responsible for loading and calling the
   PKCS#11 plugins correctly.  The APIs can look the same as previous,
   in case the gnutls-daemon can dlopen() libraries.  In other words,
   the following:

   int gnutls_certificate_set_pkcs11 (gnutls_certificate_credentials_t res,
                                      const char *library,
                                      const char *key_id);

   would indicate that the certificate structure should talk to the
   gnutls-daemon, and ask it to search for KEY_ID (if non-null) in
   LIBRARY (if given), or just be happy with any private key at all.

What do you think?

/Simon



From simon at josefsson.org  Sun Apr 22 14:29:19 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 22 Apr 2007 14:29:19 +0200
Subject: [gnutls-dev] build-in opencdk version
In-Reply-To: <462B4D25.60707@gmx.net> (Timo Schulz's message of "Sun\, 22 Apr
	2007 13\:55\:17 +0200")
References: <462B4D25.60707@gmx.net>
Message-ID: <87647o619c.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Hi!
>
> I updated the included version of opencdk.
> For a simple test, I build the source
> with ./configure --with-included-opencdk

Hi!  I'll have a look.

> No problems so far. I did *not* include files
> which are not needed by the GnuTLS API. I included
> a file, dummy.c, which includes all the prototypes
> needed to build the lib successfully.

I can't seem to find dummy.c...

/Simon



From simon at josefsson.org  Sun Apr 22 14:35:14 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 22 Apr 2007 14:35:14 +0200
Subject: [gnutls-dev] autoconf version handling
In-Reply-To: <462B3B06.4060709@gmx.net> (Timo Schulz's message of "Sun\, 22 Apr
	2007 12\:37\:58 +0200")
References: <4628A7A4.8090104@gmx.net> <878xcn9qzp.fsf@mocca.josefsson.org>
	<4628B3DF.4000404@gmx.net> <87647o98bv.fsf@mocca.josefsson.org>
	<462B3B06.4060709@gmx.net>
Message-ID: <871wic60zh.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

>>  And test how well older GnuTLS releases deals with OpenCDK 0.6.0.
>
> Probably not very good due to some changed prototypes.

I'll check this.

> But IMHO it should be no problem that older releases use the so lib
> version 8 (or better 9 for a more recent version) and the newest
> gnutls will use version 10. Correct me if I'm wrong.

Right.  However, the problem is the opencdk.h header file.
Distributors can't ship /usr/include/opencdk.h from both 0.5.x and
0.6.x at the same time.

Is there no possibility to rename the APIs that changed in 0.6 and
provide a backwards compatibility glue under the old function name?

This isn't a critical problem, but it is always nicer if newer
versions retains source-code backwards compatibility (i.e., 0.6
opencdk.h + 0.6 libopencdk.so against 0.5 application) even when the
ABI is bumped.

/Simon



From simon at josefsson.org  Sun Apr 22 14:59:54 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 22 Apr 2007 14:59:54 +0200
Subject: [gnutls-dev] RFC: PKCS#11 plans
In-Reply-To: <9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>
	(Alon Bar-Lev's message of "Sun\, 22 Apr 2007 15\:40\:52 +0300")
References: <87abx061cr.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>
Message-ID: <87d51w4l9x.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> Hello,
>
> I think this is a great idea to finally support PKCS#11!

Hi!  Thanks for your comments.  (I'm quoting your message verbosely
since you weren't subscribed and you message never reached the
list... I've added you to the whitelist of the mailing list now.)

> But:
> 1. Never link against a specific provider.

Yeah, that's what I'm leaning towards as well, but it creates more
work...

> 2. If you wish to use a daemon, the daemon interface can be PKCS#11...
> so actually this is a separate project... To write a PKCS#11 provider
> that interacts using sockets with a daemon which loads several
> providers into its namespace. I have this in my TODO list... It can
> also provide single sign on for the user.

PKCS#11 isn't a protocol-like API, so we'd have to serialize the
requests.  But that shouldn't be too difficult.  I'm thinking a
protocol similar to the GnuPG 2.x daemons, a'la:

GnuTLS: PKCS11 "/usr/local/lib/libscute.so"
Daemon: END
GnuTLS: LISTCERTS
Daemon: BD:5F:80:DE:63:03:4E:C9:E2:84:1E:63:09:55:2E:34:5C:5F:22:6F
Daemon: 15:32:B4:BA:5A:8A:79:88:CA:26:42:83:59:1B:A3:A2:1C:0B:CC:24
Daemon: END
GnuTLS: LISTKEYS:
Daemon: BD:5F:80:DE:63:03:4E:C9:E2:84:1E:63:09:55:2E:34:5C:5F:22:6F
Daemon: END
GnuTLS: SIGN BD:5F:80... 237823782323...
etc

to talk with a PKCS11 provider

Or:

GnuTLS: GNUPG
Daemon: END
GnuTLS: LISTCERTS
Daemon: BD:5F:80:DE:63:03:4E:C9:E2:84:1E:63:09:55:2E:34:5C:5F:22:6F
Daemon: 15:32:B4:BA:5A:8A:79:88:CA:26:42:83:59:1B:A3:A2:1C:0B:CC:24
Daemon: END
GnuTLS: LISTKEYS:
Daemon: BD:5F:80:DE:63:03:4E:C9:E2:84:1E:63:09:55:2E:34:5C:5F:22:6F
Daemon: END
GnuTLS: SIGN BD:5F:80... 237823782323...
etc

to talk with GnuPG 2.x gpg-agent + scdaemon + gpgsm.

GnuTLS's needs are not complex, so the protocol could be simple.  The
gnutls-daemon would then be responsible for loading the appropriate
PKCS#11 plugins, or other crypto providers.  All complexity would be
in gnutls-daemon.

> 3. You should handle dynamic events such as token remove, token
> insert, PIN request.

I don't see what would be gained by having GnuTLS be aware of those
concepts, so I'd prefer to keep that in the gnutls-daemon, or
possibly, inside each PKCS#11 provider.

> 4. What happens if signature/decrypt is requested and the token is unavailable?

1) The TLS handshake fails.
-or-
2) GnuTLS hangs waiting for gnutls-daemon to return, and gnutls-daemon
   could ask the user to insert its smartcard etc.  The operation can
   be canceled, and can timeout.

> 5. What is the meaning of the ID? Where the user may receive it? I
> guess I mean you need to support enumeration.

Yes.  I think most crypto providers have a notion of key ids.

> Handling smartcard require significant change in concept... I've
> implemented a library that should ease the interaction, and address
> the above issues.
> http://www.opensc-project.org/pkcs11-helper

I'm looking at it now, although I'm not sure I understand whether or
how I could use it.  It seems as if applications might use
pkcs11helper, but it isn't applicable to GnuTLS or gnutls-daemon.

> I believe that ignoring these will not enable GnuTLS application to
> suport hardware based crypto correctly.
>
> To begin with, I think GnuTLS should have generic crypto
> engine/provider interface. And using this interface a PKCS#11
> engine/provider should be implemented.

Yes, I also think that would be the Right Solution, although it
requires slightly more work than supporting PKCS#11 directly.

/Simon

> Best Regards,
> Alon Bar-Lev
>
> On 4/22/07, Simon Josefsson <simon at josefsson.org> wrote:
>> Hi!  I've started experimenting with PKCS#11 support in GnuTLS, and it
>> seems possible to do it.  This e-mail provides a starting point for
>> discussions.  I'm not at all sure how to implement this, so your
>> thoughts and ideas are very much appreciated!
>>
>> I've created a new branch gnutls_1_7_8_with_pkcs11 that will contain
>> these experiments.  If they are successful, they will be integrated
>> into the 1.7.x branch and become part of the next stable release
>> (which I hope to get out before or during the summer).
>>
>> There are several ways to support PKCS#11 in GnuTLS, I can think of at
>> least three:
>>
>> 1) Build-time linking to a particular PKCS#11 implementation.
>>
>>    Applications would likely have to call a new API, and my initial
>>    guess at what it would look would be:
>>
>>    int gnutls_certificate_set_pkcs11 (gnutls_certificate_credentials_t res,
>>                                       const char *key_id);
>>
>>    where KEY_ID would be an optional string denoting the Key ID of the
>>    key to use as the private key.  If KEY_ID is NULL, it would use any
>>    private key it finds.
>>
>>    This is easy to use and program for, but offers limited
>>    flexibility.
>>
>>    Refinement
>>    ----------
>>
>>    One way to make this more flexible would be to place the API in a
>>    special library: libgnutls_pkcs11_foo where foo is the PKCS#11
>>    library it uses.  In other words, there could be:
>>
>>    libgnutls_pkcs11_scute.so     uses the GnuPG 2.x PKCS#11 module
>>    libgnutls_pkcs11_seahorse.so  uses the GNOME SeaHorse PKCS#11 plugin
>>    libgnutls_pkcs11_nss.so       uses the Mozilla NSS PKCS#11 module
>>    ...
>>
>>    Each of those libraries would be directly linked to the particular
>>    PKCS#11 library.  Applications, if they need PKCS#11 functionality,
>>    would have to link to one of these libraries.  They are mutually
>>    exclusive, so you can't use both seahorse and scute, which is a
>>    serious disadvantage.  Still, sometimes it may be sufficient.
>>
>> 2) Runtime linking to a application-chosen PKCS#11 implementation.
>>
>>    This would likely use dlopen(), and applications would need to
>>    specify the path to the PKCS#11 plugin.  You'll need a new API for
>>    this as well, I'm thinking something like this:
>>
>>    int gnutls_certificate_set_pkcs11 (gnutls_certificate_credentials_t res,
>>                                       const char *library,
>>                                       const char *key_id);
>>
>>    This would dlopen() LIBRARY and search for KEY_ID, which may be
>>    NULL to indicate that any private key is fine.
>>
>>    Applications can support more than one PKCS#11 plugin with this
>>    approach.  For example, it can do two calls:
>>
>>      gnutls_certificate_set_pkcs11 (res, "/usr/lib/libscute.so", NULL);
>>      gnutls_certificate_set_pkcs11 (res, "/usr/lib/libnss.so", NULL);
>>
>>    This seems like a nice approach, although it seems sub-optimal that
>>    applications have to provide library paths.  Applications shouldn't
>>    have to care about such details.
>>
>>    Refinement
>>    ----------
>>
>>    If LIBRARY is NULL, GnuTLS could use a static list of known
>>    PKCS#11-providers, or it could read the list from a
>>    /etc/gnutls-pkcs11.conf, ~/.gnutls-pkcs11.conf, GNUTLS_PKCS11
>>    environment variable, or similar.
>>
>> 3) IPC to a gnutls-daemon that is responsible for the PKCS#11 management.
>>
>>    Here there is no linkage to any PKCS#11 plugin at all, which I
>>    consider a major advantage -- I would not want buffer-overflow
>>    attacks in PKCS#11 plugins to cause problems in the GnuTLS library.
>>
>>    The gnutls-daemon is responsible for loading and calling the
>>    PKCS#11 plugins correctly.  The APIs can look the same as previous,
>>    in case the gnutls-daemon can dlopen() libraries.  In other words,
>>    the following:
>>
>>    int gnutls_certificate_set_pkcs11 (gnutls_certificate_credentials_t res,
>>                                       const char *library,
>>                                       const char *key_id);
>>
>>    would indicate that the certificate structure should talk to the
>>    gnutls-daemon, and ask it to search for KEY_ID (if non-null) in
>>    LIBRARY (if given), or just be happy with any private key at all.
>>
>> What do you think?
>>
>> /Simon
>>



From alon.barlev at gmail.com  Sun Apr 22 15:13:42 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sun, 22 Apr 2007 16:13:42 +0300
Subject: [gnutls-dev] RFC: PKCS#11 plans
In-Reply-To: <87d51w4l9x.fsf@mocca.josefsson.org>
References: <87abx061cr.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>
	<87d51w4l9x.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>

On 4/22/07, Simon Josefsson <simon at josefsson.org> wrote:
> > 2. If you wish to use a daemon, the daemon interface can be PKCS#11...
> > so actually this is a separate project... To write a PKCS#11 provider
> > that interacts using sockets with a daemon which loads several
> > providers into its namespace. I have this in my TODO list... It can
> > also provide single sign on for the user.
>
> PKCS#11 isn't a protocol-like API, so we'd have to serialize the
> requests.  But that shouldn't be too difficult.  I'm thinking a
> protocol similar to the GnuPG 2.x daemons, a'la:

GnuPG is bad bad bad bad example.
PKCS#11 is a standard, supporting this will enable you to reduce
development maintenance.
If you support PKCS#11 directly and I develop PKCS#11 provider that
route all requests to a daemon which in turn forward the request to
"real" PKCS#11 module you get the security you like, without adding
daemon component to your development cycle.
If I, as a user, don't wish to use a daemon, I will load the "real"
daemon and not the proxy one.

> to talk with a PKCS11 provider

Well... You have:
http://gnupg-pkcs11.sourceforge.net

Which already is the daemon side... But I hate it! (Although I wrote
it... So I can use my token to S/MIME in KMail).

> GnuTLS's needs are not complex, so the protocol could be simple.  The
> gnutls-daemon would then be responsible for loading the appropriate
> PKCS#11 plugins, or other crypto providers.  All complexity would be
> in gnutls-daemon.

If you wish to do this properly you should consider how application
will use your API....

> > 3. You should handle dynamic events such as token remove, token
> > insert, PIN request.
>
> I don't see what would be gained by having GnuTLS be aware of those
> concepts, so I'd prefer to keep that in the gnutls-daemon, or
> possibly, inside each PKCS#11 provider.

Since the application would like to display a dialog of its own...
Prompt some other information to the user, or just ignore the
prompt...
GnuTLS is a library not an application, you cannot take decisions from
the developer.

> > 4. What happens if signature/decrypt is requested and the token is unavailable?
>
> 1) The TLS handshake fails.
> -or-
> 2) GnuTLS hangs waiting for gnutls-daemon to return, and gnutls-daemon
>    could ask the user to insert its smartcard etc.  The operation can
>    be canceled, and can timeout.

Well... I think the developer should decide, and prompt the user to
insert his token so that the session will not disconnect... But this
should be the application decision.

> I'm looking at it now, although I'm not sure I understand whether or
> how I could use it.  It seems as if applications might use
> pkcs11helper, but it isn't applicable to GnuTLS or gnutls-daemon.

There is a lot of logic to find the right objects, to cache sessions
so user will not be prompt every time for passphrase, track the same
token if it moves from one slot to another, support serialization,
multiple providers at the same times and much more.

> Yes, I also think that would be the Right Solution, although it
> requires slightly more work than supporting PKCS#11 directly.

True... But after you do this, I will be able to provider the provider...

Best Regads,
Alon Bar-Lev.



From alon.barlev at gmail.com  Sun Apr 22 14:40:52 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sun, 22 Apr 2007 15:40:52 +0300
Subject: [gnutls-dev] RFC: PKCS#11 plans
In-Reply-To: <87abx061cr.fsf@mocca.josefsson.org>
References: <87abx061cr.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>

Hello,

I think this is a great idea to finally support PKCS#11!

But:
1. Never link against a specific provider.
2. If you wish to use a daemon, the daemon interface can be PKCS#11...
so actually this is a separate project... To write a PKCS#11 provider
that interacts using sockets with a daemon which loads several
providers into its namespace. I have this in my TODO list... It can
also provide single sign on for the user.
3. You should handle dynamic events such as token remove, token
insert, PIN request.
4. What happens if signature/decrypt is requested and the token is unavailable?
5. What is the meaning of the ID? Where the user may receive it? I
guess I mean you need to support enumeration.

Handling smartcard require significant change in concept... I've
implemented a library that should ease the interaction, and address
the above issues.
http://www.opensc-project.org/pkcs11-helper

I believe that ignoring these will not enable GnuTLS application to
suport hardware based crypto correctly.

To begin with, I think GnuTLS should have generic crypto
engine/provider interface. And using this interface a PKCS#11
engine/provider should be implemented.

Best Regards,
Alon Bar-Lev

On 4/22/07, Simon Josefsson <simon at josefsson.org> wrote:
> Hi!  I've started experimenting with PKCS#11 support in GnuTLS, and it
> seems possible to do it.  This e-mail provides a starting point for
> discussions.  I'm not at all sure how to implement this, so your
> thoughts and ideas are very much appreciated!
>
> I've created a new branch gnutls_1_7_8_with_pkcs11 that will contain
> these experiments.  If they are successful, they will be integrated
> into the 1.7.x branch and become part of the next stable release
> (which I hope to get out before or during the summer).
>
> There are several ways to support PKCS#11 in GnuTLS, I can think of at
> least three:
>
> 1) Build-time linking to a particular PKCS#11 implementation.
>
>    Applications would likely have to call a new API, and my initial
>    guess at what it would look would be:
>
>    int gnutls_certificate_set_pkcs11 (gnutls_certificate_credentials_t res,
>                                       const char *key_id);
>
>    where KEY_ID would be an optional string denoting the Key ID of the
>    key to use as the private key.  If KEY_ID is NULL, it would use any
>    private key it finds.
>
>    This is easy to use and program for, but offers limited
>    flexibility.
>
>    Refinement
>    ----------
>
>    One way to make this more flexible would be to place the API in a
>    special library: libgnutls_pkcs11_foo where foo is the PKCS#11
>    library it uses.  In other words, there could be:
>
>    libgnutls_pkcs11_scute.so     uses the GnuPG 2.x PKCS#11 module
>    libgnutls_pkcs11_seahorse.so  uses the GNOME SeaHorse PKCS#11 plugin
>    libgnutls_pkcs11_nss.so       uses the Mozilla NSS PKCS#11 module
>    ...
>
>    Each of those libraries would be directly linked to the particular
>    PKCS#11 library.  Applications, if they need PKCS#11 functionality,
>    would have to link to one of these libraries.  They are mutually
>    exclusive, so you can't use both seahorse and scute, which is a
>    serious disadvantage.  Still, sometimes it may be sufficient.
>
> 2) Runtime linking to a application-chosen PKCS#11 implementation.
>
>    This would likely use dlopen(), and applications would need to
>    specify the path to the PKCS#11 plugin.  You'll need a new API for
>    this as well, I'm thinking something like this:
>
>    int gnutls_certificate_set_pkcs11 (gnutls_certificate_credentials_t res,
>                                       const char *library,
>                                       const char *key_id);
>
>    This would dlopen() LIBRARY and search for KEY_ID, which may be
>    NULL to indicate that any private key is fine.
>
>    Applications can support more than one PKCS#11 plugin with this
>    approach.  For example, it can do two calls:
>
>      gnutls_certificate_set_pkcs11 (res, "/usr/lib/libscute.so", NULL);
>      gnutls_certificate_set_pkcs11 (res, "/usr/lib/libnss.so", NULL);
>
>    This seems like a nice approach, although it seems sub-optimal that
>    applications have to provide library paths.  Applications shouldn't
>    have to care about such details.
>
>    Refinement
>    ----------
>
>    If LIBRARY is NULL, GnuTLS could use a static list of known
>    PKCS#11-providers, or it could read the list from a
>    /etc/gnutls-pkcs11.conf, ~/.gnutls-pkcs11.conf, GNUTLS_PKCS11
>    environment variable, or similar.
>
> 3) IPC to a gnutls-daemon that is responsible for the PKCS#11 management.
>
>    Here there is no linkage to any PKCS#11 plugin at all, which I
>    consider a major advantage -- I would not want buffer-overflow
>    attacks in PKCS#11 plugins to cause problems in the GnuTLS library.
>
>    The gnutls-daemon is responsible for loading and calling the
>    PKCS#11 plugins correctly.  The APIs can look the same as previous,
>    in case the gnutls-daemon can dlopen() libraries.  In other words,
>    the following:
>
>    int gnutls_certificate_set_pkcs11 (gnutls_certificate_credentials_t res,
>                                       const char *library,
>                                       const char *key_id);
>
>    would indicate that the certificate structure should talk to the
>    gnutls-daemon, and ask it to search for KEY_ID (if non-null) in
>    LIBRARY (if given), or just be happy with any private key at all.
>
> What do you think?
>
> /Simon
>



From simon at josefsson.org  Sun Apr 22 16:11:05 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 22 Apr 2007 16:11:05 +0200
Subject: [gnutls-dev] RFC: PKCS#11 plans
In-Reply-To: <9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>
	(Alon Bar-Lev's message of "Sun\, 22 Apr 2007 16\:13\:42 +0300")
References: <87abx061cr.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>
	<87d51w4l9x.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>
Message-ID: <87odlg33eu.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> On 4/22/07, Simon Josefsson <simon at josefsson.org> wrote:
>> > 2. If you wish to use a daemon, the daemon interface can be PKCS#11...
>> > so actually this is a separate project... To write a PKCS#11 provider
>> > that interacts using sockets with a daemon which loads several
>> > providers into its namespace. I have this in my TODO list... It can
>> > also provide single sign on for the user.
>>
>> PKCS#11 isn't a protocol-like API, so we'd have to serialize the
>> requests.  But that shouldn't be too difficult.  I'm thinking a
>> protocol similar to the GnuPG 2.x daemons, a'la:
>
> GnuPG is bad bad bad bad example.
> PKCS#11 is a standard, supporting this will enable you to reduce
> development maintenance.
> If you support PKCS#11 directly and I develop PKCS#11 provider that
> route all requests to a daemon which in turn forward the request to
> "real" PKCS#11 module you get the security you like, without adding
> daemon component to your development cycle.
> If I, as a user, don't wish to use a daemon, I will load the "real"
> daemon and not the proxy one.

GnuTLS can't talk PKCS#11 to the gnutls-daemon, can it?  I want GnuTLS
and gnutls-daemon to be separate processes.  So GnuTLS will have to
use some protocol to talk with gnutls-daemon, and the protocol could
be something like:

READCERTS
...
READKEYS
...
SIGN

etc.  That is quite similar to the GnuPG 2.x protocols, I was just
using them as an anology for how the protocol would work.

>> to talk with a PKCS11 provider
>
> Well... You have:
> http://gnupg-pkcs11.sourceforge.net

That seem to use the scdaemon protocol, but that protocol isn't
sufficient for what GnuTLS needs -- for example, I can't read
certificates from the smartcard via that protocol for OpenPGP cards.
GnuTLS needs the certificates.

>> GnuTLS's needs are not complex, so the protocol could be simple.  The
>> gnutls-daemon would then be responsible for loading the appropriate
>> PKCS#11 plugins, or other crypto providers.  All complexity would be
>> in gnutls-daemon.
>
> If you wish to do this properly you should consider how application
> will use your API....

I proposed APIs that the GnuTLS application would use in my initial
post.  Do you think the APIs need to be more advanced?  What more is
needed?

>> > 3. You should handle dynamic events such as token remove, token
>> > insert, PIN request.
>>
>> I don't see what would be gained by having GnuTLS be aware of those
>> concepts, so I'd prefer to keep that in the gnutls-daemon, or
>> possibly, inside each PKCS#11 provider.
>
> Since the application would like to display a dialog of its own...
> Prompt some other information to the user, or just ignore the
> prompt...
> GnuTLS is a library not an application, you cannot take decisions from
> the developer.

One of my ideas is that all such interaction happens in gnutls-daemon.
GnuTLS shouldn't know private keys, PINs etc.

>> > 4. What happens if signature/decrypt is requested and the token is unavailable?
>>
>> 1) The TLS handshake fails.
>> -or-
>> 2) GnuTLS hangs waiting for gnutls-daemon to return, and gnutls-daemon
>>    could ask the user to insert its smartcard etc.  The operation can
>>    be canceled, and can timeout.
>
> Well... I think the developer should decide, and prompt the user to
> insert his token so that the session will not disconnect... But this
> should be the application decision.

The problem is that it's not very generic... The PKCS#11 plugin that
gnutls-daemon loads can also ask the user to insert the token etc.
That seem to be a better design to me, but I may be missing something.

>> I'm looking at it now, although I'm not sure I understand whether or
>> how I could use it.  It seems as if applications might use
>> pkcs11helper, but it isn't applicable to GnuTLS or gnutls-daemon.
>
> There is a lot of logic to find the right objects, to cache sessions
> so user will not be prompt every time for passphrase, track the same
> token if it moves from one slot to another, support serialization,
> multiple providers at the same times and much more.

Ok.  gnutls-daemon could then support, say:

* Any PKCS#11 token via libp11

* Simple PKCS#11 tokens directly (it takes < 50 lines of code to sign
  something with scute, and I have this code working now).

* GNOME Seahorse crypto provider (although possibly this will happen
  via PKCS#11).

* gpg-agent for OpenPGP keys + OpenPGP signing.

* Microsoft CAPI

* Other crypto providers...

If the protocol to gnutls-daemon is well-specified, anyone can write a
replacement for their own neat stuff, although I hope that the
'default' gnutls-daemon will be sufficient for most users.

/Simon



From twoaday at gmx.net  Sun Apr 22 16:31:04 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 22 Apr 2007 16:31:04 +0200
Subject: [gnutls-dev] build-in opencdk version
In-Reply-To: <87647o619c.fsf@mocca.josefsson.org>
References: <462B4D25.60707@gmx.net> <87647o619c.fsf@mocca.josefsson.org>
Message-ID: <462B71A8.3090502@gmx.net>

Simon Josefsson wrote:

>> a file, dummy.c, which includes all the prototypes
>> needed to build the lib successfully.
> 
> I can't seem to find dummy.c...

Sorry, I added it to the Makefile.am but I did not
add it to the CVS. It should be there now.


	Timo




From twoaday at gmx.net  Sun Apr 22 16:34:50 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 22 Apr 2007 16:34:50 +0200
Subject: [gnutls-dev] autoconf version handling
In-Reply-To: <871wic60zh.fsf@mocca.josefsson.org>
References: <4628A7A4.8090104@gmx.net>
	<878xcn9qzp.fsf@mocca.josefsson.org>	<4628B3DF.4000404@gmx.net>
	<87647o98bv.fsf@mocca.josefsson.org>	<462B3B06.4060709@gmx.net>
	<871wic60zh.fsf@mocca.josefsson.org>
Message-ID: <462B728A.3010303@gmx.net>

Simon Josefsson wrote:

> Right.  However, the problem is the opencdk.h header file.
> Distributors can't ship /usr/include/opencdk.h from both 0.5.x and
> 0.6.x at the same time.

True, I did not think of this issue.


> Is there no possibility to rename the APIs that changed in 0.6 and
> provide a backwards compatibility glue under the old function name?

This is not a trivial task and I don't think it can be done easily.
And I'm not sure if there is a clean way to provide 100% backward
compatibility.


> This isn't a critical problem, but it is always nicer if newer
> versions retains source-code backwards compatibility (i.e., 0.6
> opencdk.h + 0.6 libopencdk.so against 0.5 application) even when the

I agree on that. But the opencdk API needed urgently a cleanup and I
thought the sooner the better so applications, especially GnuTLS, can
be migrated as soon as possible.


	Timo




From alon.barlev at gmail.com  Sun Apr 22 16:44:51 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sun, 22 Apr 2007 17:44:51 +0300
Subject: [gnutls-dev] RFC: PKCS#11 plans
In-Reply-To: <87odlg33eu.fsf@mocca.josefsson.org>
References: <87abx061cr.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>
	<87d51w4l9x.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>
	<87odlg33eu.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0704220744w12ebe5ebi47bec49bea444f98@mail.gmail.com>

On 4/22/07, Simon Josefsson <simon at josefsson.org> wrote:
> GnuTLS can't talk PKCS#11 to the gnutls-daemon, can it?  I want GnuTLS
> and gnutls-daemon to be separate processes.  So GnuTLS will have to
> use some protocol to talk with gnutls-daemon, and the protocol could
> be something like:

Why reinvent the wheel?
PKCS#11 is an API... A generic interface to access crypto devices.
Your daemon can expose such an interface, and route all PKCS#11
commands into providers loaded.

If you implement:

Application -[API]-> GnuTLS -[PKCS#11]-> Provider

Then you will be able to use a proxy provider without extra development.

Application -[API]-> GnuTLS -[PKCS#11]-> Proxy Provider -[Socket]->
Daemon -[PKCS#11]-> Provider

The proxy provider will be a different project and will provide the
same level of security you are interested in to any PKCS#11 enabled
applications.
While GnuTLS keep standard interface.

> etc.  That is quite similar to the GnuPG 2.x protocols, I was just
> using them as an anology for how the protocol would work.

Why not serialize PKCS#11 request and simply forward them to the daemon?
Why reinvent the wheel and have a different spec?

> >> to talk with a PKCS11 provider
> >
> > Well... You have:
> > http://gnupg-pkcs11.sourceforge.net
>
> That seem to use the scdaemon protocol, but that protocol isn't
> sufficient for what GnuTLS needs -- for example, I can't read
> certificates from the smartcard via that protocol for OpenPGP cards.
> GnuTLS needs the certificates.

Yes it does... Your example of OpenPGP cards is incorrect.
This implementation work with gpgsm, loading certificate objects too.

> > If you wish to do this properly you should consider how application
> > will use your API....
>
> I proposed APIs that the GnuTLS application would use in my initial
> post.  Do you think the APIs need to be more advanced?  What more is
> needed?

Yes... A library API should be generic...

Have a look at my high-level certificate API:
http://www.opensc-project.org/files/pkcs11-helper/doc/api/group__pkcs11h__certificate.html

These are the atoms required for certificate management.

Also please have a look at the core API:
http://www.opensc-project.org/files/pkcs11-helper/doc/api/group__pkcs11h__core.html

Required to manage the providers.

I don't think GnuTLS can provide good service with much simpler API.

> > There is a lot of logic to find the right objects, to cache sessions
> > so user will not be prompt every time for passphrase, track the same
> > token if it moves from one slot to another, support serialization,
> > multiple providers at the same times and much more.
>
> Ok.  gnutls-daemon could then support, say:
>
> * Any PKCS#11 token via libp11
>
> * Simple PKCS#11 tokens directly (it takes < 50 lines of code to sign
>   something with scute, and I have this code working now).
>
> * GNOME Seahorse crypto provider (although possibly this will happen
>   via PKCS#11).
>
> * gpg-agent for OpenPGP keys + OpenPGP signing.
>
> * Microsoft CAPI
>
> * Other crypto providers...
>
> If the protocol to gnutls-daemon is well-specified, anyone can write a
> replacement for their own neat stuff, although I hope that the
> 'default' gnutls-daemon will be sufficient for most users.

OK... I got your view.

I understand we going to loose another open source project accessing
smartcards correctly.

In the end we will have a different daemon for each open source project...

We have one for OpenSSH, a differnet one for GnuPG, for Gnome... Now
we have something new! We have a daemon for an API.... A daemon for
GnuTLS...
The poor user will have to run about 20 daemons for interactive
system, all loading the same PKCS#11 provider which could have been
directly used by applications.

My "mission" is to help open source projects to realize that the above
scenario is invalid, so they must focus on standardization. PKCS#11 is
the only independent standard available to access cryptographic
devices. Even if the standard seems a little complicated it is of our
users based interest to support it.

It is true that loading a library into your process is dangerous, but
it can be solved using a proxy PKCS#11 provider that will enable
safe-guarding all PKCS#11 enabled applications, while being
transparent.

It is true that without a daemon, multiple instances or applications
cannot share the same authenticated sessions, but the same PKCS#11
proxy will be able to provide a solution for this issue as well, while
being transparent.

So you have a simple option to use libassuan and work with gpg-agent
not developing any PKCS#11 code, while users may use my
gnupg-pkcs11-scd implementation to access PKCS#11 tokens (But I think
many users will tell you that the application->gpg-agent->scdaemon
implementation is much too complex for them to use).

You have an option to reinvent the whole wheel... Writing your own daemon.

Or you can design an in-process interface and allow to separate GnuTLS
from the decision of where and how crypto is implemented. Keeping
GnuTLS at the API domain.

Best Regards,
Alon Bar-Lev.



From simon at josefsson.org  Sun Apr 22 16:41:50 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 22 Apr 2007 16:41:50 +0200
Subject: [gnutls-dev] autoconf version handling
In-Reply-To: <462B728A.3010303@gmx.net> (Timo Schulz's message of "Sun\, 22 Apr
	2007 16\:34\:50 +0200")
References: <4628A7A4.8090104@gmx.net> <878xcn9qzp.fsf@mocca.josefsson.org>
	<4628B3DF.4000404@gmx.net> <87647o98bv.fsf@mocca.josefsson.org>
	<462B3B06.4060709@gmx.net> <871wic60zh.fsf@mocca.josefsson.org>
	<462B728A.3010303@gmx.net>
Message-ID: <87fy6s31zl.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

>> Is there no possibility to rename the APIs that changed in 0.6 and
>> provide a backwards compatibility glue under the old function name?
>
> This is not a trivial task and I don't think it can be done easily.
> And I'm not sure if there is a clean way to provide 100% backward
> compatibility.
>
>
>> This isn't a critical problem, but it is always nicer if newer
>> versions retains source-code backwards compatibility (i.e., 0.6
>> opencdk.h + 0.6 libopencdk.so against 0.5 application) even when the
>
> I agree on that. But the opencdk API needed urgently a cleanup and I
> thought the sooner the better so applications, especially GnuTLS, can
> be migrated as soon as possible.

Sure.  I just wanted to confirm that you/we have thought about this
problem.

I think the conclusion is that opencdk 0.6 will have to conflict
(using distro package speak) with the opencdk 0.5 package.

/Simon



From twoaday at gmx.net  Sun Apr 22 17:11:28 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Sun, 22 Apr 2007 17:11:28 +0200
Subject: [gnutls-dev] autoconf version handling
In-Reply-To: <87fy6s31zl.fsf@mocca.josefsson.org>
References: <4628A7A4.8090104@gmx.net>
	<878xcn9qzp.fsf@mocca.josefsson.org>	<4628B3DF.4000404@gmx.net>
	<87647o98bv.fsf@mocca.josefsson.org>	<462B3B06.4060709@gmx.net>
	<871wic60zh.fsf@mocca.josefsson.org>	<462B728A.3010303@gmx.net>
	<87fy6s31zl.fsf@mocca.josefsson.org>
Message-ID: <462B7B20.6030604@gmx.net>

Simon Josefsson wrote:

> Sure.  I just wanted to confirm that you/we have thought about this
> problem.

And I'm glad you reminded me of this issue!


> I think the conclusion is that opencdk 0.6 will have to conflict
> (using distro package speak) with the opencdk 0.5 package.

Yes, I thought about this myself. But as I said, I thought it would
be better to do it now.


	Timo



From simon at josefsson.org  Mon Apr 23 11:13:35 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 23 Apr 2007 11:13:35 +0200
Subject: [gnutls-dev] RFC: PKCS#11 plans
In-Reply-To: <9e0cf0bf0704220744w12ebe5ebi47bec49bea444f98@mail.gmail.com>
	(Alon Bar-Lev's message of "Sun\, 22 Apr 2007 17\:44\:51 +0300")
References: <87abx061cr.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>
	<87d51w4l9x.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>
	<87odlg33eu.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220744w12ebe5ebi47bec49bea444f98@mail.gmail.com>
Message-ID: <87y7kj1mio.fsf@mocca.josefsson.org>

"Alon Bar-Lev" <alon.barlev at gmail.com> writes:

> On 4/22/07, Simon Josefsson <simon at josefsson.org> wrote:
>> GnuTLS can't talk PKCS#11 to the gnutls-daemon, can it?  I want GnuTLS
>> and gnutls-daemon to be separate processes.  So GnuTLS will have to
>> use some protocol to talk with gnutls-daemon, and the protocol could
>> be something like:
>
> Why reinvent the wheel?
> PKCS#11 is an API... A generic interface to access crypto devices.
> Your daemon can expose such an interface, and route all PKCS#11
> commands into providers loaded.
>
> If you implement:
>
> Application -[API]-> GnuTLS -[PKCS#11]-> Provider
>
> Then you will be able to use a proxy provider without extra development.
>
> Application -[API]-> GnuTLS -[PKCS#11]-> Proxy Provider -[Socket]->
> Daemon -[PKCS#11]-> Provider
>
> The proxy provider will be a different project and will provide the
> same level of security you are interested in to any PKCS#11 enabled
> applications.
> While GnuTLS keep standard interface.

Ah, I now understand what you mean.  And yes, the
gnutls_1_7_8_with_pkcs11 branch will support PKCS#11 directly, thus
allowing for the approach you refer to here.

However, does any proxy providers exist?  If not, then GnuTLS will
link directly to the PKCS#11 providers, either directly or through
dlopen(), which is something that I'd really want to avoid.  (The code
on the branch do that, just as a proof-of-concept.)

>> etc.  That is quite similar to the GnuPG 2.x protocols, I was just
>> using them as an anology for how the protocol would work.
>
> Why not serialize PKCS#11 request and simply forward them to the daemon?
> Why reinvent the wheel and have a different spec?

Serializing PKCS#11 is not simple, and I don't know if anyone has done
this before.  Further, the serialization of PKCS#11 doesn't have to be
exactly mapped to the PKCS#11 API, it only have to support the same
things that PKCS#11 support.

>> >> to talk with a PKCS11 provider
>> >
>> > Well... You have:
>> > http://gnupg-pkcs11.sourceforge.net
>>
>> That seem to use the scdaemon protocol, but that protocol isn't
>> sufficient for what GnuTLS needs -- for example, I can't read
>> certificates from the smartcard via that protocol for OpenPGP cards.
>> GnuTLS needs the certificates.
>
> Yes it does... Your example of OpenPGP cards is incorrect.
> This implementation work with gpgsm, loading certificate objects too.

But not with OpenPGP cards:

http://lists.gnupg.org/pipermail/gnupg-users/2007-April/030898.html

Since I don't have anything other than OpenPGP cards available, that's
what is the main priority for me right now.  I don't even know
how/where to purchase one X.509 smart card for a reasonable price with
sufficient documentation for me to be able to use it.

>> > If you wish to do this properly you should consider how application
>> > will use your API....
>>
>> I proposed APIs that the GnuTLS application would use in my initial
>> post.  Do you think the APIs need to be more advanced?  What more is
>> needed?
>
> Yes... A library API should be generic...
>
> Have a look at my high-level certificate API:
> http://www.opensc-project.org/files/pkcs11-helper/doc/api/group__pkcs11h__certificate.html
>
> These are the atoms required for certificate management.
>
> Also please have a look at the core API:
> http://www.opensc-project.org/files/pkcs11-helper/doc/api/group__pkcs11h__core.html
>
> Required to manage the providers.
>
> I don't think GnuTLS can provide good service with much simpler API.

Well, let's see, I'm close to having PKCS#11 via Scute work in GnuTLS
with just one API.

>> > There is a lot of logic to find the right objects, to cache sessions
>> > so user will not be prompt every time for passphrase, track the same
>> > token if it moves from one slot to another, support serialization,
>> > multiple providers at the same times and much more.
>>
>> Ok.  gnutls-daemon could then support, say:
>>
>> * Any PKCS#11 token via libp11
>>
>> * Simple PKCS#11 tokens directly (it takes < 50 lines of code to sign
>>   something with scute, and I have this code working now).
>>
>> * GNOME Seahorse crypto provider (although possibly this will happen
>>   via PKCS#11).
>>
>> * gpg-agent for OpenPGP keys + OpenPGP signing.
>>
>> * Microsoft CAPI
>>
>> * Other crypto providers...
>>
>> If the protocol to gnutls-daemon is well-specified, anyone can write a
>> replacement for their own neat stuff, although I hope that the
>> 'default' gnutls-daemon will be sufficient for most users.
>
> OK... I got your view.

I have not yet decided though, this discussion is input to that
decision.  And anything that is decided now can be revised after
review.  And if you don't like the decisions, you can always fork or
send patches.. ;-)

Right now, what I'm actually implementing (direct PKCS#11 access in
GnuTLS) is not the same thing as I'm describing.  I have not started
working on a gnutls-daemon approach, since I'm not yet sure if that is
required to solve all problems.  Since it is more work, I'd like to
defer it if possible.

> I understand we going to loose another open source project accessing
> smartcards correctly.
>
> In the end we will have a different daemon for each open source project...

Until someone develops an inter-application protocol that all these
projects can use, yes likely.  PKCS#11 isn't a wire protocol, so that
isn't the answer.

> We have one for OpenSSH, a differnet one for GnuPG, for Gnome... Now
> we have something new! We have a daemon for an API.... A daemon for
> GnuTLS...
> The poor user will have to run about 20 daemons for interactive
> system, all loading the same PKCS#11 provider which could have been
> directly used by applications.

Applications don't want to load PKCS#11 providers.  They don't want to
know what a PKCS#11 provider is.  Thus, GnuTLS should offer to hide
this stuff from applications.  Some applications may want to know the
details, but then they can use other APIs to solve what they want.

> My "mission" is to help open source projects to realize that the above
> scenario is invalid, so they must focus on standardization. PKCS#11 is
> the only independent standard available to access cryptographic
> devices. Even if the standard seems a little complicated it is of our
> users based interest to support it.

But PKCS#11 is not a protocol...

> It is true that loading a library into your process is dangerous, but
> it can be solved using a proxy PKCS#11 provider that will enable
> safe-guarding all PKCS#11 enabled applications, while being
> transparent.

Do such a PKCS#11 proxy exists?

> It is true that without a daemon, multiple instances or applications
> cannot share the same authenticated sessions, but the same PKCS#11
> proxy will be able to provide a solution for this issue as well, while
> being transparent.

Yes, a proxy of some kind is probably needed to solve the sharing
issue.

> So you have a simple option to use libassuan and work with gpg-agent
> not developing any PKCS#11 code, while users may use my
> gnupg-pkcs11-scd implementation to access PKCS#11 tokens (But I think
> many users will tell you that the application->gpg-agent->scdaemon
> implementation is much too complex for them to use).

I think an assumption here has been that GnuTLS should support
PKCS#11, and since gpg-agent cannot solve one problem (I can't read
certificates via it) we have to consider options.

> You have an option to reinvent the whole wheel... Writing your own daemon.

That may be the most flexible and simplest solution.  It is not
completely reinventing the wheel, since I do not know about any other
solution that provides the same features.

> Or you can design an in-process interface and allow to separate GnuTLS
> from the decision of where and how crypto is implemented. Keeping
> GnuTLS at the API domain.

This is what I'm doing now on the gnutls_1_7_8_with_pkcs11 branch.
However, if there are no PKCS#11 proxy providers, I don't think this
will be the ultimate solution.  Then we need to come up with something
to proxy the signing requests.  In that case, using PCKS#11 is no
longer a generic good idea.  It isn't compatible with Microsoft CAPI,
for instance, something I'd want to support in the long run.

/Simon



From ludovic.courtes at laas.fr  Mon Apr 23 15:18:07 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 23 Apr 2007 15:18:07 +0200
Subject: [gnutls-dev] new openpgp code available
References: <4628B6A0.4060303@gmx.net> <871wic98a5.fsf@mocca.josefsson.org>
	<462B3B4E.3010703@gmx.net>
Message-ID: <87abwz1b74.fsf@laas.fr>

Hi,

Timo Schulz <twoaday at gmx.net> writes:

> Simon Josefsson wrote:
>
>>> Is there a bug tracker or bug list so I can check that
>>> all resolved bugs are not re-introduced again?
>> 
>> There is the mailing list archives...
>
> OK. IMHO the archive is not searchable, so maybe
> somebody has a hint (year, month)?

In case that helps, you can also access it via Gmane (see
http://gmane.org/), and you can even access it in NNTP using your
favorite news client (the newsgroup name are
`gmane.comp.encryption.gpg.gnutls.devel' and
`gmane.network.gnutls.general').

Thanks,
Ludovic.




From alon.barlev at gmail.com  Mon Apr 23 15:39:49 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Mon, 23 Apr 2007 16:39:49 +0300
Subject: [gnutls-dev] RFC: PKCS#11 plans
In-Reply-To: <87y7kj1mio.fsf@mocca.josefsson.org>
References: <87abx061cr.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>
	<87d51w4l9x.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>
	<87odlg33eu.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220744w12ebe5ebi47bec49bea444f98@mail.gmail.com>
	<87y7kj1mio.fsf@mocca.josefsson.org>
Message-ID: <9e0cf0bf0704230639m6ba895f7y77fbefa1c9f1df90@mail.gmail.com>

On 4/23/07, Simon Josefsson <simon at josefsson.org> wrote:
> > The proxy provider will be a different project and will provide the
> > same level of security you are interested in to any PKCS#11 enabled
> > applications.
> > While GnuTLS keep standard interface.
>
> Ah, I now understand what you mean.  And yes, the
> gnutls_1_7_8_with_pkcs11 branch will support PKCS#11 directly, thus
> allowing for the approach you refer to here.

I tought that by now we can get to a conclusion that the branch should
provide a generic crypto interface... :)

> However, does any proxy providers exist?  If not, then GnuTLS will
> link directly to the PKCS#11 providers, either directly or through
> dlopen(), which is something that I'd really want to avoid.  (The code
> on the branch do that, just as a proof-of-concept.)

As I said I have this in my todo list... Once I will see enough open
source use PKCS#11 correctly. The problem is that people use PKCS#11
as they handled files so far...

> Serializing PKCS#11 is not simple, and I don't know if anyone has done
> this before.  Further, the serialization of PKCS#11 doesn't have to be
> exactly mapped to the PKCS#11 API, it only have to support the same
> things that PKCS#11 support.

The important feature would be to expose PKCS#11 interface to the
application. The serialization protocol is irrelevant.

> > Yes it does... Your example of OpenPGP cards is incorrect.
> > This implementation work with gpgsm, loading certificate objects too.
>
> But not with OpenPGP cards:
>
> http://lists.gnupg.org/pipermail/gnupg-users/2007-April/030898.html

I told you not to use this hacky environment...

> Since I don't have anything other than OpenPGP cards available, that's
> what is the main priority for me right now.  I don't even know
> how/where to purchase one X.509 smart card for a reasonable price with
> sufficient documentation for me to be able to use it.

OK... As you wish... You will solve problems that not actually exist.

> Well, let's see, I'm close to having PKCS#11 via Scute work in GnuTLS
> with just one API.

Well... I really don't understand... I offer my experience and help...
Smartcards are not just a neat API.... All I ask is for you to provide
a generic API for crypto modules, and I will implement this engine...
This engine will use all knowedge gathered for years and will work
with many providers.
You dismiss this and go and implement a partial solution...
I really don't undestand...

> I have not yet decided though, this discussion is input to that
> decision.  And anything that is decided now can be revised after
> review.  And if you don't like the decisions, you can always fork or
> send patches.. ;-)

As I said, I am willing to WRITE the engine, one you define a generic interface.
I won't send specific patches or branch GnuTLS... I just offer my help
and experience, it is clear that you make your first steps in this
world...

> Applications don't want to load PKCS#11 providers.  They don't want to
> know what a PKCS#11 provider is.  Thus, GnuTLS should offer to hide
> this stuff from applications.  Some applications may want to know the
> details, but then they can use other APIs to solve what they want.

Here I also disagree... The application should use several APIs in
order to control its resources? So why don't you follow OpenSSL
foot-steps and provide RSA object which has several callbacks, the
application register this object within GnuTLS, so that GnuTLS is not
aware how the signature/decryption are performed?

>
> > My "mission" is to help open source projects to realize that the above
> > scenario is invalid, so they must focus on standardization. PKCS#11 is
> > the only independent standard available to access cryptographic
> > devices. Even if the standard seems a little complicated it is of our
> > users based interest to support it.
>
> But PKCS#11 is not a protocol...

Wrong again!
But nevermind....

> > It is true that loading a library into your process is dangerous, but
> > it can be solved using a proxy PKCS#11 provider that will enable
> > safe-guarding all PKCS#11 enabled applications, while being
> > transparent.
>
> Do such a PKCS#11 proxy exists?

As I said I will implement one, once I get people to understand
something about smartcards.

> I think an assumption here has been that GnuTLS should support
> PKCS#11, and since gpg-agent cannot solve one problem (I can't read
> certificates via it) we have to consider options.

For OpenPGP only.
Most users DO NOT use this card.
But I agree pgp-agent is bad bad bad approach.

> > You have an option to reinvent the whole wheel... Writing your own daemon.
>
> That may be the most flexible and simplest solution.  It is not
> completely reinventing the wheel, since I do not know about any other
> solution that provides the same features.

You are going to write native PKCS#11 code, while I already
implemented, tested, integrated and maintain...
If this not reinvent the wheel, I don't know what is to reinvent the wheel.

> This is what I'm doing now on the gnutls_1_7_8_with_pkcs11 branch.
> However, if there are no PKCS#11 proxy providers, I don't think this
> will be the ultimate solution.  Then we need to come up with something
> to proxy the signing requests.  In that case, using PCKS#11 is no
> longer a generic good idea.  It isn't compatible with Microsoft CAPI,
> for instance, something I'd want to support in the long run.

Implement generic interface and people may use it to access CAPI as well.

Best Regards,
Alon Bar-Lev.



From twoaday at gmx.net  Mon Apr 23 15:44:06 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Mon, 23 Apr 2007 15:44:06 +0200
Subject: [gnutls-dev] new openpgp code available
In-Reply-To: <87abwz1b74.fsf@laas.fr>
References: <4628B6A0.4060303@gmx.net>
	<871wic98a5.fsf@mocca.josefsson.org>	<462B3B4E.3010703@gmx.net>
	<87abwz1b74.fsf@laas.fr>
Message-ID: <462CB826.8020102@gmx.net>

Ludovic Court?s wrote:

> In case that helps, you can also access it via Gmane (see
> http://gmane.org/), and you can even access it in NNTP using your
> favorite news client (the newsgroup name are

Hmm, this does not seem to work very well. I found a site
which provides an searchable index for this mailing list
but even with such a feature, it's hard to gather all
related mails without reading most of them or all.

IMHO it's the best idea to write some tests to find
possible problems in the current code. I will try to
write at least basic tests which can be extended later.


	Timo



From ludovic.courtes at laas.fr  Mon Apr 23 15:50:22 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 23 Apr 2007 15:50:22 +0200
Subject: [gnutls-dev] RFC: PKCS#11 plans
References: <87abx061cr.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>
	<87d51w4l9x.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>
	<87odlg33eu.fsf@mocca.josefsson.org>
Message-ID: <874pn7yzc1.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> That seem to use the scdaemon protocol, but that protocol isn't
> sufficient for what GnuTLS needs -- for example, I can't read
> certificates from the smartcard via that protocol for OpenPGP cards.
> GnuTLS needs the certificates.

In this context, shouldn't we question the assumption that GnuTLS
absolutely needs access to private keys?  It seems that many smartcards
don't offer this option for security reasons: instead they only allow,
for instance, encryption/decryption of arbitrary data, as well as
extraction of the public key (certificate).

See the thread at:

  http://article.gmane.org/gmane.comp.gnu.gnupg.users/10411
  http://article.gmane.org/gmane.comp.gnu.gnupg.users/10429

(In addition, the opinion of Werner Koch in the second message is that
GnuTLS could directly talk to `gnupg-agent' instead of having its own
infrastructure.  Wouldn't that make sense?)

Thanks,
Ludovic.




From ludovic.courtes at laas.fr  Mon Apr 23 15:53:17 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 23 Apr 2007 15:53:17 +0200
Subject: [gnutls-dev] new openpgp code available
References: <4628B6A0.4060303@gmx.net> <871wic98a5.fsf@mocca.josefsson.org>
	<462B3B4E.3010703@gmx.net> <87abwz1b74.fsf@laas.fr>
	<462CB826.8020102@gmx.net>
Message-ID: <87r6qbxkmq.fsf@laas.fr>

Hi,

Timo Schulz <twoaday at gmx.net> writes:

> IMHO it's the best idea to write some tests to find
> possible problems in the current code. I will try to
> write at least basic tests which can be extended later.

Yes, a few unit tests (at least in GnuTLS) that simply do
`gnutls_openpgp_{private_,}key_import ()' would be nice.  Especially
since the distribution already contains OpenPGP public/private key files
for test purposes.  ;-)

Thanks,
Ludovic.




From simon at josefsson.org  Mon Apr 23 18:39:23 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 23 Apr 2007 18:39:23 +0200
Subject: [gnutls-dev] OpenCDK comments
In-Reply-To: <462B41A9.5050806@gmx.net> (Timo Schulz's message of "Sun\, 22 Apr
	2007 13\:06\:17 +0200")
References: <87zm538bea.fsf@mocca.josefsson.org> <4628B975.8040103@gmx.net>
	<87wt047tdc.fsf@mocca.josefsson.org> <462B41A9.5050806@gmx.net>
Message-ID: <87r6qbxcxw.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Simon Josefsson wrote:
>
>> No, it shouldn't be.  Perhaps the copy of OpenCDK inside GnuTLS can be
>> made smaller, without e.g. the keyserver files, because those have
>> caused compilation problems in the past.  I'll look into that.
>
> I forgot to mention that right now there is a callback which uses
> the keyserver code. Probably it would be the best idea to remove
> them first. I'm not sure if 'auto' key retrieval is a general feature in
> GnuTLS so the code must be probably changed at a higher level.

Having the GnuTLS library itself block and retrieve keys from a
keyserver seems to be a non-starter for me.  GnuTLS might want to
provide an API to ask the application to "search" for keys, but I
don't see any point in including this functionality.

OTOH, possibly gnutls-cli or gnutls-serv could be enhanced to support
keyserver retrieval of PGP keys?  That could use the OpenCDK keyserver
support.  OTTH, I'd rather support the GnuPG key server infrastructure
instead since it is more complete and tested (it supports DNS-based
OpenPGP retrieval for example.. :)).

/Simon



From simon at josefsson.org  Mon Apr 23 18:46:17 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 23 Apr 2007 18:46:17 +0200
Subject: [gnutls-dev] RFC: PKCS#11 plans
In-Reply-To: <874pn7yzc1.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Mon\, 23
	Apr 2007 15\:50\:22 +0200")
References: <87abx061cr.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>
	<87d51w4l9x.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>
	<87odlg33eu.fsf@mocca.josefsson.org> <874pn7yzc1.fsf@laas.fr>
Message-ID: <87mz0zxcme.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> That seem to use the scdaemon protocol, but that protocol isn't
>> sufficient for what GnuTLS needs -- for example, I can't read
>> certificates from the smartcard via that protocol for OpenPGP cards.
>> GnuTLS needs the certificates.
>
> In this context, shouldn't we question the assumption that GnuTLS
> absolutely needs access to private keys?  It seems that many smartcards
> don't offer this option for security reasons: instead they only allow,
> for instance, encryption/decryption of arbitrary data, as well as
> extraction of the public key (certificate).

Yes!  There are plans for GNOME Seahorse to provide a PKCS#11
interface for the private keys/certificates stored in the gnome
keyring.  This was what prompted my work on PKCS#11 support in GnuTLS.

One could also write a really simple PKCS#11 plugin that uses on-disk
private key/certificates.  This could be written using the GnuTLS
X.509 APIs.

In any case, the primary goal of my PKCS#11 work is to avoid the need
for GnuTLS to have access to private keys.  It just needs to read
certificates from somewhere, and have an interface to signing
operations.  Whether that is PKCS#11 or some IPC protocol to some
external gnutls-daemon-like process is an open question.

> See the thread at:
>
>   http://article.gmane.org/gmane.comp.gnu.gnupg.users/10411
>   http://article.gmane.org/gmane.comp.gnu.gnupg.users/10429
>
> (In addition, the opinion of Werner Koch in the second message is that
> GnuTLS could directly talk to `gnupg-agent' instead of having its own
> infrastructure.  Wouldn't that make sense?)

Yeah, but it turned out that gpg-agent cannot support this, since it
is not possible to get user certificates from it.  GnuTLS would have
to talk to 'gpgsm --server' as well.  I don't think the GnuTLS library
should fork+exec external programs so this approach doesn't work.
Thus, implementing PKCS#11 and using the Scute PKCS#11 provider (which
do talk to gpg-agent, scdaemon, and gpgsm) seems simpler, and even
more flexible.

/Simon



From twoaday at gmx.net  Mon Apr 23 19:13:54 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Mon, 23 Apr 2007 19:13:54 +0200
Subject: [gnutls-dev] OpenCDK comments
In-Reply-To: <87r6qbxcxw.fsf@mocca.josefsson.org>
References: <87zm538bea.fsf@mocca.josefsson.org>
	<4628B975.8040103@gmx.net>	<87wt047tdc.fsf@mocca.josefsson.org>
	<462B41A9.5050806@gmx.net> <87r6qbxcxw.fsf@mocca.josefsson.org>
Message-ID: <462CE952.2020904@gmx.net>

Simon Josefsson wrote:

> Having the GnuTLS library itself block and retrieve keys from a
> keyserver seems to be a non-starter for me.  GnuTLS might want to

Yes, I can see what you mean. I was not involved in build or
designing this API. Nikos just asked if I can provide a function
in opencdk to retrieve a key via HKP and I implemented it.


> provide an API to ask the application to "search" for keys, but I
> don't see any point in including this functionality.

Right now I don't know the internals of the GnuTLS code to say
anything about it. Maybe we can remove the callbacks without
breaking the code?


> keyserver retrieval of PGP keys?  That could use the OpenCDK keyserver
> support.

As you said, the opencdk keyserver support is very simple. I intended
it for a quick key retrieval and it will do the job.


> OTTH, I'd rather support the GnuPG key server infrastructure
> instead since it is more complete and tested (it supports DNS-based
> OpenPGP retrieval for example.. :)).

Yes, I agree with you. The GPG program has a lot of keyserver clients
(finger, hkp, http, dns, ldap) and the code is available for years and
extensively tested.


	Timo





From simon at josefsson.org  Mon Apr 23 19:57:07 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 23 Apr 2007 19:57:07 +0200
Subject: [gnutls-dev] OpenCDK comments
In-Reply-To: <462CE952.2020904@gmx.net> (Timo Schulz's message of "Mon\, 23 Apr
	2007 19\:13\:54 +0200")
References: <87zm538bea.fsf@mocca.josefsson.org> <4628B975.8040103@gmx.net>
	<87wt047tdc.fsf@mocca.josefsson.org> <462B41A9.5050806@gmx.net>
	<87r6qbxcxw.fsf@mocca.josefsson.org> <462CE952.2020904@gmx.net>
Message-ID: <87irbnvurw.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Simon Josefsson wrote:
>
>> Having the GnuTLS library itself block and retrieve keys from a
>> keyserver seems to be a non-starter for me.  GnuTLS might want to
>
> Yes, I can see what you mean. I was not involved in build or
> designing this API. Nikos just asked if I can provide a function
> in opencdk to retrieve a key via HKP and I implemented it.
>
>
>> provide an API to ask the application to "search" for keys, but I
>> don't see any point in including this functionality.
>
> Right now I don't know the internals of the GnuTLS code to say
> anything about it. Maybe we can remove the callbacks without
> breaking the code?

Hm.  Do GnuTLS currently use the keyserver stuff?!  I wonder how it
handles the blocking problem.

>> keyserver retrieval of PGP keys?  That could use the OpenCDK keyserver
>> support.
>
> As you said, the opencdk keyserver support is very simple. I intended
> it for a quick key retrieval and it will do the job.

Yup.

>> OTTH, I'd rather support the GnuPG key server infrastructure
>> instead since it is more complete and tested (it supports DNS-based
>> OpenPGP retrieval for example.. :)).
>
> Yes, I agree with you. The GPG program has a lot of keyserver clients
> (finger, hkp, http, dns, ldap) and the code is available for years and
> extensively tested.

Perhaps OpenCDK could use that infrastructure directly instead?
However, I think there are more important things to fix related to
OpenPGP than this.  I don't know if downloading keys from a keyserver
is something that typical OpenPGP clients or servers would actually be
doing.

/Simon



From simon at josefsson.org  Tue Apr 24 11:42:42 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 24 Apr 2007 11:42:42 +0200
Subject: [gnutls-dev] OpenCDK-related build failures
Message-ID: <87abwyt8fh.fsf@mocca.josefsson.org>

Building gnutls fails:

make: *** No rule to make target `literal.lo', needed by `libminiopencdk.la'.  Stop.
jas at mocca:~/src/gnutls/libextra/opencdk$

Removing literal.c from the Makefile.am (there is no literal.c in the
GnuTLS CVS) causes other failures:

../libextra/.libs/libgnutls-extra.so: undefined reference to `_cdk_filter_literal'
../libextra/.libs/libgnutls-extra.so: undefined reference to `_cdk_filter_text'

Adding plaintext.c, which seems to implement those functions, doesn't
work:

plaintext.c: In function 'literal_decode':
plaintext.c:37: error: 'CDK_PACKET' undeclared (first use in this function)
plaintext.c:37: error: (Each undeclared identifier is reported only once
plaintext.c:37: error: for each function it appears in.)
plaintext.c:37: error: expected ';' before 'pkt'
plaintext.c:48: error: too few arguments to function '_cdk_stream_fpopen'
plaintext.c:51: error: too few arguments to function '_cdk_stream_fpopen'
plaintext.c:56: warning: implicit declaration of function 'cdk_pkt_init'
plaintext.c:56: error: 'pkt' undeclared (first use in this function)
plaintext.c:78: warning: comparison between signed and unsigned
plaintext.c:83: warning: implicit declaration of function 'cdk_md_write'
plaintext.c:88: warning: comparison between signed and unsigned
plaintext.c: In function 'literal_encode':
plaintext.c:107: error: 'CDK_PACKET' undeclared (first use in this function)
plaintext.c:107: error: expected ';' before 'pkt'
plaintext.c:122: error: too few arguments to function '_cdk_stream_fpopen'
plaintext.c:137: error: 'pkt' undeclared (first use in this function)
make: *** [plaintext.lo] Error 1
jas at mocca:~/src/gnutls/libextra/opencdk$

Timo, could you take a look why GnuTLS doesn't build?

Thanks,
Simon



From twoaday at gmx.net  Tue Apr 24 11:55:16 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Tue, 24 Apr 2007 11:55:16 +0200
Subject: [gnutls-dev] OpenCDK comments
In-Reply-To: <87irbnvurw.fsf@mocca.josefsson.org>
References: <87zm538bea.fsf@mocca.josefsson.org>
	<4628B975.8040103@gmx.net>	<87wt047tdc.fsf@mocca.josefsson.org>
	<462B41A9.5050806@gmx.net>	<87r6qbxcxw.fsf@mocca.josefsson.org>
	<462CE952.2020904@gmx.net> <87irbnvurw.fsf@mocca.josefsson.org>
Message-ID: <462DD404.1030804@gmx.net>

Simon Josefsson wrote:

>> Right now I don't know the internals of the GnuTLS code to say
>> anything about it. Maybe we can remove the callbacks without
>> breaking the code?
> 
> Hm.  Do GnuTLS currently use the keyserver stuff?!  I wonder how it
> handles the blocking problem.

Now, I'm really confused. I thought I have seen it somewhere in
the code. But I can't find it again. Maybe it was just a stub.


> Perhaps OpenCDK could use that infrastructure directly instead?

The purpose of the lib is that it will be lightweight and fast. IMHO,
for real OpenPGP tasks, a real OpenPGP should be used. Like GPG. My idea
was to have the lib for key conversion, simple en- and decryption and
to allow packet handling. For example to use OpenPGP keys in an
application, a task gpgme cannot be accomplish because it is a high
level API lib. Otherwise gpgme is perfect and actually I use it myself
in many applications.


> However, I think there are more important things to fix related to
> OpenPGP than this.  I don't know if downloading keys from a keyserver
> is something that typical OpenPGP clients or servers would actually be

That's also my point. IMHO it would be the best idea to focus on the
current code and to clean it up. Keyserver and trustdb issues are
not really important right now, IMHO.


	Timo






From twoaday at gmx.net  Tue Apr 24 14:05:59 2007
From: twoaday at gmx.net (Timo Schulz)
Date: Tue, 24 Apr 2007 14:05:59 +0200
Subject: [gnutls-dev] OpenCDK-related build failures
In-Reply-To: <87abwyt8fh.fsf@mocca.josefsson.org>
References: <87abwyt8fh.fsf@mocca.josefsson.org>
Message-ID: <462DF2A7.30202@gmx.net>

Simon Josefsson wrote:

> make: *** No rule to make target `literal.lo', needed by `libminiopencdk.la'.  Stop.
> jas at mocca:~/src/gnutls/libextra/opencdk$

I'm so sorry. I should have double checked this after the other missing
file. Now the literal.c file is in the cvs.


Sorry again, I will double check now if there are all needed files in
the cvs.


	Timo



From ludovic.courtes at laas.fr  Tue Apr 24 14:27:30 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 24 Apr 2007 14:27:30 +0200
Subject: [gnutls-dev] RFC: PKCS#11 plans
References: <87abx061cr.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>
	<87d51w4l9x.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>
	<87odlg33eu.fsf@mocca.josefsson.org> <874pn7yzc1.fsf@laas.fr>
	<87mz0zxcme.fsf@mocca.josefsson.org>
Message-ID: <874pn6t0st.fsf@laas.fr>

Hi Simon,

Simon Josefsson <simon at josefsson.org> writes:

> ludovic.courtes at laas.fr (Ludovic Court?s) writes:

>> In this context, shouldn't we question the assumption that GnuTLS
>> absolutely needs access to private keys?  It seems that many smartcards
>> don't offer this option for security reasons: instead they only allow,
>> for instance, encryption/decryption of arbitrary data, as well as
>> extraction of the public key (certificate).
>
> Yes!  There are plans for GNOME Seahorse to provide a PKCS#11
> interface for the private keys/certificates stored in the gnome
> keyring.  This was what prompted my work on PKCS#11 support in GnuTLS.

Ok, I had misunderstood the rationale.

> One could also write a really simple PKCS#11 plugin that uses on-disk
> private key/certificates.  This could be written using the GnuTLS
> X.509 APIs.
>
> In any case, the primary goal of my PKCS#11 work is to avoid the need
> for GnuTLS to have access to private keys.  It just needs to read
> certificates from somewhere, and have an interface to signing
> operations.  Whether that is PKCS#11 or some IPC protocol to some
> external gnutls-daemon-like process is an open question.

Alright, got it.

> Yeah, but it turned out that gpg-agent cannot support this, since it
> is not possible to get user certificates from it.

You mean OpenPGP public key certificates, right?

If so, can't we tweak the GnuPG people into changing `gnupg-agent' to
support this?  :-)

As Alon said, it seems that there would be great value into sharing such
mechanisms among several projects.  Since GnuTLS and GnuPG are
"siblings" within the GNU Project, it'd make sense to try and find
solutions suitable to both.

Thanks,
Ludovic.




From ludovic.courtes at laas.fr  Tue Apr 24 14:48:30 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 24 Apr 2007 14:48:30 +0200
Subject: [gnutls-dev] Integrating Guile bindings?
Message-ID: <87slaqos4h.fsf@laas.fr>

Hi,

Would there be interest in integrating Guile bindings with GnuTLS
itself, i.e., distributing them with core GnuTLS?

The main advantage I can see (as a Guile user) is that it would allow
them to be deployed faster and become more widely available.  The main
drawback is that it adds up to the maintenance burden of the GnuTLS
maintainer(s), and I would perfectly understand reluctance to add more
code to the repository.

Technically, we could arrange so that this burden is limited.  For
instance, the easiest solution would be to drop the `guile-gnutls' tree
in a sub-directory of the GnuTLS source, and then use
`AC_CONFIG_SUBDIRS'.  With such an approach, the Guile bindings could
even be maintained off-tree and periodically copied to the GnuTLS
repository.

Building the Guile bindings could also be disabled if either Guile is
not found or `--enable-guile-bindings' was not explicitly passed at
configure-time, so that users who don't care about Guile don't notice
the difference.

What do you think?

Thanks,
Ludovic.




From alon.barlev at gmail.com  Tue Apr 24 17:53:12 2007
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Tue, 24 Apr 2007 18:53:12 +0300
Subject: [gnutls-dev] RFC: PKCS#11 plans
In-Reply-To: <20070424152835.8CA64D4C43@mx.npubs.com>
References: <87abx061cr.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>
	<87d51w4l9x.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>
	<87odlg33eu.fsf@mocca.josefsson.org>
	<20070424152835.8CA64D4C43@mx.npubs.com>
Message-ID: <9e0cf0bf0704240853q25c7960el5e0b32235d893575@mail.gmail.com>

On 4/24/07, Nate Nielsen <nielsen-list at memberwebs.com> wrote:
> BTW, I'm working on building a complete PKCS#11 provider for CAPI. So by
> supporting PKCS#11 you'd be able to have things like CAPI support.

This is great to hear!
It has been long since I developed for Microsoft environment... But I
can help if you like!

Best Regards,
Alon Bar-Lev.



From simon at josefsson.org  Tue Apr 24 18:13:33 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 24 Apr 2007 18:13:33 +0200
Subject: [gnutls-dev] OpenCDK-related build failures
In-Reply-To: <462DF2A7.30202@gmx.net> (Timo Schulz's message of "Tue\, 24 Apr
	2007 14\:05\:59 +0200")
References: <87abwyt8fh.fsf@mocca.josefsson.org> <462DF2A7.30202@gmx.net>
Message-ID: <87647lda36.fsf@mocca.josefsson.org>

Timo Schulz <twoaday at gmx.net> writes:

> Simon Josefsson wrote:
>
>> make: *** No rule to make target `literal.lo', needed by `libminiopencdk.la'.  Stop.
>> jas at mocca:~/src/gnutls/libextra/opencdk$
>
> I'm so sorry. I should have double checked this after the other missing
> file. Now the literal.c file is in the cvs.
>
>
> Sorry again, I will double check now if there are all needed files in
> the cvs.

It builds for me now.  Thanks!

/Simon



From wk at gnupg.org  Tue Apr 24 18:10:31 2007
From: wk at gnupg.org (Werner Koch)
Date: Tue, 24 Apr 2007 18:10:31 +0200
Subject: [gnutls-dev] RFC: PKCS#11 plans
In-Reply-To: <874pn6t0st.fsf@laas.fr> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?=
	=?utf-8?Q?s?= message of "Tue\, 24 Apr 2007 14\:27\:30 +0200")
References: <87abx061cr.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>
	<87d51w4l9x.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>
	<87odlg33eu.fsf@mocca.josefsson.org> <874pn7yzc1.fsf@laas.fr>
	<87mz0zxcme.fsf@mocca.josefsson.org> <874pn6t0st.fsf@laas.fr>
Message-ID: <87k5w192iw.fsf@wheatstone.g10code.de>

On Tue, 24 Apr 2007 14:27, ludovic.courtes at laas.fr said:

> If so, can't we tweak the GnuPG people into changing `gnupg-agent' to
> support this?  :-)

No, it would violate a design principle.


Salam-Shalom,

   Werner




From simon at josefsson.org  Tue Apr 24 18:24:40 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 24 Apr 2007 18:24:40 +0200
Subject: [gnutls-dev] RFC: PKCS#11 plans
In-Reply-To: <874pn6t0st.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Tue\, 24
	Apr 2007 14\:27\:30 +0200")
References: <87abx061cr.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>
	<87d51w4l9x.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>
	<87odlg33eu.fsf@mocca.josefsson.org> <874pn7yzc1.fsf@laas.fr>
	<87mz0zxcme.fsf@mocca.josefsson.org> <874pn6t0st.fsf@laas.fr>
Message-ID: <871wi9d9kn.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

>> Yeah, but it turned out that gpg-agent cannot support this, since it
>> is not possible to get user certificates from it.
>
> You mean OpenPGP public key certificates, right?

No, the X.509 user certificates for OpenPGP cards (the card essentially
only contain the RSA key in this situation).  They are not stored on the
smartcard, but rather inside 'gpgsm'.

> If so, can't we tweak the GnuPG people into changing `gnupg-agent' to
> support this?  :-)

Werner said recently on gnupg-users that it would violate the design to
make gnupg-agent be aware of gpgsm and X.509, so I think we've tried and
failed that approach.

Anyway, supporting PKCS#11 will allow us to use Scute, which talks to
gpg-agent, scdaemon and gpgsm.

> As Alon said, it seems that there would be great value into sharing such
> mechanisms among several projects.  Since GnuTLS and GnuPG are
> "siblings" within the GNU Project, it'd make sense to try and find
> solutions suitable to both.

Yup.  However, even if gpg-agent would be changed to support this, I
think it would be useful for GnuTLS to support PKCS#11 too.  After
thinking about it, I don't think it is important to change gpg-agent.  I
no longer think changing it would be a good idea.

Of course, if gpg-agent turns into a PKCS#11 proxy, and can support
loading any PKCS#11 provider and use it for signing etc, then having
GnuTLS speak to it would be one solution.

Btw, the status of my work is that I'm able to read out the certificate
and sign things via Scute, inside GnuTLS.  What remains to be done is to
fix GnuTLS to keep a user certificate without a private key, and to
off-load the signing operation back to the PKCS#11 provider.  I intend
to post step-by-step instructions to connect to test.gnutls.org using a
smartcard within a week or so.

My PKCS#11-fu is weak, but at least it seems quite feasible to support
Scute in GnuTLS.  I don't know how to handle PKCS#11 providers that
needs PINs etc.  Scute fortunately takes care of all such things
internally.  My main goal is to make Scute work, and possibly also
support the Mozilla soft tokens to get their CAs and user credentials.
When the Seahorse stuff is finished, supporting that is also important.
Other PKCS#11 providers, in particular any PKCS#11 plugin that is not
GPL-compatible, is not important to me unless someone financially
sponsor such work.

/Simon



From simon at josefsson.org  Tue Apr 24 18:38:18 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 24 Apr 2007 18:38:18 +0200
Subject: [gnutls-dev] Integrating Guile bindings?
In-Reply-To: <87slaqos4h.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Tue\, 24
	Apr 2007 14\:48\:30 +0200")
References: <87slaqos4h.fsf@laas.fr>
Message-ID: <87wt01budh.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Hi,
>
> Would there be interest in integrating Guile bindings with GnuTLS
> itself, i.e., distributing them with core GnuTLS?
>
> The main advantage I can see (as a Guile user) is that it would allow
> them to be deployed faster and become more widely available.  The main
> drawback is that it adds up to the maintenance burden of the GnuTLS
> maintainer(s), and I would perfectly understand reluctance to add more
> code to the repository.
>
> Technically, we could arrange so that this burden is limited.  For
> instance, the easiest solution would be to drop the `guile-gnutls' tree
> in a sub-directory of the GnuTLS source, and then use
> `AC_CONFIG_SUBDIRS'.  With such an approach, the Guile bindings could
> even be maintained off-tree and periodically copied to the GnuTLS
> repository.
>
> Building the Guile bindings could also be disabled if either Guile is
> not found or `--enable-guile-bindings' was not explicitly passed at
> configure-time, so that users who don't care about Guile don't notice
> the difference.
>
> What do you think?

Hi!  I don't have a strong opinion.  I believe that if guile-gnutls
would ever cause a ./configure && make of GnuTLS itself to fail, I'd be
rather inclined to disable it, though.  However, good configure.ac code
would be able to disable the build if it cannot be installed, and not
cause any problems.

I'm somewhat concerned about the size of the GnuTLS distribution
archive, and would rather want to modularize things (i.e., remove the
libtasn1 + opencdk copies) than include even more stuff.  But I'm not
sure this is really a valid concern.  It is still small compared to
OpenOffice...

Another concern is build-time.  Building GnuTLS from a fresh CVS is what
I often do to test things, and even today that is slower than I would
like.  (I'm not on slow hardware!)  Would I have to build the guile
stuff in order to do 'make dist'?  If there are any files in the
*.tar.gz which is generated during build in the guile/ directory,
guile-gnutls would need to be built as well.

Perhaps others could chime in... It would be interesting to know what
various GNU/Linux distributors think about this.

/Simon



From ludovic.courtes at laas.fr  Wed Apr 25 10:39:11 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 25 Apr 2007 10:39:11 +0200
Subject: [gnutls-dev] Integrating Guile bindings?
References: <87slaqos4h.fsf@laas.fr> <87wt01budh.fsf@mocca.josefsson.org>
Message-ID: <87fy6odf0w.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Hi!  I don't have a strong opinion.  I believe that if guile-gnutls
> would ever cause a ./configure && make of GnuTLS itself to fail, I'd be
> rather inclined to disable it, though.  However, good configure.ac code
> would be able to disable the build if it cannot be installed, and not
> cause any problems.

Right.

> I'm somewhat concerned about the size of the GnuTLS distribution
> archive, and would rather want to modularize things (i.e., remove the
> libtasn1 + opencdk copies) than include even more stuff.  But I'm not
> sure this is really a valid concern.  It is still small compared to
> OpenOffice...

FWIW, the GnuTLS 1.6.2 tar.gz is around 4200 KB and the Guile-GnuTLS
tar.gz is less than 460 KB.

> Another concern is build-time.  Building GnuTLS from a fresh CVS is what
> I often do to test things, and even today that is slower than I would
> like.  (I'm not on slow hardware!)  Would I have to build the guile
> stuff in order to do 'make dist'?  If there are any files in the
> *.tar.gz which is generated during build in the guile/ directory,
> guile-gnutls would need to be built as well.

In principle, nothing needs to be built in Guile-GnuTLS for "make dist"
(it has to be configured, though).  However, when starting from a fresh
checkout, there are a few `BUILT_SOURCES' that must be built to produce
the Info file.  That should be pretty fast, though.

> Perhaps others could chime in... It would be interesting to know what
> various GNU/Linux distributors think about this.

I know that D-BUS and Avahi come with Python and Java/C# bindings
(included in the main distribution), GNU Mailutils contains Guile
bindings.

Besides, there's a host of C libraries whose bindings for other
languages are maintained separately, e.g., GTK+ (GTK+ has "official"
bindings though [0], meaning that they are guaranteed to be up-to-date
wrt. the C API).

I don't know what packagers prefer.  Having bindings in the main
distribution may give them a strong incentive to actually package them.
;-)

Thanks,
Ludovic.

[0] http://gtk.org/bindings.html




From nielsen-list at memberwebs.com  Tue Apr 24 17:23:36 2007
From: nielsen-list at memberwebs.com (Nate Nielsen)
Date: Tue, 24 Apr 2007 15:23:36 +0000 (UTC)
Subject: [gnutls-dev] RFC: PKCS#11 plans
References: <87abx061cr.fsf@mocca.josefsson.org>	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>	<87d51w4l9x.fsf@mocca.josefsson.org>	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>	<87odlg33eu.fsf@mocca.josefsson.org>	<9e0cf0bf0704220744w12ebe5ebi47bec49bea444f98@mail.gmail.com>
	<87y7kj1mio.fsf@mocca.josefsson.org>
Message-ID: <20070424152335.806DDD4C3E@mx.npubs.com>

Simon Josefsson wrote:
> Serializing PKCS#11 is not simple, and I don't know if anyone has done
> this before.  Further, the serialization of PKCS#11 doesn't have to be
> exactly mapped to the PKCS#11 API, it only have to support the same
> things that PKCS#11 support.

Yes, it's certainly not simple.

gnome-keyring-cryptoki is serializing same of the PKCS#11 calls for
communication with its daemon. It's similar to  how a smart card driver
might send requests to its hardware component.

I would recommend that any such serialization remain an internal API
rather than trying to spec it out. As Alon is saying, implement PKCS#11
as the 'spec' or supported API, and then a certain PKCS#11 driver could
choose to serialize requests to a daemon (much as a smart card driver
would internally serialize or process requests).

Cheers,
Nate









From simon at josefsson.org  Wed Apr 25 11:38:26 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 25 Apr 2007 11:38:26 +0200
Subject: [gnutls-dev] RFC: PKCS#11 plans
In-Reply-To: <20070424152335.806DDD4C3E@mx.npubs.com> (Nate Nielsen's message
	of "Tue\, 24 Apr 2007 15\:23\:36 +0000 \(UTC\)")
References: <87abx061cr.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>
	<87d51w4l9x.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>
	<87odlg33eu.fsf@mocca.josefsson.org>
	<9e0cf0bf0704220744w12ebe5ebi47bec49bea444f98@mail.gmail.com>
	<87y7kj1mio.fsf@mocca.josefsson.org>
	<20070424152335.806DDD4C3E@mx.npubs.com>
Message-ID: <87zm4waj59.fsf@mocca.josefsson.org>

Nate Nielsen <nielsen-list at memberwebs.com> writes:

> Simon Josefsson wrote:
>> Serializing PKCS#11 is not simple, and I don't know if anyone has done
>> this before.  Further, the serialization of PKCS#11 doesn't have to be
>> exactly mapped to the PKCS#11 API, it only have to support the same
>> things that PKCS#11 support.
>
> Yes, it's certainly not simple.
>
> gnome-keyring-cryptoki is serializing same of the PKCS#11 calls for
> communication with its daemon. It's similar to  how a smart card driver
> might send requests to its hardware component.
>
> I would recommend that any such serialization remain an internal API
> rather than trying to spec it out. As Alon is saying, implement PKCS#11
> as the 'spec' or supported API, and then a certain PKCS#11 driver could
> choose to serialize requests to a daemon (much as a smart card driver
> would internally serialize or process requests).

Right, and that's what I'm doing in my initial work.

However, I'm not yet convinced that GnuTLS should only support PKCS#11
directly, and no other crypto hardware abstraction layer such as CAPI or
GnuPG 2.x gpg-agent, possibly through a gnutls-daemon.  Still, adding
support for more abstractions can be done later on.  I guess that since
nobody else is working on this now, PKCS#11 will be all that I will
implement unless I run into serious problems with that choice.  The
choice can be revisited in the future.

For example, to support TLS OpenPGP with keys on smart cards, I don't
think I can use PKCS#11 via Scute.  It is X.509 only.  Or?

With the current approach of using PKCS#11 directly, there is the
problem of how to load the PKCS#11 module.  Right now, it is linked at
build-time.  Presumably, it would be nice to have it linked at run-time
via dlopen(), but that creates more problems for applications.  I think
they are already unhappy with how (relatively) complex it is to use
GnuTLS.  Having to deal with loading of PKCS#11 providers is probably
not what they are hoping for.

There is also the problem of having more code (the PKCS#11 provider) run
in the same process as GnuTLS.

Still, this approach is simpler for me to code. :)

/Simon



From simon at josefsson.org  Wed Apr 25 11:49:00 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 25 Apr 2007 11:49:00 +0200
Subject: [gnutls-dev] Integrating Guile bindings?
In-Reply-To: <87fy6odf0w.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Wed\, 25
	Apr 2007 10\:39\:11 +0200")
References: <87slaqos4h.fsf@laas.fr> <87wt01budh.fsf@mocca.josefsson.org>
	<87fy6odf0w.fsf@laas.fr>
Message-ID: <87odlcainn.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

>> I'm somewhat concerned about the size of the GnuTLS distribution
>> archive, and would rather want to modularize things (i.e., remove the
>> libtasn1 + opencdk copies) than include even more stuff.  But I'm not
>> sure this is really a valid concern.  It is still small compared to
>> OpenOffice...
>
> FWIW, the GnuTLS 1.6.2 tar.gz is around 4200 KB and the Guile-GnuTLS
> tar.gz is less than 460 KB.

Oh, I thought guile-gnutls would be larger.  I actually built
guile-gnutls now, and it seemed rather painless.  I had problems since
you use the AM_PATH_LIBGNUTLS macro, but that is my fault since I
haven't installed and documented a better alternative.

I think we can wait a week or two to wait to see if there will be any
reactions from others.  If there aren't any good reasons then, let's add
it.  I suppose the manuals should be merged.

Thanks,
Simon



From nielsen-list at memberwebs.com  Tue Apr 24 17:28:36 2007
From: nielsen-list at memberwebs.com (Nate Nielsen)
Date: Tue, 24 Apr 2007 15:28:36 +0000 (UTC)
Subject: [gnutls-dev] RFC: PKCS#11 plans
References: <87abx061cr.fsf@mocca.josefsson.org>	<9e0cf0bf0704220540w2fb9168co8e3ea75cb15fa983@mail.gmail.com>	<87d51w4l9x.fsf@mocca.josefsson.org>	<9e0cf0bf0704220613j6138d941y640d6d330b2ad54c@mail.gmail.com>
	<87odlg33eu.fsf@mocca.josefsson.org>
Message-ID: <20070424152835.8CA64D4C43@mx.npubs.com>

Simon Josefsson wrote:
> Ok.  gnutls-daemon could then support, say:
> 
> * Any PKCS#11 token via libp11
> 
> * Simple PKCS#11 tokens directly (it takes < 50 lines of code to sign
>   something with scute, and I have this code working now).
> 
> * GNOME Seahorse crypto provider (although possibly this will happen
>   via PKCS#11).
> 
> * gpg-agent for OpenPGP keys + OpenPGP signing.
> 
> * Microsoft CAPI

BTW, I'm working on building a complete PKCS#11 provider for CAPI. So by
supporting PKCS#11 you'd be able to have things like CAPI support.

Cheers,
Nate













From ludovic.courtes at laas.fr  Wed Apr 25 15:14:33 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 25 Apr 2007 15:14:33 +0200
Subject: [gnutls-dev] Integrating Guile bindings?
References: <87slaqos4h.fsf@laas.fr> <87wt01budh.fsf@mocca.josefsson.org>
	<87fy6odf0w.fsf@laas.fr> <87odlcainn.fsf@mocca.josefsson.org>
Message-ID: <87mz0w61fq.fsf@laas.fr>

Simon Josefsson <simon at josefsson.org> writes:

> Oh, I thought guile-gnutls would be larger.  I actually built
> guile-gnutls now, and it seemed rather painless.  I had problems since
> you use the AM_PATH_LIBGNUTLS macro, but that is my fault since I
> haven't installed and documented a better alternative.

What's wrong with `AM_PATH_LIBGNUTLS'?

> I think we can wait a week or two to wait to see if there will be any
> reactions from others.  If there aren't any good reasons then, let's add
> it.  I suppose the manuals should be merged.

Not sure the manuals should be merged, especially since Guile bindings
are optional and part of the guile-gnutls manual is generated using
Guile.  It'd be at least simpler to keep them separated, with
cross-references between them.

When/if a decision is made to integrate it, I can provide the necessary
Autoconf/Automake snippets.  We may also want to make it "Copyright FSF"
and make the manual available under the GFDL with no invariant sections,
etc. (currently it's under a simple permissive copyleft licence, similar
to that of the GNU web pages).

Thanks,
Ludovic.




From simon at josefsson.org  Wed Apr 25 15:54:48 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 25 Apr 2007 15:54:48 +0200
Subject: [gnutls-dev] Integrating Guile bindings?
In-Reply-To: <87mz0w61fq.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Wed\, 25
	Apr 2007 15\:14\:33 +0200")
References: <87slaqos4h.fsf@laas.fr> <87wt01budh.fsf@mocca.josefsson.org>
	<87fy6odf0w.fsf@laas.fr> <87odlcainn.fsf@mocca.josefsson.org>
	<87mz0w61fq.fsf@laas.fr>
Message-ID: <87irbk8spj.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>> Oh, I thought guile-gnutls would be larger.  I actually built
>> guile-gnutls now, and it seemed rather painless.  I had problems since
>> you use the AM_PATH_LIBGNUTLS macro, but that is my fault since I
>> haven't installed and documented a better alternative.
>
> What's wrong with `AM_PATH_LIBGNUTLS'?

I have GnuTLS installed in /usr/lib (from Debian) and newer libraries in
/usr/local/lib.  Configuring guile-gnutls results in:

checking for libgnutls - version >= 1.4.0...
*** 'libgnutls-config --version' returned 1.7.9, but LIBGNUTLS (1.4.4)
*** was found! If libgnutls-config was correct, then it is best
*** to remove the old version of LIBGNUTLS. You may also be able to fix the error
*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing
*** /etc/ld.so.conf. Make sure you have run ldconfig if that is
*** required on your system.
*** If libgnutls-config was wrong, set the environment variable LIBGNUTLS_CONFIG
*** to point to the correct copy of libgnutls-config, and remove the file config.cache
*** before re-running configure
checking for libgnutls-extra-config... /usr/local/bin/libgnutls-extra-config
checking for libgnutls - version >= 1.4.0...
*** 'libgnutls-extra-config --version' returned 1.7.9, but LIBGNUTLS_EXTRA (1.4.4)
*** was found! If libgnutls-extra-config was correct, then it is best
*** to remove the old version of LIBGNUTLS_EXTRA. You may also be able to fix the error
*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing
*** /etc/ld.so.conf. Make sure you have run ldconfig if that is
*** required on your system.
*** If libgnutls-extra-config was wrong, set the environment variable LIBGNUTLS_EXTRA_CONFIG
*** to point to the correct copy of libgnutls-extra-config, and remove the file config.cache
*** before re-running configure

What's happening is that it uses libgnutls-config from /usr/local/bin
that for --libs says:

-L/usr/local/lib -lgnutls -L/usr/local/lib -lgcrypt -L/usr/local/lib -lgpg-error

Linking an application with those parameters won't make it use
libgnutls.so from /usr/local/lib, a -Wl,-rpath or similar is required
too.

This results in 'make check' failing.

Modifying LD_LIBRARY_PATH is ugly.  It is a bad recommendation.

I believe configure should simply work automatically in this not at all
uncommon situation.

The concept of a *-config program is flawed IMO.  The autoconf approach
is to test for features, and that is what we should do.  In GNU SASL and
some other projects that use GnuTLS, I use Bruno's have-lib macros.
They handle the -R problem in a more portable way, and is generally both
safer and better.  I should integrate those into libgnutls.m4 and better
document that.

>> I think we can wait a week or two to wait to see if there will be any
>> reactions from others.  If there aren't any good reasons then, let's add
>> it.  I suppose the manuals should be merged.
>
> Not sure the manuals should be merged, especially since Guile bindings
> are optional and part of the guile-gnutls manual is generated using
> Guile.  It'd be at least simpler to keep them separated, with
> cross-references between them.

Several optional things are described in the manual now...  It is a pain
to maintain separate manuals though, when generating and uploading them
to <http://www.gnu.org/software/gnutls/documentation.html>.  Also, I
would think that having the guile interface be documented in the
standard GnuTLS manual also leads to wider adoption and spread of the
guile bindings.

But I don't think strongly about it.

Possibly the guile-gnutls manual could be written as a standalone
manual, although the main gnutls manual could @include it.

> When/if a decision is made to integrate it, I can provide the necessary
> Autoconf/Automake snippets.  We may also want to make it "Copyright FSF"
> and make the manual available under the GFDL with no invariant sections,
> etc. (currently it's under a simple permissive copyleft licence, similar
> to that of the GNU web pages).

Oh, yes, right, one requirement to add anything to the core GnuTLS
package is that the copyright is transferred to the FSF and that
generally it follows the GNU project's standards (which, among other
things, imply that the manual is GFDL).  You should read:

http://www.gnu.org/prep/standards/
http://www.gnu.org/prep/maintain/

/Simon



From ludovic.courtes at laas.fr  Wed Apr 25 16:45:23 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 25 Apr 2007 16:45:23 +0200
Subject: [gnutls-dev] Integrating Guile bindings?
References: <87slaqos4h.fsf@laas.fr> <87wt01budh.fsf@mocca.josefsson.org>
	<87fy6odf0w.fsf@laas.fr> <87odlcainn.fsf@mocca.josefsson.org>
	<87mz0w61fq.fsf@laas.fr> <87irbk8spj.fsf@mocca.josefsson.org>
Message-ID: <878xcg4inw.fsf@laas.fr>

Simon Josefsson <simon at josefsson.org> writes:

> I have GnuTLS installed in /usr/lib (from Debian) and newer libraries in
> /usr/local/lib.  Configuring guile-gnutls results in:

[...]

> Linking an application with those parameters won't make it use
> libgnutls.so from /usr/local/lib, a -Wl,-rpath or similar is required
> too.
>
> This results in 'make check' failing.
>
> Modifying LD_LIBRARY_PATH is ugly.  It is a bad recommendation.
>
> I believe configure should simply work automatically in this not at all
> uncommon situation.

Yeah, I usually use a similar setting (home-built lib in `/usr/local')
and work around this by having `LD_LIBRARY_PATH' include
`/usr/local/lib'.  There's nothing wrong with updating
`LD_LIBRARY_PATH', though, as it is required anyway to get the right lib
loaded.

Nevertheless, it would certainly be nicer if it worked "out of the box".

> Several optional things are described in the manual now...  It is a pain
> to maintain separate manuals though, when generating and uploading them
> to <http://www.gnu.org/software/gnutls/documentation.html>.  Also, I
> would think that having the guile interface be documented in the
> standard GnuTLS manual also leads to wider adoption and spread of the
> guile bindings.

Good point!  :-)

> But I don't think strongly about it.
>
> Possibly the guile-gnutls manual could be written as a standalone
> manual, although the main gnutls manual could @include it.

Right, and we could arrange to just ": > guile-gnutls.texi" when Guile
is not available.

> Oh, yes, right, one requirement to add anything to the core GnuTLS
> package is that the copyright is transferred to the FSF

I guess that would fall under my copyright assignment for GnuTLS, so I'd
basically just need to change the copyright line in each file and we're
done.

> and that
> generally it follows the GNU project's standards (which, among other
> things, imply that the manual is GFDL).  You should read:
>
> http://www.gnu.org/prep/standards/
> http://www.gnu.org/prep/maintain/

This should be ok.  If you notice any specific point where it deviates
from the standards, please let me know.

Thanks,
Ludovic.




From simon at josefsson.org  Wed Apr 25 17:30:07 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 25 Apr 2007 17:30:07 +0200
Subject: [gnutls-dev] Integrating Guile bindings?
In-Reply-To: <878xcg4inw.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Wed\, 25
	Apr 2007 16\:45\:23 +0200")
References: <87slaqos4h.fsf@laas.fr> <87wt01budh.fsf@mocca.josefsson.org>
	<87fy6odf0w.fsf@laas.fr> <87odlcainn.fsf@mocca.josefsson.org>
	<87mz0w61fq.fsf@laas.fr> <87irbk8spj.fsf@mocca.josefsson.org>
	<878xcg4inw.fsf@laas.fr>
Message-ID: <87ejm879q8.fsf@mocca.josefsson.org>

ludovic.courtes at laas.fr (Ludovic Court?s) writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>> I have GnuTLS installed in /usr/lib (from Debian) and newer libraries in
>> /usr/local/lib.  Configuring guile-gnutls results in:
>
> [...]
>
>> Linking an application with those parameters won't make it use
>> libgnutls.so from /usr/local/lib, a -Wl,-rpath or similar is required
>> too.
>>
>> This results in 'make check' failing.
>>
>> Modifying LD_LIBRARY_PATH is ugly.  It is a bad recommendation.
>>
>> I believe configure should simply work automatically in this not at all
>> uncommon situation.
>
> Yeah, I usually use a similar setting (home-built lib in `/usr/local')
> and work around this by having `LD_LIBRARY_PATH' include
> `/usr/local/lib'.  There's nothing wrong with updating
> `LD_LIBRARY_PATH', though, as it is required anyway to get the right lib
> loaded.

The problem with LD_LIBRARY_PATH is that every user on the system that
wants to use an application linked without library search paths will
have to modify LD_LIBRARY_PATH.  Not everyone build application just for
their own use, and those who do, requiring users to set LD_LIBRARY_PATH
is problematic.

>> Oh, yes, right, one requirement to add anything to the core GnuTLS
>> package is that the copyright is transferred to the FSF
>
> I guess that would fall under my copyright assignment for GnuTLS, so I'd
> basically just need to change the copyright line in each file and we're
> done.

Yup.  There is nobody else who contributed code, or where you copied
code written by someone else?

>> and that
>> generally it follows the GNU project's standards (which, among other
>> things, imply that the manual is GFDL).  You should read:
>>
>> http://www.gnu.org/prep/standards/
>> http://www.gnu.org/prep/maintain/
>
> This should be ok.  If you notice any specific point where it deviates
> from the standards, please let me know.

When/if we integrate it, I'll review it further.

/Simon



From ludovic.courtes at laas.fr  Wed Apr 25 17:43:55 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 25 Apr 2007 17:43:55 +0200
Subject: [gnutls-dev] Integrating Guile bindings?
References: <87slaqos4h.fsf@laas.fr> <87wt01budh.fsf@mocca.josefsson.org>
	<87fy6odf0w.fsf@laas.fr> <87odlcainn.fsf@mocca.josefsson.org>
	<87mz0w61fq.fsf@laas.fr> <87irbk8spj.fsf@mocca.josefsson.org>
	<878xcg4inw.fsf@laas.fr> <87ejm879q8.fsf@mocca.josefsson.org>
Message-ID: <87k5w031dw.fsf@laas.fr>

Simon Josefsson <simon at josefsson.org> writes:

> Yup.  There is nobody else who contributed code, or where you copied
> code written by someone else?

Nope.  There's code stolen from another project of mine in
`modules/system/documentation' but it was also written by me so that
should not be a problem.  :-)

Thanks,
Ludovic.




From gnutls-dev at mlists.thewrittenword.com  Thu Apr 26 18:02:15 2007
From: gnutls-dev at mlists.thewrittenword.com (Peter O'Gorman)
Date: Thu, 26 Apr 2007 11:02:15 -0500
Subject: [gnutls-dev] set random seed file via gnutls api
Message-ID: <20070426160215.GJ13730@localhost.localdomain>

Hi,
We built curl with gnutls support. It works fine, with a caveat:
% curl --version --random-file /tmp/pogma/foo/a
Fatal: no entropy gathering module detected

There is no API in gnutls to set the random seed file (there is an api
in libgcrypt to do so, however). It is unfortunate that on hosts
without a /dev/random where libgcrypt has been configured to gather
entropy from a particular socket and that socket is unavailable that
it exits the application during gnutls library initialization.

Should curl be using the libgcrypt api directly to avoid this? Or
ought there be a way to set the random file via gnutls? We're thinking
the latter.

Thanks,
Peter





From simon at josefsson.org  Fri Apr 27 14:00:05 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 27 Apr 2007 14:00:05 +0200
Subject: [gnutls-dev] set random seed file via gnutls api
In-Reply-To: <20070426160215.GJ13730@localhost.localdomain> (Peter O'Gorman's
	message of "Thu\, 26 Apr 2007 11\:02\:15 -0500")
References: <20070426160215.GJ13730@localhost.localdomain>
Message-ID: <87ps5qrpru.fsf@mocca.josefsson.org>

"Peter O'Gorman" <gnutls-dev at mlists.thewrittenword.com> writes:

> Hi,
> We built curl with gnutls support. It works fine, with a caveat:
> % curl --version --random-file /tmp/pogma/foo/a
> Fatal: no entropy gathering module detected
>
> There is no API in gnutls to set the random seed file (there is an api
> in libgcrypt to do so, however). It is unfortunate that on hosts
> without a /dev/random where libgcrypt has been configured to gather
> entropy from a particular socket and that socket is unavailable that
> it exits the application during gnutls library initialization.

Ouch, yes.

> Should curl be using the libgcrypt api directly to avoid this? Or
> ought there be a way to set the random file via gnutls? We're thinking
> the latter.

Yes, if libgcrypt used by GnuTLS needs help to find a random seed file
to work properly, it seems it would make sense for GnuTLS to provide an
API to set it.

/Simon



From andrew.w.nosenko at gmail.com  Fri Apr 27 14:15:14 2007
From: andrew.w.nosenko at gmail.com (Andrew W. Nosenko)
Date: Fri, 27 Apr 2007 15:15:14 +0300
Subject: [gnutls-dev] gnutls-1.6.1.auth_cert.mem-leak.awn.1.patch
In-Reply-To: <6161f3180704260818p39b399d2x594da396b76bfb9e@mail.gmail.com>
References: <6161f3180704260818p39b399d2x594da396b76bfb9e@mail.gmail.com>
Message-ID: <6161f3180704270515s5cff14x3bd6f4a811809fdc@mail.gmail.com>

2007-04-26  Andrey Nosenko  <andrew.w.nosenko at gmail.com>

        * lib/auth_cert.c (_gnutls_selected_certs_deinit):
        Fix memory leak.

-- 
Andrew W. Nosenko <andrew.w.nosenko at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-1.6.1.auth_cert.mem-leak.awn.1.patch
Type: text/x-patch
Size: 785 bytes
Desc: not available
URL: </pipermail/attachments/20070427/50b080bc/attachment.bin>

From simon at josefsson.org  Fri Apr 27 14:26:05 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 27 Apr 2007 14:26:05 +0200
Subject: [gnutls-dev] gnutls-1.6.1.auth_cert.mem-leak.awn.1.patch
In-Reply-To: <6161f3180704270515s5cff14x3bd6f4a811809fdc@mail.gmail.com>
	(Andrew W. Nosenko's message of "Fri\, 27 Apr 2007 15\:15\:14 +0300")
References: <6161f3180704260818p39b399d2x594da396b76bfb9e@mail.gmail.com>
	<6161f3180704270515s5cff14x3bd6f4a811809fdc@mail.gmail.com>
Message-ID: <874pn2roki.fsf@mocca.josefsson.org>

"Andrew W. Nosenko" <andrew.w.nosenko at gmail.com> writes:

> 2007-04-26  Andrey Nosenko  <andrew.w.nosenko at gmail.com>
>
>        * lib/auth_cert.c (_gnutls_selected_certs_deinit):
>        Fix memory leak.

Thanks.  When do the mem leak happen?  In other words, how do I trigger
it?  I'd like to write a self-test that trigger it (which could be used
with valgrind) to improve our regression-testing, if it isn't too
difficult to do.

/Simon

> -- 
> Andrew W. Nosenko <andrew.w.nosenko at gmail.com>
> 2007-04-26  Andrey Nosenko  <andrew.w.nosenko at gmail.com>
>
> 	* lib/auth_cert.c (_gnutls_selected_certs_deinit):
> 	Fix memory leak.
>
> --- lib/auth_cert.c-	Fri Jun 16 19:25:06 2006
> +++ lib/auth_cert.c	Thu Apr 26 18:08:11 2007
> @@ -1652,10 +1652,16 @@ _gnutls_selected_certs_deinit (gnutls_se
>  	{
>  	  _gnutls_gcert_deinit (&session->internals.selected_cert_list[i]);
>  	}
> +      gnutls_free(session->internals.selected_cert_list);
>        session->internals.selected_cert_list = NULL;
>        session->internals.selected_cert_list_length = 0;
>  
>        _gnutls_gkey_deinit (session->internals.selected_key);
> +      if (session->internals.selected_key)
> +      {
> +          gnutls_free(session->internals.selected_key);
> +          session->internals.selected_key = NULL;
> +      }
>      }
>  
>    return;
> _______________________________________________
> Gnutls-dev mailing list
> Gnutls-dev at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-dev



From andrew.w.nosenko at gmail.com  Fri Apr 27 15:35:47 2007
From: andrew.w.nosenko at gmail.com (Andrew W. Nosenko)
Date: Fri, 27 Apr 2007 16:35:47 +0300
Subject: [gnutls-dev] gnutls-1.6.1.auth_cert.mem-leak.awn.1.patch
In-Reply-To: <874pn2roki.fsf@mocca.josefsson.org>
References: <6161f3180704260818p39b399d2x594da396b76bfb9e@mail.gmail.com>
	<6161f3180704270515s5cff14x3bd6f4a811809fdc@mail.gmail.com>
	<874pn2roki.fsf@mocca.josefsson.org>
Message-ID: <6161f3180704270635m198a66f4kd337c2985c240312@mail.gmail.com>

On 4/27/07, Simon Josefsson <simon at josefsson.org> wrote:
> "Andrew W. Nosenko" <andrew.w.nosenko at gmail.com> writes:
>
> > 2007-04-26  Andrey Nosenko  <andrew.w.nosenko at gmail.com>
> >
> >        * lib/auth_cert.c (_gnutls_selected_certs_deinit):
> >        Fix memory leak.
>
> Thanks.  When do the mem leak happen?  In other words, how do I trigger
> it?

  $ gnutls-cli --x509keyfile client-key.pem --x509certfile
client-cert.pem some.webservices.site.com < /dev/null

> I'd like to write a self-test that trigger it (which could be used
> with valgrind) to improve our regression-testing, if it isn't too
> difficult to do.

Yes, I also used valgrind for hunting of this leak.  But have no idea
about how to automate it...

-- 
Andrew W. Nosenko <andrew.w.nosenko at gmail.com>



From gnutls-dev at mlists.thewrittenword.com  Sat Apr 28 02:10:55 2007
From: gnutls-dev at mlists.thewrittenword.com (Peter O'Gorman)
Date: Fri, 27 Apr 2007 19:10:55 -0500
Subject: [gnutls-dev] set random seed file via gnutls api
In-Reply-To: <87ps5qrpru.fsf@mocca.josefsson.org>
References: <20070426160215.GJ13730@localhost.localdomain>
	<87ps5qrpru.fsf@mocca.josefsson.org>
Message-ID: <20070428001055.GA8893@localhost.localdomain>

On Fri, Apr 27, 2007 at 02:00:05PM +0200, Simon Josefsson wrote:
> "Peter O'Gorman" <gnutls-dev at mlists.thewrittenword.com> writes:
> 
> > Should curl be using the libgcrypt api directly to avoid this? Or
> > ought there be a way to set the random file via gnutls? We're thinking
> > the latter.
> 
> Yes, if libgcrypt used by GnuTLS needs help to find a random seed file
> to work properly, it seems it would make sense for GnuTLS to provide an
> API to set it.

Looks like I misread the gcrypt options, there is no current API for
changing the egd socket. Sorry. I am hopeful that something will be
added to the next major release of libgcrypt, if so we will come back
with a patch for GnuTLS.

Thanks,
Peter 





From wk at gnupg.org  Sat Apr 28 10:57:40 2007
From: wk at gnupg.org (Werner Koch)
Date: Sat, 28 Apr 2007 10:57:40 +0200
Subject: [gnutls-dev] set random seed file via gnutls api
In-Reply-To: <20070428001055.GA8893@localhost.localdomain> (Peter O'Gorman's
	message of "Fri\, 27 Apr 2007 19\:10\:55 -0500")
References: <20070426160215.GJ13730@localhost.localdomain>
	<87ps5qrpru.fsf@mocca.josefsson.org>
	<20070428001055.GA8893@localhost.localdomain>
Message-ID: <87lkgcev0b.fsf@wheatstone.g10code.de>

On Sat, 28 Apr 2007 02:10, gnutls-dev at mlists.thewrittenword.com said:

> Looks like I misread the gcrypt options, there is no current API for
> changing the egd socket. Sorry. I am hopeful that something will be
> added to the next major release of libgcrypt, if so we will come back
> with a patch for GnuTLS.

You can change the socket used for EGD with a configure option.  Since
early GnuPG times, the suggestion has always been to use a symlink
instead.

What is the reason that you need to change the name of the socket?
1.3.0 is scheduled for next week


Shalom-Salam,

   Werner





From gnutls-dev at mlists.thewrittenword.com  Sat Apr 28 18:04:26 2007
From: gnutls-dev at mlists.thewrittenword.com (Peter O'Gorman)
Date: Sat, 28 Apr 2007 11:04:26 -0500
Subject: [gnutls-dev] set random seed file via gnutls api
Message-ID: <20070428160426.GI8893@localhost.localdomain>

[resending from the subscribed address - sorry]

On Sat, Apr 28, 2007 at 10:57:40AM +0200, Werner Koch wrote:
> On Sat, 28 Apr 2007 02:10, gnutls-dev at mlists.thewrittenword.com said:
> 
> > Looks like I misread the gcrypt options, there is no current API for
> > changing the egd socket. Sorry. I am hopeful that something will be
> > added to the next major release of libgcrypt, if so we will come back
> > with a patch for GnuTLS.
> 
> You can change the socket used for EGD with a configure option.  Since
> early GnuPG times, the suggestion has always been to use a symlink
> instead.
> 
> What is the reason that you need to change the name of the socket?
> 1.3.0 is scheduled for next week

We use the configure option to set the socket to a path under /var,
only the superuser can start prngd with the egd socket at that path.
If prngd is not running, curl does not work, libgcrypt calls exit(2),
the user is unable to download even http:// urls. 

We patched curl locally to delay init of gnutls, so stuff like `curl
--version' does not cause gcrypt to call exit(2), but we'd still like
users without privs to be able to download https:// urls without the
egd socket at the configured path. An ordinary user can start prngd
using a different path and can then use curl's --egd-file option to
point curl (and from there gnutls and gcrypt) at this socket, thus
allowing them to download https:// urls.

I posted a patch to gcrypt-devel.

Is there some reason that you consider this a bad idea?

Peter





From simon at josefsson.org  Sun Apr 29 10:06:18 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 29 Apr 2007 10:06:18 +0200
Subject: [gnutls-dev] set random seed file via gnutls api
In-Reply-To: <20070428001055.GA8893@localhost.localdomain> (Peter O'Gorman's
	message of "Fri\, 27 Apr 2007 19\:10\:55 -0500")
References: <20070426160215.GJ13730@localhost.localdomain>
	<87ps5qrpru.fsf@mocca.josefsson.org>
	<20070428001055.GA8893@localhost.localdomain>
Message-ID: <87fy6jpptx.fsf@mocca.josefsson.org>

"Peter O'Gorman" <gnutls-dev at mlists.thewrittenword.com> writes:

> On Fri, Apr 27, 2007 at 02:00:05PM +0200, Simon Josefsson wrote:
>> "Peter O'Gorman" <gnutls-dev at mlists.thewrittenword.com> writes:
>> 
>> > Should curl be using the libgcrypt api directly to avoid this? Or
>> > ought there be a way to set the random file via gnutls? We're thinking
>> > the latter.
>> 
>> Yes, if libgcrypt used by GnuTLS needs help to find a random seed file
>> to work properly, it seems it would make sense for GnuTLS to provide an
>> API to set it.
>
> Looks like I misread the gcrypt options, there is no current API for
> changing the egd socket. Sorry. I am hopeful that something will be
> added to the next major release of libgcrypt, if so we will come back
> with a patch for GnuTLS.

I noticed your libgcrypt patch.  Thanks for working on it.

/Simon



From wk at gnupg.org  Mon Apr 30 15:30:59 2007
From: wk at gnupg.org (Werner Koch)
Date: Mon, 30 Apr 2007 15:30:59 +0200
Subject: [gnutls-dev] set random seed file via gnutls api
In-Reply-To: <20070428160426.GI8893@localhost.localdomain> (Peter O'Gorman's
	message of "Sat\, 28 Apr 2007 11\:04\:26 -0500")
References: <20070428160426.GI8893@localhost.localdomain>
Message-ID: <877iruf0q4.fsf@wheatstone.g10code.de>

On Sat, 28 Apr 2007 18:04, gnutls-dev at mlists.thewrittenword.com said:

> I posted a patch to gcrypt-devel.
>
> Is there some reason that you consider this a bad idea?

No.  I will include this in libgcrypt 1.3.


Shalom-Salam,

   Werner




From gnutls-dev at mlists.thewrittenword.com  Mon Apr 30 16:58:58 2007
From: gnutls-dev at mlists.thewrittenword.com (Peter O'Gorman)
Date: Mon, 30 Apr 2007 09:58:58 -0500
Subject: [gnutls-dev] set random seed file via gnutls api
In-Reply-To: <877iruf0q4.fsf@wheatstone.g10code.de>
References: <20070428160426.GI8893@localhost.localdomain>
	<877iruf0q4.fsf@wheatstone.g10code.de>
Message-ID: <20070430145858.GL8893@localhost.localdomain>

On Mon, Apr 30, 2007 at 03:30:59PM +0200, Werner Koch wrote:
> On Sat, 28 Apr 2007 18:04, gnutls-dev at mlists.thewrittenword.com said:
> 
> > I posted a patch to gcrypt-devel.
> >
> > Is there some reason that you consider this a bad idea?
> 
> No.  I will include this in libgcrypt 1.3.

Thank you!

Peter