From jas at extundo.com  Sun Dec  2 21:28:01 2001
From: jas at extundo.com (Simon Josefsson)
Date: Sun Dec  2 21:28:01 2001
Subject: [gnutls-dev] API comments
Message-ID: <iluitbqv5x0.fsf@dhcp128.extundo.com>

Some comments on the API:

gnutls_read() and gnutls_write() does not seem to work as read() and
write() as the API documentation on the web page says, especially the
error codes differ.  I think it would be nice if they did work as
read() and write(), I believe both Open SSL and Mozilla NSS do that.

It was unclear to me if gnutls_bye() did anything to the socket or not
(like, e.g., calling shutdown()).  I want to be able to use the socket
after disabling TLS, sending unencrypted packets.  Possible?

Documentation in info-format would be nice. :-)

Btw, I wrote some crude Emacs Lisp bindings of GNU TLS,
http://josefsson.org/securemacs/




From nmav at hellug.gr  Sun Dec  2 21:45:01 2001
From: nmav at hellug.gr (Nikos Mavroyanopoulos)
Date: Sun Dec  2 21:45:01 2001
Subject: [gnutls-dev] API comments
In-Reply-To: <iluitbqv5x0.fsf@dhcp128.extundo.com>
References: <iluitbqv5x0.fsf@dhcp128.extundo.com>
Message-ID: <20011202223932.26266057.nmav@hellug.gr>

On Sun, 02 Dec 2001 01:09:47 +0100 Simon Josefsson <jas at extundo.com> wrote:

> gnutls_read() and gnutls_write() does not seem to work as read() and
> write() as the API documentation on the web page says, especially the
> error codes differ.  
It says that "Returns the number of bytes sent, or a negative error code.",
but it may still not be clear. What do you propose?

> I think it would be nice if they did work as
> read() and write(), I believe both Open SSL and Mozilla NSS do that.
I'm trying not to tight gnutls to berkeley style sockets, or even TCP/IP.

> It was unclear to me if gnutls_bye() did anything to the socket or not
> (like, e.g., calling shutdown()).  I want to be able to use the socket
> after disabling TLS, sending unencrypted packets.  Possible?
gnutls_bye() and any other gnutls function (except of gnutls_read()/write()),
do not call any external function such as shutdown. 
Thus in your case if the return value is zero you may continue using the connection.

> Documentation in info-format would be nice. :-)
Documentation in gnutls is in latex format. This can be
converted to several other formats. (and possibly info format but
I'm not sure)

-- 
Nikos Mavroyanopoulos
mailto:nmav at hellug.gr



From nmav at hellug.gr  Sun Dec  2 21:50:01 2001
From: nmav at hellug.gr (Nikos Mavroyanopoulos)
Date: Sun Dec  2 21:50:01 2001
Subject: [gnutls-dev] API comments
In-Reply-To: <iluitbqv5x0.fsf@dhcp128.extundo.com>
References: <iluitbqv5x0.fsf@dhcp128.extundo.com>
Message-ID: <20011202224444.366be337.nmav@hellug.gr>

On Sun, 02 Dec 2001 01:09:47 +0100 Simon Josefsson <jas at extundo.com> wrote:

> Some comments on the API:
Since you've worked with other TLS APIs I'd like to hear more
comments about the gnutls api :)

If you think some things are done better in other implementations
just say it!


-- 
Nikos Mavroyanopoulos
mailto:nmav at hellug.gr



From dimalinux at mail.ru  Mon Dec  3 11:00:01 2001
From: dimalinux at mail.ru (Dima Holodovich)
Date: Mon Dec  3 11:00:01 2001
Subject: [gnutls-dev] API comments
In-Reply-To: <20011202224444.366be337.nmav@hellug.gr>
References: <iluitbqv5x0.fsf@dhcp128.extundo.com>
 <20011202224444.366be337.nmav@hellug.gr>
Message-ID: <0GNQ00IT3LMO61@mta7.pltn13.pbi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 02 December 2001 12:44 pm, Nikos Mavroyanopoulos wrote:
> On Sun, 02 Dec 2001 01:09:47 +0100 Simon Josefsson <jas at extundo.com> wrote:
>
> If you think some things are done better in other implementations
> just say it!

I've never use Spyrus, so I don't know if their interface is good -- but
the documentation of their interface looks very nice.  Certainly worth
reading if your deciding on appropriate interfaces.

