From simon at josefsson.org  Tue Jul  1 00:23:56 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 01 Jul 2008 00:23:56 +0200
Subject: guile self-tests fail in v.2.5?
Message-ID: <87d4lyimtf.fsf@mocca.josefsson.org>

Hi Ludovic,

On the master trunk there has been some heavy internal changes recently,
but no incompatible API changes as far as I understand, and now the
guile self-tests fails:

make[3]: Entering directory `/home/jas/src/gnutls/guile/tests'
guile: uncaught throw to gnutls-error: (#<gnutls-error-enum The Diffie Hellman prime sent by the server is not acceptable (not long enough).> handshake)
make[3]: *** [check-TESTS] Interrupt

Actually I need to ctrl-c it to cancel it.

Do you have any idea?  How would I debug this, anyway?  I am a bit at a
loss when running into any guile problem.

Thanks,
/Simon




From ludo at gnu.org  Wed Jul  2 16:34:55 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 02 Jul 2008 16:34:55 +0200
Subject: guile self-tests fail in v.2.5?
References: <87d4lyimtf.fsf@mocca.josefsson.org>
Message-ID: <87r6acqrqo.fsf@gnu.org>

Hi Simon,

Please find attached a patch that fixes compilation on `master' (I
prefer to let you review it and apply it).

Simon Josefsson <simon at josefsson.org> writes:

> On the master trunk there has been some heavy internal changes recently,
> but no incompatible API changes as far as I understand, and now the
> guile self-tests fails:
>
> make[3]: Entering directory `/home/jas/src/gnutls/guile/tests'
> guile: uncaught throw to gnutls-error: (#<gnutls-error-enum The Diffie Hellman prime sent by the server is not acceptable (not long enough).> handshake)
> make[3]: *** [check-TESTS] Interrupt

This is `anonymous-auth.scm': `gnutls_handshake ()' returns
`GNUTLS_E_DH_PRIME_UNACCEPTABLE' (whose error message is displayed
above).

Adding debugging output (which involves uncommenting the
`set-log-level!' and `set-log-procedure!' calls at the top of the file)
shows that the error is returned past `auth_dh_common.c:289'.

I tried changing the size of the DH prime used on the server-side (the
parameter to `make-dh-parameters'), as well as the minimum acceptable DH
size on the client side (the `set-session-dh-prime-bits!' parameter)
with no success.

I vaguely remember seeing a change regarding the default DH prime size,
but I couldn't find it.  Any hint?  Which commit initially triggered the
failure?

Thanks in advance,
Ludovic.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-compilation-of-OpenCDK-with-included-minitasn1.patch
Type: text/x-patch
Size: 1093 bytes
Desc: The patch
URL: </pipermail/attachments/20080702/7be17650/attachment.bin>

From simon at josefsson.org  Wed Jul  2 17:52:08 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 02 Jul 2008 17:52:08 +0200
Subject: GnuTLS 2.5.0
Message-ID: <877ic4wafr.fsf@mocca.josefsson.org>

The GnuTLS 2.5.x branch is NOT what you want for your stable system.  It
is intended for developers and experienced users.

This release contains a merge of Nikos' gnutls_with_mpi branch.  It
should now be possible to replace the libgcrypt calls to your own
callbacks.  A lot of low-level code has changed since 2.4.x, so expect
this to be unstable.

I intend to release 2.5.1 shortly after this release, to indent all code
to conform to the GNU Coding Standards.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.0.tar.bz2
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.0.tar.bz2

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

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

/Simon

* Version 2.5.0 (released 2008-07-02)

** Port fixes from v2.4.1 release, see below.

** Added API to replace and update the crypto backend.
The header gnutls/crypto.h is now officially supported, and declares
the symbols below.

** Rewritten opencdk crypto backend, to use the gnutls internal one.

** Update gnulib and translations.
The gnulib gc crypto code has been removed since it was never finished
and is no longer even used.  An internal non-libgcrypt crypto
implementation may be added in the future, but we'll decide that later
on.

** API and ABI modifications:
gnutls_crypto_bigint_register2: ADDED.
gnutls_crypto_cipher_register2: ADDED.
gnutls_crypto_digest_register2: ADDED.
gnutls_crypto_mac_register2: ADDED.
gnutls_crypto_pk_register2: ADDED.
gnutls_crypto_rnd_register2: ADDED.
gnutls_crypto_single_cipher_register2: ADDED.
gnutls_crypto_single_digest_register2: ADDED.
gnutls_crypto_single_mac_register2: ADDED.




From simon at josefsson.org  Wed Jul  2 17:53:27 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 02 Jul 2008 17:53:27 +0200
Subject: GnuTLS 2.5.1
Message-ID: <87zlp0uvt4.fsf@mocca.josefsson.org>

The GnuTLS 2.5.x branch is NOT what you want for your stable system.  It
is intended for developers and experienced users.

This release should contain no changes other than the result of 'make
indent' compared to v2.5.0.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.1.tar.bz2
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.1.tar.bz2

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

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

/Simon

* Version 2.5.1 (released 2008-07-02)

** Indent code.

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




From simon at josefsson.org  Wed Jul  2 17:57:43 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 02 Jul 2008 17:57:43 +0200
Subject: guile self-tests fail in v.2.5?
In-Reply-To: <87r6acqrqo.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Wed, 02
	Jul 2008 16:34:55 +0200")
References: <87d4lyimtf.fsf@mocca.josefsson.org> <87r6acqrqo.fsf@gnu.org>
Message-ID: <87skusuvm0.fsf@mocca.josefsson.org>

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

> Hi Simon,
>
> Please find attached a patch that fixes compilation on `master' (I
> prefer to let you review it and apply it).

Hi Ludovic!  May I ask why you added the lib/minitasn1 include?  OpenCDK
doesn't need libtasn1.  Otherwise it looks fine to me.

/Simon

