From sebastian_hans at yahoo.com  Mon Jan  1 17:46:11 2007
From: sebastian_hans at yahoo.com (Sebastian Hans)
Date: Mon, 1 Jan 2007 08:46:11 -0800 (PST)
Subject: [Help-gnutls] Problem starting gnutls-serv with PSK support 
Message-ID: <753251.59363.qm@web90608.mail.mud.yahoo.com>

Hi,

I have problems starting gnutls-serv with support for the PSK keyexchange. When I run the gnutls-cli-debug against the server the output shows that no protocol is supported.

To start the gnutls-serv I use the following command

gnutls-serv -d 10 -p 4433 --http --ciphers AES --protocols TLS1.1 --kx PSK --pskpasswd sha16.psk

the output generated by gnutls-cli-debug is:

C:\downloads\SSL-APIs\GnuTLS\bin>gnutls-cli-debug localhost -p 4433
Resolving 'localhost'...
Connecting to '127.0.0.1:4433'...
Checking for TLS 1.1 support... no
Checking fallback from TLS 1.1 to... failed
Checking for TLS 1.0 support... no
Checking for SSL 3.0 support... no

Server does not support none of SSL 3.0, TLS 1.0 and TLS 1.1

I tried a lot of variations but nothing worked.

I using now version 1.6.1 in Windows XP

regards

Sebastian

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20070101/f21cc6d5/attachment.htm>

From ranjit at motorola.com  Wed Jan  3 11:11:48 2007
From: ranjit at motorola.com (Avasarala Ranjit-A20990)
Date: Wed, 3 Jan 2007 18:11:48 +0800
Subject: [Help-gnutls] RE: Modifying tls code
In-Reply-To: <87d5659ing.fsf@latte.josefsson.org>
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B03C9766B@ZMY16EXM66.ds.mot.com>

Hi Simon

How do I run these ex-client-srp.c and ex-serv-srp.c? 

My requirement is as follows:

I need to establish an end to end SRP/TLS connection. 
Client authenticates to server thru SRP and then data is exchanged over
TLS.

Initially client sends data over TLS to server
Then server sends back data to client ..again over TLS'

How do I do this using the ex-client-srp.c and ex-sever-srp.c

Thanks 


Regards
Ranjit

-----Original Message-----
From: Simon Josefsson [mailto:simon at josefsson.org] 
Sent: Thursday, December 28, 2006 2:11 AM
To: Avasarala Ranjit-A20990
Cc: help-gnutls at gnu.org
Subject: Re: Modifying tls code

"Avasarala Ranjit-A20990" <ranjit at motorola.com> writes:

>  
> Hi
>
> I have a requirement to have end to end SRP/TLS connection with a 
> mechanism to send and receive data. Like the client version of SRP/TLS
> (gnutls-cli) should be able to send some data to server (gnutls-serv) 
> and the server should be able to send back some data to the 
> client(gnutls-cli).
>
> How do I go about this? Is this possible with the current tls/srp
code?
> If yes which parts of the code I should look at?

I'm not sure what you are asking for.  Implementing a client and server
that use TLS+SRP to protect the channel, and then send data back and
forward between the client and server is certainly possible, and quite
easy.  There are example TLS+SRP code in doc/examples/, see
ex-client-srp.c and ex-serv-srp.c.  Are you asking for something more
specific?

/Simon




From simon at josefsson.org  Wed Jan  3 11:29:12 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 03 Jan 2007 11:29:12 +0100
Subject: [Help-gnutls] Re: Modifying tls code
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B03C9766B@ZMY16EXM66.ds.mot.com>
	(Avasarala Ranjit-A's message of "Wed\, 3 Jan 2007 18\:11\:48 +0800")
References: <87d5659ing.fsf@latte.josefsson.org>
	<750BBC72E178114F9DC4872EBFF29A5B03C9766B@ZMY16EXM66.ds.mot.com>
Message-ID: <87bqlgh093.fsf@latte.josefsson.org>

"Avasarala Ranjit-A20990" <ranjit at motorola.com> writes:

> Hi Simon
>
> How do I run these ex-client-srp.c and ex-serv-srp.c? 

Hi.  The examples should be compiled when you built GnuTLS, but you'll
have to read the code to understand have to use them.  For example,
ex-client-srp.c uses a CA certificate in the file "ca.pem" and the
server needs "ca.pem", and also key/cert in "key.pem" and "cert.pem",
and also the SRP password files "tpasswd" and "tpasswd.conf".

> My requirement is as follows:
>
> I need to establish an end to end SRP/TLS connection. 
> Client authenticates to server thru SRP and then data is exchanged over
> TLS.
>
> Initially client sends data over TLS to server
> Then server sends back data to client ..again over TLS'
>
> How do I do this using the ex-client-srp.c and ex-sever-srp.c

Create the appropriate files as above, then modify the part of the
code that sends/receives messages.

Looking at ex-client-srp.c, the client always begin by sending a HTTP
request, then reads the reply and disconnects.  The server reads data
and sends the same data back, indefinitely.

It thus appears as if the examples are quite close to what you need.
Just change the calls to send the data you want in the client, and to
do something useful with data on the server side.

/Simon

> Thanks 
>
>
> Regards
> Ranjit
>
> -----Original Message-----
> From: Simon Josefsson [mailto:simon at josefsson.org] 
> Sent: Thursday, December 28, 2006 2:11 AM
> To: Avasarala Ranjit-A20990
> Cc: help-gnutls at gnu.org
> Subject: Re: Modifying tls code
>
> "Avasarala Ranjit-A20990" <ranjit at motorola.com> writes:
>
>>  
>> Hi
>>
>> I have a requirement to have end to end SRP/TLS connection with a 
>> mechanism to send and receive data. Like the client version of SRP/TLS
>> (gnutls-cli) should be able to send some data to server (gnutls-serv) 
>> and the server should be able to send back some data to the 
>> client(gnutls-cli).
>>
>> How do I go about this? Is this possible with the current tls/srp
> code?
>> If yes which parts of the code I should look at?
>
> I'm not sure what you are asking for.  Implementing a client and server
> that use TLS+SRP to protect the channel, and then send data back and
> forward between the client and server is certainly possible, and quite
> easy.  There are example TLS+SRP code in doc/examples/, see
> ex-client-srp.c and ex-serv-srp.c.  Are you asking for something more
> specific?
>
> /Simon




From ludovic.courtes at laas.fr  Fri Jan  5 13:57:23 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 05 Jan 2007 13:57:23 +0100
Subject: [Help-gnutls] Re: Failure to import an OpenPGP private key
References: <87u01rxgqg.fsf@laas.fr> <87lkn2or1x.fsf@latte.josefsson.org>
	<87wt6mkt3b.fsf@laas.fr> <87odru40bq.fsf@latte.josefsson.org>
	<87fybjbvbz.fsf@laas.fr> <878xgsa0e3.fsf@latte.josefsson.org>
Message-ID: <87lkkhoclo.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> However, your patch changes the external API/ABI, which is something
> we _really_ don't want to do unless we can avoid it.

Only `_gnutls' functions are changed so does that really count as an
API/ABI change (given that the `_gnutls' functions are not part of the
documented API and are not meant to be used by application programs)?

However, changing `_E_gnutls_openpgp_raw_privkey_to_gkey' may be an
issue (ABI change in `libgnutls-extra').

Also, my understanding was that the API/ABI policy may be less strict
for 1.7 than for 1.6?

> It seems a better patch would be to have
> _gnutls_openpgp_raw_privkey_to_gkey be able to figure out the format
> of the input automatically -- that seems possible to implement.  Just
> go over the input and look for non-ASCII characters (or just some
> specific non-ASCII character like \0, which I assume is guaranteed to
> always be present in OpenPGP binary keys, to avoid problems with
> non-ASCII characters in a Comment: field or similar), and set the
> armor flag accordingly.  What do you think?  If you agree, I'd
> appreciate if you could suggest a specific patch to implement this.

