From sam at robots.org.uk  Wed Apr  4 18:07:25 2007
From: sam at robots.org.uk (Sam Morris)
Date: Wed, 04 Apr 2007 17:07:25 +0100
Subject: [Help-gnutls] CA certificates -- root vs intermediate
Message-ID: <1175702845.30604.9.camel@xerces>

I've been using my own CA certificate to secure my access (with SSL/TLS)
to my personal email & web server for a while now. I originally
generated the CA certificate with gnutls' certtool program. I now need
to get the certificate working on a client running Mac OS X.

It's fairly straightforward to import the certificate into OS X's
Keychain application; however, Keychain insists that my CA is only an
"intermediate certificate authority", and therefore OS X refuses to
trust the certificate.

I have gone through the output of 'certtool --info' and 'openssl x509
-text', and have done quite some Googling by now, but I can't find any
way to determine the criteria by which Keychain decides that my
certificate is that of a root authority, or an intermediate authority.

So my question is: is this root/intermediate setting actually in the
certificate itself (in which case it's something I can fix by generating
a new certificate--although I can't find any options for this in
certtol's documentation; is it possible, or will I have to use openssl?)
or is it something I need to do in the Keychain application?

The certificate is available from
https://crypt.ethx.net/robots.org.uk-CA.crt in case anyone wants a copy.

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: </pipermail/attachments/20070404/d2187f6d/attachment.pgp>

From simon at josefsson.org  Thu Apr  5 22:57:44 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 05 Apr 2007 22:57:44 +0200
Subject: [Help-gnutls] Re: CA certificates -- root vs intermediate
In-Reply-To: <1175702845.30604.9.camel@xerces> (Sam Morris's message of "Wed\, 
	04 Apr 2007 17\:07\:25 +0100")
References: <1175702845.30604.9.camel@xerces>
Message-ID: <87wt0qwncn.fsf@mocca.josefsson.org>

Sam Morris <sam at robots.org.uk> writes:

> I've been using my own CA certificate to secure my access (with SSL/TLS)
> to my personal email & web server for a while now. I originally
> generated the CA certificate with gnutls' certtool program. I now need
> to get the certificate working on a client running Mac OS X.
>
> It's fairly straightforward to import the certificate into OS X's
> Keychain application; however, Keychain insists that my CA is only an
> "intermediate certificate authority", and therefore OS X refuses to
> trust the certificate.
>
> I have gone through the output of 'certtool --info' and 'openssl x509
> -text', and have done quite some Googling by now, but I can't find any
> way to determine the criteria by which Keychain decides that my
> certificate is that of a root authority, or an intermediate authority.
>
> So my question is: is this root/intermediate setting actually in the
> certificate itself (in which case it's something I can fix by generating
> a new certificate--although I can't find any options for this in
> certtol's documentation; is it possible, or will I have to use openssl?)
> or is it something I need to do in the Keychain application?

Basically, root certificates have subject==issuer, intermediate
certificates have subject!=issuer.

> The certificate is available from
> https://crypt.ethx.net/robots.org.uk-CA.crt in case anyone wants a copy.

The certificate is missing the 'key usage' bits of certificate
signing, and a subject key ID.  But that doesn't seem relevant to the
error message you got.  And, many commercial CAs also lack those
fields so you aren't alone in this.

I think you'll need to debug this as a Keychain problem further, to
understand exactly why it is complaining.  Can you add any other
certificate as a new trusted root CA?

/Simon




From ludo at chbouib.org  Sun Apr  8 19:32:35 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Sun, 08 Apr 2007 19:32:35 +0200
Subject: [Help-gnutls] Slight enum vs. `int' typo
Message-ID: <87tzvqvkjw.fsf@chbouib.org>

Hi,

The last argument of `gnutls_psk_set_client_credentials ()' should have
type `gnutls_psk_key_flags' instead of `unsigned int' (hopefully the
size of both types is the same on C89-compliant platforms ;-)).  I
believe that last argument should also be renamed to `format' for
clarity.

Thanks,
Ludovic.





From ludo at chbouib.org  Mon Apr  9 17:42:36 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 09 Apr 2007 17:42:36 +0200
Subject: [Help-gnutls] Semantics of `gnutls_openpgp_key_check_hostname ()'
Message-ID: <87ejmtlfkj.fsf@chbouib.org>

Hi,

Currently, `gnutls_openpgp_key_check_hostname ()' will only return true
if one of the key's names matches _exactly_ HOSTNAME.  Since key names
are not supposed to be host names but rather RFC822 strings, this is of
little use.

Perhaps it should rather check whether the email part of one of the key
names matches HOSTNAME?

Thanks,
Ludovic.





From ludovic.courtes at laas.fr  Wed Apr 11 09:59:07 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 11 Apr 2007 09:59:07 +0200
Subject: [Help-gnutls] Certificate list size in
	`gnutls_certificate_get_peers ()'
Message-ID: <87bqhv1gvo.fsf@laas.fr>

Hi,

Why does `gnutls_certificate_get_peers ()' have a LIST_SIZE parameter
that `gnutls_certificate_get_ours ()' doesn't have?  How is it supposed
to be used (I haven't used X.509 certificates so far)?

AFAIU, this parameter tells the size of the certificate chain that is
returned when X.509 certificates are used, and both functions are said
to return a "list of certificates" anyway.

Thanks,
Ludovic.





From simon at josefsson.org  Wed Apr 11 15:27:16 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 11 Apr 2007 15:27:16 +0200
Subject: [Help-gnutls] Re: Certificate list size in
	`gnutls_certificate_get_peers ()'
In-Reply-To: <87bqhv1gvo.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Wed\, 11
	Apr 2007 09\:59\:07 +0200")
References: <87bqhv1gvo.fsf@laas.fr>
Message-ID: <87fy77ca8b.fsf@mocca.josefsson.org>

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

> Hi,
>
> Why does `gnutls_certificate_get_peers ()' have a LIST_SIZE parameter
> that `gnutls_certificate_get_ours ()' doesn't have?  How is it supposed
> to be used (I haven't used X.509 certificates so far)?
>
> AFAIU, this parameter tells the size of the certificate chain that is
> returned when X.509 certificates are used, and both functions are said
> to return a "list of certificates" anyway.

Hi!  The `gnutls_certificate_get_peers' function returns an array of
gnutls_datum_t's, and the array is LIST_SIZE long.  LIST_SIZE is an
output variable.  Each gnutls_datum_t correspond to a X.509
certificate.

It is probably a mistake that `gnutls_certificate_get_ours' does not
return a LIST_SIZE parameter too.  Do you need that functionality?
Maybe we can add a new API to get the entire list, and a LIST_SIZE
parameter.

/Simon




From simon at josefsson.org  Wed Apr 11 15:30:11 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 11 Apr 2007 15:30:11 +0200
Subject: [Help-gnutls] Re: Semantics of `gnutls_openpgp_key_check_hostname
	()'
In-Reply-To: <87ejmtlfkj.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Mon\, 09 Apr 2007 17\:42\:36 +0200")
References: <87ejmtlfkj.fsf@chbouib.org>
Message-ID: <87bqhvca3g.fsf@mocca.josefsson.org>

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

> Hi,
>
> Currently, `gnutls_openpgp_key_check_hostname ()' will only return true
> if one of the key's names matches _exactly_ HOSTNAME.  Since key names
> are not supposed to be host names but rather RFC822 strings, this is of
> little use.
>
> Perhaps it should rather check whether the email part of one of the key
> names matches HOSTNAME?

I'm not sure... it is pretty important that name checks are well
defined.  As I recall, there are no clear requirements on what key
names should be in the standard, or is there?

How do this cause problems?  Perhaps we can solve it by simply
improving documentation to make it clear that you'll have to generate
a OpenPGP key with a name matching exactly the server's.  Adding
better warnings to gnutls-cli/gnutls-serv when this isn't true might
help too.

/Simon




From simon at josefsson.org  Wed Apr 11 15:35:13 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 11 Apr 2007 15:35:13 +0200
Subject: [Help-gnutls] Re: Slight enum vs. `int' typo
In-Reply-To: <87tzvqvkjw.fsf@chbouib.org> ("Ludovic =?iso-8859-1?Q?Court?=
	=?iso-8859-1?Q?=E8s=22's?= message of
	"Sun\, 08 Apr 2007 19\:32\:35 +0200")
References: <87tzvqvkjw.fsf@chbouib.org>
Message-ID: <877isjc9v2.fsf@mocca.josefsson.org>

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

> Hi,
>
> The last argument of `gnutls_psk_set_client_credentials ()' should have
> type `gnutls_psk_key_flags' instead of `unsigned int' (hopefully the
> size of both types is the same on C89-compliant platforms ;-)).  I
> believe that last argument should also be renamed to `format' for
> clarity.

Applied, thanks.

/Simon

Index: NEWS
===================================================================
RCS file: /cvs/gnutls/gnutls/NEWS,v
retrieving revision 2.860
diff -u -p -r2.860 NEWS
--- NEWS	10 Apr 2007 17:49:29 -0000	2.860
+++ NEWS	11 Apr 2007 13:31:41 -0000
@@ -40,6 +40,12 @@ gnutls_cipher_suite_info.  Suggested by 
 
 ** New configure option --disable-tls-authorization to disable tls-authz.
 
+** Fix prototype for `gnutls_psk_set_client_credentials'.
+The last parameter was renamed from 'flags' to 'format' and the type
+changed from 'unsigned int' to 'gnutls_psk_key_flags' (an enum type),
+which shouldn't cause any ABI changes.  Reported by ludo at chbouib.org
+(Ludovic Court?s).
+
 ** API and ABI modifications:
 gnutls_x509_dn_t: ADD.
 gnutls_x509_ava_st: ADD.
Index: includes/gnutls/gnutls.h.in
===================================================================
RCS file: /cvs/gnutls/gnutls/includes/gnutls/gnutls.h.in,v
retrieving revision 1.39
diff -u -p -r1.39 gnutls.h.in
--- includes/gnutls/gnutls.h.in	4 Apr 2007 14:12:52 -0000	1.39
+++ includes/gnutls/gnutls.h.in	11 Apr 2007 13:31:41 -0000
@@ -920,7 +920,7 @@ extern "C"
   int gnutls_psk_set_client_credentials (gnutls_psk_client_credentials_t res,
 					 const char *username,
 					 const gnutls_datum * key,
-					 unsigned int flags);
+					 gnutls_psk_key_flags format);
   typedef enum gnutls_psk_key_flags
   {
     GNUTLS_PSK_KEY_RAW = 0,
Index: lib/gnutls_psk.c
===================================================================
RCS file: /cvs/gnutls/gnutls/lib/gnutls_psk.c,v
retrieving revision 2.9
diff -u -p -r2.9 gnutls_psk.c
--- lib/gnutls_psk.c	15 Dec 2005 13:24:30 -0000	2.9
+++ lib/gnutls_psk.c	11 Apr 2007 13:31:41 -0000
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2005 Free Software Foundation
+ * Copyright (C) 2005, 2007 Free Software Foundation
  *
  * Author: Nikos Mavroyanopoulos
  *
@@ -78,6 +78,8 @@ gnutls_psk_allocate_client_credentials (
   * @res: is an #gnutls_psk_client_credentials_t structure.
   * @username: is the user's zero-terminated userid
   * @key: is the user's key
+  * @format: indicate the format of the key, either
+  * %GNUTLS_PSK_KEY_RAW or %GNUTLS_PSK_KEY_HEX.
   *
   * This function sets the username and password, in a
   * gnutls_psk_client_credentials_t structure.  Those will be used in
@@ -92,7 +94,7 @@ int
 gnutls_psk_set_client_credentials (gnutls_psk_client_credentials_t res,
 				   const char *username,
 				   const gnutls_datum * key,
-				   unsigned int flags)
+				   gnutls_psk_key_flags flags)
 {
   int ret;
 




From simon at josefsson.org  Wed Apr 11 15:58:45 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 11 Apr 2007 15:58:45 +0200
Subject: [Help-gnutls] Re: Error making certificate [solved]
In-Reply-To: <1174327504.4399.6.camel@localhost.localdomain> (devel's message
	of "Mon\, 19 Mar 2007 18\:05\:04 +0000")
References: <1173701185.5591.9.camel@localhost.localdomain>
	<877itmhby1.fsf@mocca.josefsson.org>
	<1173712924.5591.23.camel@localhost.localdomain>
	<873b4afoi9.fsf@mocca.josefsson.org>
	<1173897938.11282.5.camel@localhost.localdomain>
	<8764923gbk.fsf@mocca.josefsson.org>
	<1173994329.16240.7.camel@localhost.localdomain>
	<1174327504.4399.6.camel@localhost.localdomain>
Message-ID: <87tzvnau7e.fsf@mocca.josefsson.org>

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

> El jue, 15-03-2007 a las 21:32 +0000, devel escribi?:
>
>> > certtool -p --bits 2048 >  ca.key
>
>> Anyone works with mail sign certificate in any mail client?
>
> Response: Email clients do not support CA with 2048, only 1024. Thanks.

Thanks for debugging it further.  For the record, which email client
and version was this?

/Simon




From dkg-debian.org at fifthhorseman.net  Wed Apr 11 17:55:56 2007
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 11 Apr 2007 11:55:56 -0400
Subject: [Help-gnutls] Re: Semantics of `gnutls_openpgp_key_check_hostname
	()'
In-Reply-To: <87bqhvca3g.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 11 Apr 2007 15:30:11 +0200")
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
Message-ID: <877isix5v7.fsf@squeak.fifthhorseman.net>

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

On Wed 2007-04-11 09:30:11 -0400, Simon Josefsson wrote:

> ludo at chbouib.org (Ludovic Court?s) writes:
>
>> if one of the key's names matches _exactly_ HOSTNAME.  Since key
>> names are not supposed to be host names but rather RFC822 strings,
>> this is of little use.
>>
>> Perhaps it should rather check whether the email part of one of the key
>> names matches HOSTNAME?
>
> I'm not sure... it is pretty important that name checks are well
> defined.  As I recall, there are no clear requirements on what key
> names should be in the standard, or is there?

RFC 2440 [0] says:

5.11. User ID Packet (Tag 13)

   A User ID packet consists of data that is intended to represent the
   name and email address of the key holder.  By convention, it includes
   an RFC 822 mail name, but there are no restrictions on its content.
   The packet length in the header specifies the length of the user id.
   If it is text, it is encoded in UTF-8.

I think this is the relevant section to what's under discussion here.
If there's a more relevant section, please point it out!

So i think it'd be OK to put whatever you want there, though there are
certainly circumstances where i wouldn't want to sign a key/uid
binding if the uid were just the hostname.

For example, if foo.example.com runs an LDAP service as a
non-privileged user (STARTTLS-enabled, of course), i'd prefer that the
uid on the key used was something like

 ldap://foo.example.com/

and not just "foo.example.com".  Otherwise, a compromised LDAP service
could masquerade as other services on the same machine.

I'm not sure that a URI is the right thing to put there, but some
indication of the service in particular is probably worth considering.

I haven't read the documentation for
gnutls_openpgp_key_check_hostname() yet, though.

           --dkg

[0] http://www.ietf.org/rfc/rfc2440.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFGHQUBiXTlFKVLY2URApMjAJkBwfPiv9A014e3Q3+qT4ZLMC5dRACgw2L9
KSfX9IHxmDYG4aaM2dkuByE=
=KdfG
-----END PGP SIGNATURE-----




From ludovic.courtes at laas.fr  Wed Apr 11 18:35:36 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 11 Apr 2007 18:35:36 +0200
Subject: [Help-gnutls] Re: Certificate list size in
	`gnutls_certificate_get_peers ()'
References: <87bqhv1gvo.fsf@laas.fr> <87fy77ca8b.fsf@mocca.josefsson.org>
Message-ID: <87ejmqx413.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Hi!  The `gnutls_certificate_get_peers' function returns an array of
> gnutls_datum_t's, and the array is LIST_SIZE long.  LIST_SIZE is an
> output variable.  Each gnutls_datum_t correspond to a X.509
> certificate.

Ok, I had not understood it correctly.

> It is probably a mistake that `gnutls_certificate_get_ours' does not
> return a LIST_SIZE parameter too.  Do you need that functionality?
> Maybe we can add a new API to get the entire list, and a LIST_SIZE
> parameter.

Since one can hardly traverse the certificate array without knowing its
size, LIST_SIZE should probably be provided by
`gnutls_certificate_get_ours' too (or perhaps
`gnutls_certificate_get_ours2'?).

Actually, I'm writing Guile bindings for GnuTLS, hence my question.
Otherwise, since I've been using mostly OpenPGP certificates so far, so
I didn't really feel concerned with the meaning of LIST_SIZE.  ;-)

Thanks,
Ludovic.





From ludovic.courtes at laas.fr  Wed Apr 11 18:46:37 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 11 Apr 2007 18:46:37 +0200
Subject: [Help-gnutls] Re: Semantics of `gnutls_openpgp_key_check_hostname
	()'
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net>
Message-ID: <87zm5euadu.fsf@laas.fr>

Hi,

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

> For example, if foo.example.com runs an LDAP service as a
> non-privileged user (STARTTLS-enabled, of course), i'd prefer that the
> uid on the key used was something like
>
>  ldap://foo.example.com/
>
> and not just "foo.example.com".  Otherwise, a compromised LDAP service
> could masquerade as other services on the same machine.
>
> I'm not sure that a URI is the right thing to put there, but some
> indication of the service in particular is probably worth considering.

It feels strange to me to fill the user ID packet with something that is
not an RFC822 mail name, even though this is just a convention.

The Debian archive keys, for instance, contain a regular mail name, not
just "http://www.debian.org/" or some such.  The textual part (e.g.,
"Etch Stable Release Key") proves to be quite useful since it conveys
additional information.  Of course, that information could be made part
of an appropriately crafted URI (e.g.,
"http://www.debian.org/releases/etch/"), but that would be less
user-friendly... and less conventional.

So I don't know what would be best for `openpgp_key_check_hostname ()'.

Thanks,
Ludovic.





From dkg-debian.org at fifthhorseman.net  Wed Apr 11 20:19:13 2007
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 11 Apr 2007 14:19:13 -0400
Subject: [Help-gnutls] Re: Semantics of `gnutls_openpgp_key_check_hostname
	()'
In-Reply-To: <87zm5euadu.fsf@laas.fr> (Ludovic =?utf-8?Q?Court=C3=A8s's?=
	message of "Wed, 11 Apr 2007 18:46:37 +0200")
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
Message-ID: <87ejmqrcym.fsf@squeak.fifthhorseman.net>

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

On Wed 2007-04-11 12:46:37 -0400, Ludovic Court?s wrote:

> It feels strange to me to fill the user ID packet with something
> that is not an RFC822 mail name, even though this is just a
> convention.

I agree that it feels strange!  But i'm really hoping to see OpenPGP
keys used in place of X.509 certs for TLS, so we need to think about
what's the appropriate thing to put there, and how various Certificate
authorities and clients should interpret it.

The TLS-OpenPGP draft [0] doesn't seem to say anything about it:

   Considerations about the use of the web of trust or identity and
   certificate verification procedure are outside the scope of this
   document.  These are considered issues to be handled by the
   application layer protocols.

Is there another draft addressing this issue?  I think a declared
convention for certficate verification during a TLS connection would
help folks understand this new model.  When you connect to a
TLS-enabled service, you aren't connecting to an RFC 822 e-mail
address.  What would you look for in the UID of an OpenPGP-style cert
offered by such a service?

Any thoughts, suggestions, or pointers from other TLS-savvy folks on
this list?

     --dkg

[0] http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-11.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFGHSaWiXTlFKVLY2URArFCAKCG+rHbsaNeOnY/oSL3g9+a11MNyACg/GMm
nBG22duntyceLisKRjJ4DEk=
=O5ab
-----END PGP SIGNATURE-----




From simon at josefsson.org  Thu Apr 12 10:58:17 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 12 Apr 2007 10:58:17 +0200
Subject: [Help-gnutls] Re: Certificate list size in
	`gnutls_certificate_get_peers ()'
In-Reply-To: <87ejmqx413.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Wed\, 11
	Apr 2007 18\:35\:36 +0200")
References: <87bqhv1gvo.fsf@laas.fr> <87fy77ca8b.fsf@mocca.josefsson.org>
	<87ejmqx413.fsf@laas.fr>
Message-ID: <87zm5e9dg6.fsf@mocca.josefsson.org>

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

>> It is probably a mistake that `gnutls_certificate_get_ours' does not
>> return a LIST_SIZE parameter too.  Do you need that functionality?
>> Maybe we can add a new API to get the entire list, and a LIST_SIZE
>> parameter.
>
> Since one can hardly traverse the certificate array without knowing its
> size, LIST_SIZE should probably be provided by
> `gnutls_certificate_get_ours' too (or perhaps
> `gnutls_certificate_get_ours2'?).

I just realized that we can solve it without an ABI/API change: just
make the array zero-terminated.  You'll have to traverse the list in
order to find out its size, but perhaps that is not so much trouble.
What do you think?

> Actually, I'm writing Guile bindings for GnuTLS, hence my question.
> Otherwise, since I've been using mostly OpenPGP certificates so far, so
> I didn't really feel concerned with the meaning of LIST_SIZE.  ;-)

Understood.

/Simon




From simon at josefsson.org  Thu Apr 12 11:02:29 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 12 Apr 2007 11:02:29 +0200
Subject: [Help-gnutls] Re: Semantics of `gnutls_openpgp_key_check_hostname
	()'
In-Reply-To: <87ejmqrcym.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Wed\, 11 Apr 2007 14\:19\:13 -0400")
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
	<87ejmqrcym.fsf@squeak.fifthhorseman.net>
Message-ID: <87veg29d96.fsf@mocca.josefsson.org>

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

> On Wed 2007-04-11 12:46:37 -0400, Ludovic Court?s wrote:
>
>> It feels strange to me to fill the user ID packet with something
>> that is not an RFC822 mail name, even though this is just a
>> convention.
>
> I agree that it feels strange!  But i'm really hoping to see OpenPGP
> keys used in place of X.509 certs for TLS, so we need to think about
> what's the appropriate thing to put there, and how various Certificate
> authorities and clients should interpret it.
>
> The TLS-OpenPGP draft [0] doesn't seem to say anything about it:
>
>    Considerations about the use of the web of trust or identity and
>    certificate verification procedure are outside the scope of this
>    document.  These are considered issues to be handled by the
>    application layer protocols.
>
> Is there another draft addressing this issue?  I think a declared
> convention for certficate verification during a TLS connection would
> help folks understand this new model.  When you connect to a
> TLS-enabled service, you aren't connecting to an RFC 822 e-mail
> address.  What would you look for in the UID of an OpenPGP-style cert
> offered by such a service?
>
> Any thoughts, suggestions, or pointers from other TLS-savvy folks on
> this list?

I just realized: Do we have to use the ID packet for this purpose?
Can't we define a new OpenPGP packet, similar to the X.509 Subject
Alternative Name extension?  I think this is similar to how X.509
evolved: first you placed the server name in the CN, then you invented
an extension packet to hold it.

In any case, to provide interoperability, I believe there should be an
IETF document specifying this.  I'm quite busy, but I would be
interested in helping such a project.  Approaching the tls-openpgp
authors and/or the OpenPGP WG to discuss the extension could be a
first step.

/Simon




From dev001 at pas-world.com  Thu Apr 12 13:03:47 2007
From: dev001 at pas-world.com (devel)
Date: Thu, 12 Apr 2007 11:03:47 +0000
Subject: [Help-gnutls] Re: Error making certificate [solved]
In-Reply-To: <87tzvnau7e.fsf@mocca.josefsson.org>
References: <1173701185.5591.9.camel@localhost.localdomain>
	<877itmhby1.fsf@mocca.josefsson.org>
	<1173712924.5591.23.camel@localhost.localdomain>
	<873b4afoi9.fsf@mocca.josefsson.org>
	<1173897938.11282.5.camel@localhost.localdomain>
	<8764923gbk.fsf@mocca.josefsson.org>
	<1173994329.16240.7.camel@localhost.localdomain>
	<1174327504.4399.6.camel@localhost.localdomain>
	<87tzvnau7e.fsf@mocca.josefsson.org>
Message-ID: <1176375827.4353.26.camel@localhost.localdomain>

El mi?, 11-04-2007 a las 15:58 +0200, Simon Josefsson escribi?:
> Thanks for debugging it further.  For the record, which email client
> and version was this?

Evolution, 2.0.2 works.
Thunderbird works.
Outlook seems to be some problems to sign, but can read mail signed and
encripted.

-- 
--
Publicidad http://www.pas-world.com





From ludovic.courtes at laas.fr  Thu Apr 12 11:28:30 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 12 Apr 2007 11:28:30 +0200
Subject: [Help-gnutls] Re: Certificate list size in
	`gnutls_certificate_get_peers ()'
References: <87bqhv1gvo.fsf@laas.fr> <87fy77ca8b.fsf@mocca.josefsson.org>
	<87ejmqx413.fsf@laas.fr> <87zm5e9dg6.fsf@mocca.josefsson.org>
Message-ID: <87r6qqlz5t.fsf@laas.fr>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> I just realized that we can solve it without an ABI/API change: just
> make the array zero-terminated.  You'll have to traverse the list in
> order to find out its size, but perhaps that is not so much trouble.
> What do you think?

Yes, good idea.

Eventually, it might be worth choosing either one approach or the other
(i.e., null-terminated or LIST_SIZE argument) for both functions, for
the sake of consistency (maybe in the next API-breaking version?).

Thanks,
Ludovic.





From simon at josefsson.org  Thu Apr 12 12:44:37 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 12 Apr 2007 12:44:37 +0200
Subject: [Help-gnutls] Re: Certificate list size in
	`gnutls_certificate_get_peers ()'
In-Reply-To: <87r6qqlz5t.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Thu\, 12
	Apr 2007 11\:28\:30 +0200")
References: <87bqhv1gvo.fsf@laas.fr> <87fy77ca8b.fsf@mocca.josefsson.org>
	<87ejmqx413.fsf@laas.fr> <87zm5e9dg6.fsf@mocca.josefsson.org>
	<87r6qqlz5t.fsf@laas.fr>
Message-ID: <878xcx7tyi.fsf@mocca.josefsson.org>

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

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> I just realized that we can solve it without an ABI/API change: just
>> make the array zero-terminated.  You'll have to traverse the list in
>> order to find out its size, but perhaps that is not so much trouble.
>> What do you think?
>
> Yes, good idea.

Patches welcome. :)  I'm a bit busy now, but perhaps next week...

> Eventually, it might be worth choosing either one approach or the other
> (i.e., null-terminated or LIST_SIZE argument) for both functions, for
> the sake of consistency (maybe in the next API-breaking version?).

I'd rather add new APIs and deprecate the old ones.

/Simon




From ludovic.courtes at laas.fr  Thu Apr 12 14:06:03 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 12 Apr 2007 14:06:03 +0200
Subject: [Help-gnutls] Re: Semantics of `gnutls_openpgp_key_check_hostname
	()'
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
	<87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org>
Message-ID: <878xcxlrv8.fsf@laas.fr>

Simon Josefsson <simon at josefsson.org> writes:

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

[...]

>> I agree that it feels strange!  But i'm really hoping to see OpenPGP
>> keys used in place of X.509 certs for TLS, so we need to think about
>> what's the appropriate thing to put there, and how various Certificate
>> authorities and clients should interpret it.

[...]

> I just realized: Do we have to use the ID packet for this purpose?
> Can't we define a new OpenPGP packet, similar to the X.509 Subject
> Alternative Name extension?  I think this is similar to how X.509
> evolved: first you placed the server name in the CN, then you invented
> an extension packet to hold it.

In any case, I believe the user ID packet should just be thought of as a
human-readable hint, no more.  You don't make authorization decisions
based on what the user ID packet contains, but rather, for instance,
based on whether that key is in your list of authorized keys for the
purpose at hand.

So I don't clearly understand what specifying new textual packets would
buy us.  I don't know much about what X.509 does, though.

Thanks,
Ludovic.





From ludovic.courtes at laas.fr  Thu Apr 12 14:22:54 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 12 Apr 2007 14:22:54 +0200
Subject: [Help-gnutls] Re: Certificate list size in
	`gnutls_certificate_get_peers ()'
References: <87bqhv1gvo.fsf@laas.fr> <87fy77ca8b.fsf@mocca.josefsson.org>
	<87ejmqx413.fsf@laas.fr> <87zm5e9dg6.fsf@mocca.josefsson.org>
	<87r6qqlz5t.fsf@laas.fr> <878xcx7tyi.fsf@mocca.josefsson.org>
Message-ID: <871wipkcip.fsf@laas.fr>

Hey,

Simon Josefsson <simon at josefsson.org> writes:

> ludovic.courtes at laas.fr (Ludovic Court?s) writes:
>
>> Hi,
>>
>> Simon Josefsson <simon at josefsson.org> writes:
>>
>>> I just realized that we can solve it without an ABI/API change: just
>>> make the array zero-terminated.  You'll have to traverse the list in
>>> order to find out its size, but perhaps that is not so much trouble.
>>> What do you think?
>>
>> Yes, good idea.
>
> Patches welcome. :)  I'm a bit busy now, but perhaps next week...

