From fweimer at bfk.de  Mon Sep  3 17:44:00 2007
From: fweimer at bfk.de (Florian Weimer)
Date: Mon, 03 Sep 2007 17:44:00 +0200
Subject: [Help-gnutls] gnutls_x509_privkey_export_pkcs8 failure with
	GNUTLS_PKCS_USE_PBES2_3DES
Message-ID: <82r6lfvjnj.fsf@mid.bfk.de>

The following call (which maps straight to the C API) fails with
GNUTLS_E_ENCRYPTION_FAILED:

    my $pkcs8 = $key->export_pkcs8(GNUTLS_X509_FMT_PEM, "huhu",
                                   GNUTLS_PKCS_USE_PBES2_3DES);

With the GNUTLS_PKCS_USE_PKCS12_3DES flag, it works.  Is a special
format for the password required if the GNUTLS_PKCS_USE_PBES2_3DES
mode is used?

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99




From simon at josefsson.org  Tue Sep  4 09:44:55 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 04 Sep 2007 09:44:55 +0200
Subject: [Help-gnutls] GnuTLS 2.0.0
Message-ID: <87myw2an7s.fsf@mocca.josefsson.org>

We are pleased to announce a new stable GnuTLS release: Version 2.0.0.

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and comes with a binary installer for Windows.

The core GnuTLS library is distribute under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
libraries -- which contains OpenPGP and TLS/IA support, LZO2
compression, the OpenSSL compatibility library -- and the self tests and
command line tools are distributed under the GNU General Public License
version 2.0 (or later).  The manual is distributed under the GNU Free
Documentation License version 1.2 (or later).

The project page of the library is available at:
  http://www.gnutls.org/
  http://www.gnu.org/software/gnutls/
  http://josefsson.org/gnutls/

What's New
==========

The following changes have been made since GnuTLS 1.6:

* Support for external RSA/DSA signing for TLS client authentication.
  This allows you to secure the private key better, for example by using
  privilege-separation techniques between the private key and the
  network client/server.

* Support for signing X.509 certificates using RSA with SHA-256/384/512.

* Experimental support for TLS 1.2 (disabled by default).  The TLS 1.2
  specification is not finalized yet, but we implement a draft version
  for testing.

* Support for X.509 Proxy Certificates (RFC 3820)

* Support for Supplemental handshakes messages (RFC 4680).

* Support for TLS authorization extension (draft-housley-tls-authz-extns-07).

* Support for the X.509 'otherName' Subject Altnerative Names (for XMPP).

* Guile bindings for GnuTLS have been added, thanks to Ludovic Court?s.

* Improve logic of gnutls_set_default_priority() which can now be more
  recommended.

* New APIs to enumerate supported algorithms in the library.

* New APIs to access X.509 Certificate extension sequentially.

* New APIs to print X.509 Certificates and CRLs in human readable formats.

* New APIs to extract X.509 Distinguished Names from certificates.

* New APIs to handle pathLenConstraint in X.509 Basic Constraints.

* Certtool can export more than one certificate to PKCS#12.

* Several message translation improvements.

* Instructions and improvements to easily set up a HTTPS test server.

* Included copies updated to Libtasn1 1.1 and OpenCDK 0.6.4.

* Build improvements for Windows, Mac OS X, uClinux, etc.

* GnuTLS is now developed in GIT.

* Improved manual

* Many bugfixes and minor improvements.

Getting the Software
====================

GnuTLS may be downloaded from one of the mirror sites or direct from
<ftp://ftp.gnutls.org/pub/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.  Note, that GnuPG is
not available at ftp.gnu.org.

Here are the BZIP2 compressed sources (4.6MB):

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.0.0.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-2.0.0.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.0.0.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-2.0.0.tar.bz2.sig

Note, that we don't distribute gzip compressed tarballs.

In order to check that the version of GnuTLS which you are going to
install is an original and unmodified one, you should verify the OpenPGP
signature.  You can use the command

     gpg --verify gnutls-2.0.0.tar.bz2.sig

This checks whether the signature file matches the source file.  You
should see a message indicating that the signature is good and made by
that signing key.  Make sure that you have the right key, either by
checking the fingerprint of that key with other sources or by checking
that the key has been signed by a trustworthy other key.  The signing
key can be identified with the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2008-06-30]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2008-06-30]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Alternatively, after successfully verifying the OpenPGP signature of
this announcement, you could verify that the files match the following
checksum values.  The values are for SHA-1 and SHA-224 respectively:

985d86cb942b9d79abb5c8966439f23141ad803a  gnutls-2.0.0.tar.bz2

9ffe06f0fea815daaf975e39cfa0be38edc74dc8908c05a6870dede0  gnutls-2.0.0.tar.bz2

Documentation
=============

The manual is available online at:

  http://www.gnu.org/software/gnutls/documentation.html

In particular the following formats are available:

 HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html
 PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf

For developers there is a GnuTLS API reference manual formatted using
the GTK-DOC tools:

  http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html

Community
=========

If you need help to use GnuTLS, or want to help others, you are invited
to join our help-gnutls mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-gnutls>.

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-dev mailing list, see:
<http://lists.gnupg.org/mailman/listinfo/gnutls-dev>.