http://www.spyrus.com/content/products/Terisa/TLSGold-licensing/TLS-Gold-Developers-Guide.pdf

- - Dima
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8Cqe6ay1dBALttMcRAkECAJ9MJlhwpXGISZSl6ZqjiL2KcU6TCwCgoW7b
OjFdvkqyp4VTde56cpzjldg=
=3m0z
-----END PGP SIGNATURE-----



From nmav at hellug.gr  Mon Dec  3 11:33:01 2001
From: nmav at hellug.gr (Nikos Mavroyanopoulos)
Date: Mon Dec  3 11:33:01 2001
Subject: [gnutls-dev] API comments
In-Reply-To: <0GNQ00IT3LMO61@mta7.pltn13.pbi.net>
References: <iluitbqv5x0.fsf@dhcp128.extundo.com>
	<20011202224444.366be337.nmav@hellug.gr>
	<0GNQ00IT3LMO61@mta7.pltn13.pbi.net>
Message-ID: <20011203122731.0fdf7e5f.nmav@hellug.gr>

On Sun, 02 Dec 2001 14:14:10 -0800 Dima Holodovich <dimalinux at mail.ru> wrote:

> I've never use Spyrus, so I don't know if their interface is good -- but
> the documentation of their interface looks very nice.  Certainly worth
> reading if your deciding on appropriate interfaces.
> http://www.spyrus.com/content/products/Terisa/TLSGold-licensing/TLS-Gold-Developers-Guide.pdf

Well, some companies treat their documentation under some obscure licenses thus,
having considered all the problems that this may cause us, I've decided
not to read this propriatary api (and all others). This would save us from any lawsuits
for 'copying proprietary apis etc'. However if somebody else does this and performs
a comparison (I believe this is fair use), it would be ok for us to optimize the library 
depending on his remarks.

> - - Dima

-- 
Nikos Mavroyanopoulos
mailto:nmav at hellug.gr



From nmav at hellug.gr  Tue Dec  4 23:18:02 2001
From: nmav at hellug.gr (Nikos Mavroyanopoulos)
Date: Tue Dec  4 23:18:02 2001
Subject: [gnutls-dev] API comments
In-Reply-To: <Pine.LNX.4.43.0112042009290.9581-100000@vic20.blipp.com>
References: <20011202223932.26266057.nmav@hellug.gr>
	<Pine.LNX.4.43.0112042009290.9581-100000@vic20.blipp.com>
Message-ID: <20011205001442.33279316.nmav@hellug.gr>

On Tue, 4 Dec 2001 20:18:51 +0100 (CET) Simon Josefsson <jas at vic20.blipp.com> wrote:

> > It says that "Returns the number of bytes sent, or a negative error code.",
> > but it may still not be clear. What do you propose?
> The complete documentation also say:  The function has the same semantics
> as read() has.  This simply isn't true, it returns
> GNUTLS_E_{INTERRUPTED,EAGAIN} which read() doesn't do.  Those error codes
> aren't mentioned in the read() documentation either.
I'll make the documentation more precise.

> My suggestion would be to not mess with the return values for read() and
> write(), it would be simpler to replce TCP read()/write() with TLS if it
> was this way, and the TLS libraries I've used worked this way /as far as I
> can remember anyway).
Well I don't think that this would do much good. I'll have to use an errno
variable to report errors (and other messages like rehandshake). That's an
extra variable to cope with. Why don't you like the negative error codes?

> > > I think it would be nice if they did work as
> > > read() and write(), I believe both Open SSL and Mozilla NSS do that.
Well some implementations use something like tls_bind() or tls_accept().
These have no meaning in TLS or SSL. Also tls_read() and tls_write() need
to report many more things than the normal TCP/IP read() and write().
Thus I've decided to create an API that relates to TLS and not TCP (but still
has a lot of similarities). Anyway I think that it is important 
for developers to know some things about tls before using any tls layer library.
(at least as much as sockets developers know about tcp/ip)

> > I'm trying not to tight gnutls to berkeley style sockets, or even TCP/IP.
> Good. The type name "SOCKET" always bothered me.
I've renamed this to GNUTLS_SOCKET_PTR (gnutls is there to avoid namespace polution).


-- 
Nikos Mavroyanopoulos
mailto:nmav at hellug.gr