Looks like it may be more complicated than it seems because we don't
have such an array internally.  What we have is an array of
`gnutls_cert's, each of which contains both the raw certificate and the
parsed certificate (see `session->internals.selected_cert_list').

Thus, to provide a (null-terminated) array of raw certificates in
`gnutls_certificate_get_ours ()', we'd need to allocate that array or
ask users for storage.

Or we could change the `gnutls_cert' structure so that it no longer
includes `raw' and store the raw certificates elsewhere.  But that would
certainly have unforeseen implications on the rest of the code...  ;-)

I'm a bit busy, too, so I probably won't investigate it any further ATM.

Thanks,
Ludovic.





From simon at josefsson.org  Thu Apr 12 14:29:36 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 12 Apr 2007 14:29:36 +0200
Subject: [Help-gnutls] Re: Semantics of `gnutls_openpgp_key_check_hostname
	()'
In-Reply-To: <878xcxlrv8.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Thu\, 12
	Apr 2007 14\:06\:03 +0200")
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
	<87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org> <878xcxlrv8.fsf@laas.fr>
Message-ID: <87bqht6aj3.fsf@mocca.josefsson.org>

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

> Simon Josefsson <simon at josefsson.org> writes:
>
>> Daniel Kahn Gillmor <dkg-debian.org at fifthhorseman.net> writes:
>
> [...]
>
>>> I agree that it feels strange!  But i'm really hoping to see OpenPGP
>>> keys used in place of X.509 certs for TLS, so we need to think about
>>> what's the appropriate thing to put there, and how various Certificate
>>> authorities and clients should interpret it.
>
> [...]
>
>> I just realized: Do we have to use the ID packet for this purpose?
>> Can't we define a new OpenPGP packet, similar to the X.509 Subject
>> Alternative Name extension?  I think this is similar to how X.509
>> evolved: first you placed the server name in the CN, then you invented
>> an extension packet to hold it.
>
> In any case, I believe the user ID packet should just be thought of as a
> human-readable hint, no more.  You don't make authorization decisions
> based on what the user ID packet contains, but rather, for instance,
> based on whether that key is in your list of authorized keys for the
> purpose at hand.