> From 2ec3592cef768e1de579399d3f9bd725c7dabae7 Mon Sep 17 00:00:00 2001
> From: =?utf-8?q?Ludovic=20Court=C3=A8s?= <ludo at gnu.org>
> Date: Wed, 2 Jul 2008 16:18:41 +0200
> Subject: [PATCH] Fix compilation of OpenCDK with included minitasn1.
>
> * lib/opencdk/Makefile.am (INCLUDES): Rename to `AM_CPPFLAGS'.
>   (AM_CPPFLAGS)[ENABLE_MINITASN1]: Add `lib/miniitasn1'.
> ---
>  lib/opencdk/Makefile.am |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/lib/opencdk/Makefile.am b/lib/opencdk/Makefile.am
> index 4dcfeaf..aed03f6 100644
> --- a/lib/opencdk/Makefile.am
> +++ b/lib/opencdk/Makefile.am
> @@ -20,10 +20,14 @@
>  # Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
>  # MA 02110-1301, USA
>  
> -INCLUDES = -I$(top_srcdir)/lib \
> +AM_CPPFLAGS = -I$(top_srcdir)/lib \
>  	-I$(top_srcdir)/includes -I$(top_builddir)/includes \
>  	-I$(top_srcdir)/lgl -I$(top_builddir)/lgl
>  
> +if ENABLE_MINITASN1
> +AM_CPPFLAGS += -I$(top_srcdir)/lib/minitasn1
> +endif
> +
>  noinst_LTLIBRARIES = libminiopencdk.la
>  
>  libminiopencdk_la_SOURCES = armor.c filters.h keydb.h main.c types.h	\
> -- 
> 1.5.6.1
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel




From simon at josefsson.org  Wed Jul  2 18:16:27 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 02 Jul 2008 18:16:27 +0200
Subject: guile self-tests fail in v.2.5?
In-Reply-To: <87r6acqrqo.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Wed, 02
	Jul 2008 16:34:55 +0200")
References: <87d4lyimtf.fsf@mocca.josefsson.org> <87r6acqrqo.fsf@gnu.org>
Message-ID: <87lk0kuuqs.fsf@mocca.josefsson.org>

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