From jas at vic20.blipp.com  Wed Dec  5 09:28:02 2001
From: jas at vic20.blipp.com (Simon Josefsson)
Date: Wed Dec  5 09:28:02 2001
Subject: [gnutls-dev] API comments
In-Reply-To: <20011202223932.26266057.nmav@hellug.gr>
Message-ID: <Pine.LNX.4.43.0112042009290.9581-100000@vic20.blipp.com>

On Sun, 2 Dec 2001, Nikos Mavroyanopoulos wrote:

> On Sun, 02 Dec 2001 01:09:47 +0100 Simon Josefsson <jas at extundo.com> wrote:
>
> > gnutls_read() and gnutls_write() does not seem to work as read() and
> > write() as the API documentation on the web page says, especially the
> > error codes differ.
> It says that "Returns the number of bytes sent, or a negative error code.",
> but it may still not be clear. What do you propose?

The complete documentation also say:  The function has the same semantics
as read() has.  This simply isn't true, it returns
GNUTLS_E_{INTERRUPTED,EAGAIN} which read() doesn't do.  Those error codes
aren't mentioned in the read() documentation either.

My suggestion would be to not mess with the return values for read() and
write(), it would be simpler to replce TCP read()/write() with TLS if it
was this way, and the TLS libraries I've used worked this way /as far as I
can remember anyway).

> > I think it would be nice if they did work as
> > read() and write(), I believe both Open SSL and Mozilla NSS do that.
> I'm trying not to tight gnutls to berkeley style sockets, or even TCP/IP.

Good. The type name "SOCKET" always bothered me.

> > It was unclear to me if gnutls_bye() did anything to the socket or not
> > (like, e.g., calling shutdown()).  I want to be able to use the socket
> > after disabling TLS, sending unencrypted packets.  Possible?
> gnutls_bye() and any other gnutls function (except of gnutls_read()/write()),
> do not call any external function such as shutdown.
> Thus in your case if the return value is zero you may continue using the
> connection.

Perhaps the documentation could be clearer, and say that it is the "TLS
connection" that is terminated, instead of "the connection".

>
> > Documentation in info-format would be nice. :-)
> Documentation in gnutls is in latex format. This can be
> converted to several other formats. (and possibly info format but
> I'm not sure)

It was the info format I was after. :-)  Perhaps it is easier to write the
documentation in texinfo format, I don't know.  Or DocBook, it seems
popular, but I don't know anything about it.




From jas at vic20.blipp.com  Wed Dec  5 09:28:03 2001
From: jas at vic20.blipp.com (Simon Josefsson)
Date: Wed Dec  5 09:28:03 2001
Subject: [gnutls-dev] API comments
In-Reply-To: <20011202224444.366be337.nmav@hellug.gr>
Message-ID: <Pine.LNX.4.43.0112042019110.9581-100000@vic20.blipp.com>

On Sun, 2 Dec 2001, Nikos Mavroyanopoulos wrote:

> On Sun, 02 Dec 2001 01:09:47 +0100 Simon Josefsson <jas at extundo.com> wrote:
>
> > Some comments on the API:
> Since you've worked with other TLS APIs I'd like to hear more
> comments about the gnutls api :)
>
> If you think some things are done better in other implementations
> just say it!

For one thing, using "..." is horrible.  It makes it difficult to read the
values from e.g. a config file and then pass on to the function.  Also it
is much more difficult to do function bindings in other languages etc.
IMHO the "..."  feature of C should only ever be used when writing a
wrapper around printf() or other already existing functions that use
"...".

It seems as if it would be possible to solve this by using some other
value of GNUTLS_LIST though. Maybe a integer array instead.

(Feel free to disagree, of course, this was only my initial reaction.)




From nmav at hellug.gr  Wed Dec  5 13:55:02 2001
From: nmav at hellug.gr (Nikos Mavroyanopoulos)
Date: Wed Dec  5 13:55:02 2001
Subject: [gnutls-dev] API comments
In-Reply-To: <Pine.LNX.4.43.0112042019110.9581-100000@vic20.blipp.com>
References: <20011202224444.366be337.nmav@hellug.gr>
	<Pine.LNX.4.43.0112042019110.9581-100000@vic20.blipp.com>
Message-ID: <20011205145107.613f05e2.nmav@hellug.gr>

On Tue, 4 Dec 2001 20:24:09 +0100 (CET) Simon Josefsson <jas at vic20.blipp.com> wrote:

> > If you think some things are done better in other implementations
> > just say it!
> For one thing, using "..." is horrible.  It makes it difficult to read the
> values from e.g. a config file and then pass on to the function.  Also it
Well here you surely got a point. I'll try to make it simple 
(int* seems like a good replacement).


-- 
Nikos Mavroyanopoulos
mailto:nmav at hellug.gr



From nmav at hellug.gr  Fri Dec  7 18:36:02 2001
From: nmav at hellug.gr (Nikos Mavroyanopoulos)
Date: Fri Dec  7 18:36:02 2001
Subject: [gnutls-dev] gnutls 0.2.90
Message-ID: <20011207193200.7fb96289.nmav@hellug.gr>

I've put a copy of the current cvs as gnutls 0.2.90. It includes a lot
of changes (both in the API and the internals). The API has changed a lot
in order to avoid forced future changes. (ie KX_RSA was renamed to KX_X509PKI_RSA 
to allow KX_PGP_RSA). Consider this as a prerelease of gnutls 0.3.0.

the NEWS:
- gnutls_handshake(), gnutls_read() etc. functions no longer require
  the 'SOCKET cd' argument. This argument is set using the function
  gnutls_set_transport_ptr().
- introduced gnutls_x509pki_get_peer_certificate_list(). This function returns
  a list containing peer's certificate and issuers DER encoded.
- Updated X.509 certificate handling API
- Added callback to select the server certificate
- More consistent function naming (changes in several function names)
- Buffer overflow checking in ASN.1 structures parser
- Updated documentation

-- 
Nikos Mavroyanopoulos
mailto:nmav at hellug.gr



From simon+gnutls-dev at josefsson.org  Fri Dec  7 21:04:01 2001
From: simon+gnutls-dev at josefsson.org (Simon Josefsson)
Date: Fri Dec  7 21:04:01 2001
Subject: [gnutls-dev] Re: API comments
In-Reply-To: <20011205001442.33279316.nmav@hellug.gr> (Nikos
 Mavroyanopoulos's message of "Wed, 5 Dec 2001 00:14:42 +0200")
References: <20011202223932.26266057.nmav@hellug.gr>
	<Pine.LNX.4.43.0112042009290.9581-100000@vic20.blipp.com>
	<20011205001442.33279316.nmav@hellug.gr>
Message-ID: <iluher2kdg8.fsf@dhcp128.extundo.com>

Nikos Mavroyanopoulos <nmav at hellug.gr> writes:

> On Tue, 4 Dec 2001 20:18:51 +0100 (CET) Simon Josefsson <jas at vic20.blipp.com> wrote:
>
>> > It says that "Returns the number of bytes sent, or a negative error code.",
>> > but it may still not be clear. What do you propose?
>> The complete documentation also say:  The function has the same semantics
>> as read() has.  This simply isn't true, it returns
>> GNUTLS_E_{INTERRUPTED,EAGAIN} which read() doesn't do.  Those error codes
>> aren't mentioned in the read() documentation either.
> I'll make the documentation more precise.

Thank you.

>> My suggestion would be to not mess with the return values for read() and
>> write(), it would be simpler to replce TCP read()/write() with TLS if it
>> was this way, and the TLS libraries I've used worked this way /as far as I
>> can remember anyway).
> Well I don't think that this would do much good. I'll have to use an errno
> variable to report errors (and other messages like rehandshake). That's an
> extra variable to cope with. Why don't you like the negative error codes?

I don't like having a different interface than read() and write().
When porting code it is advantageous if you can re-use the read/write
logic of the code even when TLS is used.

>> > > I think it would be nice if they did work as
>> > > read() and write(), I believe both Open SSL and Mozilla NSS do that.
> Well some implementations use something like tls_bind() or tls_accept().
> These have no meaning in TLS or SSL.

This solution is much worse, yes.

> Also tls_read() and tls_write() need to report many more things than
> the normal TCP/IP read() and write().  Thus I've decided to create
> an API that relates to TLS and not TCP (but still has a lot of
> similarities). Anyway I think that it is important for developers to
> know some things about tls before using any tls layer library.  (at
> least as much as sockets developers know about tcp/ip)

Right.  Maybe the TLS specific return codes could be conveyed using
another variable like "errno".  Hm.

>> > I'm trying not to tight gnutls to berkeley style sockets, or even TCP/IP.
>> Good. The type name "SOCKET" always bothered me.
> I've renamed this to GNUTLS_SOCKET_PTR (gnutls is there to avoid namespace polution).