That seems like a fragile solution, especially since the information
(the input format) is already explicitly passed in
`gnutls_openpgp_privkey_import ()'.  That said, perhaps we could
implement this solution for 1.6 and keep the other one (or something
similar) for 1.7.  Would that be acceptable?

> Btw, to be able to use your patch, we'd might need a copyright
> assignment, if the patch is large..  would that be a problem?  I can
> send you the forms offline.

No problem, you can send it to me.

Thanks,
Ludovic.





From mario.lenz at gmx.net  Sat Jan  6 10:15:18 2007
From: mario.lenz at gmx.net (Mario Lenz)
Date: Sat, 06 Jan 2007 10:15:18 +0100
Subject: [Help-gnutls] Getting keys for my own crtypto functions (opencdk)
Message-ID: <1168074918.3206.6.camel@mario>

Hi!

I'd like to use opencdk to get keys from a key ring and then use them in
my own cryptographic functions. There are two functions in pubkey.c
which do exactly what I need: seckey_to_sexp() and pubkey_to_sexp().
Unfortunately, they are static :-(

You wouldn't make them part of the API, would you?

greez

   Mario

-- 
Wieners, in buns, no condiments. It's Hank's way. Anything else is
wrong.





From simon at josefsson.org  Mon Jan  8 16:45:00 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 08 Jan 2007 16:45:00 +0100
Subject: [Help-gnutls] Re: Getting keys for my own crtypto functions
	(opencdk)
In-Reply-To: <1168074918.3206.6.camel@mario> (Mario Lenz's message of "Sat\, 06
	Jan 2007 10\:15\:18 +0100")
References: <1168074918.3206.6.camel@mario>
Message-ID: <87r6u5a5fn.fsf@latte.josefsson.org>

Mario Lenz <mario.lenz at gmx.net> writes:

> Hi!
>
> I'd like to use opencdk to get keys from a key ring and then use them in
> my own cryptographic functions. There are two functions in pubkey.c
> which do exactly what I need: seckey_to_sexp() and pubkey_to_sexp().
> Unfortunately, they are static :-(
>
> You wouldn't make them part of the API, would you?

Hi!  Those functions use a gcry_sexp_t type... having types that are
specific to libgcrypt in the public API for OpenCDK strikes me as a
bad idea.

However, we could add a new API function that use those two functions
internally, but use a char* representation of the sexp as the external
interface?  For example:

int
cdk_pubkey_to_sexp (cdk_pkt_pubkey_t pk, char **sexp, size_t *len)

int
cdk_seckey_to_sexp (cdk_pkt_seckey_t sk, char **sexp, size_t *len)

The functions would call seckey_to_sexp and pubkey_to_sexp internally,
and then use gcry_sexp_sprint() to print the sexp into a newly
allocated string?  You'd have to use gcry_sexp_new() to re-import the
char* though, if you use libgcrypt, but I think that is a small price
to pay to keep the OpenCDK API independent of libgcrypt.

This approach seems acceptable, and if you implement it (or some
variant of this), I'd be happy to make that part of the official API.

Thanks,
Simon

PS.  Maybe you are aware of it, but did you look at GPGME?  It has
more PGP stuff, and written in a more GnuPG compatible way.  I know it
has some limitations though.  I'd wish that GnuTLS could use it
instead of OpenCDK, but right now it doesn't...




From mario.lenz at gmx.net  Mon Jan  8 17:58:08 2007
From: mario.lenz at gmx.net (Mario Lenz)
Date: Mon, 08 Jan 2007 17:58:08 +0100
Subject: [Help-gnutls] Re: Getting keys for my own crtypto functions
	(opencdk)
In-Reply-To: <87r6u5a5fn.fsf@latte.josefsson.org>
References: <1168074918.3206.6.camel@mario>
	<87r6u5a5fn.fsf@latte.josefsson.org>
Message-ID: <1168275488.3523.13.camel@mario>

Hi!

> Hi!  Those functions use a gcry_sexp_t type... having types that are
> specific to libgcrypt in the public API for OpenCDK strikes me as a
> bad idea.

Good point.

> However, we could add a new API function that use those two functions
> internally, but use a char* representation of the sexp as the external
> interface?

That would be fine, thank you :-)

> This approach seems acceptable, and if you implement it (or some
> variant of this), I'd be happy to make that part of the official API.

I'll try to do this one of the next days.

> PS.  Maybe you are aware of it, but did you look at GPGME?

Not exactly what I need, sorry.

cu

   Mario





From simon at josefsson.org  Mon Jan  8 23:13:54 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 08 Jan 2007 23:13:54 +0100
Subject: [Help-gnutls] Re: Failure to import an OpenPGP private key
In-Reply-To: <87lkkhoclo.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?=
	message of "Fri\, 05 Jan 2007 13\:57\:23 +0100")
References: <87u01rxgqg.fsf@laas.fr> <87lkn2or1x.fsf@latte.josefsson.org>
	<87wt6mkt3b.fsf@laas.fr> <87odru40bq.fsf@latte.josefsson.org>
	<87fybjbvbz.fsf@laas.fr> <878xgsa0e3.fsf@latte.josefsson.org>
	<87lkkhoclo.fsf@laas.fr>
Message-ID: <87fyalupy5.fsf@latte.josefsson.org>

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

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> However, your patch changes the external API/ABI, which is something
>> we _really_ don't want to do unless we can avoid it.
>
> Only `_gnutls' functions are changed so does that really count as an
> API/ABI change (given that the `_gnutls' functions are not part of the
> documented API and are not meant to be used by application programs)?
>
> However, changing `_E_gnutls_openpgp_raw_privkey_to_gkey' may be an
> issue (ABI change in `libgnutls-extra').

Hi!  Right, changing _E_gnutls_openpgp_raw_privkey_to_gkey is the
problem, and it actually affects both libgnutls and libgnutls-extra
(the variable is defined in libgnutla).

Incidentally, I have been thinking about changing that stuff anyway,
because I think it was the only thing that required us to use
--enable-runtime-pseudo-reloc for mingw32, and generally, having
variables in a public API/ABI is not very good.

> Also, my understanding was that the API/ABI policy may be less strict
> for 1.7 than for 1.6?

Somewhat, for 1.6 it is not an option, but for 1.7 it is possible to
discuss it.

>> It seems a better patch would be to have
>> _gnutls_openpgp_raw_privkey_to_gkey be able to figure out the format
>> of the input automatically -- that seems possible to implement.  Just
>> go over the input and look for non-ASCII characters (or just some
>> specific non-ASCII character like \0, which I assume is guaranteed to
>> always be present in OpenPGP binary keys, to avoid problems with
>> non-ASCII characters in a Comment: field or similar), and set the
>> armor flag accordingly.  What do you think?  If you agree, I'd
>> appreciate if you could suggest a specific patch to implement this.
>
> That seems like a fragile solution, especially since the information
> (the input format) is already explicitly passed in
> `gnutls_openpgp_privkey_import ()'.  That said, perhaps we could
> implement this solution for 1.6 and keep the other one (or something
> similar) for 1.7.  Would that be acceptable?

It doesn't seem that fragile to me...

However, maybe this is a good place to take the opportunity to get rid
of the _E_gnutls_* variables entirely, and to fix your problem at the
same time.  I think that is the cleanest solution here.  nm suggests
that the entire variable list is:

00000000 B _E_gnutls_openpgp_get_raw_key_creation_time
00000004 B _E_gnutls_openpgp_get_raw_key_expiration_time
00000004 C _E_gnutls_openpgp_raw_key_to_gcert
00000004 C _E_gnutls_openpgp_raw_privkey_to_gkey
00000008 B _E_gnutls_openpgp_verify_key
00000000 B _E_gnutls_openpgp_fingerprint
00000004 C _E_gnutls_openpgp_key_deinit
00000004 C _E_gnutls_openpgp_key_to_gcert
00000004 C _E_gnutls_openpgp_privkey_deinit
00000004 C _E_gnutls_openpgp_privkey_to_gkey
         U _E_gnutls_openpgp_raw_key_to_gcert
00000004 B _E_gnutls_openpgp_request_key

The variables are implemented in libgnutls-extra and used by
libgnutls, when libgnutls-extra is loaded, only in lib/auth_cert.c and
lib/gnutls_cert.c.  I'm not yet sure how to do this, ideas and
suggestions most welcome.  Perhaps more code related to openpgp should
be moved from libgnutls to libgnutls-extra.

>> Btw, to be able to use your patch, we'd might need a copyright
>> assignment, if the patch is large..  would that be a problem?  I can
>> send you the forms offline.
>
> No problem, you can send it to me.

Great, I'll send it by private e-mail.

/Simon




From ludovic.courtes at laas.fr  Tue Jan  9 11:02:44 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 09 Jan 2007 11:02:44 +0100
Subject: [Help-gnutls] Re: Failure to import an OpenPGP private key
References: <87u01rxgqg.fsf@laas.fr> <87lkn2or1x.fsf@latte.josefsson.org>
	<87wt6mkt3b.fsf@laas.fr> <87odru40bq.fsf@latte.josefsson.org>
	<87fybjbvbz.fsf@laas.fr> <878xgsa0e3.fsf@latte.josefsson.org>
	<87lkkhoclo.fsf@laas.fr> <87fyalupy5.fsf@latte.josefsson.org>
Message-ID: <87ac0sv7p7.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> However, maybe this is a good place to take the opportunity to get rid
> of the _E_gnutls_* variables entirely, and to fix your problem at the
> same time.  I think that is the cleanest solution here.  nm suggests
> that the entire variable list is:
>
> 00000000 B _E_gnutls_openpgp_get_raw_key_creation_time
> 00000004 B _E_gnutls_openpgp_get_raw_key_expiration_time
> 00000004 C _E_gnutls_openpgp_raw_key_to_gcert
> 00000004 C _E_gnutls_openpgp_raw_privkey_to_gkey
> 00000008 B _E_gnutls_openpgp_verify_key
> 00000000 B _E_gnutls_openpgp_fingerprint
> 00000004 C _E_gnutls_openpgp_key_deinit
> 00000004 C _E_gnutls_openpgp_key_to_gcert
> 00000004 C _E_gnutls_openpgp_privkey_deinit
> 00000004 C _E_gnutls_openpgp_privkey_to_gkey
>          U _E_gnutls_openpgp_raw_key_to_gcert
> 00000004 B _E_gnutls_openpgp_request_key
>
> The variables are implemented in libgnutls-extra and used by
> libgnutls, when libgnutls-extra is loaded, only in lib/auth_cert.c and
> lib/gnutls_cert.c.  I'm not yet sure how to do this, ideas and
> suggestions most welcome.  Perhaps more code related to openpgp should
> be moved from libgnutls to libgnutls-extra.

How about having a per-certificate-type "vtable", with pointers to
methods like:

  certificate_init_from_raw_key
  certificate_deinit
  certificate_send
  process_server_certificate
  ...

There are various places (e.g., in `auth_cert.c') where code
encapsulates specific X509 and OpenPGP knowledge, with things like:

  if (cert_type == GNUTLS_CRT_X509)
    ...
  else
    /* OpenPGP */

That code would instead do things like:

  _gnutls_certificate_type_vtable[cert_type].certificate_deinit (...);

(The indirection itself could rather be implemented in inline functions
that would also make sure that the method pointer is not NULL.)

`libgnutls-extra' would appropriately fill out
`_gnutls_certificate_type_vtable[GNUTLS_CRT_OPENPGP]' upon
initialization.

Determining the exact set of methods may require quite a bit of work.
However, in doing so, we'd probably automatically end up moving
OpenPGP-specific bits back from `libgnutls' to `libgnutls-extra', which
is good.

As far as the OpenPGP private key import bug is concerned, the initial
solution would still be easier to achieve.  ;-)

What do you think?

Thanks,
Ludovic.





From simon at josefsson.org  Tue Jan  9 12:02:05 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 09 Jan 2007 12:02:05 +0100
Subject: [Help-gnutls] Re: Failure to import an OpenPGP private key
In-Reply-To: <87ac0sv7p7.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?=
	message of "Tue\, 09 Jan 2007 11\:02\:44 +0100")
References: <87u01rxgqg.fsf@laas.fr> <87lkn2or1x.fsf@latte.josefsson.org>
	<87wt6mkt3b.fsf@laas.fr> <87odru40bq.fsf@latte.josefsson.org>
	<87fybjbvbz.fsf@laas.fr> <878xgsa0e3.fsf@latte.josefsson.org>
	<87lkkhoclo.fsf@laas.fr> <87fyalupy5.fsf@latte.josefsson.org>
	<87ac0sv7p7.fsf@laas.fr>
Message-ID: <87k5zwsbte.fsf@latte.josefsson.org>

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

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> However, maybe this is a good place to take the opportunity to get rid
>> of the _E_gnutls_* variables entirely, and to fix your problem at the
>> same time.  I think that is the cleanest solution here.  nm suggests
>> that the entire variable list is:
>>
>> 00000000 B _E_gnutls_openpgp_get_raw_key_creation_time
>> 00000004 B _E_gnutls_openpgp_get_raw_key_expiration_time
>> 00000004 C _E_gnutls_openpgp_raw_key_to_gcert
>> 00000004 C _E_gnutls_openpgp_raw_privkey_to_gkey
>> 00000008 B _E_gnutls_openpgp_verify_key
>> 00000000 B _E_gnutls_openpgp_fingerprint
>> 00000004 C _E_gnutls_openpgp_key_deinit
>> 00000004 C _E_gnutls_openpgp_key_to_gcert
>> 00000004 C _E_gnutls_openpgp_privkey_deinit
>> 00000004 C _E_gnutls_openpgp_privkey_to_gkey
>>          U _E_gnutls_openpgp_raw_key_to_gcert
>> 00000004 B _E_gnutls_openpgp_request_key
>>
>> The variables are implemented in libgnutls-extra and used by
>> libgnutls, when libgnutls-extra is loaded, only in lib/auth_cert.c and
>> lib/gnutls_cert.c.  I'm not yet sure how to do this, ideas and
>> suggestions most welcome.  Perhaps more code related to openpgp should
>> be moved from libgnutls to libgnutls-extra.
>
> How about having a per-certificate-type "vtable", with pointers to
> methods like:
>
>   certificate_init_from_raw_key
>   certificate_deinit
>   certificate_send
>   process_server_certificate
>   ...
>
> There are various places (e.g., in `auth_cert.c') where code
> encapsulates specific X509 and OpenPGP knowledge, with things like:
>
>   if (cert_type == GNUTLS_CRT_X509)
>     ...
>   else
>     /* OpenPGP */
>
> That code would instead do things like:
>
>   _gnutls_certificate_type_vtable[cert_type].certificate_deinit (...);
>
> (The indirection itself could rather be implemented in inline functions
> that would also make sure that the method pointer is not NULL.)
>
> `libgnutls-extra' would appropriately fill out
> `_gnutls_certificate_type_vtable[GNUTLS_CRT_OPENPGP]' upon
> initialization.
>
> Determining the exact set of methods may require quite a bit of work.
> However, in doing so, we'd probably automatically end up moving
> OpenPGP-specific bits back from `libgnutls' to `libgnutls-extra', which
> is good.

Good ideas!  I agree that we should use function indirections rather
than variables, because having variables be part of a API/ABI is a bad
idea, and causes problems on mingw32.  So there would be two
functions:

void gnutls_certtype_add (int certtype, struct gnutls_certtype_functions *hooks)

struct gnutls_certtype_functions * gnutls_certtype_get (int certtype)

which would register a new certtype with GnuTLS.

As prototyped, that would use global variables, which probably is a
bad idea, but I'm not sure what a good alternative would be -- more
thoughts about that is required.  Perhaps this should be set
per-session?  But that creates some extra work for every session, and
that seems annoying...  OTOH, that could be hidden in
gnutls_credentials_set() when it detects an openpgp cert.  Or even
more generally, when gnutls_credentials_set() detects a unknown
certtype, it requests a vtype for the certtype.  Somehow.

OTOH, if we call the functions _gnutls_certtype_add and
_gnutls_certtype_get instead, and document that they should only ever
be called by libgnutls-extra, and never by external programs, it seems
fine to use a global variable to store the function pointers --
different applications will never set different pointers, and they
will only ever be either NULL values or pointers to the loaded
gnutls-extra library.  What do you think?

The functions in auth_cert.c and gnutls_cert.c that calls these
functions would call gnutls_certtype_add (GNUTLS_CRT_X509)->deinit or
whatever.

> As far as the OpenPGP private key import bug is concerned, the initial
> solution would still be easier to achieve.  ;-)

Well, yes, but since it breaks API/ABI it is not for 1.6, and for 1.7
we can think bigger. :) But if you want, and write a quick fix for
this, that would break the API/ABI, we can install it now, and then
work on the above plan next (which also breaks the API/ABI, but for
good reasons).  I doubt it will save much time, though...

> What do you think?

If you plan to work on this, you need to fill out a copyright
assignment form for us to be able to use the work.  If this is ok, I
can send you the form to use.

/Simon




From ludovic.courtes at laas.fr  Tue Jan  9 15:40:48 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 09 Jan 2007 15:40:48 +0100
Subject: [Help-gnutls] Re: Failure to import an OpenPGP private key
References: <87u01rxgqg.fsf@laas.fr> <87lkn2or1x.fsf@latte.josefsson.org>
	<87wt6mkt3b.fsf@laas.fr> <87odru40bq.fsf@latte.josefsson.org>
	<87fybjbvbz.fsf@laas.fr> <878xgsa0e3.fsf@latte.josefsson.org>
	<87lkkhoclo.fsf@laas.fr> <87fyalupy5.fsf@latte.josefsson.org>
	<87ac0sv7p7.fsf@laas.fr> <87k5zwsbte.fsf@latte.josefsson.org>
Message-ID: <873b6kmff3.fsf@laas.fr>

Simon Josefsson <simon at josefsson.org> writes:

> Good ideas!  I agree that we should use function indirections rather
> than variables, because having variables be part of a API/ABI is a bad
> idea, and causes problems on mingw32.  So there would be two
> functions:
>
> void gnutls_certtype_add (int certtype, struct gnutls_certtype_functions *hooks)
>
> struct gnutls_certtype_functions * gnutls_certtype_get (int certtype)
>
> which would register a new certtype with GnuTLS.
>
> As prototyped, that would use global variables, which probably is a
> bad idea, but I'm not sure what a good alternative would be -- more
> thoughts about that is required.  Perhaps this should be set
> per-session?  But that creates some extra work for every session, and
> that seems annoying...  OTOH, that could be hidden in
> gnutls_credentials_set() when it detects an openpgp cert.  Or even
> more generally, when gnutls_credentials_set() detects a unknown
> certtype, it requests a vtype for the certtype.  Somehow.

I don't see any benefit in having per-session certificate types:
certificate types exist independently of sessions, conceptually.

> OTOH, if we call the functions _gnutls_certtype_add and
> _gnutls_certtype_get instead, and document that they should only ever
> be called by libgnutls-extra, and never by external programs, it seems
> fine to use a global variable to store the function pointers --
> different applications will never set different pointers, and they
> will only ever be either NULL values or pointers to the loaded
> gnutls-extra library.  What do you think?

The question to ask is how much flexibility is needed, and how
independent `libgnutls' and `libgnutls-extra' should be from each other?

Currently, the set of certificate types is fixes and (I suppose)
unlikely to change too often.  So we have `gnutls_certificate_type_t' as
an enum whose values are statically assigned in `libgnutls'.

If we were to opt for full flexibility (and a user-visible certificate
type registration mechanism), then we could have something like this:

  in libgnutls:

    typedef void *gnutls_certificate_t;

    typedef struct gnutls_certificate_type
    {
      const char *name;
      int (* certificate_init) (gnutls_certificate_t *);
      ...
    } *gnutls_certificate_type_t;

  in libgnutls-extra (initialization code):

    openpgp_cert_type = gnutls_certificate_type_new ("OpenPGP", ...);

The issue is that this adds quite a bit of overhead (at initialization
time mostly) and this requires us to have a very well chosen set of
per-certificate-type methods so that people can actually implement
unforeseen certificate authentications.  But maybe such a thing would be
over-designed?

Thus, I had in mind a simpler approach, were `gnutls_certificate_t'
remains unchanged (i.e., static), and where the certificate type
registration API is purely internal.

> Well, yes, but since it breaks API/ABI it is not for 1.6, and for 1.7
> we can think bigger. :) But if you want, and write a quick fix for
> this, that would break the API/ABI, we can install it now, and then
> work on the above plan next (which also breaks the API/ABI, but for
> good reasons).  I doubt it will save much time, though...

Would the fix I originally posted (and which breaks API/ABI) be
acceptable for 1.7 in the short term?

  http://lists.gnu.org/archive/html/help-gnutls/2006-12/msg00005.html

> If you plan to work on this, you need to fill out a copyright
> assignment form for us to be able to use the work.  If this is ok, I
> can send you the form to use.

Hey, you just sent it a few hours ago (and I already sent it to
`assign at gnu.org')!  ;-)