Hm.  That's true.

> So I don't clearly understand what specifying new textual packets would
> buy us.  I don't know much about what X.509 does, though.

The difference here is that you can look at a X.509 certificate and
tell whether it is intended for use as a server certificate for a
particular hostname.

However, the difference between X.509 and OpenPGP is that for X.509,
it is the CA who signed the server certificate who has to agree that
the server certificate is responsible for that particular server, so
the information has to be in the server certificate.  There is no
similar concept in OpenPGP.

This logic suggests that GnuTLS should not check the hostname against
the OpenPGP ID packet at all.  All authorization decisions should be
based on the trusted key list.

I think you convinced me.  I don't have time to think about code
changes right now though.  Possibly we could just improve
documentation.

/Simon




From simon at josefsson.org  Thu Apr 12 14:38:58 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 12 Apr 2007 14:38:58 +0200
Subject: [Help-gnutls] Re: Certificate list size in
	`gnutls_certificate_get_peers ()'
In-Reply-To: <871wipkcip.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Thu\, 12
	Apr 2007 14\:22\:54 +0200")
References: <87bqhv1gvo.fsf@laas.fr> <87fy77ca8b.fsf@mocca.josefsson.org>
	<87ejmqx413.fsf@laas.fr> <87zm5e9dg6.fsf@mocca.josefsson.org>
	<87r6qqlz5t.fsf@laas.fr> <878xcx7tyi.fsf@mocca.josefsson.org>
	<871wipkcip.fsf@laas.fr>
Message-ID: <877ish6a3h.fsf@mocca.josefsson.org>

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

> Hey,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> ludovic.courtes at laas.fr (Ludovic Court?s) writes:
>>
>>> Hi,
>>>
>>> Simon Josefsson <simon at josefsson.org> writes:
>>>
>>>> I just realized that we can solve it without an ABI/API change: just
>>>> make the array zero-terminated.  You'll have to traverse the list in
>>>> order to find out its size, but perhaps that is not so much trouble.
>>>> What do you think?
>>>
>>> Yes, good idea.
>>
>> Patches welcome. :)  I'm a bit busy now, but perhaps next week...
>
> Looks like it may be more complicated than it seems because we don't
> have such an array internally.  What we have is an array of
> `gnutls_cert's, each of which contains both the raw certificate and the
> parsed certificate (see `session->internals.selected_cert_list').
>
> Thus, to provide a (null-terminated) array of raw certificates in
> `gnutls_certificate_get_ours ()', we'd need to allocate that array or
> ask users for storage.
>
> Or we could change the `gnutls_cert' structure so that it no longer
> includes `raw' and store the raw certificates elsewhere.  But that would
> certainly have unforeseen implications on the rest of the code...  ;-)

Right, I was thinking of the latter solution, and I also found that it
would require some larger changes.

> I'm a bit busy, too, so I probably won't investigate it any further ATM.

I've added a TODO:

- Make gnutls_certificate_get_out return a zero-terminated array (or
  add a new API that return the size of the array).

/Simon




From ludovic.courtes at laas.fr  Thu Apr 12 15:41:20 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 12 Apr 2007 15:41:20 +0200
Subject: [Help-gnutls] Re: Semantics of `gnutls_openpgp_key_check_hostname
	()'
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
	<87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org> <878xcxlrv8.fsf@laas.fr>
	<87bqht6aj3.fsf@mocca.josefsson.org>
Message-ID: <87fy75iubj.fsf@laas.fr>

Simon Josefsson <simon at josefsson.org> writes:

> This logic suggests that GnuTLS should not check the hostname against
> the OpenPGP ID packet at all.  All authorization decisions should be
> based on the trusted key list.

Well, that `check_hostname' function is not used within GnuTLS AFAICS,
so it's not a big problem.  But it's true that it appears to be of
little practical use---not to mention that it currently does little more
than `strcmp ()'.  ;-)

Thanks,
Ludovic.





From dkg-debian.org at fifthhorseman.net  Thu Apr 12 17:17:30 2007
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 12 Apr 2007 11:17:30 -0400
Subject: OpenPGP certificate verification for TLS connections [Was: Re:
	[Help-gnutls] Re: Semantics of `gnutls_openpgp_key_check_hostname ()']
In-Reply-To: <87bqht6aj3.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 12 Apr 2007 14:29:36 +0200")
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
	<87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org> <878xcxlrv8.fsf@laas.fr>
	<87bqht6aj3.fsf@mocca.josefsson.org>
Message-ID: <87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net>

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

On Thu 2007-04-12 08:29:36 -0400, Simon Josefsson wrote:

> ludovic.courtes at laas.fr (Ludovic Court?s) writes:
>
>> In any case, I believe the user ID packet should just be thought of
>> as a human-readable hint, no more.  You don't make authorization
>> decisions based on what the user ID packet contains, but rather,
>> for instance, based on whether that key is in your list of
>> authorized keys for the purpose at hand.
>
> Hm.  That's true.

I disagree with this, actually.  One of the whole points of any PKI
(web of trust [0], X.509, etc) is that given the proper signatures,
you should be able to accept a previously-unknown key with confidence
that it belongs to the person/service you think it does.

To that end, i think that the "trusted key list" idea should *not* be
used for TLS authentication.  Instead, it should rely on the web of
trust model already provided by OpenPGP, combined with either:

 * a list or matching rule of authorized User IDs (from the
   perspective of a server), or

 * a "match" between the User ID and the service connected to (from
   the perspective of a client)

This model handles key expiration, revocation, and replacement in a
much cleaner way.

For domains that want centralized management (e.g. schools, corps,
etc), this model can also handle exclusion from a domain in a
centralized way.  This is something that X.509 offers, and we'd need
to be able to offer as well, if we want OpenPGP keys to be taken
seriously as a replacement model.

You can do a complete authorization cutoff by:

 0) establish a domain-wide authority OpenPGP key
    (e.g. "authority at example.org").

 1) use that key to sign users' keys for the domain, binding them to
    "username at example.org" with the authority's signature.

 2) establish a domain-internal keyserver, or rely on a public
    keyserver.  (call this keyserver.example.org)

 3) set up all your servers to authenticate clients using OpenPGP
    certificates in the TLS sessions.  For authentication decisions,
    your servers should only trust signatures made by
    authority at example.org.  Tell the servers to check with
    keyserver.example.org frequently (perhaps query for info about
    each key as requests are made?)

 4) When a user is to be excluded from the domain, simply revoke the
    authority at example.org signature, and publish the signature
    revocation to keyserver.example.org (this is the analog to CRLs or
    OCSP for X.509)

Likewise, you could update a server's OpenPGP key using a similar
series of steps, and an end user already enmeshed in the web of trust
could accept the new OpenPGP certificate offered without external
verification.

> The difference here is that you can look at a X.509 certificate and
> tell whether it is intended for use as a server certificate for a
> particular hostname.

Right.  This is a nice feature of X.509.  But why couldn't OpenPGP be
used in the same way?

The majority of User ID fields in existence now are RFC 822 values,
which are often bound to an individual who controls that e-mail
address.

What if we establish a convention that RFC 822 values *do* identify
people (or groups of people) who control a particular e-mail address.

That then frees up the entire range of non-822 strings to identify
other entities.

For example:

 User ID packets that contain only a URL (as defined in RFC 1738) are
 server User ID packets.  Signatures bound to these packets indicate
 that this key is used by the server responding to requests at that
 URL.

If we accept this convention, then:

 0) a domain's secure web server might have a key with User ID
    "https://example.org"

 1) the LDAP server in my previous example would claim
    "ldap://example.org" and/or possibly "ldaps://example.org"
    (depending on whether it was STARTTLS-enabled or TLS-wrapped).
    There's no harm in including both UIDs if both services are
    available.

 2) A mail transfer agent might offer "smtp://example.org" and
    "smtps://example.org" and "submission://example.org"

This proposed convention is probably too simple, and doesn't include
some things which might be nice (such as comments in the UID field in
addition to the URL itself, or an explanation of what
"https://example.org/~foo/" would mean in a UID).

I'd be curious to hear what people on this list think could be added
(or omitted) from this proposal.

> However, the difference between X.509 and OpenPGP is that for X.509,
> it is the CA who signed the server certificate who has to agree that
> the server certificate is responsible for that particular server, so
> the information has to be in the server certificate.  There is no
> similar concept in OpenPGP.

I actually think the OpenPGP signature concept is pretty much
analogous.  If you sign my key in OpenPGP, what you're really signing
is the binding of some particular User ID (or more than one) to the
public key.  If you think of a human as being a service provider for a
service with a given name and e-mail address (which is effectively a
URL for communication with that human), there's not much difference
from an authentication point of view.

> This logic suggests that GnuTLS should not check the hostname
> against the OpenPGP ID packet at all.  All authorization decisions
> should be based on the trusted key list.

I hope what i wrote above explains why i don't think this is a good
idea, but i'd be interested in hearing more arguments in this
direction so i can understand it better.

FWIW, i also don't think that adding a new packet type to OpenPGP is
the way to go.  All existing OpenPGP implementations can already
handle the User ID packet type, and since the RFC doesn't prohibit
non-RFC822 strings, I think we can legitimately propose this as an
extension, as long as we define our UID packets such that they don't
match RFC 822.

This discussion is a really good one.  I look forward to hearing other
proposals, or objections/concerns about the proposal laid out above.

Regards,

        --dkg

[0] http://www.rubin.ch/pgp/weboftrust.en.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFGHk1giXTlFKVLY2URAmioAKCRQIfEYgySxaAUH0IPK6uP6DFiigCdHT77
CYWX743u+G9TFQPz0lQVCto=
=Dnk7
-----END PGP SIGNATURE-----




From ludovic.courtes at laas.fr  Fri Apr 13 10:04:42 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 13 Apr 2007 10:04:42 +0200
Subject: [Help-gnutls] Re: OpenPGP certificate verification for TLS
	connections
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
	<87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org> <878xcxlrv8.fsf@laas.fr>
	<87bqht6aj3.fsf@mocca.josefsson.org>
	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net>
Message-ID: <87k5wgaeed.fsf@laas.fr>

Hi,

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

> On Thu 2007-04-12 08:29:36 -0400, Simon Josefsson wrote:
>
>> ludovic.courtes at laas.fr (Ludovic Court?s) writes:
>>
>>> In any case, I believe the user ID packet should just be thought of
>>> as a human-readable hint, no more.  You don't make authorization
>>> decisions based on what the user ID packet contains, but rather,
>>> for instance, based on whether that key is in your list of
>>> authorized keys for the purpose at hand.
>>
>> Hm.  That's true.

[...]

> To that end, i think that the "trusted key list" idea should *not* be
> used for TLS authentication.  Instead, it should rely on the web of
> trust model already provided by OpenPGP, combined with either:

"Trusted key list" was just an example.  I did not exclude more
sophisticated approaches, including use of web of trust information.

>  * a list or matching rule of authorized User IDs (from the
>    perspective of a server), or

What I did reject, though, is precisely this: making authorization
decisions based on user IDs (which is what the above bullet seem to
imply, IIUC).  This is for obvious reasons: one can put anything in the
user ID packet; if I know you'd grant access to your service provided my
user ID contains the string "example.org", then I'll just add that
string to my user ID.

> You can do a complete authorization cutoff by:
>
>  0) establish a domain-wide authority OpenPGP key
>     (e.g. "authority at example.org").
>
>  1) use that key to sign users' keys for the domain, binding them to
>     "username at example.org" with the authority's signature.
>
>  2) establish a domain-internal keyserver, or rely on a public
>     keyserver.  (call this keyserver.example.org)
>
>  3) set up all your servers to authenticate clients using OpenPGP
>     certificates in the TLS sessions.  For authentication decisions,
>     your servers should only trust signatures made by
>     authority at example.org.  Tell the servers to check with
>     keyserver.example.org frequently (perhaps query for info about
>     each key as requests are made?)
>
>  4) When a user is to be excluded from the domain, simply revoke the
>     authority at example.org signature, and publish the signature
>     revocation to keyserver.example.org (this is the analog to CRLs or
>     OCSP for X.509)

This approach differs from what I understood of the bullet I cited above
in that it does not rely on the user ID packet, AFAIUI.

This looks like a hierarchical authorization model ? la X.509: if a
principle is authorized by the authority (i.e., if there exists an
_authorization_ certificate signed by "authority at example.org"), then it
allowed to access the service.  There is nothing in GnuTLS and
draft-ietf-tls-openpgp-keys-11.txt preventing you from implementing such
a policy.

(This assumes that the server has somehow previously established the
authenticity of the binding between the authority and the key that
allegedly belongs to it.)