> Simon Josefsson <simon at josefsson.org> writes:
>
>> On the master trunk there has been some heavy internal changes recently,
>> but no incompatible API changes as far as I understand, and now the
>> guile self-tests fails:
>>
>> make[3]: Entering directory `/home/jas/src/gnutls/guile/tests'
>> guile: uncaught throw to gnutls-error: (#<gnutls-error-enum The Diffie Hellman prime sent by the server is not acceptable (not long enough).> handshake)
>> make[3]: *** [check-TESTS] Interrupt
>
> This is `anonymous-auth.scm': `gnutls_handshake ()' returns
> `GNUTLS_E_DH_PRIME_UNACCEPTABLE' (whose error message is displayed
> above).
>
> Adding debugging output (which involves uncommenting the
> `set-log-level!' and `set-log-procedure!' calls at the top of the file)
> shows that the error is returned past `auth_dh_common.c:289'.

Thanks, that allowed me to track down the problem.  It was a silly typo
in the dh generation code:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=bc11d56f6461ff0a2afcae7f864bed54a7b337c1

Just getting the gnutls debug log is often sufficient to solve problems
like this.  I know how to do that for the guile code now...

Thanks,
Simon




From simon at josefsson.org  Wed Jul  2 18:42:53 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 02 Jul 2008 18:42:53 +0200
Subject: guile self-tests fail in v.2.5?
In-Reply-To: <87lk0kuuqs.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 02 Jul 2008 18:16:27 +0200")
References: <87d4lyimtf.fsf@mocca.josefsson.org> <87r6acqrqo.fsf@gnu.org>
	<87lk0kuuqs.fsf@mocca.josefsson.org>
Message-ID: <878wwkutiq.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> ludo at gnu.org (Ludovic Court?s) writes:
>
>> Simon Josefsson <simon at josefsson.org> writes:
>>
>>> On the master trunk there has been some heavy internal changes recently,
>>> but no incompatible API changes as far as I understand, and now the
>>> guile self-tests fails:
>>>
>>> make[3]: Entering directory `/home/jas/src/gnutls/guile/tests'
>>> guile: uncaught throw to gnutls-error: (#<gnutls-error-enum The Diffie Hellman prime sent by the server is not acceptable (not long enough).> handshake)
>>> make[3]: *** [check-TESTS] Interrupt
>>
>> This is `anonymous-auth.scm': `gnutls_handshake ()' returns
>> `GNUTLS_E_DH_PRIME_UNACCEPTABLE' (whose error message is displayed
>> above).
>>
>> Adding debugging output (which involves uncommenting the
>> `set-log-level!' and `set-log-procedure!' calls at the top of the file)
>> shows that the error is returned past `auth_dh_common.c:289'.
>
> Thanks, that allowed me to track down the problem.  It was a silly typo
> in the dh generation code:
>
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=bc11d56f6461ff0a2afcae7f864bed54a7b337c1

Eh, I meant of course:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=b32735e1e275c4a2dbf544c04cdf344181fea555

/Simon

> Just getting the gnutls debug log is often sufficient to solve problems
> like this.  I know how to do that for the guile code now...
>
> Thanks,
> Simon




From ludo at gnu.org  Wed Jul  2 19:29:08 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 02 Jul 2008 19:29:08 +0200
Subject: guile self-tests fail in v.2.5?
References: <87d4lyimtf.fsf@mocca.josefsson.org> <87r6acqrqo.fsf@gnu.org>
	<87skusuvm0.fsf@mocca.josefsson.org>
Message-ID: <87abh0yz2z.fsf@gnu.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Hi Ludovic!  May I ask why you added the lib/minitasn1 include?  OpenCDK
> doesn't need libtasn1.  Otherwise it looks fine to me.

Hmm, it appeared to be needed back then (some C file didn't find
<libtasn1.h>), but now that I've reverted the patch, I can no longer
reproduce the problem.  So maybe this can be ignored...

Thanks,
Ludovic.





From ludo at gnu.org  Wed Jul  2 19:32:38 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 02 Jul 2008 19:32:38 +0200
Subject: guile self-tests fail in v.2.5?
References: <87d4lyimtf.fsf@mocca.josefsson.org> <87r6acqrqo.fsf@gnu.org>
	<87lk0kuuqs.fsf@mocca.josefsson.org>
Message-ID: <87r6acxkcp.fsf@gnu.org>

Hi Simon,

Simon Josefsson <simon at josefsson.org> writes:

> Thanks, that allowed me to track down the problem.  It was a silly typo
> in the dh generation code:

Good news!

Maybe that's an indication that either you should always run the Guile
tests, or the test should be duplicated in C.  ;-)

Thanks,
Ludovic.





From simon at josefsson.org  Wed Jul  2 20:02:01 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 02 Jul 2008 20:02:01 +0200
Subject: guile self-tests fail in v.2.5?
In-Reply-To: <87r6acxkcp.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Wed, 02
	Jul 2008 19:32:38 +0200")
References: <87d4lyimtf.fsf@mocca.josefsson.org> <87r6acqrqo.fsf@gnu.org>
	<87lk0kuuqs.fsf@mocca.josefsson.org> <87r6acxkcp.fsf@gnu.org>
Message-ID: <87y74ki2qu.fsf@mocca.josefsson.org>

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

> Hi Simon,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Thanks, that allowed me to track down the problem.  It was a silly typo
>> in the dh generation code:
>
> Good news!
>
> Maybe that's an indication that either you should always run the Guile
> tests, or the test should be duplicated in C.  ;-)

I had the exact same thought. :)  I prefer to always run the Guile tests,
and that is simpler than duplicating it in C.

Generating DH pair uses libgcrypt's RNG code, which may be quite slow on
some machines, so it shouldn't be used too much in the self tests.
Avoiding duplicating it in C helps here.

/Simon




From simon at josefsson.org  Wed Jul  2 20:03:45 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 02 Jul 2008 20:03:45 +0200
Subject: guile self-tests fail in v.2.5?
In-Reply-To: <87abh0yz2z.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Wed, 02
	Jul 2008 19:29:08 +0200")
References: <87d4lyimtf.fsf@mocca.josefsson.org> <87r6acqrqo.fsf@gnu.org>
	<87skusuvm0.fsf@mocca.josefsson.org> <87abh0yz2z.fsf@gnu.org>
Message-ID: <87tzf8i2ny.fsf@mocca.josefsson.org>

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

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Hi Ludovic!  May I ask why you added the lib/minitasn1 include?  OpenCDK
>> doesn't need libtasn1.  Otherwise it looks fine to me.
>
> Hmm, it appeared to be needed back then (some C file didn't find
> <libtasn1.h>), but now that I've reverted the patch, I can no longer
> reproduce the problem.  So maybe this can be ignored...

Hi.  I applied the first part of your patch, that still looked like the
right thing.

Thanks,
/Simon




From colin at colino.net  Fri Jul  4 14:07:11 2008
From: colin at colino.net (Colin Leroy)
Date: Fri, 4 Jul 2008 14:07:11 +0200
Subject: [PATCH] Little leak fix
Message-ID: <20080704140711.5c0c7fcf@paperstreet.colino.net>

Hello,

I've found out this via valgrind:

==5806== 7,698 (504 direct, 7,194 indirect) bytes in 9 blocks are 
         definitely lost in loss record 175 of 248
==5806==    at 0x4C220BC: calloc (vg_replace_malloc.c:397)
==5806==    by 0xED2FE11: _asn1_add_node_only (structure.c:54)
==5806==    by 0xED2FFF2: _asn1_copy_structure3 (structure.c:398)
==5806==    by 0xED3038D: asn1_create_element (structure.c:690)
==5806==    by 0x9733F7A: _gnutls_x509_decode_octet_string (common.c:832)
==5806==    by 0x9734243: _gnutls_x509_read_value (common.c:912)
==5806==    by 0x974756E: _decode_pkcs12_auth_safe (pkcs12.c:76)
==5806==    by 0x9748A67: gnutls_pkcs12_get_bag (pkcs12.c:598)

Attached is a patch which fixes it.

HTH,
-- 
Colin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lib_x509_common_leak.patch
Type: text/x-patch
Size: 284 bytes
Desc: not available
URL: </pipermail/attachments/20080704/4f88146d/attachment.bin>

From nmav at gnutls.org  Sat Jul  5 09:55:43 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 05 Jul 2008 10:55:43 +0300
Subject: [PATCH] Little leak fix
In-Reply-To: <20080704140711.5c0c7fcf@paperstreet.colino.net>
References: <20080704140711.5c0c7fcf@paperstreet.colino.net>
Message-ID: <486F28FF.8070506@gnutls.org>

Colin Leroy wrote:
> Hello,
> 
> I've found out this via valgrind:
> 
> ==5806== 7,698 (504 direct, 7,194 indirect) bytes in 9 blocks are 
>          definitely lost in loss record 175 of 248
> ==5806==    at 0x4C220BC: calloc (vg_replace_malloc.c:397)
> ==5806==    by 0xED2FE11: _asn1_add_node_only (structure.c:54)
> ==5806==    by 0xED2FFF2: _asn1_copy_structure3 (structure.c:398)
> ==5806==    by 0xED3038D: asn1_create_element (structure.c:690)
> ==5806==    by 0x9733F7A: _gnutls_x509_decode_octet_string (common.c:832)
> ==5806==    by 0x9734243: _gnutls_x509_read_value (common.c:912)
> ==5806==    by 0x974756E: _decode_pkcs12_auth_safe (pkcs12.c:76)
> ==5806==    by 0x9748A67: gnutls_pkcs12_get_bag (pkcs12.c:598)
> 
> Attached is a patch which fixes it.

Thank you for the patch. It was applied (slightly modified)!


regards,
Nikos




From nmav at gnutls.org  Sat Jul  5 10:21:56 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 05 Jul 2008 11:21:56 +0300
Subject: some opencdk history (was: lib/opencdk/read-packet.c: read_s2k()
 implementation)
In-Reply-To: <87skuzo28j.fsf@squeak.fifthhorseman.net>
References: <87skuzo28j.fsf@squeak.fifthhorseman.net>
Message-ID: <486F2F24.4010608@gnutls.org>

Daniel Kahn Gillmor wrote:
> After wrapping my head around the relevant section of RFC 4880 and
> bits of opencdk, i've fleshed out the previously unimplemented opencdk
> internal function intended to interpret OpenPGP String-To-Key
> transformations, read_s2k() in read-packet.c.
> 
> Attached, please find the patch for this function.  Inspection with a
> debugger shows that the values being stored are congruent with what is
> expected in other uses of the cdk_s2k_t construct.
> 
> After my first draft of this patch, i noticed that similar code
> already existed in the read_symkey_enc() function (also in
> lib/opencdk/read-packet.c).  So instead of publishing my first draft,
> i've collapsed the code for these two so that there's a canonical
> implementation of reading s2k values present in the opencdk codebase.
> The attached patch reflects this approach.
> 
> This change should not affect the API or ABI at all, and it allows
> GnuTLS to recognize encrypted secret keys (though it cannot yet use
> them, afaict).

Hello Daniel,

 I've finally found some time to check your patch and I have some
remarks. The first is about patches in opencdk. The opencdk library
included in gnutls is a crippled version of the "full" opencdk library
by Timo Schulz. This crippling was done for mainly two reasons. The full
opencdk library contained GPL code that forced us to include the openpgp
support only in libextra, and the second is that we only wanted to
include the parts of opencdk we used.

Thus if you or anyone wants to add anything to gnutls' opencdk it might
be appropriate to check the older opencdk library if it contains the
code and is under LGPL. This still will require some porting (since now
the included opencdk uses gnutls' internal api) but that wouldn't be
that difficult.

About the specific patch, it is quite useful, but since it does not
affect the gnutls' API or add anything to it, I'll keep from applying it
until it is complete.

regards,
Nikos


[0]. http://www.gnu.org/software/gnutls/releases/opencdk/
     http://savannah.nongnu.org/projects/opencdk




From simon at josefsson.org  Tue Jul  8 17:44:08 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 08 Jul 2008 17:44:08 +0200
Subject: GnuTLS 2.5.2
Message-ID: <87ej648jp3.fsf@mocca.josefsson.org>

The GnuTLS 2.5.x branch is NOT what you want for your stable system.  It
is intended for developers and experienced users.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.2.tar.bz2
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.2.tar.bz2

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

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

/Simon

* Version 2.5.2 (released 2008-07-08)

** libgnutls: Fix bug in gnutls_dh_params_generate2.
The prime and generator was swapped.

** libgnutls: New interface to register a new TLS extension handler.
The new function gnutls_ext_register can be used to register handlers
for specific TLS extension types.  The callback functions have the new
types gnutls_ext_recv_func and gnutls_ext_send_func.  A type to
classify TLS extensions, gnutls_ext_parse_type_t, has been added as
well.

** Move more code for TLS/IA extension from libgnutls to libgnutls-extra.
This was made possible by using the new gnutls_ext_register interface.
The TLS/IA functionality has only been supported through the
libgnutls-extra library, so it makes sense for the code to belong
there too.

** API and ABI modifications:
gnutls_ext_recv_func: ADDED
gnutls_ext_send_func: ADDED
gnutls_ext_parse_type_t: ADDED
gnutls_ext_register: ADDED
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20080708/92c85d41/attachment.pgp>

From dkg-debian.org at fifthhorseman.net  Tue Jul  8 17:52:27 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 08 Jul 2008 11:52:27 -0400
Subject: some opencdk history
In-Reply-To: <486F2F24.4010608@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sat\, 05 Jul 2008 11\:21\:56 +0300")
References: <87skuzo28j.fsf@squeak.fifthhorseman.net>
	<486F2F24.4010608@gnutls.org>
Message-ID: <877ibwidac.fsf@squeak.fifthhorseman.net>

On Sat 2008-07-05 01:21:56 -0700, Nikos Mavrogiannopoulos wrote:

>  I've finally found some time to check your patch and I have some
> remarks. The first is about patches in opencdk. The opencdk library
> included in gnutls is a crippled version of the "full" opencdk
> library by Timo Schulz. This crippling was done for mainly two
> reasons. The full opencdk library contained GPL code that forced us
> to include the openpgp support only in libextra, and the second is
> that we only wanted to include the parts of opencdk we used.

Cool, thanks for the explanation, Nikos.  Are you saying that the
OpenPGP pieces of GnuTLS themselves are now *not* in libextra, then?
That they currently fall under the LGPL instead?  I know that there
has been a lot of changes recently, but i haven't followed them
closely enough to know here.

Was it necessary to remove the pieces that were removed *because* they
were only under the GPL, not the LGPL?  

Was there a copyright assignment over the OpenCDK sources to the FSF?
If so, is the FSF willing to consider re-licensing the code under LGPL
so that we can include all the functionality instead of just part of
it?

> Thus if you or anyone wants to add anything to gnutls' opencdk it
> might be appropriate to check the older opencdk library if it
> contains the code and is under LGPL. This still will require some
> porting (since now the included opencdk uses gnutls' internal api)
> but that wouldn't be that difficult.

I think you're suggesting to check the source of the older opencdk if
anything seems like it is missing from the stripped-down version.
Thanks for the pointer; i'll certainly do that.

> About the specific patch, it is quite useful, but since it does not
> affect the gnutls' API or add anything to it, I'll keep from
> applying it until it is complete.

Actually, the patch as it stands does add something to the
capabilities of libgnutls: consider the case where you have a
passphrase-encrypted OpenPGP secret key.  Without the patch, GnuTLS
will actually choke on the key itself and be unable to even create a
gnutls_openpgp_privkey_t from the data (encountering the S2K chunk in
the protected key caused a CDK_Not_Implemented).

With the patch, GnuTLS can create a gnutls_openpgp_privkey_t from such
a key.  It won't be able to manipulate the key cleanly for any purpose
that requires access to the secret MPIs themselves because they are
locked, but GnuTLS will still be able to do all of the pubkey
functions with that key.  For example, It should still be possible to
get the fingerprint of the key without knowing the secret MPIs.

I consider this to be a useful step (and a bugfix worth pushing into
the 2.4.x lines in its own right).  I'm also working on trying to take
the patches one level further, as you suggest, but i think that
proposed change stands alone.

    --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080708/121fa383/attachment.pgp>

From nmav at gnutls.org  Wed Jul  9 18:48:58 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 09 Jul 2008 19:48:58 +0300
Subject: some opencdk history
In-Reply-To: <877ibwidac.fsf@squeak.fifthhorseman.net>
References: <87skuzo28j.fsf@squeak.fifthhorseman.net>	<486F2F24.4010608@gnutls.org>
	<877ibwidac.fsf@squeak.fifthhorseman.net>
Message-ID: <4874EBFA.2030208@gnutls.org>

Daniel Kahn Gillmor wrote:
> On Sat 2008-07-05 01:21:56 -0700, Nikos Mavrogiannopoulos wrote:
> 
>>  I've finally found some time to check your patch and I have some
>> remarks. The first is about patches in opencdk. The opencdk library
>> included in gnutls is a crippled version of the "full" opencdk
>> library by Timo Schulz. This crippling was done for mainly two
>> reasons. The full opencdk library contained GPL code that forced us
>> to include the openpgp support only in libextra, and the second is
>> that we only wanted to include the parts of opencdk we used.
> Cool, thanks for the explanation, Nikos.  Are you saying that the
> OpenPGP pieces of GnuTLS themselves are now *not* in libextra, then?
> That they currently fall under the LGPL instead?  I know that there
> has been a lot of changes recently, but i haven't followed them
> closely enough to know here.
> Was it necessary to remove the pieces that were removed *because* they
> were only under the GPL, not the LGPL?  

This wasn't the only reason. Of course the GPL parts had to be removed,
but there were also some other parts under LGPL that we didn't use at
that time in gnutls and/or required some rewritting, so they were also
dropped.

> Was there a copyright assignment over the OpenCDK sources to the FSF?
> If so, is the FSF willing to consider re-licensing the code under LGPL
> so that we can include all the functionality instead of just part of
> it?

Yes the FSF has relicensed all the parts of opencdk that we needed for
proper openpgp certificate support in gnutls. Those are the parts that
are now included.

> Actually, the patch as it stands does add something to the
> capabilities of libgnutls: consider the case where you have a
> passphrase-encrypted OpenPGP secret key.  Without the patch, GnuTLS
> will actually choke on the key itself and be unable to even create a
> gnutls_openpgp_privkey_t from the data (encountering the S2K chunk in
> the protected key caused a CDK_Not_Implemented).
> With the patch, GnuTLS can create a gnutls_openpgp_privkey_t from such
> a key.  It won't be able to manipulate the key cleanly for any purpose
> that requires access to the secret MPIs themselves because they are
> locked, but GnuTLS will still be able to do all of the pubkey

Ah ok... But still in the master git branch some things are required to
be added for this patch to work (I remember something that had to do
with symmetric encryption was missing). Would you like to add this part
as well?

> I consider this to be a useful step (and a bugfix worth pushing into
> the 2.4.x lines in its own right).  I'm also working on trying to take
> the patches one level further, as you suggest, but i think that
> proposed change stands alone.

Ok. I'll include this patch in 2.4.x as well.

regards,
Nikos




From nmav at gnutls.org  Wed Jul  9 18:49:59 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 09 Jul 2008 19:49:59 +0300
Subject: some opencdk history
In-Reply-To: <877ibwidac.fsf@squeak.fifthhorseman.net>
References: <87skuzo28j.fsf@squeak.fifthhorseman.net>	<486F2F24.4010608@gnutls.org>
	<877ibwidac.fsf@squeak.fifthhorseman.net>
Message-ID: <4874EC37.1060705@gnutls.org>

Daniel Kahn Gillmor wrote:

> With the patch, GnuTLS can create a gnutls_openpgp_privkey_t from such
> a key.  It won't be able to manipulate the key cleanly for any purpose
> that requires access to the secret MPIs themselves because they are
> locked, but GnuTLS will still be able to do all of the pubkey
> functions with that key.  For example, It should still be possible to
> get the fingerprint of the key without knowing the secret MPIs.

What will happen if someone tries to access the MPIs?





From ludo at gnu.org  Wed Jul  9 23:23:21 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 09 Jul 2008 23:23:21 +0200
Subject: some opencdk history
References: <87skuzo28j.fsf@squeak.fifthhorseman.net>
	<486F2F24.4010608@gnutls.org>
	<877ibwidac.fsf@squeak.fifthhorseman.net>
	<4874EBFA.2030208@gnutls.org>
Message-ID: <87skuisqeu.fsf@gnu.org>

Hi,

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Daniel Kahn Gillmor wrote:
>> On Sat 2008-07-05 01:21:56 -0700, Nikos Mavrogiannopoulos wrote:
>> 
>>>  I've finally found some time to check your patch and I have some
>>> remarks. The first is about patches in opencdk. The opencdk library
>>> included in gnutls is a crippled version of the "full" opencdk
>>> library by Timo Schulz. This crippling was done for mainly two
>>> reasons. The full opencdk library contained GPL code that forced us
>>> to include the openpgp support only in libextra, and the second is
>>> that we only wanted to include the parts of opencdk we used.
>> Cool, thanks for the explanation, Nikos.  Are you saying that the
>> OpenPGP pieces of GnuTLS themselves are now *not* in libextra, then?
>> That they currently fall under the LGPL instead?  I know that there
>> has been a lot of changes recently, but i haven't followed them
>> closely enough to know here.
>> Was it necessary to remove the pieces that were removed *because* they
>> were only under the GPL, not the LGPL?  
>
> This wasn't the only reason. Of course the GPL parts had to be removed,
> but there were also some other parts under LGPL that we didn't use at
> that time in gnutls and/or required some rewritting, so they were also
> dropped.

Still, the Guile bindings keep providing OpenPGP support as part of the
`(gnutls extra)' module, released under the GPLv3+, not the LGPL.  Does
that mean they're not in sync with core GnuTLS (which wouldn't
necessarily be a problem)?