Ok.  I still find the term "SOCKET" a bit TCP specific though, since
it should be specific to "sockets".

Sorry if my tone sounds harsh, these are only thoughts and I didn't
put much effort into thinking this through either.  I understand
designing a API is non-trivial.




From nmav at hellug.gr  Sat Dec  8 02:42:02 2001
From: nmav at hellug.gr (Nikos Mavroyanopoulos)
Date: Sat Dec  8 02:42:02 2001
Subject: [gnutls-dev] dnsname extension
Message-ID: <20011208033559.78b60eb6.nmav@hellug.gr>

 gnutls from it's early versions supported a TLS extension called dnsname.
This extension is supposed to send (from client) to the server the dnsname of the
server (much like http 1.1 does). This extension has the obvious advantage that
may allow TLS servers to use multiple certificates when doing virtual hosting
(Ie koko.hellug.gr, and test.hellug.gr are hosted in one IP but have two different
X.509 certificates).

I though that adding this to gnutls might be a good idea. Now (after some discussion
in the ietf-tls mailing list), I believe that this extension is really bad.
The virtual hosting problem is not TLS' problem but HTTPS' (rfc2818). It seems that https
is designed in such way that it will not allow virtual hosting. Thus the reaction
was to patch (or bloat) TLS to allow virtual hosting in HTTPS[0]. I think that this
is a bad protocol design (it is similar to having a TCP or IP extension that contains dnsname),
thus I plan to remove the dnsname extension before 0.3.0. I'd like to hear any
comments on this.


[0]: Alternatives to HTTPS is RFC2817 which does not have the problem of virtual hosting.

-- 
Nikos Mavroyanopoulos
mailto:nmav at hellug.gr



From nmav at hellug.gr  Mon Dec 10 18:18:01 2001
From: nmav at hellug.gr (Nikos Mavroyanopoulos)
Date: Mon Dec 10 18:18:01 2001
Subject: [gnutls-dev] gnutls 0.2.91
Message-ID: <20011210191451.67147772.nmav@hellug.gr>

I've just released gnutls 0.2.91. If there no bugs in this version I'll
release it as 0.3.0.

- Fixes in MPI handling (fixes possible bug with signed integers)
- Removed name indication extension
- Added gnutls_transport_get_ptr() and gnutls_db_get_ptr()
- Optimizations in server certificate callback.
- Fixes in anonymous authentication
- Corrections in client ciphersuite selection

-- 
Nikos Mavroyanopoulos
mailto:nmav at hellug.gr



From nmav at hellug.gr  Mon Dec 17 17:09:01 2001
From: nmav at hellug.gr (Nikos Mavroyanopoulos)
Date: Mon Dec 17 17:09:01 2001
Subject: [gnutls-dev] gnutls 0.3.0
Message-ID: <20011217180559.7a69abb7.nmav@hellug.gr>

I've just released gnutls 0.3.0.

-- 
Nikos Mavroyanopoulos
mailto:nmav at hellug.gr



From nmav at hellug.gr  Mon Dec 17 18:28:02 2001
From: nmav at hellug.gr (Nikos Mavroyanopoulos)
Date: Mon Dec 17 18:28:02 2001
Subject: [gnutls-dev] gnutls 0.3.0
Message-ID: <20011217192356.229ae302.nmav@hellug.gr>

Well, I forgot to post the Changes.
Here it is (NEWS since 0.2.11):

- Removed name indication extension
- Added gnutls_transport_get_ptr() and gnutls_db_get_ptr()
- Optimizations in server certificate callback.
- Fixes in anonymous authentication
- Corrections in client ciphersuite selection
- gnutls_handshake(), gnutls_read() etc. functions no longer require
  the 'SOCKET cd' argument. This argument is set using the function 
  gnutls_set_transport_ptr().
- introduced gnutls_x509pki_get_peer_certificate_list(). This function
  returns a list containing peer's certificate and issuers DER encoded.
- Updated X.509 certificate handling API
- Added callback to select the server certificate
- More consistent function naming (changes in several function names)
- Buffer overflow checking in ASN.1 structures parser
- Updated documentation

You may also note that 0.3.0 is not binary nor source compatible
with previous versions.

-- 
Nikos Mavroyanopoulos
mailto:nmav at hellug.gr