Windows installer
=================

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer consists
of libgpg-error 1.5, libgcrypt 1.3.0, libtasn1 1.1, opencdk 0.6.4, and
GnuTLS 2.0.0.

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.0.0.exe (24MB)
  http://josefsson.org/gnutls4win/gnutls-2.0.0.exe.sig

The checksum values for SHA-1 and SHA-224 are:

0261c116f3abdf179c0a93d04488f06b693a128a  gnutls-2.0.0.exe

d8af39cb1bcecd5c8dc9386c68edb171a20720c88e53f5443abd0bbb  gnutls-2.0.0.exe

Internationalization
====================

GnuTLS messages have been translated into German, Malay, Polish and
Swedish.  We welcome the addition of more translations.

Support
=======

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.

The GnuTLS service directory is available at:

  http://www.gnu.org/software/gnutls/commercial.html

Happy Hacking,
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/20070904/c82b4294/attachment.pgp>

From simon at josefsson.org  Thu Sep  6 13:49:25 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 06 Sep 2007 13:49:25 +0200
Subject: [Help-gnutls] Re: gnutls_x509_privkey_export_pkcs8 failure with
	GNUTLS_PKCS_USE_PBES2_3DES
In-Reply-To: <82r6lfvjnj.fsf@mid.bfk.de> (Florian Weimer's message of "Mon, 03
	Sep 2007 17:44:00 +0200")
References: <82r6lfvjnj.fsf@mid.bfk.de>
Message-ID: <87hcm8nhdm.fsf@mocca.josefsson.org>

Florian Weimer <fweimer at bfk.de> writes:

> The following call (which maps straight to the C API) fails with
> GNUTLS_E_ENCRYPTION_FAILED:
>
>     my $pkcs8 = $key->export_pkcs8(GNUTLS_X509_FMT_PEM, "huhu",
>                                    GNUTLS_PKCS_USE_PBES2_3DES);
>
> With the GNUTLS_PKCS_USE_PKCS12_3DES flag, it works.  Is a special
> format for the password required if the GNUTLS_PKCS_USE_PBES2_3DES
> mode is used?

No, I don't think so.  Maybe the PBES2 approach is buggy.  Could you
debug further why it fails?

/Simon




From fweimer at bfk.de  Thu Sep  6 14:09:26 2007
From: fweimer at bfk.de (Florian Weimer)
Date: Thu, 06 Sep 2007 14:09:26 +0200
Subject: [Help-gnutls] Re: gnutls_x509_privkey_export_pkcs8 failure with
	GNUTLS_PKCS_USE_PBES2_3DES
In-Reply-To: <87hcm8nhdm.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 06 Sep 2007 13:49:25 +0200")
References: <82r6lfvjnj.fsf@mid.bfk.de> <87hcm8nhdm.fsf@mocca.josefsson.org>
Message-ID: <82sl5sov0p.fsf@mid.bfk.de>

* Simon Josefsson:

>> With the GNUTLS_PKCS_USE_PKCS12_3DES flag, it works.  Is a special
>> format for the password required if the GNUTLS_PKCS_USE_PBES2_3DES
>> mode is used?
>
> No, I don't think so.  Maybe the PBES2 approach is buggy.  Could you
> debug further why it fails?

It seems to me that the enc_params argument to generate_key is not
properly initialized.  From the beginning of generate_key:

  /* We should use the flags here to use different
   * encryption algorithms etc. 
   */

  if (schema == PKCS12_ARCFOUR_SHA1)
    enc_params->cipher = GNUTLS_CIPHER_ARCFOUR_128;
  else if (schema == PKCS12_3DES_SHA1)
    enc_params->cipher = GNUTLS_CIPHER_3DES_CBC;
  else if (schema == PKCS12_RC2_40_SHA1)
    enc_params->cipher = GNUTLS_CIPHER_RC2_40_CBC;

schema is PBES2 in this case, and enc_params has not been filled by
the caller.  valgrind complains as well:

==8411== Conditional jump or move depends on uninitialised value(s)
==8411==    at 0x479AB24: gnutls_cipher_get_key_size (gnutls_algorithms.c:739)
==8411==    by 0x47D3DDB: generate_key (privkey_pkcs8.c:1630)
==8411==    by 0x47D7114: gnutls_x509_privkey_export_pkcs8 (privkey_pkcs8.c:345)
==8411==    by 0x4763EE1: XS_Crypt__GNUTLS__X509Privkey_export_pkcs8 (GNUTLS.xs:1108)
==8411==    by 0x80BDAD0: Perl_pp_entersub (in /usr/bin/perl)
==8411==    by 0x80BC3A8: Perl_runops_standard (in /usr/bin/perl)
==8411==    by 0x8063A1A: perl_run (in /usr/bin/perl)
==8411==    by 0x805FFD0: main (in /usr/bin/perl)

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99




From mahesh.nayak at gmail.com  Wed Sep 12 17:45:28 2007
From: mahesh.nayak at gmail.com (Mahesh Nayak)
Date: Wed, 12 Sep 2007 10:45:28 -0500
Subject: [Help-gnutls] Encoding of Subject Alternative Name having
	GNUTLS_SAN_IPADDRESS as data type.
In-Reply-To: <b1f9f3790709120840x45d63910u6426206cac2c1eee@mail.gmail.com>
References: <b1f9f3790709120840x45d63910u6426206cac2c1eee@mail.gmail.com>
Message-ID: <b1f9f3790709120845p32b03d37k66d2fa429a813106@mail.gmail.com>

Hello,

I was trying to use the GNUTLS_SAN_IPADDRESS type for the API
gnutls_x509_crt_set_subject_alternative_name( ).

I notice that when a  X509v3 Certificate is created using certool API,
the IP ADDRESS field in the  packet is not being parsed by the openssl
or XCA tool (OpenSSL shows the field  as invalid). On further
investigation, I got the following percept from the RFC  2459 ( for
x509):

RFC 2459        Internet X.509 Public Key Infrastructure    January  1999
"
When the subjectAltName extension contains a iPAddress, the address
MUST be stored in the octet string in "network byte order," as
specified in  RFC 791 [RFC 791]. The least significant bit (LSB) of
each octet is the LSB of  the corresponding byte in the network
address. For IP Version 4, as specified in  RFC 791, the octet string
MUST contain exactly four octets. "

But I see  from the GNUTLS and CERTTOOL source code that we never
convert the char* to a  network-byte-ordered-octet (for the IPADDRESS)
(I traced from  gnutls_x509_crt_set_subject_alternative_name in the
gnutls source code) . We  just go ahead with encoding the char* data
in the certificate.

Is there  something that I am missing? Or is it a bug?

If yes, could you please  tell me an alternative method to have an IP address in
the subject  alternative name?

Any help here is very valuable to me and is  appreciated.

Thanks,
Mahesh.




From martine at danga.com  Mon Sep 17 07:19:31 2007
From: martine at danga.com (Evan Martin)
Date: Sun, 16 Sep 2007 22:19:31 -0700
Subject: [Help-gnutls] windows startup still slow -- what to do?
Message-ID: <3a6f89fc0709162219h560f607bsb8507012d84337dd@mail.gmail.com>

Hello,
I've been [reluctantly] porting some software from Linux to Windows
and I was happy to discover that GnuTLS had a nice Windows installer.
After getting things mostly working, I started looking into why
startup was so slow and discovered that gnutls_global_init() takes
maybe five seconds to run on this machine.  (Laptop, "Core Duo T2400 @
1.83GHz" says the System control panel.)

I've read over the old threads on this phenomenon, so I appreciate
that the problem is at least known.  My questions are:

- Is this something that's likely to be ever fixed?  If so, can I help out?

- Otherwise, what's the best way to temporarily work around this?
(http://josefsson.org/gnutls4win/ links to
http://www.securitypunk.com/libgcrypt/ but that site appears to be
down.)  I suppose I can deal with a very slow startup on Windows with
the final release, but while I'm debugging it's killing me to have to
wait each time I run...




From simon at josefsson.org  Tue Sep 18 10:12:45 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 18 Sep 2007 10:12:45 +0200
Subject: [Help-gnutls] Re: windows startup still slow -- what to do?
In-Reply-To: <3a6f89fc0709162219h560f607bsb8507012d84337dd@mail.gmail.com>
	(Evan Martin's message of "Sun, 16 Sep 2007 22:19:31 -0700")
References: <3a6f89fc0709162219h560f607bsb8507012d84337dd@mail.gmail.com>
Message-ID: <87fy1cjssi.fsf@mocca.josefsson.org>

"Evan Martin" <martine at danga.com> writes:

> Hello,
> I've been [reluctantly] porting some software from Linux to Windows
> and I was happy to discover that GnuTLS had a nice Windows installer.
> After getting things mostly working, I started looking into why
> startup was so slow and discovered that gnutls_global_init() takes
> maybe five seconds to run on this machine.  (Laptop, "Core Duo T2400 @
> 1.83GHz" says the System control panel.)

Hi!  Thanks for feedback, the culprit here is actually libgcrypt.

> I've read over the old threads on this phenomenon, so I appreciate
> that the problem is at least known.  My questions are:
>
> - Is this something that's likely to be ever fixed?  If so, can I help out?

The problem is that libgcrypt is slow to gather entropy under Windows,
and that should very much be fixable if someone sits down and work on
it.  The reason this has probably taken so long is that it is easy to
make the code faster, but difficult to maintain security.  So I think
the patches that have been proposed so far simply do not lead to the
same amount of entropy being available.  That's bad, and such patches
are not likely to be accepted by the libgcrypt folks.

> - Otherwise, what's the best way to temporarily work around this?
> (http://josefsson.org/gnutls4win/ links to
> http://www.securitypunk.com/libgcrypt/ but that site appears to be
> down.)

Maybe some web archive site still carry their patch and pre-built DLL...
however, I think it is unclear whether their patch leads to the same
amount of good entropy, that's why it hasn't been approved.

> I suppose I can deal with a very slow startup on Windows with the
> final release, but while I'm debugging it's killing me to have to wait
> each time I run...

I think you can tell libgcrypt to not bother gathering entropy, by:

      gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);

There is some ordering issue here, and I don't recall whether you need
to call that before or after you initialize libgcrypt (via
gnutls_global_init).

Does this work?  If so, I'll add it to the GnuTLS4Win page, it may help
others in your situation.

/Simon




From mahesh.nayak at mgl.com  Tue Sep 18 15:30:36 2007
From: mahesh.nayak at mgl.com (Mahesh M. Nayak)
Date: Tue, 18 Sep 2007 19:00:36 +0530
Subject: [Help-gnutls] Re: windows startup still slow -- what to do?
References: <3a6f89fc0709162219h560f607bsb8507012d84337dd@mail.gmail.com>
	<87fy1cjssi.fsf@mocca.josefsson.org>
Message-ID: <F64DB44E775AF447888644BA91A736341DB4AF@mglblrmail.blr.mgl.com>

 " gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0); "  works on Linux. I gave it after the gnutls_global_init(). But then I am not sure whether it would work if it is given before the init function call. The gcry_control () should also be listed in the Linux PDF manual. I had trouble finding this API. After using this function, definitely there wont be any delay during random number generation and it works awesome!
 
Mahesh

________________________________

From: help-gnutls-bounces+mahesh.nayak=mgl.com at gnu.org on behalf of Simon Josefsson
Sent: Tue 9/18/2007 1:42 PM
To: Evan Martin
Cc: help-gnutls at gnu.org
Subject: [Help-gnutls] Re: windows startup still slow -- what to do?



"Evan Martin" <martine at danga.com> writes:

> Hello,
> I've been [reluctantly] porting some software from Linux to Windows
> and I was happy to discover that GnuTLS had a nice Windows installer.
> After getting things mostly working, I started looking into why
> startup was so slow and discovered that gnutls_global_init() takes
> maybe five seconds to run on this machine.  (Laptop, "Core Duo T2400 @
> 1.83GHz" says the System control panel.)

Hi!  Thanks for feedback, the culprit here is actually libgcrypt.

> I've read over the old threads on this phenomenon, so I appreciate
> that the problem is at least known.  My questions are:
>
> - Is this something that's likely to be ever fixed?  If so, can I help out?

The problem is that libgcrypt is slow to gather entropy under Windows,
and that should very much be fixable if someone sits down and work on
it.  The reason this has probably taken so long is that it is easy to
make the code faster, but difficult to maintain security.  So I think
the patches that have been proposed so far simply do not lead to the
same amount of entropy being available.  That's bad, and such patches
are not likely to be accepted by the libgcrypt folks.

> - Otherwise, what's the best way to temporarily work around this?
> (http://josefsson.org/gnutls4win/ links to
> http://www.securitypunk.com/libgcrypt/ but that site appears to be
> down.)

Maybe some web archive site still carry their patch and pre-built DLL...
however, I think it is unclear whether their patch leads to the same
amount of good entropy, that's why it hasn't been approved.

> I suppose I can deal with a very slow startup on Windows with the
> final release, but while I'm debugging it's killing me to have to wait
> each time I run...

I think you can tell libgcrypt to not bother gathering entropy, by:

      gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);

There is some ordering issue here, and I don't recall whether you need
to call that before or after you initialize libgcrypt (via
gnutls_global_init).

Does this work?  If so, I'll add it to the GnuTLS4Win page, it may help
others in your situation.

/Simon


_______________________________________________
Help-gnutls mailing list
Help-gnutls at gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnutls


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20070918/e656306a/attachment.htm>

From simon at josefsson.org  Thu Sep 20 14:16:47 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 20 Sep 2007 14:16:47 +0200
Subject: [Help-gnutls] GnuTLS 2.0.1
Message-ID: <87bqbxsf9s.fsf@mocca.josefsson.org>

We are pleased to announce a new stable GnuTLS release: Version 2.0.1.

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and comes with a binary installer for Windows.

The core GnuTLS library is distribute under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
libraries -- which contains OpenPGP and TLS/IA support, LZO2
compression, the OpenSSL compatibility library -- and the self tests and
command line tools are distributed under the GNU General Public License
version 2.0 (or later).  The manual is distributed under the GNU Free
Documentation License version 1.2 (or later).

The project page of the library is available at:
  http://www.gnutls.org/
  http://www.gnu.org/software/gnutls/
  http://josefsson.org/gnutls/

What's New
==========

The following changes have been made since GnuTLS 2.0.0:

** New directory doc/credentials/ with test credentials.
This collects the test credentials from the web page and from src/.
The script gnutls-http-serv has also been moved to that directory.

** Update SRP extension type and cipher suite with official IANA values.
This breaks backwards compatibility with SRP in older versions of
GnuTLS, but this is intentional to speed up the adoption of the
official values.  The old values we used were incorrect.

** Guile: Fix `x509-certificate-dn-oid'

** API and ABI modifications:
No changes since last version.

Getting the Software
====================

GnuTLS may be downloaded from one of the mirror sites or direct from
<ftp://ftp.gnutls.org/pub/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.  Note, that GnuPG is
not available at ftp.gnu.org.

Here are the BZIP2 compressed sources (4.7MB):

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.0.1.tar.bz2
  http://josefsson.org/gnutls/releases/gnutls-2.0.1.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.0.1.tar.bz2.sig
  http://josefsson.org/gnutls/releases/gnutls-2.0.1.tar.bz2.sig

Note, that we don't distribute gzip compressed tarballs.

In order to check that the version of GnuTLS which you are going to
install is an original and unmodified one, you should verify the OpenPGP
signature.  You can use the command

     gpg --verify gnutls-2.0.1.tar.bz2.sig

This checks whether the signature file matches the source file.  You
should see a message indicating that the signature is good and made by
that signing key.  Make sure that you have the right key, either by
checking the fingerprint of that key with other sources or by checking
that the key has been signed by a trustworthy other key.  The signing
key can be identified with the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2008-06-30]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2008-06-30]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Alternatively, after successfully verifying the OpenPGP signature of
this announcement, you could verify that the files match the following
checksum values.  The values are for SHA-1 and SHA-224 respectively:

2e5cee3021a9f8f62e4fa90c9d67f8d448dbbfcf  gnutls-2.0.1.tar.bz2

b31ae61e0452fdc1a3c9c014857daf98d1a735c3cf04b7842925cf09  gnutls-2.0.1.tar.bz2

Documentation
=============

The manual is available online at:

  http://www.gnu.org/software/gnutls/documentation.html

In particular the following formats are available:

 HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html
 PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf

For developers there is a GnuTLS API reference manual formatted using
the GTK-DOC tools:

  http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html

Community
=========

If you need help to use GnuTLS, or want to help others, you are invited
to join our help-gnutls mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-gnutls>.

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-dev mailing list, see:
<http://lists.gnupg.org/mailman/listinfo/gnutls-dev>.

Windows installer
=================

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer consists
of libgpg-error 1.5, libgcrypt 1.3.0, libtasn1 1.1, opencdk 0.6.4, and
GnuTLS 2.0.0.

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

Internationalization
====================

GnuTLS messages have been translated into German, Malay, Polish and
Swedish.  We welcome the addition of more translations.

Support
=======

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.

The GnuTLS service directory is available at:

  http://www.gnu.org/software/gnutls/commercial.html

Happy Hacking,
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/20070920/d7885df0/attachment.pgp>

From elmex at x-paste.de  Tue Sep 25 23:48:29 2007
From: elmex at x-paste.de (Robin Redeker)
Date: Tue, 25 Sep 2007 23:48:29 +0200
Subject: [Help-gnutls] push/pull functions
Message-ID: <20070925214829.GA27755@elmex>

Hi!

I have a (maybe not so?) simple question:

Can I call gnutls_record_recv/gnutls_record_send safely while I'm in a
push/pull callback?

The reason I'm asking is that I want to make bindings for GNU Smalltalk,
which has support for non-preemtive multiple threads of execution.

So, my quesion is, can I, while one of those threads might be blocked in
a pull call (which fetches bytes from a Smalltalk stream) safely call
gnutls_record_recv and gnutls_record_send?

What if some kind of re-handshake happens while I call
gnutls_record_recv? Will GnuTLS detect that it is still waiting for the
callback to read to return?

This seems to be the easiest way to implement it in the bindings for GNU
Smalltalk. If I can't do this safely I'll require to keep book on who is
waiting in which callback or I have to do other things that don't feel
right.

Having a function that feeds in data to GnuTLS in the first place and
callbacks for the recv/send functions instead would feel waaay better.

I've looked shortly at the gnutls code. It didn't look suspicious to me,
but I'm not very familiar with it too. Maybe someone can shed some light
on this?

And there is also another issue I stepped over while testing. I somehow
could't get the anonymous client example to work with gnutls-serv.

I've tried running the server with:
   gnutls-serv -p 12331 --kx "Anon DH"
   gnutls-serv -p 12331 --kx "Anon DH" -g
   gnutls-serv -p 12331 --kx "Anon DH" --dhparams /tmp/dh.pem (with a
   properly initialized dh.pem)

And I tried running my own implementation and gnutls-cli against it.
But nothing seems to work.

I'm using version 1.7.19-1 (debian package libgnutls13) and I also
downloaded gnutls-2.1.1 and compiled it myself and tried the interaction
between gnutls-serv/gnutls-cli.

All tries seem to lead to the same result:

   ~# /opt/gnutls/bin/gnutls-serv -p 12331 --kx "Anon DH" -g
   Generating temporary RSA parameters. Please wait...
   Generating Diffie Hellman parameters [768]. Please wait...
   Echo Server ready. Listening to port '12331'.

   Error in handshake
   Error: Insufficient credentials for that request.

Meanwhile on the cli side:

   ~# /opt/gnutls/bin/gnutls-cli -p 12331 localhost
   Resolving 'localhost'...
   Connecting to '127.0.0.1:12331'...
   *** Fatal error: A TLS fatal alert has been received.
   *** Received alert [40]: Handshake failed
   *** Handshake has failed
   GNUTLS ERROR: A TLS fatal alert has been received.

(I also tried appending --kx "Anon DH" to the -cli, no effect)

I've tried to google for the problem, but couldn't find a resolution for
that.


Thanks!

Robin




From nmav at gnutls.org  Wed Sep 26 10:08:02 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 26 Sep 2007 11:08:02 +0300
Subject: [Help-gnutls] push/pull functions
In-Reply-To: <20070925214829.GA27755@elmex>
References: <20070925214829.GA27755@elmex>
Message-ID: <200709261108.03100.nmav@gnutls.org>

On Wednesday 26 September 2007, Robin Redeker wrote:
> Hi!

> I have a (maybe not so?) simple question:
> Can I call gnutls_record_recv/gnutls_record_send safely while I'm in a
> push/pull callback?

As long as you don't use the same session, it should be safe.

> The reason I'm asking is that I want to make bindings for GNU Smalltalk,
> which has support for non-preemtive multiple threads of execution.

gnutls can be used with multiple threads, as long as the gcrypt callbacks are 
set and the same session is not accessed by multiple threads.

> What if some kind of re-handshake happens while I call
> gnutls_record_recv? Will GnuTLS detect that it is still waiting for the
> callback to read to return?

A rehandshake will be detected by the return value of gnutls_record_recv(). It 
is in-band data so it should procceed normally.

> And there is also another issue I stepped over while testing. I somehow
> could't get the anonymous client example to work with gnutls-serv.
> I've tried running the server with:
>    gnutls-serv -p 12331 --kx "Anon DH"
>    gnutls-serv -p 12331 --kx "Anon DH" -g
>    gnutls-serv -p 12331 --kx "Anon DH" --dhparams /tmp/dh.pem (with a
>    properly initialized dh.pem)

Thank you for reporting this. It seems that it was a bug in the handshake 
function and couldn't negotiate anonymous DH if a certificate wasn't set. It 
must be corrected in the git repository (and attached patch).


regards,
Nikos
-------------- next part --------------
diff --git a/lib/gnutls_handshake.c b/lib/gnutls_handshake.c
index f8d2724..3787796 100644
--- a/lib/gnutls_handshake.c
+++ b/lib/gnutls_handshake.c
@@ -2801,11 +2801,11 @@ _gnutls_remove_unwanted_ciphersuites (gnutls_session_t session,
   int ret = 0;
   cipher_suite_st *newSuite, cs;
   int newSuiteSize = 0, i;
-  gnutls_certificate_credentials_t x509_cred;
+  gnutls_certificate_credentials_t cert_cred;
   gnutls_kx_algorithm_t kx;
   int server = session->security_parameters.entity == GNUTLS_SERVER ? 1 : 0;
-  gnutls_kx_algorithm_t *alg;
-  int alg_size;
+  gnutls_kx_algorithm_t *alg = NULL;
+  int alg_size = 0;
 
   /* if we should use a specific certificate, 
    * we should remove all algorithms that are not supported
@@ -2813,29 +2813,30 @@ _gnutls_remove_unwanted_ciphersuites (gnutls_session_t session,
    * method (CERTIFICATE).
    */
 
-  x509_cred =
+  cert_cred =
     (gnutls_certificate_credentials_t) _gnutls_get_cred (session->key,
 							 GNUTLS_CRD_CERTIFICATE,
 							 NULL);
 
-  /* if x509_cred==NULL we should remove all X509 ciphersuites
+  /* If there are certificate credentials, find an appropriate certificate
+   * or disable them;
    */
-
   if (session->security_parameters.entity == GNUTLS_SERVER
-      && x509_cred != NULL)
+      && cert_cred != NULL)
     {
       ret = _gnutls_server_select_cert (session, requested_pk_algo);
       if (ret < 0)
 	{
 	  gnutls_assert ();
-	  return ret;
+	  _gnutls_x509_log("Could not find an appropriate certificate: %s\n", gnutls_strerror(ret));
+	  cert_cred = NULL;
 	}
     }
 
   /* get all the key exchange algorithms that are 
    * supported by the X509 certificate parameters.
    */
-  if ((ret =
+  if (cert_cred != NULL && (ret =
        _gnutls_selected_cert_supported_kx (session, &alg, &alg_size)) < 0)
     {
       gnutls_assert ();

From elmex at x-paste.de  Wed Sep 26 11:11:12 2007
From: elmex at x-paste.de (Robin Redeker)
Date: Wed, 26 Sep 2007 11:11:12 +0200
Subject: [Help-gnutls] push/pull functions
In-Reply-To: <200709261108.03100.nmav@gnutls.org>
References: <20070925214829.GA27755@elmex> <200709261108.03100.nmav@gnutls.org>
Message-ID: <20070926091112.GA11114@elmex>

On Wed, Sep 26, 2007 at 11:08:02AM +0300, Nikos Mavrogiannopoulos wrote:
> On Wednesday 26 September 2007, Robin Redeker wrote:
> > Hi!
> 
> > I have a (maybe not so?) simple question:
> > Can I call gnutls_record_recv/gnutls_record_send safely while I'm in a
> > push/pull callback?
> 
> As long as you don't use the same session, it should be safe.
> 
> > The reason I'm asking is that I want to make bindings for GNU Smalltalk,
> > which has support for non-preemtive multiple threads of execution.
> 
> gnutls can be used with multiple threads, as long as the gcrypt callbacks are 
> set and the same session is not accessed by multiple threads.

Well, usually you have a writer and a reader thread per session. Will
those interfere?  Or does it mean that I'll have to use non-blocking I/O
semantics to ensure that there are not two threads doing a recv and send
at the same time?

Also the threads in smalltalk are not "real" OS level processes, they
are much more Coroutines than something else.

Mostly it will look like this: one thread waits for new data with a
read(2), usually the smalltalk core does a select() and execute other
pseudo-threads while the reading thread is suspended. In one of the
other threads someone uses gnutls_record_send to send something.

And I wonder whether that _send somehow will interfere with the still
waiting reader (which means the thread of execution for the reader is
still blocked in the pull callback).

There certainly wont be a recursive call to gnutls_record_recv from any
other thread than the reader thread.

I hope you understand what I mean from that explanation. Please ask if
it was not clear.


I've looked at the source of gnutls, and the writing and reading seems
to be mostly seperate from what I've seen. I'm just wondering whether a
gnutls_record_send () maybe somehow will invoke a read operation which
then calls yet another pull-callback (while some other thread already
has a pull-callback on hold).

> > What if some kind of re-handshake happens while I call
> > gnutls_record_recv? Will GnuTLS detect that it is still waiting for the
> > callback to read to return?
> 
> A rehandshake will be detected by the return value of gnutls_record_recv(). It 
> is in-band data so it should procceed normally.

Ah, ok.

> > And there is also another issue I stepped over while testing. I somehow
> > could't get the anonymous client example to work with gnutls-serv.
> > I've tried running the server with:
> >    gnutls-serv -p 12331 --kx "Anon DH"
> >    gnutls-serv -p 12331 --kx "Anon DH" -g
> >    gnutls-serv -p 12331 --kx "Anon DH" --dhparams /tmp/dh.pem (with a
> >    properly initialized dh.pem)
> 
> Thank you for reporting this. It seems that it was a bug in the handshake 
> function and couldn't negotiate anonymous DH if a certificate wasn't set. It 
> must be corrected in the git repository (and attached patch).

Yes, the patch fixes it. Thanks!


And thanks for the quick response!


Robin




From nmav at gnutls.org  Wed Sep 26 12:11:26 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 26 Sep 2007 13:11:26 +0300
Subject: [Help-gnutls] push/pull functions
In-Reply-To: <20070926091112.GA11114@elmex>
References: <20070925214829.GA27755@elmex> <200709261108.03100.nmav@gnutls.org>
	<20070926091112.GA11114@elmex>
Message-ID: <200709261311.26959.nmav@gnutls.org>

On Wednesday 26 September 2007, Robin Redeker wrote:

> > > I have a (maybe not so?) simple question:
> > > Can I call gnutls_record_recv/gnutls_record_send safely while I'm in a
> > > push/pull callback?
> > As long as you don't use the same session, it should be safe.
> > > The reason I'm asking is that I want to make bindings for GNU
> > > Smalltalk, which has support for non-preemtive multiple threads of
> > > execution.
> > gnutls can be used with multiple threads, as long as the gcrypt callbacks
> > are set and the same session is not accessed by multiple threads.
> Well, usually you have a writer and a reader thread per session. Will
> those interfere?  Or does it mean that I'll have to use non-blocking I/O
> semantics to ensure that there are not two threads doing a recv and send
> at the same time?

It should work. As far as I remember it is even possible to have recv and send 
from different processes (using fork).


regards,
Nikos




From elmex at x-paste.de  Wed Sep 26 12:58:35 2007
From: elmex at x-paste.de (Robin Redeker)
Date: Wed, 26 Sep 2007 12:58:35 +0200
Subject: [Help-gnutls] push/pull functions
In-Reply-To: <200709261311.26959.nmav@gnutls.org>
References: <20070925214829.GA27755@elmex> <200709261108.03100.nmav@gnutls.org>
	<20070926091112.GA11114@elmex> <200709261311.26959.nmav@gnutls.org>
Message-ID: <20070926105835.GA26886@elmex>

On Wed, Sep 26, 2007 at 01:11:26PM +0300, Nikos Mavrogiannopoulos wrote:
> On Wednesday 26 September 2007, Robin Redeker wrote:
> 
> > > > I have a (maybe not so?) simple question:
> > > > Can I call gnutls_record_recv/gnutls_record_send safely while I'm in a
> > > > push/pull callback?
> > > As long as you don't use the same session, it should be safe.
> > > > The reason I'm asking is that I want to make bindings for GNU
> > > > Smalltalk, which has support for non-preemtive multiple threads of
> > > > execution.
> > > gnutls can be used with multiple threads, as long as the gcrypt callbacks
> > > are set and the same session is not accessed by multiple threads.
> > Well, usually you have a writer and a reader thread per session. Will
> > those interfere?  Or does it mean that I'll have to use non-blocking I/O
> > semantics to ensure that there are not two threads doing a recv and send
> > at the same time?
> 
> It should work. As far as I remember it is even possible to have recv and send 
> from different processes (using fork).

That sounds great. When I tried it today morning it seemed to work fine,
good to know it's supposed to work that way.

Thanks!

Robin




From rajeev.saini at tcs.com  Thu Sep 27 12:34:50 2007
From: rajeev.saini at tcs.com (Rajeev Saini)
Date: Thu, 27 Sep 2007 16:04:50 +0530
Subject: [Help-gnutls] GNU TLS windows problem.
Message-ID: <OF887EC646.94F0CB5C-ON65257363.0039C2C9-65257363.0039D465@tcs.com>

Hi, 
We are trying to integrate GNU TLS windows library with our application 
which requires mobile to authenticate a X509 certificate with a TCP Server 
and then the communication packets between the two can start. 

My problem is that my test mobile only supports certificate in ..der 
format. 
The certtool utility in GNU TLS makes certificates in .pem format and if i 
rename this .pem format certificate to .der format then the handshaking 
between the mobile and server fails. 
My server can use the certificate in ..PEM format but my mobile can only 
use .der format certificate. 
How can i make .der format certificates using certtool (or otherwise) such 
that i can use it on my test mobile and it performs successful hanshaking 
with the TCP server(which uses .pem or .der certificate from the same 
corresponding CA). 

Thanks in advance, 
Rajeev Saini.
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20070927/59755ce8/attachment.htm>

From simon at josefsson.org  Thu Sep 27 16:00:58 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 27 Sep 2007 16:00:58 +0200
Subject: [Help-gnutls] Re: GNU TLS windows problem.
In-Reply-To: <OF887EC646.94F0CB5C-ON65257363.0039C2C9-65257363.0039D465@tcs.com>
	(Rajeev Saini's message of "Thu, 27 Sep 2007 16:04:50 +0530")
References: <OF887EC646.94F0CB5C-ON65257363.0039C2C9-65257363.0039D465@tcs.com>
Message-ID: <87abr8gqcl.fsf@mocca.josefsson.org>

Rajeev Saini <rajeev.saini at tcs.com> writes:

> Hi, 
> We are trying to integrate GNU TLS windows library with our application 
> which requires mobile to authenticate a X509 certificate with a TCP Server 
> and then the communication packets between the two can start. 
>
> My problem is that my test mobile only supports certificate in ..der 
> format. 
> The certtool utility in GNU TLS makes certificates in .pem format and if i 
> rename this .pem format certificate to .der format then the handshaking 
> between the mobile and server fails. 

Yes, the PEM format is a text representation of the DER format.

> My server can use the certificate in ..PEM format but my mobile can only 
> use .der format certificate. 
> How can i make .der format certificates using certtool (or otherwise) such 
> that i can use it on my test mobile and it performs successful hanshaking 
> with the TCP server(which uses .pem or .der certificate from the same 
> corresponding CA). 

You can use the --outder flag to certtool when generating the
certificate.

If you already have a client certificate for the mobile and want to
convert it to DER, use:

$ certtool -i --infile IN.pem  --outder --outfile OUT.der

However, this doesn't seem to work!  Mea culpa.  The output is garbled
for some reason.  Possibly the --outder flag doesn't work when
generating certificates either.  I'll see if I can debug this.

/Simon




From rajeev.saini at tcs.com  Fri Sep 28 09:47:17 2007
From: rajeev.saini at tcs.com (Rajeev Saini)
Date: Fri, 28 Sep 2007 13:17:17 +0530
Subject: [Help-gnutls] Re: GNU TLS windows problem.
In-Reply-To: <87abr8gqcl.fsf@mocca.josefsson.org>
Message-ID: <OFCE5D1F20.714DEB98-ON65257364.002A4D4A-65257364.002A7D33@tcs.com>

Hi Simon,
Thanks for the reply.
It is very important for us to convert our certificate from PEM to DER 
format such that the mobile can use it.
certtool -i --infile IN.pem  --outder --outfile OUT.der

If possible kindly provide a patch of gnutls such that the above command 
correctly generates the DER format certificate.

Regards,
Rajeev Saini

____________________________________________
Experience certainty.   IT Services
                        Business Solutions
                        Outsourcing
____________________________________________



Simon Josefsson <simon at josefsson.org> 
09/27/2007 07:30 PM

To
Rajeev Saini <rajeev.saini at tcs.com>
cc
help-gnutls at gnu.org
Subject
Re: GNU TLS windows problem.






Rajeev Saini <rajeev.saini at tcs.com> writes:

> Hi, 
> We are trying to integrate GNU TLS windows library with our application 
> which requires mobile to authenticate a X509 certificate with a TCP 
Server 
> and then the communication packets between the two can start. 
>
> My problem is that my test mobile only supports certificate in ..der 
> format. 
> The certtool utility in GNU TLS makes certificates in .pem format and if 
i 
> rename this .pem format certificate to .der format then the handshaking 
> between the mobile and server fails. 

Yes, the PEM format is a text representation of the DER format.

> My server can use the certificate in ..PEM format but my mobile can only 

> use .der format certificate. 
> How can i make .der format certificates using certtool (or otherwise) 
such 
> that i can use it on my test mobile and it performs successful 
hanshaking 
> with the TCP server(which uses .pem or .der certificate from the same 
> corresponding CA). 

You can use the --outder flag to certtool when generating the
certificate.

If you already have a client certificate for the mobile and want to
convert it to DER, use:

$ certtool -i --infile IN.pem  --outder --outfile OUT.der

However, this doesn't seem to work!  Mea culpa.  The output is garbled
for some reason.  Possibly the --outder flag doesn't work when
generating certificates either.  I'll see if I can debug this.

/Simon

ForwardSourceID:NT00006216 
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20070928/b87ffd3b/attachment.htm>