Thanks,
Ludovic.





From dkg-debian.org at fifthhorseman.net  Thu Jul 10 04:40:55 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 09 Jul 2008 22:40:55 -0400
Subject: some opencdk history
In-Reply-To: <4874EC37.1060705@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Wed\, 09 Jul 2008 19\:49\:59 +0300")
References: <87skuzo28j.fsf@squeak.fifthhorseman.net>
	<486F2F24.4010608@gnutls.org>
	<877ibwidac.fsf@squeak.fifthhorseman.net>
	<4874EC37.1060705@gnutls.org>
Message-ID: <871w2231hk.fsf@squeak.fifthhorseman.net>

On Wed 2008-07-09 12:49:59 -0400, Nikos Mavrogiannopoulos wrote:

> What will happen if someone tries to access the MPIs?

The MPIs associated with a locked secret key are currently set to
NULL, so they are rejected by GnuTLS -- attempts to export them result
in an error (-50, i believe), but no crash.

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080709/e0b93af3/attachment.pgp>

From nmav at gnutls.org  Thu Jul 10 19:10:49 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 10 Jul 2008 20:10:49 +0300
Subject: some opencdk history
In-Reply-To: <87skuisqeu.fsf@gnu.org>
References: <87skuzo28j.fsf@squeak.fifthhorseman.net>	<486F2F24.4010608@gnutls.org>	<877ibwidac.fsf@squeak.fifthhorseman.net>	<4874EBFA.2030208@gnutls.org>
	<87skuisqeu.fsf@gnu.org>