Also, note that I used the term "authorization certificate".  A
signature packet in an OpenPGP certificate (or "transferable public
key", in RFC 2440 terms) would not do it since the sole meaning of these
signatures is that "the signer is testifying to his or her belief that
this public key belongs to the user identified by this user ID"
[RFC 2440, Section 10.1].  So you need a specific kind of authorization
certificate in addition to the OpenPGP certificate.

In general, OpenPGP does not attempt to provide an _authorization_
framework.  Thus, one has to "roll their own" authorization scheme atop
OpenPGP-based authentication.

What you proposed above is indeed an authorization scheme.  I believe it
is beyond the scope of OpenPGP and draft-ietf-tls-openpgp-keys-11.txt.
But the cool thing is that while such an authorization scheme can be
implemented on top of OpenPGP, many other schemes can as well be
implemented, including the simple "list of trusted keys".  IMO, this
freedom of choice is also what makes OpenPGP-based authentication
attractive.

Nevertheless, if the hierarchical authorization scheme you proposed
appears to be useful and convenient in a large number of use cases, it
would certainly be worthwhile specifying it or providing an
implementation.

Thanks,
Ludovic.





From rks at mur.at  Sat Apr 14 01:10:54 2007
From: rks at mur.at (Rupert Kittinger-Sereinig)
Date: Sat, 14 Apr 2007 01:10:54 +0200
Subject: OpenPGP certificate verification for TLS connections [Was: Re:
	[Help-gnutls] Re: Semantics of `gnutls_openpgp_key_check_hostname ()']
In-Reply-To: <87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net>
References: <87ejmtlfkj.fsf@chbouib.org>
	<87bqhvca3g.fsf@mocca.josefsson.org>	<877isix5v7.fsf@squeak.fifthhorseman.net>
	<87zm5euadu.fsf@laas.fr>	<87ejmqrcym.fsf@squeak.fifthhorseman.net>	<87veg29d96.fsf@mocca.josefsson.org>
	<878xcxlrv8.fsf@laas.fr>	<87bqht6aj3.fsf@mocca.josefsson.org>
	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net>
Message-ID: <46200DFE.3040009@mur.at>

Hi folks,

I have followed this thread and I would like to add a different 
perspective. What is wrong with X509 certificates? I will try to put my 
view in nutshell:

X509 certificates mix up two concepts: who is the owner of this key, but 
also: what is he allowed to do? To handle these tasks for all use cases, 
people have developed lots of complicated rules, then vendor-specific 
extensions. The result is a mess, to put it mildly.

 From a design point of view, I think it would be a good decision to 
keep user identity and user privilege management separated. OpenPGP can 
be used for the first task, but the second task is probably very domain 
specific.

One example: a secure messaging service could have millions of users. A 
gnupg keyring of this size may be a bit problematic, but a database 
should handle this easily. To validate a client connection in this 
scenario, we would need to:
- check for a trusted signature (including expiry and revocation), we 
can keep this as simple as checking for one trusted key if we want.
- now that we know the ID is authentic, we can look it up in the 
database and decide what the client is allowed to do.

As for he content of ids, I agree with Daniel: using URIs seems the 
logical choice to me, at least for servers.

cheers,
Rupert

-- 
Rupert Kittinger-Sereinig <rks at mur.at>
Krenngasse 32
A-8010 Graz
Austria





From dg at cowlark.com  Sun Apr 15 00:50:27 2007
From: dg at cowlark.com (David Given)
Date: Sat, 14 Apr 2007 23:50:27 +0100
Subject: [Help-gnutls] Assertion failure advice
Message-ID: <evrlem$lit$1@sea.gmane.org>

My program, which uses gnutls, is very occasionally crashing for no apparent
reason. After much effort (running it in a screen session for two weeks...)
I've finally managed to get some tracing:

spey: ath.c:184: _gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)'
failed.

This appears to be an assertion failure inside gnutls. I can tell from the
rest of the tracing that it's happening inside a call to gnutls_handshake().

Does anyone know what this might be signifying? It doesn't seem to be my
fault, but I have had very little experience driving the GNUTLS API and I
could easily be getting something wrong. It looks like a mutex failure, but
while my program is multithreaded, I'm using a unique session object per
socket, so I wouldn't have thought this would apply.

The actual code is in the Socket::makesecure() function here:

http://spey.cvs.sourceforge.net/spey/spey/src/Socket.cc?revision=1.12&view=markup

...line 272. Any advice gratefully appreciated.

-- 
??? ?????????????? ??? http://www.cowlark.com ???????????????????
? "Parents let children ride bicycles on the street. But parents do not
? allow children to hear vulgar words. Therefore we can deduce that cursing
? is more dangerous than being hit by a car." --- Scott Adams

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20070414/7174ad02/attachment.pgp>

From simon at josefsson.org  Mon Apr 16 09:43:04 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Apr 2007 09:43:04 +0200
Subject: [Help-gnutls] Re: Assertion failure advice
In-Reply-To: <evrlem$lit$1@sea.gmane.org> (David Given's message of "Sat\, 14
	Apr 2007 23\:50\:27 +0100")
References: <evrlem$lit$1@sea.gmane.org>
Message-ID: <87abx8ojcn.fsf@mocca.josefsson.org>

David Given <dg at cowlark.com> writes:

> My program, which uses gnutls, is very occasionally crashing for no apparent
> reason. After much effort (running it in a screen session for two weeks...)
> I've finally managed to get some tracing:

Thanks for debugging this.

> spey: ath.c:184: _gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)'
> failed.
>
> This appears to be an assertion failure inside gnutls. I can tell from the
> rest of the tracing that it's happening inside a call to gnutls_handshake().

This looks like a gcrypt and mutex related problem to me.  I'm cc'ing
the libgcrypt mailing list.  Werner, any ideas?  What would trigger
this assertion?

> Does anyone know what this might be signifying? It doesn't seem to be my
> fault, but I have had very little experience driving the GNUTLS API and I
> could easily be getting something wrong. It looks like a mutex failure, but
> while my program is multithreaded, I'm using a unique session object per
> socket, so I wouldn't have thought this would apply.

Does you program link to libgcrypt through some other dependency?
Think LDAP, etc.  Do you initialize libgcrypt/gnutls with mutexes?

/Simon




From ludovic.courtes at laas.fr  Mon Apr 16 14:03:43 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 16 Apr 2007 14:03:43 +0200
Subject: [Help-gnutls] Re: OpenPGP certificate verification for TLS
	connections
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
	<87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org> <878xcxlrv8.fsf@laas.fr>
	<87bqht6aj3.fsf@mocca.josefsson.org>
	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net> <46200DFE.3040009@mur.at>
Message-ID: <87647wv84g.fsf@laas.fr>

Hi,

Rupert Kittinger-Sereinig <rks at mur.at> writes:

> From a design point of view, I think it would be a good decision to
> keep user identity and user privilege management separated. OpenPGP
> can be used for the first task, but the second task is probably very
> domain specific.

Agreed.  FWIW, I use OpenPGP-based authentication in a peer-to-peer-like
application.  Here, OpenPGP public keys serve as a means to identify
peers---the user ID packet of each key is not used for identifying
purposes.  "Authorization" in a p2p system is "sloppy".  The exact
authorization decision-making process can be quite complex, involving a
lot of different criteria: did I already meet the peer with key
"1234abcd" earlier?  How much resources did it contribute to me or to
the service?  How much trustworthy do I consider it?  Etc.

So, clearly, in this context, authorization is very
application-specific.

This is of course way different from more centralized scenarios, like,
say, the archival service in a company.  In such scenarios, X.509 might
prove to be more convenient than OpenPGP, I dunno.

> One example: a secure messaging service could have millions of
> users. A gnupg keyring of this size may be a bit problematic, but a
> database should handle this easily. To validate a client connection in
> this scenario, we would need to:
> - check for a trusted signature (including expiry and revocation), we
> can keep this as simple as checking for one trusted key if we want.

What do you mean by "trusted signature"?  Something like an
"authorization certificate" signed by a "trusted authority" (see my
previous post)?

> - now that we know the ID is authentic, we can look it up in the
> database and decide what the client is allowed to do.
>
> As for he content of ids, I agree with Daniel: using URIs seems the
> logical choice to me, at least for servers.

Why?  How does this derive from the authorization scheme you just
sketched?

Thanks,
Ludovic.





From rks at mur.at  Mon Apr 16 22:28:08 2007
From: rks at mur.at (Rupert Kittinger-Sereinig)
Date: Mon, 16 Apr 2007 22:28:08 +0200
Subject: [Help-gnutls] Re: OpenPGP certificate verification for
	TLS	connections
In-Reply-To: <87647wv84g.fsf@laas.fr>
References: <87ejmtlfkj.fsf@chbouib.org>
	<87bqhvca3g.fsf@mocca.josefsson.org>	<877isix5v7.fsf@squeak.fifthhorseman.net>
	<87zm5euadu.fsf@laas.fr>	<87ejmqrcym.fsf@squeak.fifthhorseman.net>	<87veg29d96.fsf@mocca.josefsson.org>
	<878xcxlrv8.fsf@laas.fr>	<87bqht6aj3.fsf@mocca.josefsson.org>	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net>
	<46200DFE.3040009@mur.at> <87647wv84g.fsf@laas.fr>
Message-ID: <4623DC58.60008@mur.at>

Ludovic Court?s schrieb:
...
>> One example: a secure messaging service could have millions of
>> users. A gnupg keyring of this size may be a bit problematic, but a
>> database should handle this easily. To validate a client connection in
>> this scenario, we would need to:
>> - check for a trusted signature (including expiry and revocation), we
>> can keep this as simple as checking for one trusted key if we want.
> 
> What do you mean by "trusted signature"?  Something like an
> "authorization certificate" signed by a "trusted authority" (see my
> previous post)?
> 

I mean trusted in the sense of the pgp trustdb. Ideally, every user 
should be able to configure how he wants to construct his web of trust.

E.g. for a server application, the admin could choose a handfull of 
"user managers" whose keys he would put in the keyring and assign 
ultimte trust to each one.

Another example: a user of web services could validate the server key 
fingerprint, and locally sign them with his own key.

>> - now that we know the ID is authentic, we can look it up in the
>> database and decide what the client is allowed to do.
>>

One more point: even if the user id is relevant and not the key, key 
revocation must still ber handled on a key basis. But this is only 
necessary for key compromise, which should be a rare event. If a user 
should be denied access, this can be handled via his id.

>> As for he content of ids, I agree with Daniel: using URIs seems the
>> logical choice to me, at least for servers.
> 
> Why?  How does this derive from the authorization scheme you just
> sketched?
> 

I did not want to imply that this follows from the first part, I just 
wanted to say I think it is the right thing to do :-)

To be more precise, I would suggest using URIs a defined in RFC 2396, 
section 3, without the additional restriction that the path and query 
components must be empty.

Since this is also a straightforward method to define how to access the 
server, it should be easy for the client to check.

cheers,
Rupert

-- 
Rupert Kittinger-Sereinig <rks at mur.at>
Krenngasse 32
A-8010 Graz
Austria





From dg at cowlark.com  Tue Apr 17 01:46:59 2007
From: dg at cowlark.com (David Given)
Date: Tue, 17 Apr 2007 00:46:59 +0100
Subject: [Help-gnutls] Re: Assertion failure advice
In-Reply-To: <87bqho8xuh.fsf@wheatstone.g10code.de>
References: <evrlem$lit$1@sea.gmane.org> <87abx8ojcn.fsf@mocca.josefsson.org>
	<87bqho8xuh.fsf@wheatstone.g10code.de>
Message-ID: <f011ro$3od$1@sea.gmane.org>

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

Werner Koch wrote:
[...]
> The thread callbacks are not setup at time.  This should be done even
> before the version check and definitely before initializing secure
> memory.  Here is an example using GNU Pth:

I've just noticed that there's a section of the gnutls manual calling
'Multithreaded programs' which, er, I'd completely missed the first time
through. Which means that I haven't been telling gnutls to set up gcrypt
properly. Mea culpa; sorry.

Presumably I'm only getting this crash when two threads try to do a TLS
handshake at the same time, at exactly the right time to cause gcrypt to step
on its own toes.

I'll fix this and see if the problem goes away.

- --
??? ?????????????? ??? http://www.cowlark.com ???????????????????
? "Parents let children ride bicycles on the street. But parents do not
? allow children to hear vulgar words. Therefore we can deduce that cursing
? is more dangerous than being hit by a car." --- Scott Adams
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGJArzf9E0noFvlzgRAp8uAJwMELeePd61OgydP9wDp5qi8bktxwCglsLH
lLz7wkVAudzDCJ3U4EV6YFY=
=+b83
-----END PGP SIGNATURE-----





From simon at josefsson.org  Tue Apr 17 10:47:13 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 17 Apr 2007 10:47:13 +0200
Subject: [Help-gnutls] Re: Assertion failure advice
In-Reply-To: <f011ro$3od$1@sea.gmane.org> (David Given's message of "Tue\, 17
	Apr 2007 00\:46\:59 +0100")
References: <evrlem$lit$1@sea.gmane.org> <87abx8ojcn.fsf@mocca.josefsson.org>
	<87bqho8xuh.fsf@wheatstone.g10code.de> <f011ro$3od$1@sea.gmane.org>
Message-ID: <87y7kr1j72.fsf@mocca.josefsson.org>

David Given <dg at cowlark.com> writes:

> Werner Koch wrote:
> [...]
>> The thread callbacks are not setup at time.  This should be done even
>> before the version check and definitely before initializing secure
>> memory.  Here is an example using GNU Pth:
>
> I've just noticed that there's a section of the gnutls manual calling
> 'Multithreaded programs' which, er, I'd completely missed the first time
> through. Which means that I haven't been telling gnutls to set up gcrypt
> properly. Mea culpa; sorry.
>
> Presumably I'm only getting this crash when two threads try to do a TLS
> handshake at the same time, at exactly the right time to cause gcrypt to step
> on its own toes.
>
> I'll fix this and see if the problem goes away.

Good.  It was good to know what error is likely to come up if you
forget to initialize threading properly.  Thanks again for reporting,
and let us know how it works out.

/Simon




From ludovic.courtes at laas.fr  Tue Apr 17 11:27:47 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 17 Apr 2007 11:27:47 +0200
Subject: [Help-gnutls] Re: OpenPGP certificate verification for
	TLS	connections
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
	<87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org> <878xcxlrv8.fsf@laas.fr>
	<87bqht6aj3.fsf@mocca.josefsson.org>
	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net> <46200DFE.3040009@mur.at>
	<87647wv84g.fsf@laas.fr> <4623DC58.60008@mur.at>
Message-ID: <874pnffizw.fsf@laas.fr>

Hi,

Rupert Kittinger-Sereinig <rks at mur.at> writes:

> Ludovic Court?s schrieb:
> ...
>>> One example: a secure messaging service could have millions of
>>> users. A gnupg keyring of this size may be a bit problematic, but a
>>> database should handle this easily. To validate a client connection in
>>> this scenario, we would need to:
>>> - check for a trusted signature (including expiry and revocation), we
>>> can keep this as simple as checking for one trusted key if we want.
>>
>> What do you mean by "trusted signature"?  Something like an
>> "authorization certificate" signed by a "trusted authority" (see my
>> previous post)?
>>
>
> I mean trusted in the sense of the pgp trustdb. Ideally, every user
> should be able to configure how he wants to construct his web of trust.
>
> E.g. for a server application, the admin could choose a handfull of
> "user managers" whose keys he would put in the keyring and assign
> ultimte trust to each one.
>
> Another example: a user of web services could validate the server key
> fingerprint, and locally sign them with his own key.

Nitpick: As mentioned earlier in this thread, signing an OpenPGP public
key means that "the signer is testifying to his or her belief that this
public key belongs to the user identified by this user ID" [RFC 2440,
Section 10.1].  I think this is not what you want here.

Thanks,
Ludovic.





From dkg-debian.org at fifthhorseman.net  Tue Apr 17 20:18:42 2007
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 17 Apr 2007 14:18:42 -0400
Subject: [Help-gnutls] Re: OpenPGP certificate verification for
	TLS	connections
In-Reply-To: <874pnffizw.fsf@laas.fr> (Ludovic =?utf-8?Q?Court=C3=A8s's?=
	message of "Tue, 17 Apr 2007 11:27:47 +0200")
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
	<87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org> <878xcxlrv8.fsf@laas.fr>
	<87bqht6aj3.fsf@mocca.josefsson.org>
	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net> <46200DFE.3040009@mur.at>
	<87647wv84g.fsf@laas.fr> <4623DC58.60008@mur.at>
	<874pnffizw.fsf@laas.fr>
Message-ID: <87y7kqeuf1.fsf@squeak.fifthhorseman.net>

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

On Tue 2007-04-17 05:27:47 -0400, Ludovic Court?s wrote:

> Rupert Kittinger-Sereinig <rks at mur.at> writes:
>
>> I mean trusted in the sense of the pgp trustdb. Ideally, every user
>> should be able to configure how he wants to construct his web of
>> trust.
>>
>> E.g. for a server application, the admin could choose a handfull of
>> "user managers" whose keys he would put in the keyring and assign
>> ultimte trust to each one.

Yes, this is the most flexible, distributed variant of PKI that i've
seen offered yet.  It is *exactly* the functionality that we're
missing in the current X.509 architecture.

And that "user managers" don't need to be given ultimate trust.  Your
server authentication policy could be "at least two 'user managers'
must sign off on any given key for a user." Or it could be something
even more complicated.

Note that the OpenPGP web of trust infrastructure allows for clean,
arbitrary authentication policy, configurable by existing tools.  The
authentication question OpenPGP asks is: "to whom does the presented
key really belong?"  The answer it gives is a list of authenticated
User IDs: all User IDs that have been sufficiently validated by the
web of trust.

Given this list of User IDs, the system can now perform arbitrary
*authorization* policy checks: Are any of the presented User IDs
authorized to use the particular service?

Note that the authorization layer is completely agnostic about the
keys.  This is a feature, not a bug!  It means users can have multiple
keys (if each key is signed by the appropriate trusted people), users
can revoke old keys in the case of compromise, keys can expire, and so
on, all without any changes to the server itself or any centralized
control [0].

>> Another example: a user of web services could validate the server
>> key fingerprint, and locally sign them with his own key.
>
> Nitpick: As mentioned earlier in this thread, signing an OpenPGP
> public key means that "the signer is testifying to his or her belief
> that this public key belongs to the user identified by this user ID"
> [RFC 2440, Section 10.1].  I think this is not what you want here.

i think this is precisely what is needed, actually.  Take as an
existing example, the default form of key/identity matching used in
OpenSSH: the ~/.ssh/known_hosts file.  An entry in that file indicates
that the user trusts that the key is bound to that host (the host
being the agent who controls that key).

We don't want the user to trust the given key for any arbitrary host.
The user is explicitly testifying to the binding between the key and
the host itself, which is exactly what the signature means.

The model where individual agents (whether human or service) have
explicitly-defined authentication policies based on the OpenPGP
web-of-trust, and separate authorization policies based on User ID is
capable of emulating the two dominant forms of PKI in use today.  It
can emulate both:

 a) simple openssh-style point-to-point relationships (each agent only
    trusts themselves to identify other agents, and accepts/signs
    key/UID tuples on a case-by-case basis, and stores appropriate
    UIDs where needed for future authorization), and

 b) X.509 hierarchical models (each agent only trusts a single third
    party to identify other agents.  authorization is handled by an
    external policy layer)

And it opens the door for what i personally really want to see, which
is a universal, distributed trust model.

    --dkg

[0] publication of signatures/revocation certificates to a keyserver
    is semi-centralized, but given that any number of keyservers could
    be used, and there is no requirement that the keyserver be a
    locked-down or centrally-maintained service, the system is still
    quite decentralized.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFGJQ96iXTlFKVLY2URAkeEAKCfpFvCosOqhqSJAni1pc1jrCXUrgCguKlE
zW7czMkY98jN6KR8HwmJHaU=
=HKv7
-----END PGP SIGNATURE-----




From rks at mur.at  Tue Apr 17 20:22:36 2007
From: rks at mur.at (Rupert Kittinger-Sereinig)
Date: Tue, 17 Apr 2007 20:22:36 +0200
Subject: [Help-gnutls] Re: OpenPGP certificate verification
	for	TLS	connections
In-Reply-To: <874pnffizw.fsf@laas.fr>
References: <87ejmtlfkj.fsf@chbouib.org>
	<87bqhvca3g.fsf@mocca.josefsson.org>	<877isix5v7.fsf@squeak.fifthhorseman.net>
	<87zm5euadu.fsf@laas.fr>	<87ejmqrcym.fsf@squeak.fifthhorseman.net>	<87veg29d96.fsf@mocca.josefsson.org>
	<878xcxlrv8.fsf@laas.fr>	<87bqht6aj3.fsf@mocca.josefsson.org>	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net>
	<46200DFE.3040009@mur.at>	<87647wv84g.fsf@laas.fr>
	<4623DC58.60008@mur.at> <874pnffizw.fsf@laas.fr>
Message-ID: <4625106C.2020105@mur.at>

Ludovic Court?s schrieb:
> Hi,
> 
> Rupert Kittinger-Sereinig <rks at mur.at> writes:
> 
>> Ludovic Court?s schrieb:
>> ...
>>>> One example: a secure messaging service could have millions of
>>>> users. A gnupg keyring of this size may be a bit problematic, but a
>>>> database should handle this easily. To validate a client connection in
>>>> this scenario, we would need to:
>>>> - check for a trusted signature (including expiry and revocation), we
>>>> can keep this as simple as checking for one trusted key if we want.
>>> What do you mean by "trusted signature"?  Something like an
>>> "authorization certificate" signed by a "trusted authority" (see my
>>> previous post)?
>>>
>> I mean trusted in the sense of the pgp trustdb. Ideally, every user
>> should be able to configure how he wants to construct his web of trust.
>>
>> E.g. for a server application, the admin could choose a handfull of
>> "user managers" whose keys he would put in the keyring and assign
>> ultimte trust to each one.
>>
>> Another example: a user of web services could validate the server key
>> fingerprint, and locally sign them with his own key.
> 
> Nitpick: As mentioned earlier in this thread, signing an OpenPGP public
> key means that "the signer is testifying to his or her belief that this
> public key belongs to the user identified by this user ID" [RFC 2440,
> Section 10.1].  I think this is not what you want here.
> 
> Thanks,
> Ludovic.
> 

Why do you think so? If I verify that the key belongs to a person (e.g 
by checking the fingerprint) I may well document that for later 
reference by signing the key.

Rupert

-- 
Rupert Kittinger-Sereinig <rks at mur.at>
Krenngasse 32
A-8010 Graz
Austria





From smurf at smurf.noris.de  Tue Apr 17 21:12:01 2007
From: smurf at smurf.noris.de (Matthias Urlichs)
Date: Tue, 17 Apr 2007 21:12:01 +0200
Subject: [Help-gnutls] Re: OpenPGP certificate verification for
	TLS	connections
In-Reply-To: <87y7kqeuf1.fsf@squeak.fifthhorseman.net>
References: <87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org> <878xcxlrv8.fsf@laas.fr>
	<87bqht6aj3.fsf@mocca.josefsson.org>
	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net>
	<46200DFE.3040009@mur.at> <87647wv84g.fsf@laas.fr>
	<4623DC58.60008@mur.at> <874pnffizw.fsf@laas.fr>
	<87y7kqeuf1.fsf@squeak.fifthhorseman.net>
Message-ID: <20070417191201.GK14768@kiste.smurf.noris.de>

Hi,

Daniel Kahn Gillmor:
> i think this is precisely what is needed, actually.  Take as an
> existing example, the default form of key/identity matching used in
> OpenSSH: the ~/.ssh/known_hosts file.  An entry in that file indicates
> that the user trusts that the key is bound to that host (the host
> being the agent who controls that key).
> 
Good example, that. I do NOT want to ask my user "is that really the key
of the host you want to talk to?" questions. In a large system, that's
pointless, especially as you're really not supposed to give the same key
to multiple hosts. Does any of you ever check that fingerprint against
the original?

So what I *really* want is a host key that's signed by the systems'
admin key, and I want to tell my users, or rather my default suer setup,
"if you see a host key that's signed by _that_ key here, and if you're
connecting to hosts in _these_ domains, maybe print a nice info the
first time you see it in an interactive session, but otherwise assume
it's OK".

Or something along these lines.

-- 
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
 - -
How many Bavarian Illuminati does it take to screw in a lightbulb?

Three: one to screw it in, and one to confuse the issue.




From dkg-debian.org at fifthhorseman.net  Tue Apr 17 22:03:58 2007
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 17 Apr 2007 16:03:58 -0400
Subject: [Help-gnutls] Re: OpenPGP certificate verification for
	TLS	connections
In-Reply-To: <20070417191201.GK14768@kiste.smurf.noris.de> (Matthias Urlichs's
	message of "Tue, 17 Apr 2007 21:12:01 +0200")
References: <87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org> <878xcxlrv8.fsf@laas.fr>
	<87bqht6aj3.fsf@mocca.josefsson.org>
	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net> <46200DFE.3040009@mur.at>
	<87647wv84g.fsf@laas.fr> <4623DC58.60008@mur.at>
	<874pnffizw.fsf@laas.fr> <87y7kqeuf1.fsf@squeak.fifthhorseman.net>
	<20070417191201.GK14768@kiste.smurf.noris.de>
Message-ID: <87d522daz5.fsf@squeak.fifthhorseman.net>

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

On Tue 2007-04-17 15:12:01 -0400, Matthias Urlichs wrote:

> Good example, that. I do NOT want to ask my user "is that really the
> key of the host you want to talk to?" questions. In a large system,
> that's pointless, especially as you're really not supposed to give
> the same key to multiple hosts. Does any of you ever check that
> fingerprint against the original?

i check the fingerprints! (but i know i'm in the minority...)

What i'd really prefer is to have my ssh servers offer GPG keys,
though.  When i set up the server, i'd create the key with a UID (or
UIDs) relevant to the hostname(s) used by that host.  Then i'd sign
the key/uid combination with my "server administrator" key.

My ssh client would know to trust the server administrator key to
identify hosts properly, and would be able to verify everything
automatically, with no manual fingerprint checking or shunting
/etc/ssh/sshd_host_rsa_key.pub over a serial line or sneakernet or
whatever.

This (openssh) is perhaps a little off-topic for the GnuTLS list, but
i think it illustrates a common use case for TLS connections.

> So what I *really* want is a host key that's signed by the systems'
> admin key, and I want to tell my users, or rather my default suer
> setup, "if you see a host key that's signed by _that_ key here, and
> if you're connecting to hosts in _these_ domains, maybe print a nice
> info the first time you see it in an interactive session, but
> otherwise assume it's OK".

i'd agree with this, except i'd say "if you see a host key *bound to
the expected User ID* signed by _that_ key..."

This is because the client should be checking not just that the key is
signed by a trusted authority, but that the authority claims it
belongs to the entity the client is connecting to.

It does raise an interesting question of whether the web-of-trust
should be able to accomodate "only trust key X signatures when they're
bound to User IDs of the following form".  This would let you say, for
example, "i trust dkg to identify people/servers within the
fifthhorseman.net domain, but i'd rather not trust his identifications
of anyone else."

Is there a way to represent something like that in the current
web-of-trust architecture?

    --dkg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFGJSgriXTlFKVLY2URAts5AKCQroiBaQhCRB1L+J+VeGVwjMh21gCgrj+K
RT+kKVhnkq3IZ4G71CWjDBg=
=sVjy
-----END PGP SIGNATURE-----




From rks at mur.at  Tue Apr 17 23:10:24 2007
From: rks at mur.at (Rupert Kittinger-Sereinig)
Date: Tue, 17 Apr 2007 23:10:24 +0200
Subject: [Help-gnutls] Re: OpenPGP certificate verification
	for	TLS	connections
In-Reply-To: <87d522daz5.fsf@squeak.fifthhorseman.net>
References: <87ejmqrcym.fsf@squeak.fifthhorseman.net>	<87veg29d96.fsf@mocca.josefsson.org>
	<878xcxlrv8.fsf@laas.fr>	<87bqht6aj3.fsf@mocca.josefsson.org>	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net>
	<46200DFE.3040009@mur.at>	<87647wv84g.fsf@laas.fr>
	<4623DC58.60008@mur.at>	<874pnffizw.fsf@laas.fr>
	<87y7kqeuf1.fsf@squeak.fifthhorseman.net>	<20070417191201.GK14768@kiste.smurf.noris.de>
	<87d522daz5.fsf@squeak.fifthhorseman.net>
Message-ID: <462537C0.70708@mur.at>

Daniel Kahn Gillmor schrieb:
> 
>> So what I *really* want is a host key that's signed by the systems'
>> admin key, and I want to tell my users, or rather my default suer
>> setup, "if you see a host key that's signed by _that_ key here, and
>> if you're connecting to hosts in _these_ domains, maybe print a nice
>> info the first time you see it in an interactive session, but
>> otherwise assume it's OK".
> 
> i'd agree with this, except i'd say "if you see a host key *bound to
> the expected User ID* signed by _that_ key..."
> 
> This is because the client should be checking not just that the key is
> signed by a trusted authority, but that the authority claims it
> belongs to the entity the client is connecting to.
> 
> It does raise an interesting question of whether the web-of-trust
> should be able to accomodate "only trust key X signatures when they're
> bound to User IDs of the following form".  This would let you say, for
> example, "i trust dkg to identify people/servers within the
> fifthhorseman.net domain, but i'd rather not trust his identifications
> of anyone else."
> 
> Is there a way to represent something like that in the current
> web-of-trust architecture?
> 

In principle, this should be easy: keep different keyrings and/or 
trustdbs for different groups of user ids. whether this is easy to 
implement with concrete implementations is another question :-)

Rupert

-- 
Rupert Kittinger-Sereinig <rks at mur.at>
Krenngasse 32
A-8010 Graz
Austria





From ludovic.courtes at laas.fr  Wed Apr 18 09:17:31 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 18 Apr 2007 09:17:31 +0200
Subject: [Help-gnutls] Re: OpenPGP certificate verification
	for	TLS	connections
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
	<87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org> <878xcxlrv8.fsf@laas.fr>
	<87bqht6aj3.fsf@mocca.josefsson.org>
	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net> <46200DFE.3040009@mur.at>
	<87647wv84g.fsf@laas.fr> <4623DC58.60008@mur.at>
	<874pnffizw.fsf@laas.fr> <4625106C.2020105@mur.at>
Message-ID: <871wii8838.fsf@laas.fr>

Hi,

Rupert Kittinger-Sereinig <rks at mur.at> writes:

> Ludovic Court?s schrieb:
>> Hi,
>>
>> Rupert Kittinger-Sereinig <rks at mur.at> writes:

[...]

>>> I mean trusted in the sense of the pgp trustdb. Ideally, every user
>>> should be able to configure how he wants to construct his web of trust.
>>>
>>> E.g. for a server application, the admin could choose a handfull of
>>> "user managers" whose keys he would put in the keyring and assign
>>> ultimte trust to each one.
>>>
>>> Another example: a user of web services could validate the server key
>>> fingerprint, and locally sign them with his own key.
>>
>> Nitpick: As mentioned earlier in this thread, signing an OpenPGP public
>> key means that "the signer is testifying to his or her belief that this
>> public key belongs to the user identified by this user ID" [RFC 2440,
>> Section 10.1].  I think this is not what you want here.
>>
>> Thanks,
>> Ludovic.
>>
>
> Why do you think so? If I verify that the key belongs to a person (e.g
> by checking the fingerprint) I may well document that for later
> reference by signing the key.

Just because you know for sure that key XYZ belongs to Mr. Someone whom
you've met at the pub the day before doesn't mean you grant him
_authorization_ to use the service you provide.

Instead, you need something that says "key XYZ is authorized to take
such and such actions".  And this does not depend on whether key XYZ
actually belongs to Mr. Someone.

Thanks,
Ludovic.





From ludovic.courtes at laas.fr  Wed Apr 18 09:34:29 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 18 Apr 2007 09:34:29 +0200
Subject: [Help-gnutls] Re: OpenPGP certificate verification for
	TLS	connections
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
	<87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org> <878xcxlrv8.fsf@laas.fr>
	<87bqht6aj3.fsf@mocca.josefsson.org>
	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net> <46200DFE.3040009@mur.at>
	<87647wv84g.fsf@laas.fr> <4623DC58.60008@mur.at>
	<874pnffizw.fsf@laas.fr> <87y7kqeuf1.fsf@squeak.fifthhorseman.net>
Message-ID: <87647u5e62.fsf@laas.fr>

Hi,

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

> Note that the OpenPGP web of trust infrastructure allows for clean,
> arbitrary authentication policy, configurable by existing tools.  The
> authentication question OpenPGP asks is: "to whom does the presented
> key really belong?"  The answer it gives is a list of authenticated
> User IDs: all User IDs that have been sufficiently validated by the
> web of trust.
>
> Given this list of User IDs, the system can now perform arbitrary
> *authorization* policy checks: Are any of the presented User IDs
> authorized to use the particular service?
>
> Note that the authorization layer is completely agnostic about the
> keys.  This is a feature, not a bug!  It means users can have multiple
> keys (if each key is signed by the appropriate trusted people), users
> can revoke old keys in the case of compromise, keys can expire, and so
> on, all without any changes to the server itself or any centralized
> control [0].

I think I'm only starting to get your point, sorry for the delay.  ;-)

My understanding of what you're saying it this (where "I" is the
server):

  1. When I receive a connection from someone, I check the list of
     signers contained in their public key (or "OpenPGP certificate", or
     "transferable public key").

  2. If that key is signed by someone I trust, then I can trust the
     key-user ID binding itself.

  3. _Since_ I trust the key-user ID binding, I can now make
     authorization decisions based only on the user ID.

And this is why the contents of user ID packets matters: URIs would
indeed make it easier to implement step (3).  I think I got it.  :-)

That's probably a useful usage pattern.  The problem that I see is that
it would be non-standard, so (getting back to the original topic) it may
be beyond the scope of GnuTLS.  What would be useful, though, is a set
of tools to traverse the signer graph (as is required by step (2)).

Thanks,
Ludovic.






From simon at josefsson.org  Wed Apr 18 15:19:30 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 18 Apr 2007 15:19:30 +0200
Subject: [Help-gnutls] GnuTLS 1.6.2
Message-ID: <87fy6xkefx.fsf@mocca.josefsson.org>

I am happy to announce GnuTLS 1.6.2!

This is a bugfix-only release on the stable branch.  This version is
what we recommend for those who need a stable version of GnuTLS.

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

* Version 1.6.2 (released 2007-04-18)

** Fix X.509 signing with RSA-PKCS#1 to set a NULL parameters fields.
Before, we remove the parameters field, which resulted in a slightly
different DER encoding which in turn caused signature verification
failures of GnuTLS-generated RSA certificates in some other
implementations (e.g., GnuPG 2.x's gpgsm).  Depending on which RFCs
you read, this may or may not be correct, but our new behaviour appear
to be consistent with other widely used implementations.

** Regenerate the PKIX ASN.1 syntax tree.
For some reason, after changing the ASN.1 type of ldap-UID in the last
release, the generated C file built from the ASN.1 schema was not
refreshed.  This can cause problems when reading/writing UID
components inside X.500 Distinguished Names.  Reported by devel
<dev001 at pas-world.com>.

** Updated translations.

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

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

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

All manual formats are available from:
  http://www.gnutls.org/manual/

Direct link to the most popular formats:
  http://www.gnutls.org/manual/gnutls.html - HTML format
  http://www.gnutls.org/manual/gnutls.pdf  - PDF format
  http://www.gnutls.org/reference/ch01.html  - API Reference, GTK-DOC HTML

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

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

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

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

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

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

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:

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

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

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

d9b0cc20d10d4f0d4f2427a111b0481ae3cbb7da  gnutls-1.6.2.tar.bz2
1a9f990e7dedbc82581e86976dd3dbbfff4129cf  gnutls-1.6.2.tar.bz2.sig

15c6463785b04d75ae688f63f47af687428cdf3fa9175fbe1996f8b1  gnutls-1.6.2.tar.bz2
c498d81417baf2c26dfa05b207f4614fa53d195a2a85f7b88d0a9fd9  gnutls-1.6.2.tar.bz2.sig

1b794512cd3d1050fe0df60ef4718b96161ad1ff  gnutls-1.6.2.exe
49c1788bcb17b5f151a5d64de1907eec31720e88  gnutls-1.6.2.exe.sig

91eda127ac905024198398bea6d7ab7dba7e01aeb54651e21a4f7961  gnutls-1.6.2.exe
f203bdc33cfb3cb3fd795299f0453960864b2c70e249b9850e782466  gnutls-1.6.2.exe.sig

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

From dkg-debian.org at fifthhorseman.net  Wed Apr 18 17:19:41 2007
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 18 Apr 2007 11:19:41 -0400
Subject: [Help-gnutls] Re: OpenPGP certificate verification for
	TLS	connections
In-Reply-To: <87647u5e62.fsf@laas.fr> (Ludovic =?utf-8?Q?Court=C3=A8s's?=
	message of "Wed, 18 Apr 2007 09:34:29 +0200")
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
	<87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org> <878xcxlrv8.fsf@laas.fr>
	<87bqht6aj3.fsf@mocca.josefsson.org>
	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net> <46200DFE.3040009@mur.at>
	<87647wv84g.fsf@laas.fr> <4623DC58.60008@mur.at>
	<874pnffizw.fsf@laas.fr> <87y7kqeuf1.fsf@squeak.fifthhorseman.net>
	<87647u5e62.fsf@laas.fr>
Message-ID: <873b2xk8vm.fsf@squeak.fifthhorseman.net>

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

On Wed 2007-04-18 03:34:29 -0400, Ludovic Court?s wrote:

> I think I'm only starting to get your point, sorry for the delay.  ;-)
>
> My understanding of what you're saying it this (where "I" is the
> server):
>
>   1. When I receive a connection from someone, I check the list of
>      signers contained in their public key (or "OpenPGP certificate", or
>      "transferable public key").
>
>   2. If that key is signed by someone I trust, then I can trust the
>      key-user ID binding itself.
>
>   3. _Since_ I trust the key-user ID binding, I can now make
>      authorization decisions based only on the user ID.
>
> And this is why the contents of user ID packets matters: URIs would
> indeed make it easier to implement step (3).  I think I got it.  :-)

Yes, exactly!  Thanks for persevering through my poor explanations.
Servers would have URIs in their User ID packets and humans (and other
clients) would continue to have rfc822 User ID packets, making it easy
for each one to recognize the other.

There's no *need* for servers to use URI User IDs, of course: a web
server at http://example.org/ could just offer a User ID of
"example.org web server <http at example.org>" (or some comparable
kludge).  In fact, they could offer both User ID packets without
trouble.  But there ought to be a convention so that connecting client
knows which User IDs to even bother looking for (or checking
signatures against), given the address she is connecting to.

> That's probably a useful usage pattern.  The problem that I see is
> that it would be non-standard, 

I'm not convinced that using User IDs for authorization is
non-standard.  Look, for example, at the existing model for mutual
key-based authentication for apache2's mod_ssl (which is one of the
things i'm hoping gnutls can provide an alternative to).  mod_ssl is
configured with a list of trusted certificate authorities
(SSLCACertificatePath).  Those authorities are trusted to identify the
clients who connect (assuming SSLVerifyClient is on).  mod_ssl then
exports the client's Distinguished Name (the X.509 equivalent of
OpenPGP's User ID) to the environment in $SSL_CLIENT_S_DN_*, and
alternately treats the user as though they had done HTTP Basic Auth
(SSLOptions +FakeBasicAuth), which leaves it up to an apache authz
module to do authorization.

In short, the client *authenticates* with her certificate, and the
server *authorizes* against her User ID.

The same is true from the other direction: our web browsers don't
store a list of certificates for every web site: they store a list of
certificate authorities, and trust the authorties to sign off on an
attribute of the offered server cert (the SubjectAltName or the CN),
which is then tested against the address of the service we're trying
to connect to.  The signature has to check out, (that is, it should be
properly *authenticated*) but the SubjectAltName also needs to match
the expected hostname for the browser to *authorize* a connection to
it.

> so (getting back to the original topic) it may be beyond the scope
> of GnuTLS.

By analogy with OpenSSL (which contains significant infrastructure for
managing X.509 certificate hierarchy trust), i would suggest that it
is not outside the scope of GnuTLS to implement a well-thought-out
scheme for trust checking when using OpenPGP certificates.

> What would be useful, though, is a set of tools to traverse the
> signer graph (as is required by step (2)).

gnupg contains a very thorough and well-tested trustdb mechanism,
which i was hoping we could rely on.  A standard convention for
matching User IDs with servers seems to be the only piece of the
puzzle that's lacking.

      --dkg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFGJjb+iXTlFKVLY2URAq4lAJ48Fcwu5sVxnbJYSXCIQ4jrnDVPrwCfQdwx
1lWvU655j98EATlgRsy3vtc=
=ve+Y
-----END PGP SIGNATURE-----




From dkg-debian.org at fifthhorseman.net  Wed Apr 18 17:23:33 2007
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 18 Apr 2007 11:23:33 -0400
Subject: [Help-gnutls] Re: OpenPGP certificate verification for TLS
	connections
In-Reply-To: <871wii8838.fsf@laas.fr> (Ludovic =?utf-8?Q?Court=C3=A8s's?=
	message of "Wed, 18 Apr 2007 09:17:31 +0200")
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
	<87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org> <878xcxlrv8.fsf@laas.fr>
	<87bqht6aj3.fsf@mocca.josefsson.org>
	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net> <46200DFE.3040009@mur.at>
	<87647wv84g.fsf@laas.fr> <4623DC58.60008@mur.at>
	<874pnffizw.fsf@laas.fr> <4625106C.2020105@mur.at>
	<871wii8838.fsf@laas.fr>
Message-ID: <87y7kpiu4q.fsf_-_@squeak.fifthhorseman.net>

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

On Wed 2007-04-18 03:17:31 -0400, Ludovic Court?s wrote:

> Rupert Kittinger-Sereinig <rks at mur.at> writes:
>
>> Ludovic Court?s schrieb:
>>>
>>> Rupert Kittinger-Sereinig <rks at mur.at> writes:
>
> [...]
>
>>>> I mean trusted in the sense of the pgp trustdb. Ideally, every user
>>>> should be able to configure how he wants to construct his web of trust.
>>>>
>>>> E.g. for a server application, the admin could choose a handfull of
>>>> "user managers" whose keys he would put in the keyring and assign
>>>> ultimte trust to each one.
>>>>
>>>> Another example: a user of web services could validate the server key
>>>> fingerprint, and locally sign them with his own key.
>>>
>>> Nitpick: As mentioned earlier in this thread, signing an OpenPGP public
>>> key means that "the signer is testifying to his or her belief that this
>>> public key belongs to the user identified by this user ID" [RFC 2440,
>>> Section 10.1].  I think this is not what you want here.
>>>
>>> Thanks,
>>> Ludovic.
>>>
>>
>> Why do you think so? If I verify that the key belongs to a person (e.g
>> by checking the fingerprint) I may well document that for later
>> reference by signing the key.
>
> Just because you know for sure that key XYZ belongs to Mr. Someone
> whom you've met at the pub the day before doesn't mean you grant him
> _authorization_ to use the service you provide.
>
> Instead, you need something that says "key XYZ is authorized to take
> such and such actions".  And this does not depend on whether key XYZ
> actually belongs to Mr. Someone.

Or rather, you need something that says "Mr. Someone is authorized to
take such and such actions, and i will use my existing web of trust to
establish whether this is indeed Mr. Someone."  Don't authorize the
key, authorize the *person*.

          --dkg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFGJjfKiXTlFKVLY2URAmVQAJ4+fwdkMQjLdq6ir8Yls/Ulz8YhawCeJXm8
wmMno9Oq7cnnuh88kxQ7GcQ=
=mSpL
-----END PGP SIGNATURE-----




From simon at josefsson.org  Wed Apr 18 22:05:46 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 18 Apr 2007 22:05:46 +0200
Subject: [Help-gnutls] Re: GnuTLS 1.6.2
In-Reply-To: <nnhcrdpt6j.fsf@sellafield.lysator.liu.se> ("Niels
	=?iso-8859-1?Q?M=F6ller=22's?=
	message of "Wed\, 18 Apr 2007 18\:02\:12 +0200")
References: <mailman.2225.1176911164.7795.info-gnu@gnu.org>
	<nnhcrdpt6j.fsf@sellafield.lysator.liu.se>
Message-ID: <87veftih2d.fsf@mocca.josefsson.org>

nisse at lysator.liu.se (Niels M?ller) writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>> ** Fix X.509 signing with RSA-PKCS#1 to set a NULL parameters fields.
>> Before, we remove the parameters field, which resulted in a slightly
>> different DER encoding which in turn caused signature verification
>> failures of GnuTLS-generated RSA certificates in some other
>> implementations (e.g., GnuPG 2.x's gpgsm).  Depending on which RFCs
>> you read, this may or may not be correct, but our new behaviour appear
>> to be consistent with other widely used implementations.
>
> Hmm, does that mean that you use equivalent signature generation as
> nettle? This is what I use (for md5; sha1 and sha256 are similar).
>
> nettle/pkcs1-rsa-md5:
>
>   /* From pkcs-1v2
>    *
>    *   md5 OBJECT IDENTIFIER ::=
>    *     {iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5}
>    *
>    * The parameters part of the algorithm identifier is NULL:
>    *
>    *   md5Identifier ::= AlgorithmIdentifier {md5, NULL}
>    */
>   
>   static const uint8_t
>   md5_prefix[] =
>   {
>     /* 18 octets prefix, 16 octets hash, 34 total. */
>     0x30,       32, /* SEQUENCE */
>       0x30,     12, /* SEQUENCE */
>         0x06,    8, /* OBJECT IDENTIFIER */
>     	0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x02, 0x05,
>         0x05,    0, /* NULL */
>       0x04,     16  /* OCTET STRING */
>         /* Here comes the raw hash value */
>   };

Yes.  In earlier versions, X.509 RSA signatures did not have the NULL
at all, but had an empty field.

Note that different code is used for RSA signing in TLS and RSA
signing in X.509 in GnuTLS.  The same problem came up in the TLS
context too for TLS v1.2 and there I added the following.  (TLS before
v1.2 doesn't use RSA PKCS#1.)

#if 1
      /* Use NULL parameters. */
      memcpy (concat,
	      "\x30\x21\x30\x09\x06\x05\x2b\x0e\x03\x02\x1a\x05\x00\x04\x14",
	      15);
      _gnutls_hash_deinit (td_sha, &concat[15]);
      dconcat.size = 35;
#else
      /* No parameters field. */
      memcpy (concat,
	      "\x30\x1f\x30\x07\x06\x05\x2b\x0e\x03\x02\x1a\x04\x14",
	      13);
      _gnutls_hash_deinit (td_sha, &concat[13]);
      dconcat.size = 33;
#endif

/Simon




From ludovic.courtes at laas.fr  Thu Apr 19 10:17:30 2007
From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 19 Apr 2007 10:17:30 +0200
Subject: [Help-gnutls] Re: OpenPGP certificate verification for
	TLS	connections
References: <87ejmtlfkj.fsf@chbouib.org> <87bqhvca3g.fsf@mocca.josefsson.org>
	<877isix5v7.fsf@squeak.fifthhorseman.net> <87zm5euadu.fsf@laas.fr>
	<87ejmqrcym.fsf@squeak.fifthhorseman.net>
	<87veg29d96.fsf@mocca.josefsson.org> <878xcxlrv8.fsf@laas.fr>
	<87bqht6aj3.fsf@mocca.josefsson.org>
	<87wt0h4o6t.fsf_-_@squeak.fifthhorseman.net> <46200DFE.3040009@mur.at>
	<87647wv84g.fsf@laas.fr> <4623DC58.60008@mur.at>
	<874pnffizw.fsf@laas.fr> <87y7kqeuf1.fsf@squeak.fifthhorseman.net>
	<87647u5e62.fsf@laas.fr> <873b2xk8vm.fsf@squeak.fifthhorseman.net>
Message-ID: <87vefsg4md.fsf@laas.fr>

Hi,

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

> On Wed 2007-04-18 03:34:29 -0400, Ludovic Court?s wrote:

[...]

>> That's probably a useful usage pattern.  The problem that I see is
>> that it would be non-standard, 
>
> I'm not convinced that using User IDs for authorization is
> non-standard.

[...]

> In short, the client *authenticates* with her certificate, and the
> server *authorizes* against her User ID.

Right, but that's X.509.  ;-)  By "non-standard", I meant that it is not
currently standardized, e.g., by RFC 2440.

> By analogy with OpenSSL (which contains significant infrastructure for
> managing X.509 certificate hierarchy trust), i would suggest that it
> is not outside the scope of GnuTLS to implement a well-thought-out
> scheme for trust checking when using OpenPGP certificates.

Sure, but the first step would probably to try and standardize this
practice through an RFC.

Thanks,
Ludovic.





From simon at josefsson.org  Thu Apr 19 11:11:54 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Apr 2007 11:11:54 +0200
Subject: [Help-gnutls] Re: GnuTLS 1.6.2
In-Reply-To: <nnd521pes7.fsf@sellafield.lysator.liu.se> ("Niels
	=?iso-8859-1?Q?M=F6ller=22's?=
	message of "Wed\, 18 Apr 2007 23\:13\:12 +0200")
References: <mailman.2225.1176911164.7795.info-gnu@gnu.org>
	<nnhcrdpt6j.fsf@sellafield.lysator.liu.se>
	<87veftih2d.fsf@mocca.josefsson.org>
	<nnd521pes7.fsf@sellafield.lysator.liu.se>
Message-ID: <87irbsiv8l.fsf@mocca.josefsson.org>

nisse at lysator.liu.se (Niels M?ller) writes:

>> Note that different code is used for RSA signing in TLS and RSA
>> signing in X.509 in GnuTLS.  The same problem came up in the TLS
>> context too for TLS v1.2 and there I added the following.  (TLS before
>> v1.2 doesn't use RSA PKCS#1.)
>
> That's strange... I haven't worked at all with TLS or SSL recently,
> but I just looked up the Pike/Roxen SSL-3 implementation which I
> wrote about ten years ago. It uses a NULL parameter. It interoperated
> fine with the Netscape browser at the time. It's later been upgraded
> to support TLS, and at least I haven't heard about any
> interoperability problems.
>
> The relevant file is
> http://pike.ida.liu.se/development/cvs/log.xml?file=7.7/lib/modules/Standards.pmod/PKCS.pmod/Signature.pmod&module=Pike,
> and there are actually no changes to the digestinfo formatting since I
> checked in revision 1.1, 1997-11-30.
>
>   //! @decl string build_digestinfo(string msg, Crypto.Hash hash)
>   //! Construct a PKCS-1 digestinfo
>   //! @param msg
>   //!   message to digest
>   //! @param hash
>   //!   crypto hash object such as @[Crypto.SHA] or @[Crypto.MD5]
>   string build_digestinfo(string msg, HASH hash)
>   {
>     if(!hash->asn1_id) error("Unknown ASN.1 id for hash.\n");
>     string d = hash->hash(msg);
>     string id = hash->asn1_id();
>   
>     return sprintf("%c%c%c%c%c%c%s%c%c%c%c%s",
>                    0x30, sizeof(id) + sizeof(d) + 8, 0x30, sizeof(id) + 4,
>                    0x06, sizeof(id), id, 0x05, 0x00, 0x04, sizeof(d), d);
>   } //                                   ^^^^^^^^^^
>
> Note the NULL object on the final line.
>
> I'm sure you have read the specifications much more recently than I,
> but as far as I remember, SSL and TLS have always used PKCS#1 style
> RSA signatures, so it really surprises me that you say some versions
> of TLS didn't specify that.

Are you sure that code is used for signing in the RSA key exchange
ciphersuites, and not X.509 signing?  The RSA key exchange
ciphersuites in TLS < 1.2 doesn't use RSA-PKCS#1 but sign a
concatenation of the MD5 + SHA1 hash instead, see RFC 4346:

   In RSA signing, a 36-byte structure of two hashes (one SHA and one
   MD5) is signed (encrypted with the private key).  It is encoded with
   PKCS #1 block type 1, as described in [PKCS1A].

Only the padding is according to PKCS#1.  In TLS 1.2, RSA signing is
done using one hash function only, and the hash OID is prepended
(actually the entire structure is the DigestInfo ASN.1 structure, just
like in your code, so it may hold parameters too).

Btw, I noticed that the lastest TLS 1.2 draft says:

   In RSA signing, the opaque vector contains the signature generated
   using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1B].  As
   discussed in [PKCS1B], the DigestInfo MUST be DER encoded and for
   digest algorithms without parameters (which include SHA-1) the
   DigestInfo.AlgorithmIdentifier.parameters field SHOULD be omitted but
   implementations MUST accept both without parameters and with NULL
   parameters. Note that earlier versions of TLS used a different RSA
   signature scheme which did not include a DigestInfo encoding.

Initially I did follow the SHOULD and omitted the NULL, but I had
interop problems with the only other TLS 1.2 implementation I'm aware
of, so I changed GnuTLS.  The old code is still available in a
#if-block, in case this changes again until the RFC is published.

> PS. Feel free to forward this message to some gnutls list if you find
> it appropriate; I'm not sending it to help-gnutls at gnu.org since my
> previous message was automatically rejected.

The list is subscriber-only, I believe, but I added you to the
whitelist now, in case it makes a difference.

/Simon




From nisse at lysator.liu.se  Thu Apr 19 13:35:47 2007
From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=)
Date: Thu, 19 Apr 2007 13:35:47 +0200
Subject: [Help-gnutls] Re: GnuTLS 1.6.2
In-Reply-To: <87irbsiv8l.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 19 Apr 2007 11:11:54 +0200")
References: <mailman.2225.1176911164.7795.info-gnu@gnu.org>
	<nnhcrdpt6j.fsf@sellafield.lysator.liu.se>
	<87veftih2d.fsf@mocca.josefsson.org>
	<nnd521pes7.fsf@sellafield.lysator.liu.se>
	<87irbsiv8l.fsf@mocca.josefsson.org>
Message-ID: <nny7kooauk.fsf@sellafield.lysator.liu.se>

Simon Josefsson <simon at josefsson.org> writes:

> Are you sure that code is used for signing in the RSA key exchange
> ciphersuites, and not X.509 signing?  The RSA key exchange
> ciphersuites in TLS < 1.2 doesn't use RSA-PKCS#1 but sign a
> concatenation of the MD5 + SHA1 hash instead, see RFC 4346:

Looking deeper, it seems you are absolutely right. The Pike/Roxen code
doesn't use the standard sign method in the RSA class fr SSL, but uses
a special hack which does precisely what you describe. What a mess.
Sorry for the confusion.

Good to here that it is being cleaned up, at least to some degree, in
TLS.

> Initially I did follow the SHOULD and omitted the NULL, but I had
> interop problems with the only other TLS 1.2 implementation I'm aware
> of, so I changed GnuTLS.  The old code is still available in a
> #if-block, in case this changes again until the RFC is published.

If you care about the ASN.1 level, using the NULL may seem somewhat
silly and redundant. I tend to think about it as just a magic string
associated with the hash function. Then exactly which string is used
doesn't matter. What *does* matter is that everybody uses the same
string.

I would strongly recommend that the TLS folks stick to the magic
strings specified in RFC 3447, section 9.2. I think that's what most
IETF protocols do. A quick search turns up, e.g., RFC 4051 (Proposed
Standard), which explicitly writes out the magic string for rsa-md5,
matching RFC 3447, and then says that for the other hash algorithms,
only the object identifier is changed.

Introducing new magic strings in the TLS spec makes absolutely no
sense to me.

(The signature code in nettle never tries to take the pkcs#1-padding
apart. For signature verification, it constructs one padded value (a
bignum) by doing the secret RSA operation on the given signature, and
a second padded value from the hash of the locally computed hash of
the document being verified (in all protocols I've seen, the hash
algorithm to use is known from context, you never have to examine the
signature value to figure it out), and then it compares the padded
values as s bignums. I think this way of implementing it is more
robust, but it depends on everybody using the same magic value).

Regards,
/Niels




From simon at josefsson.org  Thu Apr 19 14:22:29 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Apr 2007 14:22:29 +0200
Subject: [Help-gnutls] Re: GnuTLS 1.6.2
In-Reply-To: <nny7kooauk.fsf@sellafield.lysator.liu.se> ("Niels
	=?iso-8859-1?Q?M=F6ller=22's?=
	message of "Thu\, 19 Apr 2007 13\:35\:47 +0200")
References: <mailman.2225.1176911164.7795.info-gnu@gnu.org>
	<nnhcrdpt6j.fsf@sellafield.lysator.liu.se>
	<87veftih2d.fsf@mocca.josefsson.org>
	<nnd521pes7.fsf@sellafield.lysator.liu.se>
	<87irbsiv8l.fsf@mocca.josefsson.org>
	<nny7kooauk.fsf@sellafield.lysator.liu.se>
Message-ID: <871wigh7ui.fsf@mocca.josefsson.org>

nisse at lysator.liu.se (Niels M?ller) writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>> Are you sure that code is used for signing in the RSA key exchange
>> ciphersuites, and not X.509 signing?  The RSA key exchange
>> ciphersuites in TLS < 1.2 doesn't use RSA-PKCS#1 but sign a
>> concatenation of the MD5 + SHA1 hash instead, see RFC 4346:
>
> Looking deeper, it seems you are absolutely right. The Pike/Roxen code
> doesn't use the standard sign method in the RSA class fr SSL, but uses
> a special hack which does precisely what you describe. What a mess.
> Sorry for the confusion.
>
> Good to here that it is being cleaned up, at least to some degree, in
> TLS.

Yes, I agree.

>> Initially I did follow the SHOULD and omitted the NULL, but I had
>> interop problems with the only other TLS 1.2 implementation I'm aware
>> of, so I changed GnuTLS.  The old code is still available in a
>> #if-block, in case this changes again until the RFC is published.
>
> If you care about the ASN.1 level, using the NULL may seem somewhat
> silly and redundant. I tend to think about it as just a magic string
> associated with the hash function. Then exactly which string is used
> doesn't matter. What *does* matter is that everybody uses the same
> string.
>
> I would strongly recommend that the TLS folks stick to the magic
> strings specified in RFC 3447, section 9.2. I think that's what most
> IETF protocols do. A quick search turns up, e.g., RFC 4051 (Proposed
> Standard), which explicitly writes out the magic string for rsa-md5,
> matching RFC 3447, and then says that for the other hash algorithms,
> only the object identifier is changed.
>
> Introducing new magic strings in the TLS spec makes absolutely no
> sense to me.

I agree, although I think there is likely some other specifications
that says the parameters field should be omitted, rather than to have
a NULL value in it.  So it may be too late to make everyone use the
same magic string.  The best one can do is to use the same string as
most modern implementations do.  Here I think the current TLS 1.2
draft is probably wrong.

> (The signature code in nettle never tries to take the pkcs#1-padding
> apart. For signature verification, it constructs one padded value (a
> bignum) by doing the secret RSA operation on the given signature, and
> a second padded value from the hash of the locally computed hash of
> the document being verified (in all protocols I've seen, the hash
> algorithm to use is known from context, you never have to examine the
> signature value to figure it out), and then it compares the padded
> values as s bignums. I think this way of implementing it is more
> robust, but it depends on everybody using the same magic value).

Yes, agreed.  GnuTLS actually throws the decrypted blob at libtasn1,
but when libgcrypt supports PKCS#1 I think the code should be
replaced.  Alternatively, all signing requests could be sent to an
external process which can support other approaches too, such as
PKCS#11 smartcards etc.

/Simon




From ludo at chbouib.org  Mon Apr 23 23:56:47 2007
From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 23 Apr 2007 23:56:47 +0200
Subject: [Help-gnutls] [ANN] Guile-GnuTLS 0.0
Message-ID: <87647mu540.fsf@chbouib.org>

Hi,

I am pleased to announce the first release of Guile-GnuTLS, labeled
"0.0".  It is available from here:

  http://www.laas.fr/~lcourtes/software/guile/guile-gnutls-0.0.tar.gz

Documentation is accessible at:

  http://www.laas.fr/~lcourtes/software/guile/guile-gnutls.html

The SHA-1 sums of these files are:

  9ccbcdb18981790f4324479d76ab3661a656f16f  guile-gnutls-0.0.tar.gz
  5c9ef58b7ec2528550c637589af4215dd200051c  guile-gnutls.html

Guile-GnuTLS is a set of GNU Guile bindings for GnuTLS.  It allows
programmers to use GnuTLS facilities from Guile Scheme programs.
Despite the version number, a large subset of the GnuTLS API is already
covered, including OpenPGP-based authentication from GnuTLS-Extra.  The
only build-time and run-time requirements are Guile 1.8 and GnuTLS 1.4
or later.

Note that bindings of the core GnuTLS API are released under the LGPL
version 2.1 or later, while bindings of GnuTLS-Extra are released under
the GPL version 2 or later.

A test suite can be run using "make check".  If one of the
OpenPGP-related tests fails, it may be the case that you hit a GnuTLS
bug that is not fixed yet in the version you're using.

Please send comments, bug reports, feature requests, etc., to myself.

Thanks,
Ludovic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: </pipermail/attachments/20070423/1713ffd7/attachment.pgp>

From diptikalyan at gmail.com  Wed Apr 25 17:41:05 2007
From: diptikalyan at gmail.com (Diptikalyan Saha)
Date: Wed, 25 Apr 2007 11:41:05 -0400
Subject: [Help-gnutls] ex-client-srp and ex-serv-srp
Message-ID: <6d763010704250841u3401cabey9826c61c84afa23f@mail.gmail.com>

Hi,
      I am new to GnuTLS. I installed GnuTLS 1.7.8 on windows XP, and tried
to compile&run ex-client-srp.c and ex-serv-srp.c in examples directory and
got "handshake failed" error.

Heres what I did (using cygwin)


$srptool --create-conf tpasswd.conf
$srptool --passwd tpasswd --passwd-conf tpasswd.conf -u user
  password: pass
$srptool --passwd tpasswd --passwd-conf tpasswd.conf --verify -u user

$certtool --generate-privkey > x509-ca-key.pem
$echo 'cn = GnuTLS test CA' > ca.tmpl
$echo 'ca' >> ca.tmpl
$echo 'cert_signing_key' >> ca.tmpl
$certtool --generate-self-signed --load-privkey x509-ca-key.pem \
--template ca.tmpl --outfile x509-ca.pem
$certtool --generate-privkey > x509-server-key.pem
$echo 'organization = GnuTLS test server' > server.tmpl
$echo 'cn = test.gnutls.org' >> server.tmpl
$echo 'tls_www_server' >> server.tmpl
$echo 'encryption_key' >> server.tmpl
$echo 'signing_key' >> server.tmpl
$certtool --generate-certificate --load-privkey x509-server-key.pem \
--load-ca-certificate x509-ca.pem --load-ca-privkey x509-ca-key.pem \
--template server.tmpl --outfile x509-server.pem

Changed the three lines of code in ex-serv-srp.c
to
#define KEYFILE "x509-server-key.pem"
#define CERTFILE "x509-server.pem"
#define CAFILE "x509-ca.pem"

and
in ex-client-srp.c
#define CAFILE "x509-ca.pem"

The I compiled both the files and ran it and I got the following error:

$./srv.exe
cho Server ready. Listening to port '5556'.
 connection from 127.0.0.1, port 2076
** Handshake has failed (A TLS packet with unexpected length was received.)

$ ./cli.exe
*** Handshake failed

Please help me in this regard.



Thanks

Dipti.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20070425/7c9fe021/attachment.htm>

From diptikalyan at gmail.com  Thu Apr 26 15:53:29 2007
From: diptikalyan at gmail.com (Diptikalyan Saha)
Date: Thu, 26 Apr 2007 09:53:29 -0400
Subject: [Help-gnutls] Re: ex-client-srp and ex-serv-srp
In-Reply-To: <6d763010704250841u3401cabey9826c61c84afa23f@mail.gmail.com>
References: <6d763010704250841u3401cabey9826c61c84afa23f@mail.gmail.com>
Message-ID: <6d763010704260653mc7946c0w47ddcfbb7870ab63@mail.gmail.com>

Well I found a workaround to the problem. The same source when compiler with
Visual Studio works perfectly..I guess the problem of length comes due to
compilation in cygwin.

Thanks
Diptikalyan.


On 4/25/07, Diptikalyan Saha <diptikalyan at gmail.com> wrote:
>
> Hi,
>       I am new to GnuTLS. I installed GnuTLS 1.7.8 on windows XP, and
> tried to compile&run ex-client-srp.c and ex-serv-srp.c in examples
> directory and got "handshake failed" error.
>
> Heres what I did (using cygwin)
>
>
> $srptool --create-conf tpasswd.conf
> $srptool --passwd tpasswd --passwd-conf tpasswd.conf -u user
>   password: pass
> $srptool --passwd tpasswd --passwd-conf tpasswd.conf --verify -u user
>
> $certtool --generate-privkey > x509-ca-key.pem
> $echo 'cn = GnuTLS test CA' > ca.tmpl
> $echo 'ca' >> ca.tmpl
> $echo 'cert_signing_key' >> ca.tmpl
> $certtool --generate-self-signed --load-privkey x509-ca-key.pem \
> --template ca.tmpl --outfile x509-ca.pem
> $certtool --generate-privkey > x509-server-key.pem
> $echo 'organization = GnuTLS test server' > server.tmpl
> $echo 'cn = test.gnutls.org' >> server.tmpl
> $echo 'tls_www_server' >> server.tmpl
> $echo 'encryption_key' >> server.tmpl
> $echo 'signing_key' >> server.tmpl
> $certtool --generate-certificate --load-privkey x509-server-key.pem \
> --load-ca-certificate x509-ca.pem --load-ca-privkey x509-ca-key.pem \
> --template server.tmpl --outfile x509-server.pem
>
> Changed the three lines of code in ex-serv-srp.c
> to
> #define KEYFILE "x509-server-key.pem"
> #define CERTFILE "x509-server.pem"
> #define CAFILE "x509-ca.pem"
>
> and
> in ex-client-srp.c
> #define CAFILE "x509-ca.pem"
>
> The I compiled both the files and ran it and I got the following error:
>
> $./srv.exe
> cho Server ready. Listening to port '5556'.
>  connection from 127.0.0.1, port 2076
> ** Handshake has failed (A TLS packet with unexpected length was
> received.)
>
> $ ./cli.exe
> *** Handshake failed
>
> Please help me in this regard.
>
>
>
> Thanks
>
> Dipti.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20070426/c5f8e132/attachment.htm>

From simon at josefsson.org  Thu Apr 26 16:21:31 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 26 Apr 2007 16:21:31 +0200
Subject: [Help-gnutls] Re: ex-client-srp and ex-serv-srp
In-Reply-To: <6d763010704260653mc7946c0w47ddcfbb7870ab63@mail.gmail.com>
	(Diptikalyan Saha's message of "Thu\, 26 Apr 2007 09\:53\:29 -0400")
References: <6d763010704250841u3401cabey9826c61c84afa23f@mail.gmail.com>
	<6d763010704260653mc7946c0w47ddcfbb7870ab63@mail.gmail.com>
Message-ID: <874pn3w710.fsf@mocca.josefsson.org>

The error message is a bit sub-optimal, I think you'll get this error if
there a problem with the credentials (e.g., the file is in the wrong
directory, cannot be read, or bad format or similar).  The reasons for
why that happens is a long story, and probably the examples could be
improved here..

Btw, was it difficult to build the examples using VS?  Are you using the
official GnuTLS DLL, or did you build GnuTLS from source too?

/Simon

"Diptikalyan Saha" <diptikalyan at gmail.com> writes:

> Well I found a workaround to the problem. The same source when compiler with
> Visual Studio works perfectly..I guess the problem of length comes due to
> compilation in cygwin.
>
> Thanks
> Diptikalyan.
>
>
> On 4/25/07, Diptikalyan Saha <diptikalyan at gmail.com> wrote:
>>
>> Hi,
>>       I am new to GnuTLS. I installed GnuTLS 1.7.8 on windows XP, and
>> tried to compile&run ex-client-srp.c and ex-serv-srp.c in examples
>> directory and got "handshake failed" error.
>>
>> Heres what I did (using cygwin)
>>
>>
>> $srptool --create-conf tpasswd.conf
>> $srptool --passwd tpasswd --passwd-conf tpasswd.conf -u user
>>   password: pass
>> $srptool --passwd tpasswd --passwd-conf tpasswd.conf --verify -u user
>>
>> $certtool --generate-privkey > x509-ca-key.pem
>> $echo 'cn = GnuTLS test CA' > ca.tmpl
>> $echo 'ca' >> ca.tmpl
>> $echo 'cert_signing_key' >> ca.tmpl
>> $certtool --generate-self-signed --load-privkey x509-ca-key.pem \
>> --template ca.tmpl --outfile x509-ca.pem
>> $certtool --generate-privkey > x509-server-key.pem
>> $echo 'organization = GnuTLS test server' > server.tmpl
>> $echo 'cn = test.gnutls.org' >> server.tmpl
>> $echo 'tls_www_server' >> server.tmpl
>> $echo 'encryption_key' >> server.tmpl
>> $echo 'signing_key' >> server.tmpl
>> $certtool --generate-certificate --load-privkey x509-server-key.pem \
>> --load-ca-certificate x509-ca.pem --load-ca-privkey x509-ca-key.pem \
>> --template server.tmpl --outfile x509-server.pem
>>
>> Changed the three lines of code in ex-serv-srp.c
>> to
>> #define KEYFILE "x509-server-key.pem"
>> #define CERTFILE "x509-server.pem"
>> #define CAFILE "x509-ca.pem"
>>
>> and
>> in ex-client-srp.c
>> #define CAFILE "x509-ca.pem"
>>
>> The I compiled both the files and ran it and I got the following error:
>>
>> $./srv.exe
>> cho Server ready. Listening to port '5556'.
>>  connection from 127.0.0.1, port 2076
>> ** Handshake has failed (A TLS packet with unexpected length was
>> received.)
>>
>> $ ./cli.exe
>> *** Handshake failed
>>
>> Please help me in this regard.
>>
>>
>>
>> Thanks
>>
>> Dipti.
>>
>>
>>
> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnutls




From simon at josefsson.org  Thu Apr 26 16:47:13 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 26 Apr 2007 16:47:13 +0200
Subject: [Help-gnutls] Re: ex-client-srp and ex-serv-srp
In-Reply-To: <6d763010704260737w57e0a389s17a93eb60f00dbfe@mail.gmail.com>
	(Diptikalyan Saha's message of "Thu\, 26 Apr 2007 10\:37\:50 -0400")
References: <6d763010704250841u3401cabey9826c61c84afa23f@mail.gmail.com>
	<6d763010704260653mc7946c0w47ddcfbb7870ab63@mail.gmail.com>
	<874pn3w710.fsf@mocca.josefsson.org>
	<6d763010704260737w57e0a389s17a93eb60f00dbfe@mail.gmail.com>
Message-ID: <87r6q7ur9q.fsf@mocca.josefsson.org>

"Diptikalyan Saha" <diptikalyan at gmail.com> writes:

> I used the official GnuTLS dlls in the GnuTLS/bin directory. Not much
> difficulty in building with Visual Studio..I have to include some ifdef
> _WIN32 tag to include winsock.h instead of sys/ arpa/ header files...and
> changed tcp.c to do include windows socket programming stuff.

Thanks for the information.

> There is abolute no change in the credential files. I compiled using
> cl.exeand it worked.  May be the two executables (made by gcc and vs)
> read the
> credential files in different fashion maybe - i donno.

It is possible that CR/LF issues may be that cause of problems like
this.

/Simon

> Thanks
> Dipti.
>
>
>
> On 4/26/07, Simon Josefsson <simon at josefsson.org> wrote:
>
>> The error message is a bit sub-optimal, I think you'll get this error if
>> there a problem with the credentials (e.g., the file is in the wrong
>> directory, cannot be read, or bad format or similar).  The reasons for
>> why that happens is a long story, and probably the examples could be
>> improved here..
>>
>> Btw, was it difficult to build the examples using VS?  Are you using the
>> official GnuTLS DLL, or did you build GnuTLS from source too?
>>
>> /Simon
>>
>> "Diptikalyan Saha" <diptikalyan at gmail.com> writes:
>>
>> > Well I found a workaround to the problem. The same source when compiler
>> with
>> > Visual Studio works perfectly..I guess the problem of length comes due
>> to
>> > compilation in cygwin.
>> >
>> > Thanks
>> > Diptikalyan.
>> >
>> >
>> > On 4/25/07, Diptikalyan Saha <diptikalyan at gmail.com> wrote:
>> >>
>> >> Hi,
>> >>       I am new to GnuTLS. I installed GnuTLS 1.7.8 on windows XP, and
>> >> tried to compile&run ex-client-srp.c and ex-serv-srp.c in examples
>> >> directory and got "handshake failed" error.
>> >>
>> >> Heres what I did (using cygwin)
>> >>
>> >>
>> >> $srptool --create-conf tpasswd.conf
>> >> $srptool --passwd tpasswd --passwd-conf tpasswd.conf -u user
>> >>   password: pass
>> >> $srptool --passwd tpasswd --passwd-conf tpasswd.conf --verify -u user
>> >>
>> >> $certtool --generate-privkey > x509-ca-key.pem
>> >> $echo 'cn = GnuTLS test CA' > ca.tmpl
>> >> $echo 'ca' >> ca.tmpl
>> >> $echo 'cert_signing_key' >> ca.tmpl
>> >> $certtool --generate-self-signed --load-privkey x509-ca-key.pem \
>> >> --template ca.tmpl --outfile x509-ca.pem
>> >> $certtool --generate-privkey > x509-server-key.pem
>> >> $echo 'organization = GnuTLS test server' > server.tmpl
>> >> $echo 'cn = test.gnutls.org' >> server.tmpl
>> >> $echo 'tls_www_server' >> server.tmpl
>> >> $echo 'encryption_key' >> server.tmpl
>> >> $echo 'signing_key' >> server.tmpl
>> >> $certtool --generate-certificate --load-privkey x509-server-key.pem \
>> >> --load-ca-certificate x509-ca.pem --load-ca-privkey x509-ca-key.pem \
>> >> --template server.tmpl --outfile x509-server.pem
>> >>
>> >> Changed the three lines of code in ex-serv-srp.c
>> >> to
>> >> #define KEYFILE "x509-server-key.pem"
>> >> #define CERTFILE "x509-server.pem"
>> >> #define CAFILE "x509-ca.pem"
>> >>
>> >> and
>> >> in ex-client-srp.c
>> >> #define CAFILE "x509-ca.pem"
>> >>
>> >> The I compiled both the files and ran it and I got the following error:
>> >>
>> >> $./srv.exe
>> >> cho Server ready. Listening to port '5556'.
>> >>  connection from 127.0.0.1, port 2076
>> >> ** Handshake has failed (A TLS packet with unexpected length was
>> >> received.)
>> >>
>> >> $ ./cli.exe
>> >> *** Handshake failed
>> >>
>> >> Please help me in this regard.
>> >>
>> >>
>> >>
>> >> Thanks
>> >>
>> >> Dipti.
>> >>
>> >>
>> >>
>> > _______________________________________________
>> > Help-gnutls mailing list
>> > Help-gnutls at gnu.org
>> > http://lists.gnu.org/mailman/listinfo/help-gnutls
>>