From nspring at cs.washington.edu  Tue Dec 18 01:28:01 2001
From: nspring at cs.washington.edu (Neil Spring)
Date: Tue Dec 18 01:28:01 2001
Subject: [gnutls-dev] gnutls 0.3.0
In-Reply-To: <20011217192356.229ae302.nmav@hellug.gr>
References: <20011217192356.229ae302.nmav@hellug.gr>
Message-ID: <20011218002528.GB12036@cs.washington.edu>

Would it be useful to add numeric #defines of the gnutls
library version number?  This would make it easier to write
source code that supports multiple versions of gnutls at
compile time.  gnutls currently has a string representation
"0.3.0", but I can't use that to express the differences
between versions, like:

#if LIBGNUTLS_VERSION_MINOR >= 3
  gnutls_read(state...)
#else
  gnutls_read(sd, state...)
#endif

As an example, ALSA has a numeric version defined in
/usr/include/alsa/version.h:

  /*
   *  version.h
   */
  
  #define SND_LIB_MAJOR           0 /**< major number of library version */
  #define SND_LIB_MINOR           9 /**< minor number of library version */
  #define SND_LIB_SUBMINOR        0 /**< subminor number of library version */
  /** library version */
  #define SND_LIB_VERSION         ((SND_LIB_MAJOR<<16)|\
                                   (SND_LIB_MINOR<<8)|\
                                    SND_LIB_SUBMINOR)
  /** library version (string) */
  #define SND_LIB_VERSION_STR     "0.9.0beta9"

alternately, linux-style versions would be ok too:

/usr/src/linux/include/linux/version.h:
  #define UTS_RELEASE "2.4.9"
  #define LINUX_VERSION_CODE 132105
  #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))

thanks, 
-neil
btw, the 0.3.0 interface looks cleaner.



From wk at gnupg.org  Tue Dec 18 08:50:01 2001
From: wk at gnupg.org (Werner Koch)
Date: Tue Dec 18 08:50:01 2001
Subject: [gnutls-dev] gnutls 0.3.0
In-Reply-To: <20011218002528.GB12036@cs.washington.edu> (Neil Spring's
 message of "Mon, 17 Dec 2001 16:25:30 -0800")
References: <20011217192356.229ae302.nmav@hellug.gr>
	<20011218002528.GB12036@cs.washington.edu>
Message-ID: <87n10h0xwo.fsf@alberti.gnupg.de>

On Mon, 17 Dec 2001 16:25:30 -0800, Neil Spring said:

> Would it be useful to add numeric #defines of the gnutls
> library version number?  This would make it easier to write
> source code that supports multiple versions of gnutls at

I'd suggest to use configure.ac to create whatever version specific
macros you need.  It is pretty easy to get the version number by using 
libgcrypt-config --version and some of the usual shell tools.  You can
even do this in a plain Makefile if you don't use configure.

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus




From nmav at hellug.gr  Fri Dec 21 09:21:01 2001
From: nmav at hellug.gr (Nikos Mavroyanopoulos)
Date: Fri Dec 21 09:21:01 2001
Subject: [gnutls-dev] gnutls 0.3.1
Message-ID: <20011221101519.5d236557.nmav@hellug.gr>

I'll be unavailable for some weeks, thus I've released gnutls 0.3.1 which
seems to correct some problems in 0.3.0. It corrects some problems
with big endian machines, and some configure-time bugs.

Have nice holidays!

-- 
Nikos Mavroyanopoulos
mailto:nmav at hellug.gr



From nmav at hellug.gr  Sun Dec 30 19:05:02 2001
From: nmav at hellug.gr (Nikos Mavroyanopoulos)
Date: Sun Dec 30 19:05:02 2001
Subject: [gnutls-dev] using serveral certificates on the server side
Message-ID: <20011230220046.6271c497.nmav@hellug.gr>

> I am using the CVS version of GnuTLS.

> - the server asks for a client authentication
> - the server knows two CAs: ca1 and ca2 (I give them through a PEM
> encoded file)
> - the client knows one CA: ca1
> - the server has got a ca1 signed certificate
> - the client has got a ca2 signed certificate

> I have the following problem:=20
> --> When doing the handshake, the connection to the server is refused
> (code : -9).
[...]

> It is like if the server did not use the second certificate when giving
> it several certificates.

Well this was a bug in the client side of gnutls. I've just
commited a fix in the cvs. 

-- 
Nikos Mavroyanopoulos