Thanks,
Ludovic.





From ludovic.courtes at laas.fr  Tue Jan  9 15:51:18 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 09 Jan 2007 15:51:18 +0100
Subject: [Help-gnutls] Re: Getting keys for my own crtypto functions
	(opencdk)
References: <1168074918.3206.6.camel@mario>
	<87r6u5a5fn.fsf@latte.josefsson.org>
Message-ID: <87lkkcjlsp.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> PS.  Maybe you are aware of it, but did you look at GPGME?  It has
> more PGP stuff, and written in a more GnuPG compatible way.  I know it
> has some limitations though.  I'd wish that GnuTLS could use it
> instead of OpenCDK, but right now it doesn't...

I had this feeling, at first, but for some purposes GPGME turns out to
be too high-level, and too much GPG-oriented.  For instance, while
gnutls-extra currently provides first-class public/private and keyring
objects, GPGME doesn't provide such a thing.  Instead, GPGME expects any
key that is to be handled to be imported in the per-user GPG keyring.

That can be quite inconvenient for applications that use keys
meaningless to the user (as a person), or that do not want keys to be
stored on the file system just because they were imported once for
verification purposes.

Thanks,
Ludovic.





From ranjit at motorola.com  Wed Jan 10 08:05:57 2007
From: ranjit at motorola.com (Avasarala Ranjit-A20990)
Date: Wed, 10 Jan 2007 15:05:57 +0800
Subject: [Help-gnutls] Running srp/tls from windows version of gnutls
In-Reply-To: <87fyalupy5.fsf@latte.josefsson.org>
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B03CDC268@ZMY16EXM66.ds.mot.com>

Hi

Can I run the programs ex-client-srp and ex-serv-srp from windows
version of gnutls? Is yes how do I go about it?

Thanks 


Regards
Ranjit




From sascha.ziemann at secunet.com  Wed Jan 10 12:03:16 2007
From: sascha.ziemann at secunet.com (Sascha Ziemann)
Date: Wed, 10 Jan 2007 12:03:16 +0100
Subject: [Help-gnutls] How to restrict certification path length
Message-ID: <45A4C7F4.60204@secunet.com>

Hi,

is it possible to specify the maximum certification path length in a
configuration file for certtool? Internet explorer reports the path
length of certificates made by certtool as unlimited.

I have a Root CA, which signs an Issuer CA, and an Issuer CA , which
signs client and server certificates. I would like to restrict the path
length of the Root CA to two and the path length of the issuer CA to one
in order to avoid any hacks made with the client or server certificates.

Regards,
Ziemann





From mario.lenz at gmx.net  Wed Jan 10 19:39:54 2007
From: mario.lenz at gmx.net (Mario Lenz)
Date: Wed, 10 Jan 2007 19:39:54 +0100
Subject: [Help-gnutls] Re: Getting keys for my own crtypto functions
	(opencdk)
In-Reply-To: <87r6u5a5fn.fsf@latte.josefsson.org>
References: <1168074918.3206.6.camel@mario>
	<87r6u5a5fn.fsf@latte.josefsson.org>
Message-ID: <1168454394.3210.16.camel@mario>

Hi!

> This approach seems acceptable, and if you implement it (or some
> variant of this), I'd be happy to make that part of the official API.

Would you please have a look at these functions? If you think they're ok
I'll do some tests:

/**
 * cdk_pubkey_to_sexp:
 * @pk:
 * @sexp:
 * @len: where to store the length of sexp (may be NULL)
 *
 * Convert a public key to an S- expression. sexp is allocated
 * by this function, so you have to cdk_free() the memory when you don't
 * need it any more.
 **/

int
cdk_pubkey_to_sexp (cdk_pkt_pubkey_t pk, char **sexp, size_t * len)
{
  int rc;
  char *buf;
  size_t sexp_len;
  gcry_sexp_t pk_sexp;

  if (!pk || !sexp)
    return CDK_Inv_Value;

  rc = pubkey_to_sexp (&pk_sexp, pk);
  if (rc)
    return rc;

  sexp_len = gcry_sexp_sprint (pk_sexp, GCRYSEXP_FMT_CANON, NULL, 0);
  if (!sexp_len)
    {
      gcry_sexp_release (pk_sexp);
      return CDK_Gcry_Error;
    }

  buf = (char *) cdk_malloc (sexp_len);
  if (!buf)
    {
      gcry_sexp_release (pk_sexp);
      return CDK_Out_Of_Core;
    }

  sexp_len =
    gcry_sexp_sprint (pk_sexp, GCRYSEXP_FMT_CANON, pk_sexp, sexp_len);

  gcry_sexp_release (pk_sexp);

  if (!sexp_len)
    {
      cdk_free (buf);
      return CDK_Gcry_Error;
    }

  if (len)
    *len = sexp_len;
  *sexp = buf;

  return 0;
}

/**
 * cdk_seckey_to_sexp:
 * @sk:
 * @sexp:
 * @len: where to store the length of sexp (may be NULL)
 *
 * Convert a secret key to an S- expression. sexp is allocated
 * by this function, so you have to cdk_free() the memory when you don't
 * need it any more.
 **/

int
cdk_seckey_to_sexp (cdk_pkt_seckey_t sk, char **sexp, size_t * len)
{
  int rc;
  char *buf;
  size_t sexp_len;
  gcry_sexp_t sk_sexp;

  if (!sk || !sexp)
    return CDK_Inv_Value;

  rc = seckey_to_sexp (&sk_sexp, sk);
  if (rc)
    return rc;

  sexp_len = gcry_sexp_sprint (sk_sexp, GCRYSEXP_FMT_CANON, NULL, 0);
  if (!sexp_len)
    {
      gcry_sexp_release (sk_sexp);
      return CDK_Gcry_Error;
    }

  buf = (char *) cdk_malloc (sexp_len);
  if (!buf)
    {
      gcry_sexp_release (sk_sexp);
      return CDK_Out_Of_Core;
    }

  sexp_len =
    gcry_sexp_sprint (sk_sexp, GCRYSEXP_FMT_CANON, sk_sexp, sexp_len);

  gcry_sexp_release (sk_sexp);

  if (!sexp_len)
    {
      cdk_free (buf);
      return CDK_Gcry_Error;
    }

  if (len)
    *len = sexp_len;
  *sexp = buf;

  return 0;
}

cu

   Mario

-- 
Wieners, in buns, no condiments. It's Hank's way. Anything else is
wrong.





From mario.lenz at gmx.net  Thu Jan 11 07:38:45 2007
From: mario.lenz at gmx.net (Mario Lenz)
Date: Thu, 11 Jan 2007 06:38:45 +0000 (UTC)
Subject: [Help-gnutls] Re: Getting keys for my own crtypto
	functions	(opencdk)
References: <1168074918.3206.6.camel@mario>
	<87r6u5a5fn.fsf@latte.josefsson.org>
	<1168454394.3210.16.camel@mario>
Message-ID: <loom.20070111T072544-517@post.gmane.org>

Argument #3 of gcry_sexp_sprint() should be buf, of course. Well, just tell me
if this would be ok *in general* and I'll do some tests.

greez

   Mario

PS
I used GCRYSEXP_FMT_CANON because GCRYSEXP_FMT_DEFAULT sounds like a libgcrypt
default. The canonical format might be easier to use if someone wants to / has
to use some other crypto lib.





From simon at josefsson.org  Thu Jan 11 08:01:33 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 11 Jan 2007 08:01:33 +0100
Subject: [Help-gnutls] Re: Getting keys for my own crtypto functions
	(opencdk)
In-Reply-To: <1168454394.3210.16.camel@mario> (Mario Lenz's message of "Wed\, 
	10 Jan 2007 19\:39\:54 +0100")
References: <1168074918.3206.6.camel@mario>
	<87r6u5a5fn.fsf@latte.josefsson.org> <1168454394.3210.16.camel@mario>
Message-ID: <87fyaioxma.fsf@latte.josefsson.org>

Mario Lenz <mario.lenz at gmx.net> writes:

> Hi!
>
>> This approach seems acceptable, and if you implement it (or some
>> variant of this), I'd be happy to make that part of the official API.
>
> Would you please have a look at these functions? If you think they're ok
> I'll do some tests:

Hi!  Yes, that was what I had in mind.

> I used GCRYSEXP_FMT_CANON because GCRYSEXP_FMT_DEFAULT sounds like a libgcrypt
> default. The canonical format might be easier to use if someone wants to / has
> to use some other crypto lib.

Agreed.

Btw, you'll need to assign the copyright of your patch for us to be
able to use it.  I hope this is ok.  I'll send you the form privately.

/Simon




From simon at josefsson.org  Thu Jan 11 08:09:25 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 11 Jan 2007 08:09:25 +0100
Subject: [Help-gnutls] Re: Failure to import an OpenPGP private key
In-Reply-To: <873b6kmff3.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?=
	message of "Tue\, 09 Jan 2007 15\:40\:48 +0100")
References: <87u01rxgqg.fsf@laas.fr> <87lkn2or1x.fsf@latte.josefsson.org>
	<87wt6mkt3b.fsf@laas.fr> <87odru40bq.fsf@latte.josefsson.org>
	<87fybjbvbz.fsf@laas.fr> <878xgsa0e3.fsf@latte.josefsson.org>
	<87lkkhoclo.fsf@laas.fr> <87fyalupy5.fsf@latte.josefsson.org>
	<87ac0sv7p7.fsf@laas.fr> <87k5zwsbte.fsf@latte.josefsson.org>
	<873b6kmff3.fsf@laas.fr>
Message-ID: <877ivuox96.fsf@latte.josefsson.org>

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

> Simon Josefsson <simon at josefsson.org> writes:
>
>> Good ideas!  I agree that we should use function indirections rather
>> than variables, because having variables be part of a API/ABI is a bad
>> idea, and causes problems on mingw32.  So there would be two
>> functions:
>>
>> void gnutls_certtype_add (int certtype, struct gnutls_certtype_functions *hooks)
>>
>> struct gnutls_certtype_functions * gnutls_certtype_get (int certtype)
>>
>> which would register a new certtype with GnuTLS.
>>
>> As prototyped, that would use global variables, which probably is a
>> bad idea, but I'm not sure what a good alternative would be -- more
>> thoughts about that is required.  Perhaps this should be set
>> per-session?  But that creates some extra work for every session, and
>> that seems annoying...  OTOH, that could be hidden in
>> gnutls_credentials_set() when it detects an openpgp cert.  Or even
>> more generally, when gnutls_credentials_set() detects a unknown
>> certtype, it requests a vtype for the certtype.  Somehow.
>
> I don't see any benefit in having per-session certificate types:
> certificate types exist independently of sessions, conceptually.

Yup.  Making them per-session would be a way to avoid global
variables, though.

>> OTOH, if we call the functions _gnutls_certtype_add and
>> _gnutls_certtype_get instead, and document that they should only ever
>> be called by libgnutls-extra, and never by external programs, it seems
>> fine to use a global variable to store the function pointers --
>> different applications will never set different pointers, and they
>> will only ever be either NULL values or pointers to the loaded
>> gnutls-extra library.  What do you think?
>
> The question to ask is how much flexibility is needed, and how
> independent `libgnutls' and `libgnutls-extra' should be from each other?
>
> Currently, the set of certificate types is fixes and (I suppose)
> unlikely to change too often.  So we have `gnutls_certificate_type_t' as
> an enum whose values are statically assigned in `libgnutls'.
>
> If we were to opt for full flexibility (and a user-visible certificate
> type registration mechanism), then we could have something like this:
>
>   in libgnutls:
>
>     typedef void *gnutls_certificate_t;
>
>     typedef struct gnutls_certificate_type
>     {
>       const char *name;
>       int (* certificate_init) (gnutls_certificate_t *);
>       ...
>     } *gnutls_certificate_type_t;
>
>   in libgnutls-extra (initialization code):
>
>     openpgp_cert_type = gnutls_certificate_type_new ("OpenPGP", ...);
>
> The issue is that this adds quite a bit of overhead (at initialization
> time mostly) and this requires us to have a very well chosen set of
> per-certificate-type methods so that people can actually implement
> unforeseen certificate authentications.  But maybe such a thing would be
> over-designed?

Yes, I think so.  We can't anticipate what requirement future
certificate types might have, and it will likely not be generic enough
anyway.  This kind of abstraction isn't part of the TLS standard
anyway, so it makes little sense to over-design in this area.

> Thus, I had in mind a simpler approach, were `gnutls_certificate_t'
> remains unchanged (i.e., static), and where the certificate type
> registration API is purely internal.

This seems simpler, yes... so the registration functions should
probably be called _gnutls_register_extra_openpgp_certtype() or
whatever.  This avoids giving false expectation too.

>> Well, yes, but since it breaks API/ABI it is not for 1.6, and for 1.7
>> we can think bigger. :) But if you want, and write a quick fix for
>> this, that would break the API/ABI, we can install it now, and then
>> work on the above plan next (which also breaks the API/ABI, but for
>> good reasons).  I doubt it will save much time, though...
>
> Would the fix I originally posted (and which breaks API/ABI) be
> acceptable for 1.7 in the short term?
>
>   http://lists.gnu.org/archive/html/help-gnutls/2006-12/msg00005.html

Yes, that seems ok.  I'll see if I can implement the above, cleaner,
approach fast though.  Or if you want to work on that... :) If I
forget about this, just remind me and I'll apply your patch.

>> If you plan to work on this, you need to fill out a copyright
>> assignment form for us to be able to use the work.  If this is ok, I
>> can send you the form to use.
>
> Hey, you just sent it a few hours ago (and I already sent it to
> `assign at gnu.org')!  ;-)

Well, duh.  That would explains my sense of deja vu, then.  Sorry.

/Simon