Message-ID: <48764299.6040907@gnutls.org>

Ludovic Court?s wrote:

> Still, the Guile bindings keep providing OpenPGP support as part of the
> `(gnutls extra)' module, released under the GPLv3+, not the LGPL.  Does
> that mean they're not in sync with core GnuTLS (which wouldn't
> necessarily be a problem)?

Indeed it should be moved to the core library.

regards,
Nikos






From ludo at gnu.org  Thu Jul 10 21:14:04 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 10 Jul 2008 21:14:04 +0200
Subject: some opencdk history
References: <87skuzo28j.fsf@squeak.fifthhorseman.net>
	<486F2F24.4010608@gnutls.org>
	<877ibwidac.fsf@squeak.fifthhorseman.net>
	<4874EBFA.2030208@gnutls.org> <87skuisqeu.fsf@gnu.org>
	<48764299.6040907@gnutls.org>
Message-ID: <87r6a1blhf.fsf@gnu.org>

Hi,

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Ludovic Court?s wrote:
>
>> Still, the Guile bindings keep providing OpenPGP support as part of the
>> `(gnutls extra)' module, released under the GPLv3+, not the LGPL.  Does
>> that mean they're not in sync with core GnuTLS (which wouldn't
>> necessarily be a problem)?
>
> Indeed it should be moved to the core library.