From simon at josefsson.org  Thu Jan 11 09:18:55 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 11 Jan 2007 09:18:55 +0100
Subject: [Help-gnutls] Re: Failure to import an OpenPGP private key
In-Reply-To: <877ivuox96.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Thu\, 11 Jan 2007 08\:09\:25 +0100")
References: <87u01rxgqg.fsf@laas.fr> <87lkn2or1x.fsf@latte.josefsson.org>
	<87wt6mkt3b.fsf@laas.fr> <87odru40bq.fsf@latte.josefsson.org>
	<87fybjbvbz.fsf@laas.fr> <878xgsa0e3.fsf@latte.josefsson.org>
	<87lkkhoclo.fsf@laas.fr> <87fyalupy5.fsf@latte.josefsson.org>
	<87ac0sv7p7.fsf@laas.fr> <87k5zwsbte.fsf@latte.josefsson.org>
	<873b6kmff3.fsf@laas.fr> <877ivuox96.fsf@latte.josefsson.org>
Message-ID: <873b6iou1c.fsf@latte.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> Yes, that seems ok.  I'll see if I can implement the above, cleaner,
> approach fast though.

Installed in CVS now.  Could you suggest the patch to fix your
original problem, using this new scheme?

I just realized a thing: I'm not sure we are really breaking the
API/ABI here though.  No public API/ABI is modified, only internal
_gnutls_* APIs.  The same holds for your first patch.  Changing
_gnutls_* APIs without bumping the shared library version should be
ok, right?  gnutls-extra should be the only user of those _gnutls*
symbols, and libgnutls-extra is only ever guaranteed to work with the
same version of libgnutls (and gnutls_global_init_extra already checks
this).

Anyway, I think the installed patch is cleaner.  For one, it removed
including GPL'd gnutls-extra header files in the LGPL'd libgnutls,
which seems like a good step.  There are still some variables which
are used between gnutls and gnutls-extra, but I'll see if they cause
any real problems (e.g., on mingw32) before working on moving those to
a function-based API.

/Simon