Yes, but that would cause an incompatibility for little in return, so I
thing we'd be better off leaving things as they are.

Thanks,
Ludovic.





From nmav at gnutls.org  Sat Jul 12 11:17:39 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 12 Jul 2008 12:17:39 +0300
Subject: some opencdk history
In-Reply-To: <871w2231hk.fsf@squeak.fifthhorseman.net>
References: <87skuzo28j.fsf@squeak.fifthhorseman.net>	<486F2F24.4010608@gnutls.org>	<877ibwidac.fsf@squeak.fifthhorseman.net>	<4874EC37.1060705@gnutls.org>
	<871w2231hk.fsf@squeak.fifthhorseman.net>
Message-ID: <487876B3.2020608@gnutls.org>

Daniel Kahn Gillmor wrote:
> On Wed 2008-07-09 12:49:59 -0400, Nikos Mavrogiannopoulos wrote:
> 
>> What will happen if someone tries to access the MPIs?
> 
> The MPIs associated with a locked secret key are currently set to
> NULL, so they are rejected by GnuTLS -- attempts to export them result
> in an error (-50, i believe), but no crash.

I don't know if this is enough. We should have a way to indicate that
this key is encrypted otherwise it would not be distinguishable from
broken keys. Do you have something in mind for that?




From duane at e164.org  Thu Jul 24 07:07:44 2008
From: duane at e164.org (Duane)
Date: Thu, 24 Jul 2008 15:07:44 +1000
Subject: OpenPGP Browser Support
Message-ID: <48880E20.1070101@e164.org>


I was pleasantly surprised to learn that OpenPGP has been accepted as a
RFC, however I'm unable to find a browser or plugin for a browser that
supports this, is anyone able to enlighten me?

-- 

Best regards,
 Duane

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20080724/7eb0c29d/attachment.pgp>