From simon at josefsson.org  Thu Jan 11 09:21:48 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 11 Jan 2007 09:21:48 +0100
Subject: [Help-gnutls] Re: Running srp/tls from windows version of gnutls
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B03CDC268@ZMY16EXM66.ds.mot.com>
	(Avasarala Ranjit-A's message of "Wed\, 10 Jan 2007 15\:05\:57 +0800")
References: <87fyalupy5.fsf@latte.josefsson.org>
	<750BBC72E178114F9DC4872EBFF29A5B03CDC268@ZMY16EXM66.ds.mot.com>
Message-ID: <87y7oanfc3.fsf@latte.josefsson.org>

"Avasarala Ranjit-A20990" <ranjit at motorola.com> writes:

> Hi
>
> Can I run the programs ex-client-srp and ex-serv-srp from windows
> version of gnutls? Is yes how do I go about it?

Hi!  I haven't tested it, but yes, I think that should work.  The
examples are built, and installed by the Windows installer in
C:\Program Files\GnuTLS-1.2.3\bin.  You'll have to make sure the
relevant files are present in the working directory (same as for
Unix), but other than that, I don't think anything extra is needed.

Since this is untested, you get to be the first one who tests this...
Let us know if it works for you.

/Simon




From simon at josefsson.org  Thu Jan 11 11:41:28 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 11 Jan 2007 11:41:28 +0100
Subject: [Help-gnutls] Re: How to restrict certification path length
In-Reply-To: <45A4C7F4.60204@secunet.com> (Sascha Ziemann's message of "Wed\, 
	10 Jan 2007 12\:03\:16 +0100")
References: <45A4C7F4.60204@secunet.com>
Message-ID: <87odp5onfr.fsf@latte.josefsson.org>

Sascha Ziemann <sascha.ziemann at secunet.com> writes:

> Hi,
>
> is it possible to specify the maximum certification path length in a
> configuration file for certtool? Internet explorer reports the path
> length of certificates made by certtool as unlimited.
>
> I have a Root CA, which signs an Issuer CA, and an Issuer CA , which
> signs client and server certificates. I would like to restrict the path
> length of the Root CA to two and the path length of the issuer CA to one
> in order to avoid any hacks made with the client or server certificates.

Hi!  This is not possible today, but I implemented this in CVS.
Thanks for the suggestion!  You can try CVS now, or tomorrow's daily
snapshot.  Please let me know if/how it works.  Here are the NEWS
entries:

** Certtool now print the value of the pathLenConstraints field for certs.

** Certtool now query for path length constraints when generating CA certs.
For batch uses, the certtool configuration name is "path_len".
Suggested by Sascha Ziemann <sascha.ziemann at secunet.com>.

** Add new API to get/set pathLenConstraint in the Basic Constraints.
The new functions gnutls_x509_crt_get_basic_constraints and
gnutls_x509_crt_set_basic_constraints provide a superset of the
functionality in the old gnutls_x509_crt_get_ca_status and
gnutls_x509_crt_set_ca_status (respectively), but the old functions
will continue to be supported.

** API and ABI modifications:
gnutls_x509_crt_get_basic_constraints: ADD.
gnutls_x509_crt_set_basic_constraints: ADD.

/Simon




From bohtvaroh at gmail.com  Thu Jan 11 14:26:32 2007
From: bohtvaroh at gmail.com (Alexander Semyonov)
Date: Thu, 11 Jan 2007 15:26:32 +0200
Subject: [Help-gnutls] STARTTLS example using GnuTLS C api
Message-ID: <b44075f80701110526w4ce090b5xef17ceb92e14d8f0@mail.gmail.com>

Hi. I am implementing Jabber (XMPP) protocol and I need an example about
acompleting the starttls procedure with gnutls api (as I understood - switch
to secure tcp connection on existing unsecure one). I tried Google but
couldnt find any example. Can someone supply me with it? Thanx.

Alexander Semyonov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20070111/727009ad/attachment.htm>

From simon at josefsson.org  Thu Jan 11 15:05:58 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 11 Jan 2007 15:05:58 +0100
Subject: [Help-gnutls] Re: STARTTLS example using GnuTLS C api
In-Reply-To: <b44075f80701110526w4ce090b5xef17ceb92e14d8f0@mail.gmail.com>
	(Alexander Semyonov's message of "Thu\, 11 Jan 2007 15\:26\:32 +0200")
References: <b44075f80701110526w4ce090b5xef17ceb92e14d8f0@mail.gmail.com>
Message-ID: <87bql5odyx.fsf@latte.josefsson.org>

"Alexander Semyonov" <bohtvaroh at gmail.com> writes:

> Hi. I am implementing Jabber (XMPP) protocol and I need an example about
> acompleting the starttls procedure with gnutls api (as I understood - switch
> to secure tcp connection on existing unsecure one). I tried Google but
> couldnt find any example. Can someone supply me with it? Thanx.

GNU SASL uses GnuTLS to do STARTTLS for IMAP and SMTP, look at
src/gsasl.c, although it is a rather complex example.  GnuTLS doesn't
care if you use starttls, the API you use are the same, so you could
take a look at the examples in the manual:

http://www.gnu.org/software/gnutls/manual/html_node/Simple-client-example-with-anonymous-authentication.html

Insert your read/write's to negotiate STARTTLS in the unprotected
protocol, right after the call to tcp_connect().

/Simon




From smurf at smurf.noris.de  Thu Jan 11 15:06:55 2007
From: smurf at smurf.noris.de (Matthias Urlichs)
Date: Thu, 11 Jan 2007 15:06:55 +0100
Subject: [Help-gnutls] STARTTLS example using GnuTLS C api
In-Reply-To: <b44075f80701110526w4ce090b5xef17ceb92e14d8f0@mail.gmail.com>
References: <b44075f80701110526w4ce090b5xef17ceb92e14d8f0@mail.gmail.com>
Message-ID: <20070111140655.GC19609@kiste.smurf.noris.de>

Hi,

Alexander Semyonov:
> Hi. I am implementing Jabber (XMPP) protocol and I need an example about
> acompleting the starttls procedure with gnutls api (as I understood - switch
> to secure tcp connection on existing unsecure one). I tried Google but
> couldnt find any example. Can someone supply me with it? Thanx.
> 
The gnutls-cli command line program does that.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf at smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Of course, Ankh-Morpork's citizens had always claimed that the river water
was incredibly pure. Any water that had passed through so many kidneys,
they reasoned, had to be very pure indeed.
		-- Terry Pratchett (Sourcery)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: </pipermail/attachments/20070111/311cab0b/attachment.pgp>

From simon at josefsson.org  Thu Jan 11 15:14:04 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 11 Jan 2007 15:14:04 +0100
Subject: [Help-gnutls] Re: Problem starting gnutls-serv with PSK support
In-Reply-To: <753251.59363.qm@web90608.mail.mud.yahoo.com> (Sebastian Hans's
	message of "Mon\, 1 Jan 2007 08\:46\:11 -0800 \(PST\)")
References: <753251.59363.qm@web90608.mail.mud.yahoo.com>
Message-ID: <877ivtodlf.fsf@latte.josefsson.org>

Sebastian Hans <sebastian_hans at yahoo.com> writes:

> Hi,
>
> I have problems starting gnutls-serv with support for the PSK keyexchange. When I run the gnutls-cli-debug against the server the output shows that no protocol is supported.
>
> To start the gnutls-serv I use the following command
>
> gnutls-serv -d 10 -p 4433 --http --ciphers AES --protocols TLS1.1 --kx PSK --pskpasswd sha16.psk
>
> the output generated by gnutls-cli-debug is:
>
> C:\downloads\SSL-APIs\GnuTLS\bin>gnutls-cli-debug localhost -p 4433
> Resolving 'localhost'...
> Connecting to '127.0.0.1:4433'...
> Checking for TLS 1.1 support... no
> Checking fallback from TLS 1.1 to... failed
> Checking for TLS 1.0 support... no
> Checking for SSL 3.0 support... no
>
> Server does not support none of SSL 3.0, TLS 1.0 and TLS 1.1

Yeah, gnutls-cli-debug doesn't try with that many cipher suites, so it
will fail to negotiate anything if the server only supports strange
ciphers.  This isn't Windows-specific.

I think we could make gnutls-serv always support ANON_DH by using
static DH parameters, unless the user provided real parameters.  But
if a server only supports, say, PSK, gnutls-cli-debug will not be able
to connect unless it knows the PSK details.

> I tried a lot of variations but nothing worked.

Try to use gnutls-cli directly instead:

$ ./gnutls-cli localhost -p 4433 --pskusername jas --pskkey db2d5ef736e7e03a167f25dd2023d19a
Resolving 'localhost'...
Connecting to '127.0.0.1:4433'...
- Version: TLS 1.1
- Key Exchange: PSK
- Cipher: AES 128 CBC
- MAC: SHA
- Compression: DEFLATE
- Handshake was completed

- Simple Client Mode:
...

/Simon




From sascha.ziemann at secunet.com  Thu Jan 11 16:22:41 2007
From: sascha.ziemann at secunet.com (Sascha Ziemann)
Date: Thu, 11 Jan 2007 16:22:41 +0100
Subject: [Help-gnutls] Include CA certificate in PKCS12
Message-ID: <45A65641.4070907@secunet.com>

Hi,

it is useful to include the certificate of the CAs into a PKCS12 file,
when delivering client PSEs. I tried to use the option
--load-certificate twice while running "certtool --to-p12" but this does
not seem to work. I also tried --load-ca-certificate but that does not
work either.

What is the right way to include two CA certificates into a PKCS12 file?

Regards,
Ziemann





From simon at josefsson.org  Thu Jan 11 21:47:39 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 11 Jan 2007 21:47:39 +0100
Subject: [Help-gnutls] Re: Include CA certificate in PKCS12
In-Reply-To: <45A65641.4070907@secunet.com> (Sascha Ziemann's message of "Thu\,
	11 Jan 2007 16\:22\:41 +0100")
References: <45A65641.4070907@secunet.com>
Message-ID: <87zm8pb89g.fsf@latte.josefsson.org>

Sascha Ziemann <sascha.ziemann at secunet.com> writes:

> Hi,
>
> it is useful to include the certificate of the CAs into a PKCS12 file,
> when delivering client PSEs. I tried to use the option
> --load-certificate twice while running "certtool --to-p12" but this does
> not seem to work. I also tried --load-ca-certificate but that does not
> work either.
>
> What is the right way to include two CA certificates into a PKCS12 file?

Hi!  Right now this isn't possible, but I implemented support for this
in CVS.  I haven't tested the resulting PKCS#12 blob with anything, so
I don't know exactly what various programs expect.  Unfortunately,
there are many ways to store multiple certificates in a PKCS#12
file...  Please let me know if/how it works for you.  Here is the news
entry:

** Certtool --to-p12 can now store more than one certificate in the blob.
Before it could only store one certificate, but now it will read and
store as many certificate there are from the --load-certificate file.
Suggested by Sascha Ziemann <sascha.ziemann at secunet.com>.

A sample run:

jas at mocca:~/src/gnutls/src$ ./certtool --to-p12 --load-certificate foo.pem > bar.p12
Generating a PKCS #12 structure...
Loading certificate list...
Loaded 3 certificates.
Enter a name for the key: hepp
Enter password:
jas at mocca:~/src/gnutls/src$

At least certtool is able to read and parse the result...

/Simon




From simon at josefsson.org  Fri Jan 12 15:06:57 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 12 Jan 2007 15:06:57 +0100
Subject: [Help-gnutls] Re: Include CA certificate in PKCS12
In-Reply-To: <45A74F53.5010806@secunet.com> (Sascha Ziemann's message of "Fri\,
	12 Jan 2007 10\:05\:23 +0100")
References: <45A65641.4070907@secunet.com>
	<87zm8pb89g.fsf@latte.josefsson.org> <45A74F53.5010806@secunet.com>
Message-ID: <87mz4oz6da.fsf@latte.josefsson.org>

Sascha Ziemann <sascha.ziemann at secunet.com> writes:

> Simon Josefsson schrieb:
>> Hi!  Right now this isn't possible, but I implemented support for this
>> in CVS.  I haven't tested the resulting PKCS#12 blob with anything, so
>> I don't know exactly what various programs expect.  Unfortunately,
>> there are many ways to store multiple certificates in a PKCS#12
>> file...  Please let me know if/how it works for you.
> Thanks! I tried todays snapshot. It works fine with Internet Explorer 6.
> I was able to import all certificates of the certification path at once.
> But it does not work with Firefox 2.0.0.1. Maybe Firefox is not able to
> import CA certificates from PKCS12 files. I will try to figure this out.

Try changing the order of the certificates in the file, that may
matter...  Otherwise, you'll simply have to debug Firefox why it
doesn't work.  PKCS#12 interoperability is a mess.

/Simon




From mario.lenz at gmx.net  Sun Jan 14 15:18:04 2007
From: mario.lenz at gmx.net (Mario Lenz)
Date: Sun, 14 Jan 2007 14:18:04 +0000 (UTC)
Subject: [Help-gnutls] Re: Getting keys for my own crtypto
	functions	(opencdk)
References: <1168074918.3206.6.camel@mario>
	<87r6u5a5fn.fsf@latte.josefsson.org>
	<1168454394.3210.16.camel@mario>
	<87fyaioxma.fsf@latte.josefsson.org>
Message-ID: <loom.20070114T150348-80@post.gmane.org>

Hi!

> > Would you please have a look at these functions? If you think they're ok
> > I'll do some tests:
> 
> Hi!  Yes, that was what I had in mind.

I've done some tests now and everything's working.

to be included in opencdk.h:

cdk_error_t cdk_pubkey_to_sexp (cdk_pkt_pubkey_t pk, char **sexp, size_t * len);
cdk_error_t cdk_seckey_to_sexp (cdk_pkt_seckey_t sk, char **sexp, size_t * len);

to be added to src/pubkey.c:

/**
 * cdk_pubkey_to_sexp:
 * @pk: the public key
 * @sexp: where to store the S- expression
 * @len: the length of sexp
 *
 * Convert a public key to an S- expression. sexp is allocated
 * by this function, but you have to cdk_free() it yourself.
 * The S- expression is stored in canonical format as used by
 * libgcrypt (GCRYSEXP_FMT_CANON).
 **/

cdk_error_t
cdk_pubkey_to_sexp (cdk_pkt_pubkey_t pk, char **sexp, size_t * len)
{
  int rc;
  char *buf;
  size_t sexp_len;
  gcry_sexp_t pk_sexp;

  if (!pk || !sexp)
    return CDK_Inv_Value;

  rc = pubkey_to_sexp (&pk_sexp, pk);
  if (rc)
    return rc;

  sexp_len = gcry_sexp_sprint (pk_sexp, GCRYSEXP_FMT_CANON, NULL, 0);
  if (!sexp_len)
    {
      return CDK_Gcry_Error;
    }

  buf = (char *) cdk_malloc (sexp_len);
  if (!buf)
    {
      gcry_sexp_release (pk_sexp);
      return CDK_Out_Of_Core;
    }

  sexp_len =
    gcry_sexp_sprint (pk_sexp, GCRYSEXP_FMT_CANON, buf, sexp_len);

  gcry_sexp_release (pk_sexp);

  if (!sexp_len)
    {
      cdk_free (buf);
      return CDK_Gcry_Error;
    }

  if (len)
    *len = sexp_len;
  *sexp = buf;

  return CDK_Success;
}

/**
 * cdk_seckey_to_sexp:
 * @sk: the secret key
 * @sexp: where to store the S- expression
 * @len: the length of sexp
 *
 * Convert a public key to an S- expression. sexp is allocated
 * by this function, but you have to cdk_free() it yourself.
 * The S- expression is stored in canonical format as used by
 * libgcrypt (GCRYSEXP_FMT_CANON).
 **/

cdk_error_t
cdk_seckey_to_sexp (cdk_pkt_seckey_t sk, char **sexp, size_t * len)
{
  int rc;
  char *buf;
  size_t sexp_len;
  gcry_sexp_t sk_sexp;

  if (!sk || !sexp)
    return CDK_Inv_Value;

  rc = seckey_to_sexp (&sk_sexp, sk);
  if (rc)
    return rc;

  sexp_len = gcry_sexp_sprint (sk_sexp, GCRYSEXP_FMT_CANON, NULL, 0);
  if (!sexp_len)
    {
      return CDK_Gcry_Error;
    }

  buf = (char *) cdk_malloc (sexp_len);
  if (!buf)
    {
      gcry_sexp_release (sk_sexp);
      return CDK_Out_Of_Core;
    }

  sexp_len =
    gcry_sexp_sprint (sk_sexp, GCRYSEXP_FMT_CANON, buf, sexp_len);

  gcry_sexp_release (sk_sexp);

  if (!sexp_len)
    {
      cdk_free (buf);
      return CDK_Gcry_Error;
    }

  if (len)
    *len = sexp_len;
  *sexp = buf;

  return CDK_Success;
}


> Btw, you'll need to assign the copyright of your patch for us to be
> able to use it.  I hope this is ok.  I'll send you the form privately.

I've sent it just a moment ago.

greez

   Mario





From simon at josefsson.org  Sun Jan 14 22:23:23 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 14 Jan 2007 22:23:23 +0100
Subject: [Help-gnutls] Re: Getting keys for my own crtypto
	functions	(opencdk)
In-Reply-To: <loom.20070114T150348-80@post.gmane.org> (Mario Lenz's message of
	"Sun\, 14 Jan 2007 14\:18\:04 +0000 \(UTC\)")
References: <1168074918.3206.6.camel@mario>
	<87r6u5a5fn.fsf@latte.josefsson.org> <1168454394.3210.16.camel@mario>
	<87fyaioxma.fsf@latte.josefsson.org>
	<loom.20070114T150348-80@post.gmane.org>
Message-ID: <87d55hfgl0.fsf@latte.josefsson.org>

Mario Lenz <mario.lenz at gmx.net> writes:

> I've done some tests now and everything's working.

Great, added to CVS.

/Simon




From m at tthias.eu  Mon Jan 15 01:15:15 2007
From: m at tthias.eu (Matthias Wimmer)
Date: Mon, 15 Jan 2007 01:15:15 +0100
Subject: [Help-gnutls] STARTTLS example using GnuTLS C api
In-Reply-To: <b44075f80701110526w4ce090b5xef17ceb92e14d8f0@mail.gmail.com>
References: <b44075f80701110526w4ce090b5xef17ceb92e14d8f0@mail.gmail.com>
Message-ID: <45AAC793.9070103@tthias.eu>

Alexander Semyonov schrieb:
> Hi. I am implementing Jabber (XMPP) protocol and I need an example about 
> acompleting the starttls procedure with gnutls api (as I understood - 
> switch to secure tcp connection on existing unsecure one). I tried 
> Google but couldnt find any example. Can someone supply me with it? Thanx.

You can find an example in the current SVN version of jabberd14 as well, 
if you want to see it in some Jabber related code ;-)

http://svn.jabberd.org/trunk/jabberd14/jabberd/mio_tls.c

The function is mio_ssl_starttls() at the end of the file.


Matthias

-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Z?richer Str. 243    Fax +49-89 95 89 91 56
81476 M?nchen        http://ma.tthias.eu/





From ludovic.courtes at laas.fr  Mon Jan 15 11:25:31 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 15 Jan 2007 11:25:31 +0100
Subject: [Help-gnutls] Re: Failure to import an OpenPGP private key
References: <87u01rxgqg.fsf@laas.fr> <87lkn2or1x.fsf@latte.josefsson.org>
	<87wt6mkt3b.fsf@laas.fr> <87odru40bq.fsf@latte.josefsson.org>
	<87fybjbvbz.fsf@laas.fr> <878xgsa0e3.fsf@latte.josefsson.org>
	<87lkkhoclo.fsf@laas.fr> <87fyalupy5.fsf@latte.josefsson.org>
	<87ac0sv7p7.fsf@laas.fr> <87k5zwsbte.fsf@latte.josefsson.org>
	<873b6kmff3.fsf@laas.fr> <877ivuox96.fsf@latte.josefsson.org>
	<873b6iou1c.fsf@latte.josefsson.org>
Message-ID: <87ac0kvb6s.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Installed in CVS now.  Could you suggest the patch to fix your
> original problem, using this new scheme?

Thanks for doing it!  Attached is the updated patch.

> I just realized a thing: I'm not sure we are really breaking the
> API/ABI here though.  No public API/ABI is modified, only internal
> _gnutls_* APIs.  The same holds for your first patch.

Indeed, no _public_ ABI/API is modified.  That said, the ABI _is_
modified: one cannot use an older `libgnutls-extra' with a newer
`libgnutls' (or vice versa).  But that would have been an issue only if
one had been allowed to use different versions of `libgnutls-extra' and
`libgnutls' together.

> Changing
> _gnutls_* APIs without bumping the shared library version should be
> ok, right?  gnutls-extra should be the only user of those _gnutls*
> symbols, and libgnutls-extra is only ever guaranteed to work with the
> same version of libgnutls (and gnutls_global_init_extra already checks
> this).

Ok, so there's not problem.  ;-)

Changing the SO version should be ok.

> Anyway, I think the installed patch is cleaner.  For one, it removed
> including GPL'd gnutls-extra header files in the LGPL'd libgnutls,
> which seems like a good step.  There are still some variables which
> are used between gnutls and gnutls-extra, but I'll see if they cause
> any real problems (e.g., on mingw32) before working on moving those to
> a function-based API.

Good.

In my original message [0], I had in mind something that would implement
a slightly higher abstraction level over certificate types, such that no
X509/OpenPGP-specific code and no `switch (certtype)' need to appear in
`auth_cert.c' et al.  For instance, we'd move the
`proc_{x509,openpgp}_server_certificate ()' functions to specific files,
and instead just call
`_gnutls_cert_vtable[certtype].process_server_certificate ()', and so on.

But maybe it's a bit cosmetic.

Thanks,
Ludovic.

[0] http://lists.gnu.org/archive/html/help-gnutls/2007-01/msg00008.html


ChangeLog entry:

	* lib/gnutls_cert.c (_gnutls_raw_privkey_to_gkey): Pass KEY_ENC to
	`_E_gnutls_openpgp_raw_privkey_to_gkey ()'.

	* lib/gnutls_extra_hooks.h
	(_gnutls_openpgp_raw_privkey_to_gkey_func): Added a
	`gnutls_openpgp_key_fmt_t' argument.

	* libextra/gnutls_openpgp.c
	(_gnutls_openpgp_raw_privkey_to_gkey): Take a new FORMAT
	argument.  When FORMAT is `BASE64', set the armor flag on OUT.
	(gnutls_certificate_set_openpgp_key_mem): Pass
	`GNUTLS_OPENPGP_FMT_RAW' as the last argument to
	`_gnutls_openpgp_raw_privkey_to_gkey ()'.

	* libextra/openpgp/gnutls_openpgp.h
	(_gnutls_openpgp_raw_privkey_to_gkey): Updated accordingly.

	* libextra/openpgp/privkey.c (gnutls_openpgp_privkey_import):
	Pass FORMAT to `_gnutls_openpgp_raw_privkey_to_gkey ()'.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ,,armored-priv-key-2.diff
Type: text/x-diff
Size: 3623 bytes
Desc: The updated patch.
URL: </pipermail/attachments/20070115/0cd10b86/attachment.diff>

From simon at josefsson.org  Tue Jan 16 11:14:35 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 16 Jan 2007 11:14:35 +0100
Subject: [Help-gnutls] Re: Failure to import an OpenPGP private key
In-Reply-To: <87ac0kvb6s.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?=
	message of "Mon\, 15 Jan 2007 11\:25\:31 +0100")
References: <87u01rxgqg.fsf@laas.fr> <87lkn2or1x.fsf@latte.josefsson.org>
	<87wt6mkt3b.fsf@laas.fr> <87odru40bq.fsf@latte.josefsson.org>
	<87fybjbvbz.fsf@laas.fr> <878xgsa0e3.fsf@latte.josefsson.org>
	<87lkkhoclo.fsf@laas.fr> <87fyalupy5.fsf@latte.josefsson.org>
	<87ac0sv7p7.fsf@laas.fr> <87k5zwsbte.fsf@latte.josefsson.org>
	<873b6kmff3.fsf@laas.fr> <877ivuox96.fsf@latte.josefsson.org>
	<873b6iou1c.fsf@latte.josefsson.org> <87ac0kvb6s.fsf@laas.fr>
Message-ID: <87r6tvwa5w.fsf@latte.josefsson.org>

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

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Installed in CVS now.  Could you suggest the patch to fix your
>> original problem, using this new scheme?
>
> Thanks for doing it!  Attached is the updated patch.

Applied.

>> I just realized a thing: I'm not sure we are really breaking the
>> API/ABI here though.  No public API/ABI is modified, only internal
>> _gnutls_* APIs.  The same holds for your first patch.
>
> Indeed, no _public_ ABI/API is modified.  That said, the ABI _is_
> modified: one cannot use an older `libgnutls-extra' with a newer
> `libgnutls' (or vice versa).  But that would have been an issue only if
> one had been allowed to use different versions of `libgnutls-extra' and
> `libgnutls' together.

Right.  That has never been allowed, and I don't see the point in
permitting that.  libgnutls and libgnutls-extra are tightly coupled.

> In my original message [0], I had in mind something that would implement
> a slightly higher abstraction level over certificate types, such that no
> X509/OpenPGP-specific code and no `switch (certtype)' need to appear in
> `auth_cert.c' et al.  For instance, we'd move the
> `proc_{x509,openpgp}_server_certificate ()' functions to specific files,
> and instead just call
> `_gnutls_cert_vtable[certtype].process_server_certificate ()', and so on.

Yes, I think that would be nice.  All the code could then do something
like:

 if (_gnutls_cert_vtable[certtype])
   _gnutls_cert_vtable[certtype].process_server_certificate ()
 else
   return GNUTLS_E_INIT_LIBEXTRA;

Would you like to propose a patch for that?  I'd expect it to only
require changes to gnutls_cert.c/auth_cert.c...

/Simon




From ludovic.courtes at laas.fr  Tue Jan 16 11:27:48 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 16 Jan 2007 11:27:48 +0100
Subject: [Help-gnutls] Re: Failure to import an OpenPGP private key
References: <87u01rxgqg.fsf@laas.fr> <87lkn2or1x.fsf@latte.josefsson.org>
	<87wt6mkt3b.fsf@laas.fr> <87odru40bq.fsf@latte.josefsson.org>
	<87fybjbvbz.fsf@laas.fr> <878xgsa0e3.fsf@latte.josefsson.org>
	<87lkkhoclo.fsf@laas.fr> <87fyalupy5.fsf@latte.josefsson.org>
	<87ac0sv7p7.fsf@laas.fr> <87k5zwsbte.fsf@latte.josefsson.org>
	<873b6kmff3.fsf@laas.fr> <877ivuox96.fsf@latte.josefsson.org>
	<873b6iou1c.fsf@latte.josefsson.org> <87ac0kvb6s.fsf@laas.fr>
	<87r6tvwa5w.fsf@latte.josefsson.org>
Message-ID: <87y7o3l10b.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Applied.

Thanks!

> Yes, I think that would be nice.  All the code could then do something
> like:
>
>  if (_gnutls_cert_vtable[certtype])
>    _gnutls_cert_vtable[certtype].process_server_certificate ()
>  else
>    return GNUTLS_E_INIT_LIBEXTRA;

Exactly.

> Would you like to propose a patch for that?  I'd expect it to only
> require changes to gnutls_cert.c/auth_cert.c...

I might be able to do that but I can't really make any commitment at
this point due to other deadlines.  I'll let you know when/if I give it
a try.

Thanks,
Ludovic.





From ludovic.courtes at laas.fr  Tue Jan 16 14:54:46 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 16 Jan 2007 14:54:46 +0100
Subject: [Help-gnutls] TLS/OpenPGP draft expiring soon
Message-ID: <87zm8jhyah.fsf@laas.fr>

Hi,

I just noticed that the proposal to extend TLS to support OpenPGP
certificates written by Nikos Mavrogiannopoulos expires on February 1st:

  http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-11.txt

Are there any news regarding this?

Thanks,
Ludovic.





From simon at josefsson.org  Tue Jan 16 16:58:01 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 16 Jan 2007 16:58:01 +0100
Subject: [Help-gnutls] Re: TLS/OpenPGP draft expiring soon
In-Reply-To: <87zm8jhyah.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?=
	message of "Tue\, 16 Jan 2007 14\:54\:46 +0100")
References: <87zm8jhyah.fsf@laas.fr>
Message-ID: <87ejpvt14m.fsf@latte.josefsson.org>

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

> Hi,
>
> I just noticed that the proposal to extend TLS to support OpenPGP
> certificates written by Nikos Mavrogiannopoulos expires on February 1st:
>
>   http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-11.txt
>
> Are there any news regarding this?

Hi!  The document is in the RFC editor's queue, see:

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8235&rfc_flag=0

/Simon




From simon at josefsson.org  Tue Jan 16 17:02:02 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 16 Jan 2007 17:02:02 +0100
Subject: [Help-gnutls] Re: Failure to import an OpenPGP private key
In-Reply-To: <87y7o3l10b.fsf@laas.fr> (Ludovic =?iso-8859-1?Q?Court=E8s's?=
	message of "Tue\, 16 Jan 2007 11\:27\:48 +0100")
References: <87u01rxgqg.fsf@laas.fr> <87lkn2or1x.fsf@latte.josefsson.org>
	<87wt6mkt3b.fsf@laas.fr> <87odru40bq.fsf@latte.josefsson.org>
	<87fybjbvbz.fsf@laas.fr> <878xgsa0e3.fsf@latte.josefsson.org>
	<87lkkhoclo.fsf@laas.fr> <87fyalupy5.fsf@latte.josefsson.org>
	<87ac0sv7p7.fsf@laas.fr> <87k5zwsbte.fsf@latte.josefsson.org>
	<873b6kmff3.fsf@laas.fr> <877ivuox96.fsf@latte.josefsson.org>
	<873b6iou1c.fsf@latte.josefsson.org> <87ac0kvb6s.fsf@laas.fr>
	<87r6tvwa5w.fsf@latte.josefsson.org> <87y7o3l10b.fsf@laas.fr>
Message-ID: <87ac0jt0xx.fsf@latte.josefsson.org>

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

>> Yes, I think that would be nice.  All the code could then do something
>> like:
>>
>>  if (_gnutls_cert_vtable[certtype])
>>    _gnutls_cert_vtable[certtype].process_server_certificate ()
>>  else
>>    return GNUTLS_E_INIT_LIBEXTRA;
>
> Exactly.
>
>> Would you like to propose a patch for that?  I'd expect it to only
>> require changes to gnutls_cert.c/auth_cert.c...
>
> I might be able to do that but I can't really make any commitment at
> this point due to other deadlines.  I'll let you know when/if I give it
> a try.

No hurry, and it doesn't seem that important... I'd do it myself, but
it has too low priority for me, and I'm quite busy with other stuff.

Thanks,
Simon




From dkg-debian.org at fifthhorseman.net  Tue Jan 16 17:14:11 2007
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 16 Jan 2007 11:14:11 -0500
Subject: [Help-gnutls] TLS/OpenPGP draft expiring soon
In-Reply-To: <87zm8jhyah.fsf@laas.fr>
References: <87zm8jhyah.fsf@laas.fr>
Message-ID: <17836.63955.481542.439077@squeak.fifthhorseman.net>

At 2007-01-16 14:54, ludovic.courtes at laas.fr said:

> I just noticed that the proposal to extend TLS to support OpenPGP
> certificates written by Nikos Mavrogiannopoulos expires on February 1st:
> 
>   http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-11.txt
> 
> Are there any news regarding this?

I would also like to know about this.  I think this draft is
important, and would love to see it get wider attention.  I've written
an article about TLS certificate authentication that ended up pretty
strongly in favor of the OpenPGP certificate model:

 http://www.debian-administration.org/users/dkg/weblog/12

For those of us who are interested in promoting this model, what are
possible courses of action to help out?

	--dkg




From simon at josefsson.org  Tue Jan 16 19:14:41 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 16 Jan 2007 19:14:41 +0100
Subject: [Help-gnutls] Re: TLS/OpenPGP draft expiring soon
In-Reply-To: <17836.63955.481542.439077@squeak.fifthhorseman.net> (Daniel Kahn
	Gillmor's message of "Tue\, 16 Jan 2007 11\:14\:11 -0500")
References: <87zm8jhyah.fsf@laas.fr>
	<17836.63955.481542.439077@squeak.fifthhorseman.net>
Message-ID: <871wluj0tq.fsf@latte.josefsson.org>

Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:

> At 2007-01-16 14:54, ludovic.courtes at laas.fr said:
>
>> I just noticed that the proposal to extend TLS to support OpenPGP
>> certificates written by Nikos Mavrogiannopoulos expires on February 1st:
>> 
>>   http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-11.txt
>> 
>> Are there any news regarding this?
>
> I would also like to know about this.  I think this draft is
> important, and would love to see it get wider attention.  I've written
> an article about TLS certificate authentication that ended up pretty
> strongly in favor of the OpenPGP certificate model:
>
>  http://www.debian-administration.org/users/dkg/weblog/12

Cool!

Btw, the TLS servername extension (see RFC 3546) is intended to solve
the first problem you noticed, that servers cannot offer multiple
X.509 certificates.

> For those of us who are interested in promoting this model, what are
> possible courses of action to help out?

Work on mod_gnutls for Apache.  It should not have to be a big
project, but it is a good way to get this feature into Apache.

Also, testing and improving the OpenPGP parts of GnuTLS would be
useful.  In particular, OpenCDK isn't really in the shape that I'd
like to see it in.  Funding someone to work on that (I'm available :))
would be one way.

Thanks,
Simon




From simon at josefsson.org  Tue Jan 16 19:18:17 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 16 Jan 2007 19:18:17 +0100
Subject: [Help-gnutls] Re: TLS/OpenPGP draft expiring soon
In-Reply-To: <87ejpvt14m.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Tue\, 16 Jan 2007 16\:58\:01 +0100")
References: <87zm8jhyah.fsf@laas.fr> <87ejpvt14m.fsf@latte.josefsson.org>
Message-ID: <87wt3mhm3a.fsf@latte.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> ludovic.courtes at laas.fr (Ludovic Court?s) writes:
>
>> Hi,
>>
>> I just noticed that the proposal to extend TLS to support OpenPGP
>> certificates written by Nikos Mavrogiannopoulos expires on February 1st:
>>
>>   http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-11.txt
>>
>> Are there any news regarding this?
>
> Hi!  The document is in the RFC editor's queue, see:
>
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8235&rfc_flag=0

And for those unfamiliar with the IETF process, that means that the
document is done and will be an official RFC soon.

/Simon




From ranjit at motorola.com  Tue Jan 16 19:24:46 2007
From: ranjit at motorola.com (Avasarala Ranjit-A20990)
Date: Wed, 17 Jan 2007 02:24:46 +0800
Subject: [Help-gnutls] How do I run ex-client-srp ?
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B03D15355@ZMY16EXM66.ds.mot.com>


Hi Simon

How do I run ex-client-srp? I mean what are the arguments I need to
give? I tried this:

./ex-serv-srp
Echo Server ready. Listening to port '5556'.

- connection from 127.0.0.1, port 36417
*** Handshake has failed (Error in password file.)

*** Handshake failed
GNUTLS ERROR: A TLS packet with unexpected length was received.
[a20990 at mlabgate examples]$ 


Regards
Ranjit





From mario.lenz at gmx.net  Tue Jan 16 20:05:46 2007
From: mario.lenz at gmx.net (Mario Lenz)
Date: Tue, 16 Jan 2007 20:05:46 +0100
Subject: [Help-gnutls] Re: TLS/OpenPGP draft expiring soon
In-Reply-To: <871wluj0tq.fsf@latte.josefsson.org>
References: <87zm8jhyah.fsf@laas.fr>
	<17836.63955.481542.439077@squeak.fifthhorseman.net>
	<871wluj0tq.fsf@latte.josefsson.org>
Message-ID: <1168974346.3210.25.camel@sarge>

Hi!

> In particular, OpenCDK isn't really in the shape that I'd
> like to see it in.  Funding someone to work on that (I'm available :))
> would be one way.

Well, maybe I could spare some time to help you. What is you don't like
about OpenCDK? And what is it intended to *do* exactly? A definition of
the main programming goal would be a start. For example: I'm using
OpenCDK to get keys out of a keyring and use them with libgcrypt. Is
this it, and the encrypt/decrypt/sign/whatever functions are goodies, or
is it the other way round?

greez

   Mario

-- 
Wieners, in buns, no condiments. It's Hank's way. Anything else is
wrong.





From simon at josefsson.org  Fri Jan 19 13:50:08 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 19 Jan 2007 13:50:08 +0100
Subject: [Help-gnutls] Re: TLS/OpenPGP draft expiring soon
In-Reply-To: <1168974346.3210.25.camel@sarge> (Mario Lenz's message of "Tue\, 
	16 Jan 2007 20\:05\:46 +0100")
References: <87zm8jhyah.fsf@laas.fr>
	<17836.63955.481542.439077@squeak.fifthhorseman.net>
	<871wluj0tq.fsf@latte.josefsson.org> <1168974346.3210.25.camel@sarge>
Message-ID: <87irf3kwov.fsf@latte.josefsson.org>

Mario Lenz <mario.lenz at gmx.net> writes:

> Hi!
>
>> In particular, OpenCDK isn't really in the shape that I'd
>> like to see it in.  Funding someone to work on that (I'm available :))
>> would be one way.
>
> Well, maybe I could spare some time to help you. What is you don't like
> about OpenCDK? And what is it intended to *do* exactly? A definition of
> the main programming goal would be a start. For example: I'm using
> OpenCDK to get keys out of a keyring and use them with libgcrypt. Is
> this it, and the encrypt/decrypt/sign/whatever functions are goodies, or
> is it the other way round?

My general uneasiness around OpenCDK stems from the same kind of
questions, which appear to be unanswered...  Starting a texinfo manual
for OpenCDK, with some general introductions to what OpenCDK aims to
be would be immensely useful.

It seems as if OpenCDK duplicate some of the functionality that
properly belong to GnuPG.  However, as far as I know, there aren't any
APIs in GnuPG to do what OpenCDK does, even if the functionality is
there.  A serious question would be if we want to continue maintain
OpenCDK at all.  Making the same functionality be available from some
GnuPG component could give some advantages -- such as smartcard
support, gpg-agent support for passphrase caching, and hopefully
better maintained code.

Right now I keep maintaining OpenCDK because we are stuck with it, and
that approach rarely results in the best products...

I don't really have any thoughts about the code, I haven't looked hard
enough to really have a feeling of it.  I have a general preference to
use gnulib, though, and using gnulib modules where appropriate, and
there are some stuff in opencdk that could be replaced with some
gnulib module.

/Simon




From simon at josefsson.org  Fri Jan 19 15:08:57 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 19 Jan 2007 15:08:57 +0100
Subject: [Help-gnutls] Re: TLS/OpenPGP draft expiring soon
In-Reply-To: <87irf3kwov.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Fri\, 19 Jan 2007 13\:50\:08 +0100")
References: <87zm8jhyah.fsf@laas.fr>
	<17836.63955.481542.439077@squeak.fifthhorseman.net>
	<871wluj0tq.fsf@latte.josefsson.org> <1168974346.3210.25.camel@sarge>
	<87irf3kwov.fsf@latte.josefsson.org>
Message-ID: <87ejprkt1i.fsf@latte.josefsson.org>

Also, creating examples and a self test for the OpenPGP stuff would be
useful.  Have you managed to get it to work at all?  I tried this:

jas at mocca:~/src/gnutls$ gpg -a --export-secret-keys b565716f > ~/privkey.gpg

The above step would be nice to avoid, btw, although I'm not exactly
sure which file formats are supported/required.  This area seems
under-documented.

Starting the server:

jas at mocca:~/src/gnutls$ /home/jas/src/gnutls/src/gnutls-serv --pgpkeyring ~/.gnupg/pubring.gpg --pgptrustdb ~/.gnupg/secring.gpg --pgpkeyfile ~/privkey.gpg --pgpcertfile ~/josefsson.org/key.txt
Echo Server ready. Listening to port '5556'.

Error in handshake
Error: Decryption has failed.

Starting the client:

jas at mocca:~/src/gnutls$ /home/jas/src/gnutls/src/gnutls-cli --pgpkeyring ~/.gnupg/pubring.gpg --pgptrustdb ~/.gnupg/secring.gpg --pgpkeyfile ~/privkey.gpg --pgpcertfile ~/josefsson.org/key.txt --port 5556 localhost
Processed 1 client PGP certificate...
Resolving 'localhost'...
Connecting to '127.0.0.1:5556'...
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [20]: Bad record MAC
*** Handshake has failed
GNUTLS ERROR: A TLS fatal alert has been received.
jas at mocca:~/src/gnutls$

Enabling debugging in the server indicate this:

|<2>| ASSERT: gnutls_pk.c:283
|<2>| ASSERT: auth_rsa.c:258
|<1>| auth_rsa: Possible PKCS #1 format attack

However, if I look at the decrypted RSA signature, it is just garbage.
Probably it is using the wrong private or public key.

I think the OpenPGP integration in GnuTLS generally needs some TLC,
and if you have time to work on it, that would appreciated.

Thanks,
Simon




From simon at josefsson.org  Thu Jan 25 11:13:58 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 25 Jan 2007 11:13:58 +0100
Subject: [Help-gnutls] Re: How do I run ex-client-srp ?
In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B03D15355@ZMY16EXM66.ds.mot.com>
	(Avasarala Ranjit-A's message of "Wed\, 17 Jan 2007 02\:24\:46 +0800")
References: <750BBC72E178114F9DC4872EBFF29A5B03D15355@ZMY16EXM66.ds.mot.com>
Message-ID: <87hcufv2ft.fsf@latte.josefsson.org>

"Avasarala Ranjit-A20990" <ranjit at motorola.com> writes:

> Hi Simon
>
> How do I run ex-client-srp? I mean what are the arguments I need to
> give? I tried this:

Hi!  The tool doesn't take any arguments.  Did you read an earlier
post about this:

http://article.gmane.org/gmane.network.gnutls.general/613

> ./ex-serv-srp
> Echo Server ready. Listening to port '5556'.
>
> - connection from 127.0.0.1, port 36417
> *** Handshake has failed (Error in password file.)
>
> *** Handshake failed
> GNUTLS ERROR: A TLS packet with unexpected length was received.
> [a20990 at mlabgate examples]$ 

Did you create the password file as described in the URL above?

I now verified that the steps I explained earlier works fine with
GnuTLS 1.6.1 under Windows XP.

To use the ex-*-srp examples, you'll need to invoke:

C:\> srptool -u user -p tpasswd -c tpasswd.conf
Enter password: [Type 'pass']
C:\>

Then invoke './ex-serv-srp' in the same directory as the tpasswd*
files are in, and then invoke ./ex-client-srp'.

Or change the username/password in the source code.

/Simon




From ranjit at motorola.com  Thu Jan 25 12:16:49 2007
From: ranjit at motorola.com (Avasarala Ranjit-A20990)
Date: Thu, 25 Jan 2007 19:16:49 +0800
Subject: [Help-gnutls] RE: How do I run ex-client-srp ?
In-Reply-To: <87hcufv2ft.fsf@latte.josefsson.org>
References: <750BBC72E178114F9DC4872EBFF29A5B03D15355@ZMY16EXM66.ds.mot.com>
	<87hcufv2ft.fsf@latte.josefsson.org>
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B03D8B068@ZMY16EXM66.ds.mot.com>

Thanks Simon for the help 


Regards
Ranjit

-----Original Message-----
From: Simon Josefsson [mailto:simon at josefsson.org] 
Sent: Thursday, January 25, 2007 3:44 PM
To: Avasarala Ranjit-A20990
Cc: help-gnutls at gnu.org
Subject: Re: How do I run ex-client-srp ?

"Avasarala Ranjit-A20990" <ranjit at motorola.com> writes:

> Hi Simon
>
> How do I run ex-client-srp? I mean what are the arguments I need to 
> give? I tried this:

Hi!  The tool doesn't take any arguments.  Did you read an earlier post
about this:

http://article.gmane.org/gmane.network.gnutls.general/613

> ./ex-serv-srp
> Echo Server ready. Listening to port '5556'.
>
> - connection from 127.0.0.1, port 36417
> *** Handshake has failed (Error in password file.)
>
> *** Handshake failed
> GNUTLS ERROR: A TLS packet with unexpected length was received.
> [a20990 at mlabgate examples]$

Did you create the password file as described in the URL above?

I now verified that the steps I explained earlier works fine with GnuTLS
1.6.1 under Windows XP.

To use the ex-*-srp examples, you'll need to invoke:

C:\> srptool -u user -p tpasswd -c tpasswd.conf Enter password: [Type
'pass'] C:\>

Then invoke './ex-serv-srp' in the same directory as the tpasswd* files
are in, and then invoke ./ex-client-srp'.

Or change the username/password in the source code.

/Simon




From simon at josefsson.org  Thu Jan 25 12:39:09 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 25 Jan 2007 12:39:09 +0100
Subject: [Help-gnutls] FOSDEM
Message-ID: <874pqfuyhu.fsf@latte.josefsson.org>

I'll be attending FOSDEM <http://www.fosdem.org/2007/> this year, so
if anyone wants to chat or have a beer or something, I'm interested!

/Simon




From m at tthias.eu  Fri Jan 26 02:26:47 2007
From: m at tthias.eu (Matthias Wimmer)
Date: Fri, 26 Jan 2007 02:26:47 +0100
Subject: [Help-gnutls] Verifying subjectAltNames
Message-ID: <45B958D7.6000007@tthias.eu>

Hi!

I am trying to find out how to verify subjectAltNames using GnuTLS. For 
that I need to check the id-on-xmppAddr as a UTF8String inside a 
otherName entity which again is inside this subjectAltName extension. 
(This is needed by a server implementation of RFC 3920 which I am 
porting from OpenSSL to GnuTLS.)

I first tried to do this using gnutls_x509_crt_get_subject_alt_name() is 
the comments on this function tell:
"GNUTLS will return the Alternative name (2.5.29.17), or a negativ error 
code."

This does not seem to be true, as this function does not return complete 
subjectAltName data, but only parts of it (the hostname). When trying to 
read id-on-xmppAddr data inside otherName, GnuTLS just returns an error. 
I would highly recomment, that the function description should be 
adopted to note, that this function cannot be used to access arbitrary 
subjectAltName extensions.

So I tried to use gnutls_x509_crt_get_extension_by_oid() which returns 
me the subjectAltName extension, that contains what I am looking for. 
The question now is: does GnuTLS support me processing the returned DER 
data, or do I have to use libtasn for further processing?


Thank you for any feed-back

Matthias

-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Z?richer Str. 243    Fax +49-89 95 89 91 56
81476 M?nchen        http://ma.tthias.eu/





From simon at josefsson.org  Fri Jan 26 16:35:45 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 26 Jan 2007 16:35:45 +0100
Subject: [Help-gnutls] Re: Verifying subjectAltNames
In-Reply-To: <45B958D7.6000007@tthias.eu> (Matthias Wimmer's message of "Fri\, 
	26 Jan 2007 02\:26\:47 +0100")
References: <45B958D7.6000007@tthias.eu>
Message-ID: <87y7npdcmm.fsf@latte.josefsson.org>

Matthias Wimmer <m at tthias.eu> writes:

> Hi!
>
> I am trying to find out how to verify subjectAltNames using
> GnuTLS. For that I need to check the id-on-xmppAddr as a UTF8String
> inside a otherName entity which again is inside this subjectAltName
> extension. (This is needed by a server implementation of RFC 3920
> which I am porting from OpenSSL to GnuTLS.)
>
> I first tried to do this using gnutls_x509_crt_get_subject_alt_name()
> is the comments on this function tell:
> "GNUTLS will return the Alternative name (2.5.29.17), or a negativ
> error code."
>
> This does not seem to be true, as this function does not return
> complete subjectAltName data, but only parts of it (the
> hostname). When trying to read id-on-xmppAddr data inside otherName,
> GnuTLS just returns an error. I would highly recomment, that the
> function description should be adopted to note, that this function
> cannot be used to access arbitrary subjectAltName extensions.

Hi!  I think we should improve gnutls_x509_crt_get_subject_alt_name()
here -- it doesn't support otherName SAN's, which is what RFC 3920 is
using.  I'd expect that you got the GNUTLS_E_X509_UNKNOWN_SAN error?

> So I tried to use gnutls_x509_crt_get_extension_by_oid() which returns
> me the subjectAltName extension, that contains what I am looking
> for. The question now is: does GnuTLS support me processing the
> returned DER data, or do I have to use libtasn for further processing?

No, GnuTLS doesn't support that.  Using libtasn1 to do this is
possible, but it is easier to add the functionality to GnuTLS itself.

I'm not sure what a good API would be, maybe you could suggest
something?  What is missing is a field to return the OID of the
otherName data.  Perhaps we could add a function like:

int
gnutls_x509_crt_get_subject_alt_name2 (gnutls_x509_crt_t cert,
                                       unsigned int seq,
                                       void *ret,
                                       size_t * ret_size,
                                       void *oid,
                                       size_t *oid_size,
                                       unsigned int *critical)

If the SAN is an otherName, it would return the OID.

A problem with this API is that an GNUTLS_E_SHORT_MEMORY_BUFFER error
could mean that either the RET or the OID variable was too small.  I
think this API is a bad idea, but I'm not sure what a better one could
be.

What would the simplest API be for you?  Maybe one that searched
through the entire SAN for a particular otherName OID?

int
gnutls_x509_crt_search_san_othername (gnutls_x509_crt_t cert,
                                      const char *oid,
                                      unsigned int seq,
                                      void *ret,
                                      size_t * ret_size,
                                      unsigned int *critical)

It is not completely flexible, but it may be simpler for you.

/Simon




From m at tthias.eu  Fri Jan 26 22:03:04 2007
From: m at tthias.eu (Matthias Wimmer)
Date: Fri, 26 Jan 2007 22:03:04 +0100
Subject: [Help-gnutls] Re: Verifying subjectAltNames
In-Reply-To: <87y7npdcmm.fsf@latte.josefsson.org>
References: <45B958D7.6000007@tthias.eu> <87y7npdcmm.fsf@latte.josefsson.org>
Message-ID: <45BA6C88.2080201@tthias.eu>

Simon Josefsson schrieb:
> Hi!  I think we should improve gnutls_x509_crt_get_subject_alt_name()
> here -- it doesn't support otherName SAN's, which is what RFC 3920 is
> using.  I'd expect that you got the GNUTLS_E_X509_UNKNOWN_SAN error?

Yes, that's what I got.

>> So I tried to use gnutls_x509_crt_get_extension_by_oid() which returns
>> me the subjectAltName extension, that contains what I am looking
>> for. The question now is: does GnuTLS support me processing the
>> returned DER data, or do I have to use libtasn for further processing?
> 
> No, GnuTLS doesn't support that.  Using libtasn1 to do this is
> possible, but it is easier to add the functionality to GnuTLS itself.

For me as a library user anyway :-) I don't usurp to use libtasn1 directly.

> I'm not sure what a good API would be, maybe you could suggest
> something?

Well for my purpose / the purpose of using GnuTLS for XMPP (RFC 3920) 
the best would be to have a higher level function like 
gnutls_x509_crt_check_hostname(), e.g. gnutls_x509_crt_check_jid() where 
instead of a hostname, a JID (= XMPP address) is passed in.

If the JID contains an '@' or '/' sign, the JID is only checked against 
the id-on-xmppAddr. Else the JID is an IDN, which is checked (as UTF-8 
value) against the id-on-xmppAddr or (after punicode-encoding) against 
dNSName. If neither id-on-xmppAddr nor dNSName is present in the 
certificate, a check against CN is done.

But sure this is only a solution for XMPP, and it might be good to have 
an interface to access arbitrary otherNames ...

> What is missing is a field to return the OID of the
> otherName data.  Perhaps we could add a function like:
> 
> int
> gnutls_x509_crt_get_subject_alt_name2 (gnutls_x509_crt_t cert,
>                                        unsigned int seq,
>                                        void *ret,
>                                        size_t * ret_size,
>                                        void *oid,
>                                        size_t *oid_size,
>                                        unsigned int *critical)
> 
> If the SAN is an otherName, it would return the OID.

Maybe gnutls_x509_crt_get_subject_alt_name() could return an error code 
indicating, that it is an otherName. In that case the user could have 
two functions: one to get the oid of the otherName, and another to get 
the value!?

> What would the simplest API be for you?  Maybe one that searched
> through the entire SAN for a particular otherName OID?

The best API for me would be the one I described above. But a function, 
that allows me to check for otherName/id-on-xmppAddr extenions would be 
okay for me as well.


Matthias

-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Z?richer Str. 243    Fax +49-89 95 89 91 56
81476 M?nchen        http://ma.tthias.eu/





From john at yarbbles.com  Sun Jan 28 10:13:01 2007
From: john at yarbbles.com (John Brooks)
Date: Sun, 28 Jan 2007 02:13:01 -0700
Subject: [Help-gnutls] Verifying certificates with IPv6 crashes
Message-ID: <45BC691D.6040900@yarbbles.com>

#0  0xb76f6e5d in gnutls_auth_get_type () from /usr/lib/libgnutls.so.13
#1  0xb76fb42d in gnutls_certificate_verify_peers2 () from 
/usr/lib/libgnutls.so.13
#2  0xb7748d61 in ModuleSSLGnuTLS::VerifyCertificate (this=0x80c7050, 
session=0x80c70c8, user=0x8110f9c)
    at m_ssl_gnutls.cpp:668

This happens only on sockets that are IPv6; IPv4 works fine. Since it 
crashes inside gnutls, my best guess is that something isn't properly 
handling IPv6 there; I went over our code quickly and didn't see 
anything that involved the IP that might be a problem..

If you need more specifics on our implementation, see: 
http://svn.inspircd.org/index.cgi/trunk/inspircd/src/modules/extra/m_ssl_gnutls.cpp?view=co 
(Specifically, void VerifyCertificate(issl_session* session, Extensible* 
user))

Thanks :)

 - Special




From simon at josefsson.org  Mon Jan 29 20:16:16 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 29 Jan 2007 20:16:16 +0100
Subject: [Help-gnutls] Re: Verifying certificates with IPv6 crashes
In-Reply-To: <45BC691D.6040900@yarbbles.com> (John Brooks's message of "Sun\, 
	28 Jan 2007 02\:13\:01 -0700")
References: <45BC691D.6040900@yarbbles.com>
Message-ID: <873b5td4ov.fsf@latte.josefsson.org>

John Brooks <john at yarbbles.com> writes:

> #0  0xb76f6e5d in gnutls_auth_get_type () from /usr/lib/libgnutls.so.13
> #1  0xb76fb42d in gnutls_certificate_verify_peers2 () from
> /usr/lib/libgnutls.so.13
> #2  0xb7748d61 in ModuleSSLGnuTLS::VerifyCertificate (this=0x80c7050,
> session=0x80c70c8, user=0x8110f9c)
>    at m_ssl_gnutls.cpp:668
>
> This happens only on sockets that are IPv6; IPv4 works fine. Since it
> crashes inside gnutls, my best guess is that something isn't properly
> handling IPv6 there; I went over our code quickly and didn't see
> anything that involved the IP that might be a problem..
>
> If you need more specifics on our implementation, see:
> http://svn.inspircd.org/index.cgi/trunk/inspircd/src/modules/extra/m_ssl_gnutls.cpp?view=co
> (Specifically, void VerifyCertificate(issl_session* session,
> Extensible* user))

The GnuTLS library is generally not aware of IPv4 vs IPv6 differences,
so without more information, I'm not sure that is the best theory.
The function you indicate is quite short:

  int server = session->security_parameters.entity == GNUTLS_SERVER ? 0 : 1;

  return
    _gnutls_map_kx_get_cred (_gnutls_cipher_suite_get_kx_algo
			     (&session->security_parameters.
			      current_cipher_suite), server);

If code like that crashes, it probably means that the session variable
is NULL or garbled.

Please build a local copy of GnuTLS and re-run 'gdb' single-stepping
before the crash.  Running the binary under valgrind might help too.

Btw, have you looked at the GnuTLS C++ library?  If you are using C++,
it might be more appropriate.  However, few have tried it, and there
are no documentation or examples, so you are on your on. :)

/Simon




From simon at josefsson.org  Mon Jan 29 20:56:55 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 29 Jan 2007 20:56:55 +0100
Subject: [Help-gnutls] Re: Verifying subjectAltNames
In-Reply-To: <45BA6C88.2080201@tthias.eu> (Matthias Wimmer's message of "Fri\, 
	26 Jan 2007 22\:03\:04 +0100")
References: <45B958D7.6000007@tthias.eu> <87y7npdcmm.fsf@latte.josefsson.org>
	<45BA6C88.2080201@tthias.eu>
Message-ID: <87ps8xbo8o.fsf@latte.josefsson.org>

Matthias Wimmer <m at tthias.eu> writes:

>> I'm not sure what a good API would be, maybe you could suggest
>> something?
>
> Well for my purpose / the purpose of using GnuTLS for XMPP (RFC 3920)
> the best would be to have a higher level function like
> gnutls_x509_crt_check_hostname(), e.g. gnutls_x509_crt_check_jid()
> where instead of a hostname, a JID (= XMPP address) is passed in.
>
> If the JID contains an '@' or '/' sign, the JID is only checked
> against the id-on-xmppAddr. Else the JID is an IDN, which is checked
> (as UTF-8 
> value) against the id-on-xmppAddr or (after punicode-encoding) against
> dNSName. If neither id-on-xmppAddr nor dNSName is present in the
> certificate, a check against CN is done.
>
> But sure this is only a solution for XMPP, and it might be good to
> have an interface to access arbitrary otherNames ...

GnuTLS currently doesn't do UTF-8 let alone any IDN stuff, and I think
it would be nice to keep that to a minimum, to reduce external
dependencies.  So that API isn't really a good solution.

>> What is missing is a field to return the OID of the
>> otherName data.  Perhaps we could add a function like:
>>
>> int
>> gnutls_x509_crt_get_subject_alt_name2 (gnutls_x509_crt_t cert,
>>                                        unsigned int seq,
>>                                        void *ret,
>>                                        size_t * ret_size,
>>                                        void *oid,
>>                                        size_t *oid_size,
>>                                        unsigned int *critical)
>>
>> If the SAN is an otherName, it would return the OID.
>
> Maybe gnutls_x509_crt_get_subject_alt_name() could return an error
> code indicating, that it is an otherName. In that case the user could
> have two functions: one to get the oid of the otherName, and another
> to get the value!?

Not very pretty, but it is a solution.  Patches welcome..

I just noticed that the current API is lacking another important
thing: you don't know what kind of SAN was returned.  There should be
an 'gnutls_x509_subject_alt_name_t' output variable.

>> What would the simplest API be for you?  Maybe one that searched
>> through the entire SAN for a particular otherName OID?
>
> The best API for me would be the one I described above. But a
> function, that allows me to check for otherName/id-on-xmppAddr
> extenions would be okay for me as well.

Ok.  I'll think some more on an API that would fix both these
problems...  and give you and others some more time to think about it
too.

/Simon




From m at tthias.eu  Mon Jan 29 21:36:15 2007
From: m at tthias.eu (Matthias Wimmer)
Date: Mon, 29 Jan 2007 21:36:15 +0100
Subject: [Help-gnutls] Re: Verifying subjectAltNames
In-Reply-To: <87ps8xbo8o.fsf@latte.josefsson.org>
References: <45B958D7.6000007@tthias.eu>
	<87y7npdcmm.fsf@latte.josefsson.org>	<45BA6C88.2080201@tthias.eu>
	<87ps8xbo8o.fsf@latte.josefsson.org>
Message-ID: <45BE5ABF.6020005@tthias.eu>

Hi Simon!

Simon Josefsson schrieb:
>> Well for my purpose / the purpose of using GnuTLS for XMPP (RFC 3920)
>> the best would be to have a higher level function like
>> gnutls_x509_crt_check_hostname(), e.g. gnutls_x509_crt_check_jid()
>> where instead of a hostname, a JID (= XMPP address) is passed in.
>>
>> If the JID contains an '@' or '/' sign, the JID is only checked
>> against the id-on-xmppAddr. Else the JID is an IDN, which is checked
>> (as UTF-8 
>> value) against the id-on-xmppAddr or (after punicode-encoding) against
>> dNSName. If neither id-on-xmppAddr nor dNSName is present in the
>> certificate, a check against CN is done.
>>
>> But sure this is only a solution for XMPP, and it might be good to
>> have an interface to access arbitrary otherNames ...
> 
> GnuTLS currently doesn't do UTF-8 let alone any IDN stuff, and I think
> it would be nice to keep that to a minimum, to reduce external
> dependencies.  So that API isn't really a good solution.

I know. It only was the "what would be best for me" solution. UTF-8 
shouldn't be a problem, as if the caller would provide the address in 
UTF-8 and in the certificate it is a UTF-8 string (required by standard) 
as well. So it is just a binary comparison.
The IDN stuff could be solved by letting the caller provide the the 
punicoded string (in addition to the UTF-8 version) which can then be 
compared to the content of dNSName or CN like at present.

The thing is: without such a function, I even have to reimplement 
gnutls_x509_crt_check_hostname(), as this function does not allow me to 
request, that only dNSName is checked (but not CN). Which has to be done 
in case I detected, that there is an id-on-xmppAddr present but I had no 
match. - As fallback to CN should only be done, if neither 
id-on-xmppAddr nor dNSName has been present.

>>> What is missing is a field to return the OID of the
>>> otherName data.  Perhaps we could add a function like:
>>>
>>> int
>>> gnutls_x509_crt_get_subject_alt_name2 (gnutls_x509_crt_t cert,
>>>                                        unsigned int seq,
>>>                                        void *ret,
>>>                                        size_t * ret_size,
>>>                                        void *oid,
>>>                                        size_t *oid_size,
>>>                                        unsigned int *critical)
>>>
>>> If the SAN is an otherName, it would return the OID.
>> Maybe gnutls_x509_crt_get_subject_alt_name() could return an error
>> code indicating, that it is an otherName. In that case the user could
>> have two functions: one to get the oid of the otherName, and another
>> to get the value!?
> 
> Not very pretty, but it is a solution.  Patches welcome..
> 
> I just noticed that the current API is lacking another important
> thing: you don't know what kind of SAN was returned.  There should be
> an 'gnutls_x509_subject_alt_name_t' output variable.

Yes, that would be very useful as well.

In that case the interface proposed above would get even simpler. No 
need to return an error indicating that it is an otherName in the first 
call. The result could be already returned in this first call with 
gnutls_x509_subject_alt_name_t telling that it is an otherName. There 
would be just a second call required, that returns the OID of the 
otherName then.


Matthias

-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Z?richer Str. 243    Fax +49-89 95 89 91 56
81476 M?nchen        http://ma.tthias.eu/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4263 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20070129/04fb38f9/attachment.bin>

From dev001 at pas-world.com  Tue Jan 30 23:23:31 2007
From: dev001 at pas-world.com (devel)
Date: Tue, 30 Jan 2007 23:23:31 +0100
Subject: [Help-gnutls] About entropy gathering
Message-ID: <1170195811.3052.13.camel@Portatil>

Hello,
When a machine do not have entropy for make random number gnutls wait
for complete gathering.
In some case computer can not collect entropy, bad configuration,no
hw..., And this seems to be a problem.

My question is this. Have GNUTLS any time limit to wait for entropy?


--
Devel it, Precio http://www.pas-world.com





From simon at josefsson.org  Wed Jan 31 06:02:17 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 31 Jan 2007 06:02:17 +0100
Subject: [Help-gnutls] Re: About entropy gathering
In-Reply-To: <1170195811.3052.13.camel@Portatil> (devel's message of "Tue\, 30
	Jan 2007 23\:23\:31 +0100")
References: <1170195811.3052.13.camel@Portatil>
Message-ID: <87sldr7pra.fsf@latte.josefsson.org>

devel <dev001 at pas-world.com> writes:

> Hello,
> When a machine do not have entropy for make random number gnutls wait
> for complete gathering.
> In some case computer can not collect entropy, bad configuration,no
> hw..., And this seems to be a problem.
>
> My question is this. Have GNUTLS any time limit to wait for entropy?

Hi!  No, there is no such time limit.  GnuTLS uses libgcrypt for
entropy gathering, and there are two purposes for which entropy is
needed: when generating RSA/DSA keys, or D-H parameters, and when
generating session keying material.  If I remember correctly, the
former uses /dev/random plus some libgcrypt internal stuff, the latter
uses /dev/urandom plus some internal stuff.  Thus, GnuTLS should never
hang waiting for entropy generation during session-specific stuff.

We've had some reports in the past that says GnuTLS (or, rather,
libgcrypt) hangs waiting for entropy even during sessions, but nobody
have been able to track things down or reproduce it, if I understand
correctly.  I think some of those reports, related to the Debian exim
packages, were caused by re-generating D-H parameters in the server,
which will hang.  I think that has been fixed now, though.

My message is this: if you have problems with the system hanging
waiting for entropy, I think there is a bug somewhere (*), and you'll
need to provide more debugging information.

/Simon

(*) Well, ok, with the exception for Windows and some other platforms,
where there isn't really any good RNG and libgcrypt may take some
time.  But on a normal GNU/Linux system, there shouldn't be a problem,
or there is a bug.




From simon at josefsson.org  Wed Jan 31 12:58:45 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 31 Jan 2007 12:58:45 +0100
Subject: [Help-gnutls] Re: About entropy gathering
In-Reply-To: <1170243947.3480.15.camel@Portatil> (devel's message of "Wed\, 31
	Jan 2007 12\:45\:47 +0100")
References: <1170195811.3052.13.camel@Portatil>
	<87sldr7pra.fsf@latte.josefsson.org>
	<1170243947.3480.15.camel@Portatil>
Message-ID: <87wt335rwq.fsf@latte.josefsson.org>

devel <dev001 at pas-world.com> writes:

> Well,
> The problem is that without time limit a "machine operator"
> can not know if there is a "hardware problem". For example, my machine
> wait about >30seconds for 1024bits or random data, my machine has not
> Hardware RNG (Athlon64 X2) that runs a program slow that PentimIII with
> hw_rng module (<1second).
> On hard load of gathering entropy, a machine operator can not know that
> program is waiting for RNG data. The program, the machine, and the
> server could be slow because machine can not collect true random data.
>
> I think that function that collect entropy should exit,with error code,
> if a throught of bytes/sg can not be collected. Is my opinion.

If the time-limit is 30s, you then wouldn't be able to generate a
private key on your athlon64, while waiting longer would make that
possible.  Deciding on the time-limit is difficult.  On smaller
machines, generating the required entropy can take many minutes.

A process indicator might be useful, and if someone wants to work on
adding one -- just read one byte of randomness at a time and display
some progress to the user after each byte has been read -- I'd like to
integrate it.

However, when you talk about 'server', what do you mean?  Generating
RSA/DSA private keys or DH parameters can block, but a GnuTLS server
should never (if I understand how we are using libgcrypt correctly).
If you are having a GnuTLS server block on randomness, please give
more details -- that shouldn't happen.

/Simon




From dev001 at pas-world.com  Wed Jan 31 19:27:28 2007
From: dev001 at pas-world.com (devel)
Date: Wed, 31 Jan 2007 19:27:28 +0100
Subject: [Help-gnutls] Re: About entropy gathering
In-Reply-To: <87wt335rwq.fsf@latte.josefsson.org>
References: <1170195811.3052.13.camel@Portatil>
	<87sldr7pra.fsf@latte.josefsson.org>
	<1170243947.3480.15.camel@Portatil>
	<87wt335rwq.fsf@latte.josefsson.org>
Message-ID: <1170268048.5688.0.camel@Portatil>

O mi?, 31-01-2007 ?s 12:58 +0100, Simon Josefsson escribiu:

> If the time-limit is 30s, you then wouldn't be able to generate a
> private key on your athlon64, while waiting longer would make that
> possible.  Deciding on the time-limit is difficult.  On smaller
> machines, generating the required entropy can take many minutes.


You said that you can not choose time limit, this is true. But user can,
he knows machine and hardware. Typical time limit could be 3600seconds
or more with default config file, or define directive.

Really this option (time limit) is not needed, but in some case the
computer is slow, no cpu used, no hard disk noise, and pseudo random
data have low throught, and program do not exit.

Where is the problem?, said the user.

> 
> A process indicator might be useful, and if someone wants to work on
> adding one -- just read one byte of randomness at a time and display
> some progress to the user after each byte has been read -- I'd like to
> integrate it.

> However, when you talk about 'server', what do you mean?  Generating
> RSA/DSA private keys or DH parameters can block, but a GnuTLS server
> should never (if I understand how we are using libgcrypt correctly).
> If you are having a GnuTLS server block on randomness, please give
> more details -- that shouldn't happen.
> 
> /Simon

"Server" as machine that signs, make keys and certicates, really
computer, this is a mistake.

Personal computer do not need too much real random data (nowdays), and
in professional computer, administrator should test hw_rng and bytes/sg.


Well, it's true, time limit does not seem very useful.


--
Devel it, Precio http://www.pas-world.com