From dkg-debian.org at fifthhorseman.net  Thu Jul 24 19:10:15 2008
From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 24 Jul 2008 13:10:15 -0400
Subject: OpenPGP Browser Support
In-Reply-To: <48880E20.1070101@e164.org> (duane@e164.org's message of "Thu\,
	24 Jul 2008 15\:07\:44 +1000")
References: <48880E20.1070101@e164.org>
Message-ID: <874p6fxl6w.fsf@squeak.fifthhorseman.net>

On Thu 2008-07-24 01:07:44 -0400, Duane wrote:

> I was pleasantly surprised to learn that OpenPGP has been accepted
> as a RFC, however I'm unable to find a browser or plugin for a
> browser that supports this, is anyone able to enlighten me?

I've yet to find one either, unfortunately.  There are two major
fields of work to see this happen successfully:

 * adapt one of the browsers that uses gnutls (epiphany?  galeon?) to
   be able to handle this TLS extension: this includes deciding how to
   store a keyring of trusted identity certifiers.

 * do the UI work necessary in that browser to let users choose how to
   manage their set of trusted identity certifiers.

Some implementation decisions would need to be made:

 * do you want to use/interact with the user's standard GPG keyring
   for any of this?

 * do you want to use the full web-of-trust model, or is a list of
   trusted authorities (similar to the current X.509 model)
   sufficient?

 * how do you plan to match the OpenPGP User IDs to hosts?  Is just
   the name sufficient?  What about alternate ports?  (e.g. is
   "www.example.com" the User ID you'll look for?  or should it be
   "https://www.example.com/"?  Or for alternate ports (e.g. not 443
   for https), should it be "www.example.com:4343" ? I don't believe
   the RFC actually specifies what must go here (though i'd be happy
   to be shown otherwise).

I'd really love to see this project get underway, but i haven't seen
anyone doing it yet.

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20080724/63e758be/attachment.pgp>

From duane at e164.org  Fri Jul 25 00:37:18 2008
From: duane at e164.org (Duane)
Date: Fri, 25 Jul 2008 08:37:18 +1000
Subject: OpenPGP Browser Support
In-Reply-To: <874p6fxl6w.fsf@squeak.fifthhorseman.net>
References: <48880E20.1070101@e164.org>
	<874p6fxl6w.fsf@squeak.fifthhorseman.net>
Message-ID: <4889041E.1070703@e164.org>

Daniel Kahn Gillmor wrote:

> Some implementation decisions would need to be made:
> 
>  * do you want to use/interact with the user's standard GPG keyring
>    for any of this?

This is going to open a can of worms, but disallowing this is
detrimental for security, X.509 has a very small amount of deployment
because of the 'pop-up tax', there is nothing intrinsically wrong with
X.509, however you are fighting mind set if you go down that path.

>  * do you want to use the full web-of-trust model, or is a list of
>    trusted authorities (similar to the current X.509 model)
>    sufficient?

There is no practical or technical reason both can't be accommodated,
I've already been in contact with the guys from CAcert over this, I'll
probably have to do the coding, but they are more than happy to sign
OpenPGP keys in the same manner as X.509 certs and given demand I doubt
any other CA would choose not to support this as well, money is money
after all.

>  * how do you plan to match the OpenPGP User IDs to hosts?  Is just
>    the name sufficient?  What about alternate ports?  (e.g. is
>    "www.example.com" the User ID you'll look for?  or should it be
>    "https://www.example.com/"?  Or for alternate ports (e.g. not 443
>    for https), should it be "www.example.com:4343" ? I don't believe
>    the RFC actually specifies what must go here (though i'd be happy
>    to be shown otherwise).

I have some ideas about this as well ;)

No the RFC didn't specify what has to go where and this is bad, ideally
we need an RFC specifically on this topic and I've been trying to make
some head way on this subject but have had a general lack of feed back.

I have written in depth about this topic already, so rather than repeat
myself I'll just paste a link to the relevant document:

http://open-pgp.info/wiki/index.php?title=DNS_Encryption_Draft

Although it doesn't cover port, I'm afraid I don't know enough about the
TLS protocol to comment on if https would be suitable or not, but there
is always the escalation with TLS, but the downside is information is
leaked or changed in transit. These days the way to get a new prefix
like https is through SRV records, eg _httpg._tcp ...

> I'd really love to see this project get underway, but i haven't seen
> anyone doing it yet.

Me too!

-- 

Best regards,
 Duane

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

From agl at imperialviolet.org  Sat Jul 26 00:16:50 2008
From: agl at imperialviolet.org (Adam Langley)
Date: Fri, 25 Jul 2008 15:16:50 -0700
Subject: OpenPGP Browser Support
In-Reply-To: <4889041E.1070703@e164.org>
References: <48880E20.1070101@e164.org>
	<874p6fxl6w.fsf@squeak.fifthhorseman.net> <4889041E.1070703@e164.org>
Message-ID: <396556a20807251516y6ce11fd5x3ce6fafb1a3ecef0@mail.gmail.com>

On Thu, Jul 24, 2008 at 3:37 PM, Duane <duane at e164.org> wrote:
> I have written in depth about this topic already, so rather than repeat
> myself I'll just paste a link to the relevant document:
>
> http://open-pgp.info/wiki/index.php?title=DNS_Encryption_Draft

This document seems to be dealing with something quite different,
namely providing some confidentiality to DNS resolvers. But that's not
an uninteresting topic in of itself.

However, rather than have queries encrypted to a server and signed
replies, I'd suggest that clients include an elliptic-curve
Diffie-Hellman public key in the request and encrypt the request with
the shared key (assuming that the client know's the server's key). The
server than calculates the shared key, encrypts the reply and sticks a
MAC on the end.

The advantage being that it should be a lot faster. Clients cache the
results and there's (effectively) no performance hit.

If a server can get a cache hit on the client's public key, it's
equally very fast. Otherwise (and this would almost always be the case
for root/gTLD servers), you can do about 4000 key
agreements/second/core[1]. For a modern, 8-core machine that's 32Kq/s.
I can't find recent data on DNS server load at the root or gTLD level,
although I suspect it's within an order of magnitude of that. For ISP
level server, that should be fine.

[1] http://cr.yp.to/ecdh.html

-- 
Adam Langley agl at imperialviolet.org http://www.imperialviolet.org




From duane at e164.org  Sat Jul 26 01:33:50 2008
From: duane at e164.org (Duane)
Date: Sat, 26 Jul 2008 09:33:50 +1000
Subject: OpenPGP Browser Support
In-Reply-To: <396556a20807251516y6ce11fd5x3ce6fafb1a3ecef0@mail.gmail.com>
References: <48880E20.1070101@e164.org>	
	<874p6fxl6w.fsf@squeak.fifthhorseman.net>
	<4889041E.1070703@e164.org>
	<396556a20807251516y6ce11fd5x3ce6fafb1a3ecef0@mail.gmail.com>
Message-ID: <488A62DE.9090404@e164.org>

Adam Langley wrote:
> On Thu, Jul 24, 2008 at 3:37 PM, Duane <duane at e164.org> wrote:
>> I have written in depth about this topic already, so rather than repeat
>> myself I'll just paste a link to the relevant document:
>>
>> http://open-pgp.info/wiki/index.php?title=DNS_Encryption_Draft
> 
> This document seems to be dealing with something quite different,
> namely providing some confidentiality to DNS resolvers. But that's not
> an uninteresting topic in of itself.

Sorry about this, but since I posted that I split the draft into 2, well
3, documents.

The DNS Encryption stuff, Standardisation of OpenPGP information:

http://open-pgp.info/wiki/index.php?title=Standardisation_of_Information_in_OpenPGP_User_IDs_for_Server_Purposes

And a chunk of text left over I'm not sure what to do with entirely:

http://open-pgp.info/wiki/index.php?title=Why_X.509_is_Bad

> However, rather than have queries encrypted to a server and signed
> replies, I'd suggest that clients include an elliptic-curve
> Diffie-Hellman public key in the request and encrypt the request with
> the shared key (assuming that the client know's the server's key). The
> server than calculates the shared key, encrypts the reply and sticks a
> MAC on the end.

The public-key + signed replies are only for session key setup, once
established the server/client can switch to AES or some other
symmetrical encryption. The reason for signed replies is to prevent
spoofed packets from downgrading or sending fake error messages.

> If a server can get a cache hit on the client's public key, it's
> equally very fast. Otherwise (and this would almost always be the case

Actually I'm going the other way, clients are trying to get cache hits
on server keys since that's where you need to calculate confidence
ratings, the server doesn't need to know anything about the client, in
fact the less the server knows about the client the better.

> for root/gTLD servers), you can do about 4000 key
> agreements/second/core[1]. For a modern, 8-core machine that's 32Kq/s.
> I can't find recent data on DNS server load at the root or gTLD level,
> although I suspect it's within an order of magnitude of that. For ISP
> level server, that should be fine.

Actually this will be a little difficult to deal with, a number of root
servers have anycast addresses so it will mess with sessions, all the
client can do is re-request a new session set-up using the same AES key
unless the servers some how share session keys and cookies some how.

I suppose I really should make a note about this in the draft.

-- 

Best regards,
 Duane




From duane at e164.org  Sun Jul 27 02:27:49 2008
From: duane at e164.org (Duane)
Date: Sun, 27 Jul 2008 10:27:49 +1000
Subject: Draft Update
Message-ID: <488BC105.6070000@e164.org>



Ok, I've made some updates, firstly removing specific references to DNS
since this is no longer specifically meant to be for DNS and other
changes to remove references to using the user id field, and instead
using user attributes to have the information in a format much more
suitable for computers, this makes more sense to me than a blob of
string doesn't need to be split up and parsed to extract the information.

http://open-pgp.info/wiki/index.php?title=Standardisation_of_OpenPGP_Keys_for_Server_Purposes

Is there anything I've missed or overlooked at all?

-- 

Best regards,
 Duane





From ludo at gnu.org  Sun Jul 27 21:14:07 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Sun, 27 Jul 2008 21:14:07 +0200
Subject: Draft Update
References: <488BC105.6070000@e164.org>
Message-ID: <87abg3w35s.fsf@gnu.org>

Hi,

Duane <duane at e164.org> writes:

> Ok, I've made some updates, firstly removing specific references to DNS
> since this is no longer specifically meant to be for DNS and other
> changes to remove references to using the user id field, and instead
> using user attributes to have the information in a format much more
> suitable for computers, this makes more sense to me than a blob of
> string doesn't need to be split up and parsed to extract the information.
>
> http://open-pgp.info/wiki/index.php?title=Standardisation_of_OpenPGP_Keys_for_Server_Purposes
>
> Is there anything I've missed or overlooked at all?

We had a discussion earlier where Daniel Kahn Gillmor proposed (ab)using
user IDs in OpenPGP keys in a way similar to what you propose:

  http://thread.gmane.org/gmane.network.gnutls.general/802/focus=824

Thanks,
Ludovic.





From duane at e164.org  Sun Jul 27 22:57:50 2008
From: duane at e164.org (Duane)
Date: Mon, 28 Jul 2008 06:57:50 +1000
Subject: Draft Update
In-Reply-To: <87abg3w35s.fsf@gnu.org>
References: <488BC105.6070000@e164.org> <87abg3w35s.fsf@gnu.org>
Message-ID: <488CE14E.9000009@e164.org>

Ludovic Court?s wrote:

> We had a discussion earlier where Daniel Kahn Gillmor proposed (ab)using
> user IDs in OpenPGP keys in a way similar to what you propose:
> 
>   http://thread.gmane.org/gmane.network.gnutls.general/802/focus=824

The RFC ended up pretty much just stating the hostname was to be used in
place of other user id information. I actually went a bit further than
this, but have since changed it to store the information in User
Attribute Types instead.

-- 

Best regards,
 Duane