From nmav at gnutls.org  Fri Nov  2 19:06:08 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 02 Nov 2012 19:06:08 +0100
Subject: Fwd: [oss-security] please verify unusual x.509 constraints are
	handled
In-Reply-To: <5090DFCE.3050608@fifthhorseman.net>
References: <20120627131318.GA30758@cmpxchg8b.com>
	<5090DFCE.3050608@fifthhorseman.net>
Message-ID: <50940B90.3020301@gnutls.org>

On 10/31/2012 09:22 AM, Daniel Kahn Gillmor wrote:

> * The problem with canonicalization is the subjectName/issuerName DN
>   should be canonicalized, but this isnt always implemented. In this
>   case the PrintableString doesnt match the UTF8String. If this is the
>   only problem with the chain reported, then there is a bug.

I don't really understand what the author means here about
canonicalization of a DN (canonicalization is not a PKIX term), but most
probably he means about the caseIgnoreMatch string comparison algorithm
of RFC5280. This is utter idiocy that we are not going to support in
GnuTLS. The Distinguished name of a certificate isn't copied by a
secretary which may enter an extra space or transform a capital letter
to lower case. A certificate's DN is copied by software which does not
introduce these errors. The only issues we had with our opaque
comparison is on case where these errors were deliberately inserted for
testing, real world certificates do not have any issue.

I really don't know what the PKIX authors were thinking when adopting
this string comparison algorithm from the time of telex.

regards,
Nikos



From nmav at gnutls.org  Sat Nov  3 20:26:33 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 03 Nov 2012 20:26:33 +0100
Subject: gnutls + openpgp
Message-ID: <50956FE9.60203@gnutls.org>

Hello,
 It seem that the IETF TLS working group is defining a new certificate
type extension, which in short makes the openpgp certificate type
extension obsolete. The authors of the new draft are not very keen into
adding the openpgp key type into the new certificate type extension,
based on the fact that this is not widely used. So my question is does
it really make sense to pursue that? Are there applications using gnutls
with openpgp keys?

And even more, if it is shown they are not widely used, does it make
sense to support openpgp keys in gnutls at all?

regards,
Nikos



From rich at kde.org  Sat Nov  3 22:01:20 2012
From: rich at kde.org (Richard Moore)
Date: Sat, 3 Nov 2012 21:01:20 +0000
Subject: gnutls + openpgp
In-Reply-To: <50956FE9.60203@gnutls.org>
References: <50956FE9.60203@gnutls.org>
Message-ID: <CAMp7mVvrmDA0RFDOQs+mExkj1TFwXqkJZiwSkVY3EMraXQTyGg@mail.gmail.com>

On 3 November 2012 19:26, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> And even more, if it is shown they are not widely used, does it make
> sense to support openpgp keys in gnutls at all?

If they're not used, then supporting them simply means gnutls has a
bigger attack surface for no benefit.

Cheers

Rich.



From home_pw at msn.com  Sat Nov  3 21:55:19 2012
From: home_pw at msn.com (Peter Williams)
Date: Sat, 3 Nov 2012 13:55:19 -0700
Subject: gnutls + openpgp
In-Reply-To: <50956FE9.60203@gnutls.org>
References: <50956FE9.60203@gnutls.org>
Message-ID: <SNT402-EAS131EE431888DF4B14721AD192660@phx.gbl>

So what are they doing ... That cannot be done within the existing type definer?

If folks need an extension, there are two reasons: 

1) the concept needs replacing (eg define life do pgp Certs are undefinable)

2) one needs the tcp or http stack to be doing interpretation, before connect establish.

I can guess this is related to dnssec, preventing connection establish if the tcp engine cannot confirm the new-cert is registered by DNs

All part of the militarization of the web, I suspect. 

Sent from my iPhone

On Nov 3, 2012, at 12:26 PM, "Nikos Mavrogiannopoulos" <nmav at gnutls.org> wrote:

> Hello,
> It seem that the IETF TLS working group is defining a new certificate
> type extension, which in short makes the openpgp certificate type
> extension obsolete. The authors of the new draft are not very keen into
> adding the openpgp key type into the new certificate type extension,
> based on the fact that this is not widely used. So my question is does
> it really make sense to pursue that? Are there applications using gnutls
> with openpgp keys?
> 
> And even more, if it is shown they are not widely used, does it make
> sense to support openpgp keys in gnutls at all?
> 
> regards,
> Nikos
> 
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> https://lists.gnu.org/mailman/listinfo/gnutls-devel



From n.mavrogiannopoulos at gmail.com  Sun Nov  4 12:05:04 2012
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sun, 04 Nov 2012 12:05:04 +0100
Subject: gnutls + openpgp
In-Reply-To: <CAMp7mVvrmDA0RFDOQs+mExkj1TFwXqkJZiwSkVY3EMraXQTyGg@mail.gmail.com>
References: <50956FE9.60203@gnutls.org>
	<CAMp7mVvrmDA0RFDOQs+mExkj1TFwXqkJZiwSkVY3EMraXQTyGg@mail.gmail.com>
Message-ID: <50964BE0.1030306@gmail.com>

On 11/03/2012 10:01 PM, Richard Moore wrote:

> On 3 November 2012 19:26, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> And even more, if it is shown they are not widely used, does it make
>> sense to support openpgp keys in gnutls at all?
> If they're not used, then supporting them simply means gnutls has a
> bigger attack surface for no benefit.


This is not really true. One needs to specifically enable the openpgp.
That codebase doesn't affect an application which is only using the
X.509 part of gnutls. The main concern IMO, is the maintenance cost, and
it'd be better not to have it if there are no users of the subsystem.

regards,
Nikos



From ott at mirix.org  Sun Nov  4 19:44:43 2012
From: ott at mirix.org (Matthias-Christian Ott)
Date: Sun, 04 Nov 2012 19:44:43 +0100
Subject: gnutls + openpgp
In-Reply-To: <50956FE9.60203@gnutls.org>
References: <50956FE9.60203@gnutls.org>
Message-ID: <5096B79B.1080809@mirix.org>

On 2012-11-03 20:26, Nikos Mavrogiannopoulos wrote:
> And even more, if it is shown they are not widely used, does it make
> sense to support openpgp keys in gnutls at all?

Despite of mod_gnutls I'm not aware of any software that supports it. I
tried to make Mozilla aware of TLS with OpenPGP [1], but (I think) there
seems to be no interest and getting support for this into NSS didn't
seem "politically" easy. So it's a chicken and egg problem.

I wouldn't remove it, because otherwise X.509 is the only means of
authentication in TLS (I think everything in the X.509 vs. OpenPGP
debate has been said and both have their practical reasons for
existence). Perhaps draft-ietf-tls-oob-pubkey is a compromise.

Regards,
Matthias-Christian

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=290029



From wk at gnupg.org  Mon Nov  5 09:32:29 2012
From: wk at gnupg.org (Werner Koch)
Date: Mon, 05 Nov 2012 09:32:29 +0100
Subject: gnutls + openpgp
In-Reply-To: <5096B79B.1080809@mirix.org> (Matthias-Christian Ott's message of
	"Sun, 04 Nov 2012 19:44:43 +0100")
References: <50956FE9.60203@gnutls.org> <5096B79B.1080809@mirix.org>
Message-ID: <87objc1mci.fsf@vigenere.g10code.de>

On Sun,  4 Nov 2012 19:44, ott at mirix.org said:

> Despite of mod_gnutls I'm not aware of any software that supports it. I
> tried to make Mozilla aware of TLS with OpenPGP [1], but (I think) there
> seems to be no interest and getting support for this into NSS didn't
> seem "politically" easy. So it's a chicken and egg problem.

It is even not possible to get OpenPGP into Thunderbird, proper.  We
tried this since about 2000 without any success.  It is a pity that you
need the Enigmail extension instead of having proper support included in
Thunderbird.  Almost all other mail clients support OpenPGP - with the
exception of Outlook and Thunderbird.

Thus why should they support a TLS option in Firefox if they don't even
support the de-facto mail encryption standard in Thunderbird.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




From dkg at fifthhorseman.net  Tue Nov  6 05:32:24 2012
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 05 Nov 2012 23:32:24 -0500
Subject: gnutls + openpgp
In-Reply-To: <50956FE9.60203@gnutls.org>
References: <50956FE9.60203@gnutls.org>
Message-ID: <509892D8.9040003@fifthhorseman.net>

On 11/03/2012 03:26 PM, Nikos Mavrogiannopoulos wrote:
>  It seem that the IETF TLS working group is defining a new certificate
> type extension, which in short makes the openpgp certificate type
> extension obsolete. The authors of the new draft are not very keen into
> adding the openpgp key type into the new certificate type extension,
> based on the fact that this is not widely used. So my question is does
> it really make sense to pursue that? Are there applications using gnutls
> with openpgp keys?
> 
> And even more, if it is shown they are not widely used, does it make
> sense to support openpgp keys in gnutls at all?

given the hassle involved in convincing other major TLS implementations
to adopt TLS extensions, and the lack of adoption of OpenPGP
certificates in TLS in general, i've been thinking recently that the
simpler approach is just to propose and implement new "standards" within
the X.509 space and allow the verifiers to transform the weird
certificates on either side.  The worst thing that happens there is
something akin to a browser warning; and if you can propose an X.509
verification routine or plugin for the peers, it's possibly narrower in
scope than asking for a TLS extension.

The downside of this approach, of course, is that there's no clear way
to signal that a non-standard X.509 certificate would be acceptable for
the remote peer :(  Oh, and the other major downside of course is that
the X.509 format is a really ungainly one, if you had to choose a
generic container.

I'm pretty disheartened by the TLS WG's rationales for discarding RFC
6091 when working on oob-key, though.  If the main concern is that there
isn't a mechanism for indicating the difference between what kinds of
certificates you're prepared to offer, and what kind of certificates
you're prepared to accept, then it seems to me that should be fixed as a
revision of 6091, rather than maintain two separate registries of
certificate types.

I'd reply with something like this on the IETF list, but i'm not sure
how useful that would be, given the back-and-forth you've already had.

Any thoughts on what sort of feedback i might give that would be useful?

	--dkg

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

From daniel at haxx.se  Tue Nov  6 19:31:54 2012
From: daniel at haxx.se (Daniel Stenberg)
Date: Tue, 6 Nov 2012 19:31:54 +0100 (CET)
Subject: WARNING: gnome-keyring ??
Message-ID: <alpine.DEB.2.00.1211061929280.31654@tvnag.unkk.fr>

Hi friends!

I'm building curl on Debian against GnuTLS 2.12.20 and when I call 
gnutls_global_init() I get some ugly output sent to stderr:

   WARNING: gnome-keyring:: couldn't connect to:
   /home/daniel/.cache/keyring-iN3fsp/pkcs11: No such file or directory

I really dislike that a library would output anything at all to stderr like 
this. Can I do anything to prevent it? Is this really a desired feature?

-- 

  / daniel.haxx.se



From nmav at gnutls.org  Tue Nov  6 20:26:41 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 06 Nov 2012 20:26:41 +0100
Subject: WARNING: gnome-keyring ??
In-Reply-To: <alpine.DEB.2.00.1211061929280.31654@tvnag.unkk.fr>
References: <alpine.DEB.2.00.1211061929280.31654@tvnag.unkk.fr>
Message-ID: <50996471.4010503@gnutls.org>

On 11/06/2012 07:31 PM, Daniel Stenberg wrote:

> Hi friends!
> I'm building curl on Debian against GnuTLS 2.12.20 and when I call
> gnutls_global_init() I get some ugly output sent to stderr:
>   WARNING: gnome-keyring:: couldn't connect to:
>   /home/daniel/.cache/keyring-iN3fsp/pkcs11: No such file or directory
> I really dislike that a library would output anything at all to stderr
> like this. Can I do anything to prevent it? Is this really a desired
> feature?


Hello,
 This doesn't look like it is from gnutls. It looks like it is the
output from the gnome-keyring pkcs11 module. I add Stef for verification.

You could disable that module from being loaded by editing the
corresponding file in /etc/pkcs11/modules/.

regards,
Nikos



From code at funwithsoftware.org  Wed Nov  7 03:32:24 2012
From: code at funwithsoftware.org (Patrick Pelletier)
Date: Tue, 06 Nov 2012 18:32:24 -0800
Subject: gnutls + openpgp
In-Reply-To: <50956FE9.60203@gnutls.org>
References: <50956FE9.60203@gnutls.org>
Message-ID: <5099C838.2050108@funwithsoftware.org>

On 11/3/12 12:26 PM, Nikos Mavrogiannopoulos wrote:

> And even more, if it is shown they are not widely used, does it make
> sense to support openpgp keys in gnutls at all?

FWIW, I noticed that the hs-tls folks have expressed some interest in 
OpenPGP, although admittedly there's been no further activity in 7 months:

https://github.com/vincenthz/hs-tls/issues/10

But still, it might be worthwhile to touch base with those guys.  It 
would be somewhat ironic if GnuTLS dropped support for OpenPGP at the 
same time hs-tls was adding support.

--Patrick




From daniel at haxx.se  Wed Nov  7 09:24:11 2012
From: daniel at haxx.se (Daniel Stenberg)
Date: Wed, 7 Nov 2012 09:24:11 +0100 (CET)
Subject: WARNING: gnome-keyring ??
In-Reply-To: <50996471.4010503@gnutls.org>
References: <alpine.DEB.2.00.1211061929280.31654@tvnag.unkk.fr>
	<50996471.4010503@gnutls.org>
Message-ID: <alpine.DEB.2.00.1211062219150.31654@tvnag.unkk.fr>

On Tue, 6 Nov 2012, Nikos Mavrogiannopoulos wrote:

>>   WARNING: gnome-keyring:: couldn't connect to:
>>   /home/daniel/.cache/keyring-iN3fsp/pkcs11: No such file or directory

> This doesn't look like it is from gnutls. It looks like it is the output 
> from the gnome-keyring pkcs11 module. I add Stef for verification.
>
> You could disable that module from being loaded by editing the corresponding 
> file in /etc/pkcs11/modules/.

Thanks.

I'm using GnuTLS here to get TLS and SSL support for my library and tool. I 
have no idea what the pcks11 module does or doesn't do for me in this context, 
but it feels wrong to have to disable something system-wide for a single tool 
I build to not send warnings on stderr...

-- 

  / daniel.haxx.se



From nmav at gnutls.org  Wed Nov  7 10:10:03 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 7 Nov 2012 10:10:03 +0100
Subject: WARNING: gnome-keyring ??
In-Reply-To: <alpine.DEB.2.00.1211062219150.31654@tvnag.unkk.fr>
References: <alpine.DEB.2.00.1211061929280.31654@tvnag.unkk.fr>
	<50996471.4010503@gnutls.org>
	<alpine.DEB.2.00.1211062219150.31654@tvnag.unkk.fr>
Message-ID: <CAJU7zaJFkAfBjPBmkEM6ENOM27ywE8NW_x5drZMz9SLELEDeMQ@mail.gmail.com>

On Wed, Nov 7, 2012 at 9:24 AM, Daniel Stenberg <daniel at haxx.se> wrote:

>> This doesn't look like it is from gnutls. It looks like it is the output
>> from the gnome-keyring pkcs11 module. I add Stef for verification.
>> You could disable that module from being loaded by editing the
>> corresponding file in /etc/pkcs11/modules/.
> I'm using GnuTLS here to get TLS and SSL support for my library and tool. I
> have no idea what the pcks11 module does or doesn't do for me in this
> context, but it feels wrong to have to disable something system-wide for a
> single tool I build to not send warnings on stderr...

The warning on stderr shouldn't have been there. A module that is
being loaded should either succeed loading or fail with a return code.
However this is not under my control to suppress. The PKCS #11 support
(this is about smart cards) is transparent and system wide because we
want all applications that use gnutls to be able to use smart cards
transparently (e.g. you can load your private key from a smart card
the same way you'd load it from a file).

regards,
Nikos



From oneingray at gmail.com  Wed Nov  7 15:33:23 2012
From: oneingray at gmail.com (Ivan Shmakov)
Date: Wed, 07 Nov 2012 21:33:23 +0700
Subject: "known in advance" public key authentication? 
Message-ID: <864nl1iito.fsf@gray.siamics.net>

	For my application, I need to establish a secure communication
	between two peers, and as it seems, TLS is a perfect fit for
	that.

	A feature of this application is that the public keys of the
	peers are effectively ?known in advance?, so, while self-signed
	(unsigned?) X.509 certificates (or some OpenPGP ones) could be
	employed, there's no practical benefit from CC/WoT verification.

	Hence, the question is: is there a way to specify the local key
	pair and the remote public key to GnuTLS ?directly?, just prior
	to connecting the remote?

	TIA.

-- 
FSF associate member #7257




From stefw at gnome.org  Wed Nov  7 10:03:08 2012
From: stefw at gnome.org (Stef Walter)
Date: Wed, 07 Nov 2012 10:03:08 +0100
Subject: Fwd: Re: WARNING: gnome-keyring ??
In-Reply-To: <509979A4.5020701@gnutls.org>
References: <50996471.4010503@gnutls.org> <509979A4.5020701@gnutls.org>
Message-ID: <509A23CC.2090509@gnome.org>

On 11/06/2012 09:57 PM, Nikos Mavrogiannopoulos wrote:
> Hey Stef,
>  I tried to CC you but I used the wrong address...

This is because the GNOME_KEYRING_CONTROL environment variable is set
but gnome-keyring-daemon is not running. So the work around is to not
have the environment variable set.

But there's a patch to fix this. It just needs testing:

https://bugzilla.gnome.org/show_bug.cgi?id=665961

Cheers,

Stef


> 
> -------- Original Message --------
> Subject: Re: WARNING: gnome-keyring ??
> Date: Tue, 06 Nov 2012 20:26:41 +0100
> From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
> To: Daniel Stenberg <daniel at haxx.se>
> CC: help-gnutls at gnu.org, Stef Walter <stefw at collabora.co.uk>
> 
> On 11/06/2012 07:31 PM, Daniel Stenberg wrote:
> 
>> Hi friends!
>> I'm building curl on Debian against GnuTLS 2.12.20 and when I call
>> gnutls_global_init() I get some ugly output sent to stderr:
>>   WARNING: gnome-keyring:: couldn't connect to:
>>   /home/daniel/.cache/keyring-iN3fsp/pkcs11: No such file or directory
>> I really dislike that a library would output anything at all to stderr
>> like this. Can I do anything to prevent it? Is this really a desired
>> feature?
> 
> 
> 
> 
> Hello,
>  This doesn't look like it is from gnutls. It looks like it is the
> output from the gnome-keyring pkcs11 module. I add Stef for verification.
> 
> You could disable that module from being loaded by editing the
> corresponding file in /etc/pkcs11/modules/.
> 
> regards,
> Nikos
> 




From GMurray at webwayone.co.uk  Wed Nov  7 16:06:25 2012
From: GMurray at webwayone.co.uk (Graham Murray)
Date: Wed, 7 Nov 2012 15:06:25 +0000
Subject: "known in advance" public key authentication?
In-Reply-To: <864nl1iito.fsf@gray.siamics.net>
References: <864nl1iito.fsf@gray.siamics.net>
Message-ID: <1352300785.3674.20.camel@gmdev.webwayone.co.uk>

On Wed, 2012-11-07 at 14:33 +0000, Ivan Shmakov wrote:
> 	For my application, I need to establish a secure communication
> 	between two peers, and as it seems, TLS is a perfect fit for
> 	that.
> 
> 	A feature of this application is that the public keys of the
> 	peers are effectively ?known in advance?, so, while self-signed
> 	(unsigned?) X.509 certificates (or some OpenPGP ones) could be
> 	employed, there's no practical benefit from CC/WoT verification.
> 
> 	Hence, the question is: is there a way to specify the local key
> 	pair and the remote public key to GnuTLS ?directly?, just prior
> 	to connecting the remote?

Would PSK not do what you want?



From ilari.liusvaara at elisanet.fi  Wed Nov  7 16:35:00 2012
From: ilari.liusvaara at elisanet.fi (Ilari Liusvaara)
Date: Wed, 7 Nov 2012 17:35:00 +0200
Subject: "known in advance" public key authentication?
In-Reply-To: <864nl1iito.fsf@gray.siamics.net>
References: <864nl1iito.fsf@gray.siamics.net>
Message-ID: <20121107153500.GA22846@LK-Perkele-VI.localdomain>

On Wed, Nov 07, 2012 at 09:33:23PM +0700, Ivan Shmakov wrote:
 
> 	Hence, the question is: is there a way to specify the local key
> 	pair and the remote public key to GnuTLS ?directly?, just prior
> 	to connecting the remote?

I implemented about half of that (client that ever connects to one
server, so it hardcodes its public key instead of messing with certs).

The outgoing key and certificate are set the same way self-signed
or not.

I don't know a way to specify expected public key. Instead,
in the code I wrote, I extract the certificate and then check the
key:

- gnutls_certificate_get_peers 
- gnutls_x509_crt_import (index 0)
- gnutls_x509_crt_get_pk_algorithm
- gnutls_x509_crt_get_pk_rsa_raw / gnutls_x509_crt_get_pk_dsa_raw

The same thing should work on the server end.

-Ilari



From dkg at fifthhorseman.net  Wed Nov  7 16:47:29 2012
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 07 Nov 2012 10:47:29 -0500
Subject: "known in advance" public key authentication?
In-Reply-To: <1352300785.3674.20.camel@gmdev.webwayone.co.uk>
References: <864nl1iito.fsf@gray.siamics.net>
	<1352300785.3674.20.camel@gmdev.webwayone.co.uk>
Message-ID: <509A8291.9080502@fifthhorseman.net>

On 11/07/2012 10:06 AM, Graham Murray wrote:
> On Wed, 2012-11-07 at 14:33 +0000, Ivan Shmakov wrote:
>> 	For my application, I need to establish a secure communication
>> 	between two peers, and as it seems, TLS is a perfect fit for
>> 	that.
>>
>> 	A feature of this application is that the public keys of the
>> 	peers are effectively ?known in advance?, so, while self-signed
>> 	(unsigned?) X.509 certificates (or some OpenPGP ones) could be
>> 	employed, there's no practical benefit from CC/WoT verification.
>>
>> 	Hence, the question is: is there a way to specify the local key
>> 	pair and the remote public key to GnuTLS ?directly?, just prior
>> 	to connecting the remote?
> 
> Would PSK not do what you want?

PSK is not public key authentication, since the keys are shared.

I think the OP may want to avoid calling
gnutls_certificate_verify_peers2, and write their own function to be
passed to gnutls_certificate_set_verify_function that just compares the
certificate received against a local file.

https://www.gnu.org/software/gnutls/manual/html_node/Certificate-credentials.html

Alternately (for a bit more flexibility in re-keying, should that come
up, at the cost of extra administrative overhead), the OP could run
their own X.509 or OpenPGP signing authority; then ship that signing
authority with both peers, and use it to sign the certificates of either
peer.

	--dkg

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

From oneingray at gmail.com  Wed Nov  7 16:49:48 2012
From: oneingray at gmail.com (Ivan Shmakov)
Date: Wed, 07 Nov 2012 22:49:48 +0700
Subject: "known in advance" public key authentication?
References: <864nl1iito.fsf@gray.siamics.net>
	<1352300785.3674.20.camel@gmdev.webwayone.co.uk>
Message-ID: <86vcdhh0pv.fsf@gray.siamics.net>

>>>>> Graham Murray <GMurray at webwayone.co.uk> writes:
>>>>> On Wed, 2012-11-07 at 14:33 +0000, Ivan Shmakov wrote:

[?]

 >> A feature of this application is that the public keys of the peers
 >> are effectively ?known in advance?, so, while self-signed
 >> (unsigned?) X.509 certificates (or some OpenPGP ones) could be
 >> employed, there's no practical benefit from CC/WoT verification.

 >> Hence, the question is: is there a way to specify the local key pair
 >> and the remote public key to GnuTLS ?directly?, just prior to
 >> connecting the remote?

 > Would PSK not do what you want?

	Unfortunately, no.  The keys are known in advance precisely
	because they're public.

-- 
FSF associate member #7257




From oneingray at gmail.com  Wed Nov  7 17:32:27 2012
From: oneingray at gmail.com (Ivan Shmakov)
Date: Wed, 07 Nov 2012 23:32:27 +0700
Subject: "known in advance" public key authentication?
References: <864nl1iito.fsf@gray.siamics.net>
	<1352300785.3674.20.camel@gmdev.webwayone.co.uk>
	<509A8291.9080502@fifthhorseman.net>
Message-ID: <86obj9gyqs.fsf@gray.siamics.net>

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

[?]

 > I think the OP may want to avoid calling
 > gnutls_certificate_verify_peers2, and write their own function to be
 > passed to gnutls_certificate_set_verify_function that just compares
 > the certificate received against a local file.

	The problem is that I'd need to either pass around an otherwise
	superfluous X.509 (private key, certificate) file, or to create
	it when a connection is to be established.

 > https://www.gnu.org/software/gnutls/manual/html_node/Certificate-credentials.html

 > Alternately (for a bit more flexibility in re-keying, should that
 > come up, at the cost of extra administrative overhead), the OP could
 > run their own X.509 or OpenPGP signing authority; then ship that
 > signing authority with both peers, and use it to sign the
 > certificates of either peer.

	To put it short, the application in question uses
	?self-certified identifiers?; i. e., the public key /is/ the
	identifier of the peer.  Thus, there doesn't seem to be any
	reason whatsoever to sign the public keys used, and both X.509
	and OpenPGP hence become of little use.

-- 
FSF associate member #7257




From dkg at fifthhorseman.net  Wed Nov  7 18:11:14 2012
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 07 Nov 2012 12:11:14 -0500
Subject: "known in advance" public key authentication?
In-Reply-To: <86obj9gyqs.fsf@gray.siamics.net>
References: <864nl1iito.fsf@gray.siamics.net>
	<1352300785.3674.20.camel@gmdev.webwayone.co.uk>
	<509A8291.9080502@fifthhorseman.net>
	<86obj9gyqs.fsf@gray.siamics.net>
Message-ID: <509A9632.4070005@fifthhorseman.net>

On 11/07/2012 11:32 AM, Ivan Shmakov wrote:
> 	To put it short, the application in question uses
> 	?self-certified identifiers?; i. e., the public key /is/ the
> 	identifier of the peer.  Thus, there doesn't seem to be any
> 	reason whatsoever to sign the public keys used, and both X.509
> 	and OpenPGP hence become of little use.

yes, understood.  Given the ubiquity of these certificate formats, the
simplest thing for you to do with your application is to treat the
certificate format as a (bulky, overcomplicated) container format for
your public key material.

Self-signed certificates (or even un-signed certificates with a bogus
signing mechanism) are perfectly capable of transporting public key
material.

	--dkg

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

From nmav at gnutls.org  Wed Nov  7 18:52:51 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 07 Nov 2012 18:52:51 +0100
Subject: "known in advance" public key authentication?
In-Reply-To: <86obj9gyqs.fsf@gray.siamics.net>
References: <864nl1iito.fsf@gray.siamics.net>
	<1352300785.3674.20.camel@gmdev.webwayone.co.uk>
	<509A8291.9080502@fifthhorseman.net>
	<86obj9gyqs.fsf@gray.siamics.net>
Message-ID: <509A9FF3.5080609@gnutls.org>

On 11/07/2012 05:32 PM, Ivan Shmakov wrote:


>  > Alternately (for a bit more flexibility in re-keying, should that
>  > come up, at the cost of extra administrative overhead), the OP could
>  > run their own X.509 or OpenPGP signing authority; then ship that
>  > signing authority with both peers, and use it to sign the
>  > certificates of either peer.
> 
> 	To put it short, the application in question uses
> 	?self-certified identifiers?; i. e., the public key /is/ the
> 	identifier of the peer.  Thus, there doesn't seem to be any
> 	reason whatsoever to sign the public keys used, and both X.509
> 	and OpenPGP hence become of little use.

Currently you cannot avoid using a container for the public keys, either
X.509 or Openpgp. You may completely ignore it after that and only
compare the raw keys, or their identifiers e.g. with by using one of the
_get_key_id() functions.

regards,
Nikos



From fw at deneb.enyo.de  Wed Nov  7 22:52:33 2012
From: fw at deneb.enyo.de (Florian Weimer)
Date: Wed, 07 Nov 2012 22:52:33 +0100
Subject: "known in advance" public key authentication?
In-Reply-To: <864nl1iito.fsf@gray.siamics.net> (Ivan Shmakov's message of
	"Wed, 07 Nov 2012 21:33:23 +0700")
References: <864nl1iito.fsf@gray.siamics.net>
Message-ID: <87k3txhyhq.fsf@mid.deneb.enyo.de>

* Ivan Shmakov:

> 	Hence, the question is: is there a way to specify the local key
> 	pair and the remote public key to GnuTLS ?directly?, just prior
> 	to connecting the remote?

I recommend to use self-signed X.509 certificates, this way you can
port your software to other crypto libraries.  It is possible to
override the certificate verification function and replace the
PKI-based verificiation with something that performs a database
lookup, for instance.  You can use the subject DN or a hash to look up
the certificate in the database, and perform a bit-wise comparison
between the peer certificate and what is found in the database.

Make sure your certificates are valid X.509v3.  GNUTLS is extremely
forgiving, and if you've got a widely deployed certificate which
cannot be used with Java (for instance), this can be annoying.



From n.mavrogiannopoulos at gmail.com  Wed Nov  7 23:31:54 2012
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 07 Nov 2012 23:31:54 +0100
Subject: "known in advance" public key authentication?
In-Reply-To: <87k3txhyhq.fsf@mid.deneb.enyo.de>
References: <864nl1iito.fsf@gray.siamics.net>
	<87k3txhyhq.fsf@mid.deneb.enyo.de>
Message-ID: <509AE15A.3040608@gmail.com>

On 11/07/2012 10:52 PM, Florian Weimer wrote:


> Make sure your certificates are valid X.509v3.  GNUTLS is extremely
> forgiving, and if you've got a widely deployed certificate which
> cannot be used with Java (for instance), this can be annoying.


What do you mean by valid X.509v3? I suppose even the authors of X.509
wouldn't even know what that means :) Anything we could improve?

regards,
Nikos




From oneingray at gmail.com  Thu Nov  8 04:18:26 2012
From: oneingray at gmail.com (Ivan Shmakov)
Date: Thu, 08 Nov 2012 10:18:26 +0700
Subject: "known in advance" public key authentication?
References: <864nl1iito.fsf@gray.siamics.net>
	<87k3txhyhq.fsf@mid.deneb.enyo.de>
Message-ID: <86bof8hjel.fsf@gray.siamics.net>

>>>>> Florian Weimer <fw at deneb.enyo.de> writes:

[?]

 > Make sure your certificates are valid X.509v3.  GNUTLS is extremely
 > forgiving, and if you've got a widely deployed certificate which
 > cannot be used with Java (for instance), this can be annoying.

	Even if I'd choose to follow this path, the certificates will be
	generated ?on demand?, using the information the application has
	access to.  Should such certificates be found unsuitable for a
	particular TLS implementation, I'd only need to amend the
	generation procedure, and regenerate the offending certificates.
	(Though, indeed, that may take a good deal of time should the
	application in question become widely deployed.)

	That being said, I've got an impression that OpenPGP
	certificates and keys are much more simple to generate (from C
	code, at the least.)  Do I understand it correctly that the
	support for OpenPGP certificates isn't implemented as widely as
	that for X.509 ones?

	The other idea would be to use ?anonymous? authentication, and
	then perform a kind of a ?check? against MitM on the already
	established channel.  Is there a way to initiate a ?re-keying?
	using a caller-provided symmetric key, for instance?

	OTOH, most of the data transferred over such a channel will
	either be public (and then either self-certifying or signed) or
	already encrypted anyway.  Thus, for a start, I may forget about
	authentication altogether.  Unfortunately, some fraction of the
	data is likely to be at least mildly sensitive, and apart from
	that, an authenticated channel opens a possibility of a DoS.

-- 
FSF associate member #7257




From dkg at fifthhorseman.net  Thu Nov  8 07:44:46 2012
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 08 Nov 2012 01:44:46 -0500
Subject: "known in advance" public key authentication?
In-Reply-To: <86bof8hjel.fsf@gray.siamics.net>
References: <864nl1iito.fsf@gray.siamics.net>
	<87k3txhyhq.fsf@mid.deneb.enyo.de>
	<86bof8hjel.fsf@gray.siamics.net>
Message-ID: <509B54DE.8050102@fifthhorseman.net>

On 11/07/2012 10:18 PM, Ivan Shmakov wrote:
> 	OTOH, most of the data transferred over such a channel will
> 	either be public (and then either self-certifying or signed) or
> 	already encrypted anyway.  Thus, for a start, I may forget about
> 	authentication altogether.  Unfortunately, some fraction of the
> 	data is likely to be at least mildly sensitive, and apart from
> 	that, an authenticated channel opens a possibility of a DoS.

Without robust and reliable authentication of your peer, you can have no
guarantees of confidentiality.

Put another way: if you don't know who you are talking to, you cannot
have a private conversation.  You might be talking to the very person
you want to keep a secret from!

Association of a public key with a peer over an untrusted network is a
challenging problem.  Simply presenting a random public key at
connection time and expecting the other peer will automatically know
it's the right one opens your application up to a MITM attack.

You seem to be leaning in the direction of an unauthenticated
connection; while that might be sufficient against an eavesdropping-only
attacker, i advise you to reconsider.  On the internet, it's not a large
leap to go from an eavesdropper to a MITM :(

	--dkg

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

From help-gnutls-phil at spodhuis.org  Thu Nov  8 08:14:22 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Thu, 8 Nov 2012 02:14:22 -0500
Subject: WARNING: gnome-keyring ??
In-Reply-To: <CAJU7zaJFkAfBjPBmkEM6ENOM27ywE8NW_x5drZMz9SLELEDeMQ@mail.gmail.com>
References: <alpine.DEB.2.00.1211061929280.31654@tvnag.unkk.fr>
	<50996471.4010503@gnutls.org>
	<alpine.DEB.2.00.1211062219150.31654@tvnag.unkk.fr>
	<CAJU7zaJFkAfBjPBmkEM6ENOM27ywE8NW_x5drZMz9SLELEDeMQ@mail.gmail.com>
Message-ID: <20121108071422.GA19260@redoubt.spodhuis.org>

On 2012-11-07 at 10:10 +0100, Nikos Mavrogiannopoulos wrote:
> The warning on stderr shouldn't have been there. A module that is
> being loaded should either succeed loading or fail with a return code.
> However this is not under my control to suppress. The PKCS #11 support
> (this is about smart cards) is transparent and system wide because we
> want all applications that use gnutls to be able to use smart cards
> transparently (e.g. you can load your private key from a smart card
> the same way you'd load it from a file).

This doesn't make sense in all cases; for system daemons, mostly not,
and Exim does TLS init at start-up, to validate the config.  So we got
user complaints when I released 4.80 in May with my changes to overhaul
the GnuTLS integration.  I wrote the fix below a few months back and it
will be part of 4.82 (whenever that's released).  Perhaps this approach
is of use to others?

I introduced an Exim config option "gnutls_enable_pkcs11" which defaults
false.  Then the code in the GnuTLS binding has:

----------------------------8< cut here >8------------------------------
#ifdef HAVE_GNUTLS_PKCS11
  /* By default, gnutls_global_init will init PKCS11 support in auto mode,
  which loads modules from a config file, which sounds good and may be wanted
  by some sysadmin, but also means in common configurations that GNOME keyring
  environment variables are used and so breaks for users calling mailq.
  To prevent this, we init PKCS11 first, which is the documented approach. */
  if (!gnutls_enable_pkcs11)
    {
    rc = gnutls_pkcs11_init(GNUTLS_PKCS11_FLAG_MANUAL, NULL);
    exim_gnutls_err_check(US"gnutls_pkcs11_init");
    }
#endif
----------------------------8< cut here >8------------------------------

exim_gnutls_err_check() is a macro checking rc against GNUTLS_E_SUCCESS.

If memory serves, this was well documented by GnuTLS; I just hadn't
known of the interaction of environment variables with GUI-drivers for
some modules.

If we ever have Exim daemons which need pkcs11 support and folks still
want to run mailq with GNOME_* environment variables set, I may have to
start inhibiting the start-up TLS check for some cases.



From nmav at gnutls.org  Thu Nov  8 10:41:21 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 8 Nov 2012 10:41:21 +0100
Subject: WARNING: gnome-keyring ??
In-Reply-To: <20121108071422.GA19260@redoubt.spodhuis.org>
References: <alpine.DEB.2.00.1211061929280.31654@tvnag.unkk.fr>
	<50996471.4010503@gnutls.org>
	<alpine.DEB.2.00.1211062219150.31654@tvnag.unkk.fr>
	<CAJU7zaJFkAfBjPBmkEM6ENOM27ywE8NW_x5drZMz9SLELEDeMQ@mail.gmail.com>
	<20121108071422.GA19260@redoubt.spodhuis.org>
Message-ID: <CAJU7zaJNcDovoCu6J5yuXdN+qq1UYbALaHBoopZhQyVdzu_Ubw@mail.gmail.com>

On Thu, Nov 8, 2012 at 8:14 AM, Phil Pennock
<help-gnutls-phil at spodhuis.org> wrote:

>> (this is about smart cards) is transparent and system wide because we
>> want all applications that use gnutls to be able to use smart cards
>> transparently (e.g. you can load your private key from a smart card
>> the same way you'd load it from a file).
> This doesn't make sense in all cases; for system daemons, mostly not,
> and Exim does TLS init at start-up, to validate the config.

Well a system daemon may use a hardware security module (HSM) to speed
up, e.g., RSA and protect its keys, so it still makes sense there
(smart cards and HSMs are both accessed via the PKCS #11 API).

> So we got
> user complaints when I released 4.80 in May with my changes to overhaul
> the GnuTLS integration.  I wrote the fix below a few months back and it
> will be part of 4.82 (whenever that's released).  Perhaps this approach
> is of use to others?
...
> If we ever have Exim daemons which need pkcs11 support and folks still
> want to run mailq with GNOME_* environment variables set, I may have to
> start inhibiting the start-up TLS check for some cases.

The approach seems correct to disable PKCS #11. I should also document
it if it is not already there. However, were the requests to disable
PKCS #11 due to the messages being printed by gnome-keyring, or
because of some other reason?

If it is the former could the gnome-keyring module be more silent on
failures and print messages only if some debugging environment
variable is present?

regards,
Nikos



From stefw at gnome.org  Thu Nov  8 12:31:27 2012
From: stefw at gnome.org (Stef Walter)
Date: Thu, 08 Nov 2012 12:31:27 +0100
Subject: WARNING: gnome-keyring ??
In-Reply-To: <CAJU7zaJNcDovoCu6J5yuXdN+qq1UYbALaHBoopZhQyVdzu_Ubw@mail.gmail.com>
References: <alpine.DEB.2.00.1211061929280.31654@tvnag.unkk.fr>
	<50996471.4010503@gnutls.org>
	<alpine.DEB.2.00.1211062219150.31654@tvnag.unkk.fr>
	<CAJU7zaJFkAfBjPBmkEM6ENOM27ywE8NW_x5drZMz9SLELEDeMQ@mail.gmail.com>
	<20121108071422.GA19260@redoubt.spodhuis.org>
	<CAJU7zaJNcDovoCu6J5yuXdN+qq1UYbALaHBoopZhQyVdzu_Ubw@mail.gmail.com>
Message-ID: <509B980F.3060605@gnome.org>

On 11/08/2012 10:41 AM, Nikos Mavrogiannopoulos wrote:
> The approach seems correct to disable PKCS #11. I should also document
> it if it is not already there. However, were the requests to disable
> PKCS #11 due to the messages being printed by gnome-keyring, or
> because of some other reason?

FWIW, It is also possible to only enable PKCS#11 in certain applications
via the p11-kit configuration:

http://p11-glue.freedesktop.org/doc/p11-kit/config-module.html

This can be done either globally by the admin of a system or for a
specific user.

> If it is the former could the gnome-keyring module be more silent on
> failures and print messages only if some debugging environment
> variable is present?

Yes, that's what this committed fix accomplishes:

https://bugzilla.gnome.org/show_bug.cgi?id=665961

No messages are printed if the daemon cannot be connected to. If a debug
environment variable is set, then the messages are printed.

If the (begnign, but misleading) warnings are too bothersome, you could
try out the patch and comment on the bug? That would help distros know
how tested the patch is, and whether to backport it.

Cheers,

Stef



From nmav at gnutls.org  Thu Nov  8 22:57:25 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 08 Nov 2012 22:57:25 +0100
Subject: gnutls + openpgp
In-Reply-To: <5099C838.2050108@funwithsoftware.org>
References: <50956FE9.60203@gnutls.org> <5099C838.2050108@funwithsoftware.org>
Message-ID: <509C2AC5.1050904@gnutls.org>

On 11/07/2012 03:32 AM, Patrick Pelletier wrote:

> On 11/3/12 12:26 PM, Nikos Mavrogiannopoulos wrote:
> 
>> And even more, if it is shown they are not widely used, does it make
>> sense to support openpgp keys in gnutls at all?
> 
> FWIW, I noticed that the hs-tls folks have expressed some interest in
> OpenPGP, although admittedly there's been no further activity in 7 months:
> 
> https://github.com/vincenthz/hs-tls/issues/10
> 
> But still, it might be worthwhile to touch base with those guys.  It
> would be somewhat ironic if GnuTLS dropped support for OpenPGP at the
> same time hs-tls was adding support.


Hello Patrick,
 Even if this code will be removed at some point this will not be
anytime soon. If it proves that there no users at all then it will be
marked as deprecated and stay in the code as a second class citizen (no
new features being added) until the next ABI break.

regards,
Nikos



From nmav at gnutls.org  Thu Nov  8 23:56:30 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 08 Nov 2012 23:56:30 +0100
Subject: gnutls 2.12.21
Message-ID: <509C389E.8000901@gnutls.org>

Hello,
 I've just released gnutls 2.12.21. It includes few bug fixes in the old
stable branch.

Version 2.12.21 (released 2012-11-08)

** libgnutls: Backported patch to compile with libtasn1 3.0.
Minimum libtasn1 dependency is now 2.14.

** libgnutls: Always tolerate key usage violation errors from the side
of the peer, but also notify via an audit message.

** minitasn1: Upgraded to libtasn1 version 3.0.

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


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

GnuTLS may be downloaded from one of the GNU mirror sites or directly
>From <ftp://ftp.gnu.org/gnu/gnutls/?.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.21.tar.bz2.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos



From nmav at gnutls.org  Fri Nov  9 00:41:30 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 09 Nov 2012 00:41:30 +0100
Subject: gnutls 3.0.26
Message-ID: <509C432A.7080008@gnutls.org>

Hello,
 I've just released gnutls 3.0.26. This is a bug-fix release on the
previous stable branch.

* Version 3.0.26 (released 2012-11-09)

** libgnutls: Always tolerate key usage violation errors from the side
of the peer, but also notify via an audit message.

** libgnutls: gnutls_x509_crl_verify() includes time checks.

** libgnutls: Increased maximum password length in the PKCS #12
functions.

** API and ABI modifications:
GNUTLS_CERT_REVOCATION_DATA_TOO_OLD: Added
GNUTLS_CERT_REVOCATION_DATA_ISSUED_IN_FUTURE: Added



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

GnuTLS may be downloaded from one of the GNU mirror sites or directly
>From <ftp://ftp.gnu.org/gnu/gnutls/>.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the XZ compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.xz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.xz

Here are the LZIP compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.lz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.xz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.xz.sig

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.lz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.26.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos



From help-gnutls-phil at spodhuis.org  Sat Nov 10 00:50:57 2012
From: help-gnutls-phil at spodhuis.org (Phil Pennock)
Date: Fri, 9 Nov 2012 18:50:57 -0500
Subject: WARNING: gnome-keyring ??
In-Reply-To: <CAJU7zaJNcDovoCu6J5yuXdN+qq1UYbALaHBoopZhQyVdzu_Ubw@mail.gmail.com>
References: <alpine.DEB.2.00.1211061929280.31654@tvnag.unkk.fr>
	<50996471.4010503@gnutls.org>
	<alpine.DEB.2.00.1211062219150.31654@tvnag.unkk.fr>
	<CAJU7zaJFkAfBjPBmkEM6ENOM27ywE8NW_x5drZMz9SLELEDeMQ@mail.gmail.com>
	<20121108071422.GA19260@redoubt.spodhuis.org>
	<CAJU7zaJNcDovoCu6J5yuXdN+qq1UYbALaHBoopZhQyVdzu_Ubw@mail.gmail.com>
Message-ID: <20121109235056.GA44142@redoubt.spodhuis.org>

On 2012-11-08 at 10:41 +0100, Nikos Mavrogiannopoulos wrote:
> Well a system daemon may use a hardware security module (HSM) to speed
> up, e.g., RSA and protect its keys, so it still makes sense there
> (smart cards and HSMs are both accessed via the PKCS #11 API).

True.  In this case, the use of the same binary as the daemon and the
interrogator, so that it _could_ be called by users, combined with
initialising TLS support at start-up, is the issue.

> The approach seems correct to disable PKCS #11. I should also document
> it if it is not already there. However, were the requests to disable
> PKCS #11 due to the messages being printed by gnome-keyring, or
> because of some other reason?

Gnome support.

In practice, most MTAs today will not be keeping keys in HSMs simply
because they're too low value, without a means to verify host identity
when connecting on MX.  I hope that the DANE work and Tony Finch's draft
for how to use that with mail/MX will change things.

> If it is the former could the gnome-keyring module be more silent on
> failures and print messages only if some debugging environment
> variable is present?

Ideally.  However, mail server operators often keep up-to-date on the
mail server software, so that they can react to security issues and get
new features, while keeping the base OS unchanged.  It will take years
for the current gnome keyring modules to drop out of systems so that we
can even consider switching the default.

-Phil



From nmav at gnutls.org  Sat Nov 10 01:05:58 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 10 Nov 2012 01:05:58 +0100
Subject: gnutls 3.1.4
Message-ID: <509D9A66.3010404@gnutls.org>

Hello,
 I've just released gnutls 3.1.4. This release includes initial support
for the DTLS-SRTP protocol contributed by martin Storsjo updated on the
new DANE library, and several simplifications on the existing API.

* Version 3.1.4 (released 2012-11-10)

** libgnutls: gnutls_certificate_verify_peers2() will set flags
depending on the available revocation data validity.

** libgnutls: Added gnutls_certificate_verification_status_print(), a
function to print the verification status code in human readable text.

** libgnutls: Added priority string %VERIFY_DISABLE_CRL_CHECKS.

** libgnutls: Simplified certificate verification by adding
gnutls_certificate_verify_peers3().

** libgnutls: Added support for extension to establish keys for SRTP.
Contributed by Martin Storsjo.

** libgnutls: The X.509 verification functions check the key
usage bits and pathlen constraints and on failure output
GNUTLS_CERT_SIGNER_CONSTRAINTS_FAILURE.

** libgnutls: gnutls_x509_crl_verify() includes the time checks.

** libgnutls: Added verification flag
GNUTLS_VERIFY_DO_NOT_ALLOW_UNSORTED_CHAIN and made
GNUTLS_VERIFY_ALLOW_UNSORTED_CHAIN the default.

** libgnutls: Always tolerate key usage violation errors from the side
of the peer, but also notify via an audit message.

** gnutls-cli: Added --local-dns option.

** danetool: Corrected bug that prevented loading PEM files.

** danetool: Added --check option to allow querying and verifying a
site's DANE data.

** libgnutls-dane: Added pkg-config file for the library.

** API and ABI modifications:
gnutls_session_get_id2: Added
gnutls_sign_is_secure: Added
gnutls_certificate_verify_peers3: Added
gnutls_ocsp_status_request_is_checked: Added
gnutls_certificate_verification_status_print: Added
gnutls_srtp_set_profile: Added
gnutls_srtp_set_profile_direct: Added
gnutls_srtp_get_selected_profile: Added
gnutls_srtp_get_profile_name: Added
gnutls_srtp_get_profile_id: Added
gnutls_srtp_get_keys: Added
gnutls_srtp_get_mki: Added
gnutls_srtp_set_mki: Added
gnutls_srtp_profile_t: Added
dane_cert_type_name: Added
dane_match_type_name: Added
dane_cert_usage_name: Added
dane_verification_status_print: Added
GNUTLS_CERT_REVOCATION_DATA_SUPERSEDED: Added
GNUTLS_CERT_REVOCATION_DATA_ISSUED_IN_FUTURE: Added
GNUTLS_CERT_SIGNER_CONSTRAINTS_FAILURE: Added
GNUTLS_CERT_UNEXPECTED_OWNER: Added
GNUTLS_VERIFY_DO_NOT_ALLOW_UNSORTED_CHAIN: Added


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

GnuTLS may be downloaded from one of the GNU mirror sites or directly
>From <ftp://ftp.gnu.org/gnu/gnutls/>.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the XZ compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.xz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.xz

Here are the LZIP compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.lz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.xz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.xz.sig

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.lz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.4.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos



From nyc4bos at aol.com  Sat Nov 10 00:24:39 2012
From: nyc4bos at aol.com (nyc4bos at aol.com)
Date: Fri, 09 Nov 2012 18:24:39 -0500
Subject: gnutls 3.0.26
References: <509C432A.7080008@gnutls.org>
Message-ID: <84fw4iqs08.fsf@aol.com>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Hello,
>  I've just released gnutls 3.0.26. This is a bug-fix release on the
> previous stable branch.

Is there a precompiled binary Windows version of GnuTLS 3.0.26 available?

The last version of 3.0.x I see on ftp://ftp.gnu.org/gnu/gnutls/w32/
is 3.0.22

Thanks.




From nmav at gnutls.org  Sat Nov 10 11:23:56 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 10 Nov 2012 11:23:56 +0100
Subject: gnutls 3.0.26
In-Reply-To: <84fw4iqs08.fsf@aol.com>
References: <509C432A.7080008@gnutls.org> <84fw4iqs08.fsf@aol.com>
Message-ID: <509E2B3C.6060608@gnutls.org>

On 11/10/2012 12:24 AM, nyc4bos at aol.com wrote:


>> Hello,
>>  I've just released gnutls 3.0.26. This is a bug-fix release on the
>> previous stable branch.
> 
> Is there a precompiled binary Windows version of GnuTLS 3.0.26 available?


No but you can use 3.1.4. They are binary and source compatible.

 

regards,
Nikos



From oneingray at gmail.com  Sun Nov 11 15:59:34 2012
From: oneingray at gmail.com (Ivan Shmakov)
Date: Sun, 11 Nov 2012 21:59:34 +0700
Subject: "known in advance" public key authentication?
References: <864nl1iito.fsf@gray.siamics.net>
	<1352300785.3674.20.camel@gmdev.webwayone.co.uk>
	<509A8291.9080502@fifthhorseman.net> <86obj9gyqs.fsf@gray.siamics.net>
	<509A9FF3.5080609@gnutls.org>
Message-ID: <86d2zkdw2x.fsf@gray.siamics.net>

>>>>> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
>>>>> On 11/07/2012 05:32 PM, Ivan Shmakov wrote:

[?]

 >> To put it short, the application in question uses ?self-certified
 >> identifiers?; i. e., the public key /is/ the identifier of the peer.
 >> Thus, there doesn't seem to be any reason whatsoever to sign the
 >> public keys used, and both X.509 and OpenPGP hence become of little
 >> use.

 > Currently you cannot avoid using a container for the public keys,
 > either X.509 or Openpgp.

	Do I understand it correctly that it's a requirement of the TLS
	protocol itself?

	As for the implementation, gnutls_certificate_set_x509_key ()
	assumes that at least one certificate is available, and, AIUI,
	GnuTLS will try to find the ?best? matching certificate
	associated with the credentials sometime later (during
	handshake?)

 > You may completely ignore it after that and only compare the raw
 > keys, or their identifiers e. g. with by using one of the
 > _get_key_id () functions.

	ACK, thanks!

	What'd be the simplest code to craft a self-signed certificate
	out of a gnutls_x509_privkey_t instance?

	I guess, it'd be something along the lines of:

  gnutls_x509_crt_t crt;
  {
    /* craft a dummy certificate */
    int ra
      = gnutls_x509_crt_init (&crt);
    assert (ra == 0);
    int rb
      = gnutls_x509_crt_set_key (crt, priv);
    assert (rb == 0);
    /* NB: doesn't accept empty strings */
    int rc
      = gnutls_x509_crt_set_dn_by_oid (crt, GNUTLS_OID_X520_COMMON_NAME,
                                       0, "Foo!", 4);
    assert (rc == 0);
    /* FIXME: what else to call? */
  }

-- 
FSF associate member #7257




From nmav at gnutls.org  Tue Nov 13 10:40:17 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 13 Nov 2012 10:40:17 +0100
Subject: "known in advance" public key authentication?
In-Reply-To: <86d2zkdw2x.fsf@gray.siamics.net>
References: <864nl1iito.fsf@gray.siamics.net>
	<1352300785.3674.20.camel@gmdev.webwayone.co.uk>
	<509A8291.9080502@fifthhorseman.net>
	<86obj9gyqs.fsf@gray.siamics.net> <509A9FF3.5080609@gnutls.org>
	<86d2zkdw2x.fsf@gray.siamics.net>
Message-ID: <CAJU7zaKb9mN7+zrGrbHfd3HxxyR7bKB04pjSQLA47mkXFtnmjg@mail.gmail.com>

On Sun, Nov 11, 2012 at 3:59 PM, Ivan Shmakov <oneingray at gmail.com> wrote:

>  > Currently you cannot avoid using a container for the public keys,
>  > either X.509 or Openpgp.
>         Do I understand it correctly that it's a requirement of the TLS
>         protocol itself?

Yes.

>         As for the implementation, gnutls_certificate_set_x509_key ()
>         assumes that at least one certificate is available, and, AIUI,
>         GnuTLS will try to find the ?best? matching certificate
>         associated with the credentials sometime later (during
>         handshake?)

Best matching means that it matches the algorithms requested by the
peer. Typically RSA certificates work with everyone.

>         I guess, it'd be something along the lines of:
>   gnutls_x509_crt_t crt;
>   {
>     /* craft a dummy certificate */
>     int ra
>       = gnutls_x509_crt_init (&crt);
>     assert (ra == 0);
>     int rb
>       = gnutls_x509_crt_set_key (crt, priv);
>     assert (rb == 0);
>     /* NB: doesn't accept empty strings */
>     int rc
>       = gnutls_x509_crt_set_dn_by_oid (crt, GNUTLS_OID_X520_COMMON_NAME,

You'll have to sign it using gnutls_x509_crt_privkey_sign(). It is
better the check the certtool source for other possible options.

regards,
Nikos



From oneingray at gmail.com  Tue Nov 13 21:01:31 2012
From: oneingray at gmail.com (Ivan Shmakov)
Date: Wed, 14 Nov 2012 03:01:31 +0700
Subject: "known in advance" public key authentication?
References: <864nl1iito.fsf@gray.siamics.net>
	<1352300785.3674.20.camel@gmdev.webwayone.co.uk>
	<509A8291.9080502@fifthhorseman.net> <86obj9gyqs.fsf@gray.siamics.net>
	<509A9FF3.5080609@gnutls.org> <86d2zkdw2x.fsf@gray.siamics.net>
	<CAJU7zaKb9mN7+zrGrbHfd3HxxyR7bKB04pjSQLA47mkXFtnmjg@mail.gmail.com>
Message-ID: <86a9ulb7c4.fsf@gray.siamics.net>

>>>>> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

[?]

 > You'll have to sign it using gnutls_x509_crt_privkey_sign ().  It is
 > better the check the certtool source for other possible options.

	ACK, thanks.

	So, I've ended up with the code MIME'd.  Then, however,
	gnutls_handshake () fails with GNUTLS_E_PK_SIG_VERIFY_FAILED.
	Do I understand it correctly that such an error points to some
	bug in the certificate signing part?

-- 
FSF associate member #7257	np. emphutured.mod
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-csrc
Size: 1229 bytes
Desc: not available
URL: </pipermail/attachments/20121114/bf5a1702/attachment.c>

From bortzmeyer at nic.fr  Wed Nov 14 09:23:29 2012
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Wed, 14 Nov 2012 09:23:29 +0100
Subject: No longer a Web site at gnutls.org?
Message-ID: <20121114082329.GA1350@nic.fr>

Is it normal that <http://gnutls.org/> no longer displays a proper
Web page but a parking warning instead?



From latze at angry-red-pla.net  Wed Nov 14 09:41:46 2012
From: latze at angry-red-pla.net (Carolin Latze)
Date: Wed, 14 Nov 2012 09:41:46 +0100
Subject: No longer a Web site at gnutls.org?
Message-ID: <ovk32wjneodq82w507rxc20h.1352882473621@email.android.com>

I discovered the same. Www.gnutls.org works though

Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:

>Is it normal that <http://gnutls.org/> no longer displays a proper
>Web page but a parking warning instead?
>
>_______________________________________________
>Help-gnutls mailing list
>Help-gnutls at gnu.org
>https://lists.gnu.org/mailman/listinfo/help-gnutls

From nmav at gnutls.org  Wed Nov 14 11:04:23 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 14 Nov 2012 11:04:23 +0100
Subject: No longer a Web site at gnutls.org?
In-Reply-To: <20121114082329.GA1350@nic.fr>
References: <20121114082329.GA1350@nic.fr>
Message-ID: <CAJU7za+3LFOSAR2mzRqczMD28WQRK+sPvJO+2c1fnVTV1i-oxA@mail.gmail.com>

On Wed, Nov 14, 2012 at 9:23 AM, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
> Is it normal that <http://gnutls.org/> no longer displays a proper
> Web page but a parking warning instead?

Didn't know that. I'll check it this evening.

Thanks.



From nmav at gnutls.org  Wed Nov 14 18:17:45 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 14 Nov 2012 18:17:45 +0100
Subject: "known in advance" public key authentication?
In-Reply-To: <86a9ulb7c4.fsf@gray.siamics.net>
References: <864nl1iito.fsf@gray.siamics.net>
	<1352300785.3674.20.camel@gmdev.webwayone.co.uk>
	<509A8291.9080502@fifthhorseman.net>
	<86obj9gyqs.fsf@gray.siamics.net> <509A9FF3.5080609@gnutls.org>
	<86d2zkdw2x.fsf@gray.siamics.net>
	<CAJU7zaKb9mN7+zrGrbHfd3HxxyR7bKB04pjSQLA47mkXFtnmjg@mail.gmail.com>
	<86a9ulb7c4.fsf@gray.siamics.net>
Message-ID: <50A3D239.3070801@gnutls.org>

On 11/13/2012 09:01 PM, Ivan Shmakov wrote:

>>>>>> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
> 
> [?]
> 
>  > You'll have to sign it using gnutls_x509_crt_privkey_sign ().  It is
>  > better the check the certtool source for other possible options.
> 
> 	ACK, thanks.
> 
> 	So, I've ended up with the code MIME'd.  Then, however,
> 	gnutls_handshake () fails with GNUTLS_E_PK_SIG_VERIFY_FAILED.
> 	Do I understand it correctly that such an error points to some
> 	bug in the certificate signing part?


It means that the TLS signature in the session cannot be verified using
the provided certificate. Could it be a mismatch between your
certificate and the private key? Did you try with certtool generated
certificates? I'd suggest to increase verbosity in order to find out
what is the actual reason of failure.

regards,
Nikos



From fw at deneb.enyo.de  Thu Nov 15 22:12:57 2012
From: fw at deneb.enyo.de (Florian Weimer)
Date: Thu, 15 Nov 2012 22:12:57 +0100
Subject: "known in advance" public key authentication?
In-Reply-To: <509AE15A.3040608@gmail.com> (Nikos Mavrogiannopoulos's message
	of "Wed, 07 Nov 2012 23:31:54 +0100")
References: <864nl1iito.fsf@gray.siamics.net>
	<87k3txhyhq.fsf@mid.deneb.enyo.de> <509AE15A.3040608@gmail.com>
Message-ID: <87mwyi4lk6.fsf@mid.deneb.enyo.de>

* Nikos Mavrogiannopoulos:

> On 11/07/2012 10:52 PM, Florian Weimer wrote:
>
>
>> Make sure your certificates are valid X.509v3.  GNUTLS is extremely
>> forgiving, and if you've got a widely deployed certificate which
>> cannot be used with Java (for instance), this can be annoying.

> What do you mean by valid X.509v3? I suppose even the authors of X.509
> wouldn't even know what that means :) Anything we could improve?

I managed to create a version 1 certificate with extensions. 8-/



From n.mavrogiannopoulos at gmail.com  Sun Nov 18 20:28:37 2012
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sun, 18 Nov 2012 20:28:37 +0100
Subject: "known in advance" public key authentication?
In-Reply-To: <87mwyi4lk6.fsf@mid.deneb.enyo.de>
References: <864nl1iito.fsf@gray.siamics.net>
	<87k3txhyhq.fsf@mid.deneb.enyo.de> <509AE15A.3040608@gmail.com>
	<87mwyi4lk6.fsf@mid.deneb.enyo.de>
Message-ID: <50A936E5.8060300@gmail.com>

On 11/15/2012 10:12 PM, Florian Weimer wrote:

> * Nikos Mavrogiannopoulos:
> 
>> On 11/07/2012 10:52 PM, Florian Weimer wrote:
>>
>>
>>> Make sure your certificates are valid X.509v3.  GNUTLS is extremely
>>> forgiving, and if you've got a widely deployed certificate which
>>> cannot be used with Java (for instance), this can be annoying.
> 
>> What do you mean by valid X.509v3? I suppose even the authors of X.509
>> wouldn't even know what that means :) Anything we could improve?
> 
> I managed to create a version 1 certificate with extensions. 8-/


Was that using certtool or by the API? If it is the former then it is
indeed a bug, but for the latter I don't know if it's worth the
complexity of the checks.

regards,
Nikos




From fw at deneb.enyo.de  Sun Nov 18 20:53:23 2012
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 18 Nov 2012 20:53:23 +0100
Subject: "known in advance" public key authentication?
In-Reply-To: <50A936E5.8060300@gmail.com> (Nikos Mavrogiannopoulos's message
	of "Sun, 18 Nov 2012 20:28:37 +0100")
References: <864nl1iito.fsf@gray.siamics.net>
	<87k3txhyhq.fsf@mid.deneb.enyo.de> <509AE15A.3040608@gmail.com>
	<87mwyi4lk6.fsf@mid.deneb.enyo.de> <50A936E5.8060300@gmail.com>
Message-ID: <87haomd6x8.fsf@mid.deneb.enyo.de>

* Nikos Mavrogiannopoulos:

>>> What do you mean by valid X.509v3? I suppose even the authors of X.509
>>> wouldn't even know what that means :) Anything we could improve?
>> 
>> I managed to create a version 1 certificate with extensions. 8-/

> Was that using certtool or by the API? If it is the former then it is
> indeed a bug, but for the latter I don't know if it's worth the
> complexity of the checks.

No, it was using the APIs.

It might sense to add a best-effort certificate sanity checking
function, with explicit warning that future versions might impose
tighter checks.  I have to think about it.



From rich at kde.org  Sun Nov 18 21:37:27 2012
From: rich at kde.org (Richard Moore)
Date: Sun, 18 Nov 2012 20:37:27 +0000
Subject: Example of creating certificate from code using gnutls
Message-ID: <CAMp7mVsZXLm-z3CGm-kPLgaiDS-DW9Urods7MfmjdS+T+6G=eQ@mail.gmail.com>

Hi All,

I've continued my experiments with gnutls and have now got code for
creating certificate signing requests and creating self-signed
certificates. The latter especially is missing from the documentation,
so hopefully it will be useful to people. One bug that had me
scratching my head for a while was a missing extern "C" in the
abstract.h header, but from the git logs it appears that has been
addressed in newer releases.

Creating a CSR:
https://gitorious.org/qt-examples/qt-examples/trees/master/gnutls-experiments/create-request

Creating and signing a self-signed cert:
https://gitorious.org/qt-examples/qt-examples/trees/master/gnutls-experiments/create-certificate

Cheers

Rich.



From oneingray at gmail.com  Mon Nov 19 08:09:21 2012
From: oneingray at gmail.com (Ivan Shmakov)
Date: Mon, 19 Nov 2012 14:09:21 +0700
Subject: "known in advance" public key authentication?
References: <864nl1iito.fsf@gray.siamics.net>
	<1352300785.3674.20.camel@gmdev.webwayone.co.uk>
	<509A8291.9080502@fifthhorseman.net> <86obj9gyqs.fsf@gray.siamics.net>
	<509A9FF3.5080609@gnutls.org> <86d2zkdw2x.fsf@gray.siamics.net>
	<CAJU7zaKb9mN7+zrGrbHfd3HxxyR7bKB04pjSQLA47mkXFtnmjg@mail.gmail.com>
	<86a9ulb7c4.fsf@gray.siamics.net> <50A3D239.3070801@gnutls.org>
Message-ID: <86r4nq83xa.fsf@gray.siamics.net>

>>>>> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
>>>>> On 11/13/2012 09:01 PM, Ivan Shmakov wrote:

[?]

 >> Then, however, gnutls_handshake () fails with
 >> GNUTLS_E_PK_SIG_VERIFY_FAILED.  Do I understand it correctly that
 >> such an error points to some bug in the certificate signing part?

 > It means that the TLS signature in the session cannot be verified
 > using the provided certificate.

	ACK, thanks.

 > Could it be a mismatch between your certificate and the private key?
 > Did you try with certtool generated certificates?

	I did it the other way around: added a gnutls_x509_crt_export ()
	call to my code, and investigated the result with certtool(1).

 > I'd suggest to increase verbosity in order to find out what is the
 > actual reason of failure.

	The problem was that I've embedded the key pairs into the code
	roughly as follows:

   char x[]
     = ("\x1337\xcafe" ...);

	Somewhat surprisingly, the compiler interpreted that as:

   char x[]
     = { 0x1337, 0xcafe, ... };     /* IOW, { 0x37, 0xfe, ... } */

	instead of the intended:

   char x[]
     = { 0x13, '3', '7', 0xca, 'f', 'e', ... };

	After I've made the code less ambiguous, the issue was no more:

$ ./cbx34kx8szoy1wgdshn99dhz4d 
We're the Client; xfd =  3
We're the Server; xfd =  4
S: gnutls_handshake () => 0 (Success.) ; 2 (No such file or directory)
C: gnutls_handshake () => 0 (Success.) ; 2 (No such file or directory)
Read     4 bytes, starting with 13 37 ffffffca fffffffe
$ 

	(The code above uses socketpair (AF_UNIX, ...) to establish a
	connection to run GnuTLS over.)

-- 
FSF associate member #7257




From nmav at gnutls.org  Mon Nov 19 09:59:00 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 19 Nov 2012 09:59:00 +0100
Subject: Example of creating certificate from code using gnutls
In-Reply-To: <CAMp7mVsZXLm-z3CGm-kPLgaiDS-DW9Urods7MfmjdS+T+6G=eQ@mail.gmail.com>
References: <CAMp7mVsZXLm-z3CGm-kPLgaiDS-DW9Urods7MfmjdS+T+6G=eQ@mail.gmail.com>
Message-ID: <CAJU7zaLBBj75hnvzZdeEr=UtYGffuc-2iMhhyP=_pHJstQ_cMQ@mail.gmail.com>

On Sun, Nov 18, 2012 at 9:37 PM, Richard Moore <rich at kde.org> wrote:
> Hi All,
> I've continued my experiments with gnutls and have now got code for
> creating certificate signing requests and creating self-signed
> certificates. The latter especially is missing from the documentation,
> so hopefully it will be useful to people.

Hello Richard,
 If you propose some additions to the documentation for that I'd be
happy to include and/or enhance them. The certificate
generation/handling in general was a bit neglected from the
documentation because it was considered an advanced use (there are
many domain-specific profiles). However, it may warrant an additional
section or so.

regards,
Nikos



From arekm at maven.pl  Sat Nov 24 09:35:53 2012
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Sat, 24 Nov 2012 09:35:53 +0100
Subject: gnutls 3.1.0 -> 3.1.4 wMNAF-based multiplication change and a
	problem
In-Reply-To: <50B07EED.4040802@gnutls.org>
References: <201211232352.50000.arekm@maven.pl> <50B07EED.4040802@gnutls.org>
Message-ID: <201211240935.53313.arekm@maven.pl>

On Saturday 24 of November 2012, Nikos Mavrogiannopoulos wrote:
> On 11/23/2012 11:52 PM, Arkadiusz Mi?kiewicz wrote:
> > Hi
> > Starting with a commit:
> > 
> > commit 45bf20ad3f799bf219958c3ba705898440c74e4a
> > Author: Ilya Tumaykin <itumaykin at gmail.com>
> > Date:   Thu Aug 30 11:36:34 2012 +0400
> > 
> >     wMNAF-based multiplication
> > 
> > php started to segfault here.
> > 
> > To reproduce here I'm using php cli program + module gmp and curl.
> > 
> > Uninstalling php gmp module and the problem is gone. My curl uses gnutls.
> > 
> > The fact that I need gmp php module to reproduce makes me wonder
> > if there is some global state (maybe in gmp) that's overwritten by
> > gnutls?
> > 
> > Any ideas/hints on what can be going on here?
> 
> Hello,
>  Could it be that the gmp module uses some conflicting gmp library
> version? (check whether you have multiple gmp libraries in your system).

There is only one gmp library in my system (and php doesn't have any bundled 
library).

Now I see that php gmp module uses:

mp_set_memory_functions(gmp_emalloc, gmp_erealloc, gmp_efree);

gmp_exxx are functions that use Zend memory management code. 

This conflicts with gnutls gmp usage. Confirmed by commenting out that line 
(so generic memory management functions are used in php gmp module) - no 
longer segfaults.

> It is better to send these questions to the ML so if anyone encounters
> the same problem would find the discussion as well.

Ok, CC help-gnutls@

> regards,
> Nikos

-- 
Arkadiusz Mi?kiewicz, arekm / maven.pl



From arekm at maven.pl  Fri Nov 23 23:52:49 2012
From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=)
Date: Fri, 23 Nov 2012 23:52:49 +0100
Subject: gnutls 3.1.0 -> 3.1.4 wMNAF-based multiplication change and a problem
Message-ID: <201211232352.50000.arekm@maven.pl>


Hi

Starting with a commit:

commit 45bf20ad3f799bf219958c3ba705898440c74e4a
Author: Ilya Tumaykin <itumaykin at gmail.com>
Date:   Thu Aug 30 11:36:34 2012 +0400

    wMNAF-based multiplication

php started to segfault here.

To reproduce here I'm using php cli program + module gmp and curl.

Uninstalling php gmp module and the problem is gone. My curl uses gnutls.

The fact that I need gmp php module to reproduce makes me wonder
if there is some global state (maybe in gmp) that's overwritten by gnutls?

Any ideas/hints on what can be going on here?

Thanks,

ps. to reproduce, php + curl php module + gmp php module. Run php cli and press ctrl+d.

Program received signal SIGSEGV, Segmentation fault.
0x00007fffea23ef20 in ?? ()
(gdb) bt
#0  0x00007fffea23ef20 in ?? ()
#1  0x00007fffeb445d3b in mp_clear_multi (a=a at entry=0xc63ed0) at multi.c:38
#2  0x00007fffeb4472ca in ecc_del_point (p=0xc63ed0) at ecc_points.c:62
#3  0x00007fffeb446972 in _ecc_wmnaf_cache_entry_free (p=<optimized out>) at ecc_mulmod_cached.c:54
#4  ecc_wmnaf_cache_free () at ecc_mulmod_cached.c:68
#5  0x00007fffeb445685 in gnutls_crypto_deinit () at init.c:44
#6  0x00007fffeb3adb71 in gnutls_global_deinit () at gnutls_global.c:305
#7  0x00007fffee0c9a79 in Curl_gtls_cleanup () at gtls.c:182
#8  0x00007fffee0ca189 in Curl_ssl_cleanup () at sslgen.c:193
#9  0x00007fffee0bbbf5 in curl_global_cleanup () at easy.c:325
#10 0x00007fffee6f9bf8 in zm_shutdown_curl () from /usr/lib64/php/curl.so
#11 0x00007ffff7a96105 in module_destructor () from /usr/lib64/libphp_common-5.3.18.so
#12 0x00007ffff7a9b4ae in ?? () from /usr/lib64/libphp_common-5.3.18.so
#13 0x00007ffff7a9cd08 in zend_hash_graceful_reverse_destroy () from /usr/lib64/libphp_common-5.3.18.so
#14 0x00007ffff7a8f175 in zend_shutdown () from /usr/lib64/libphp_common-5.3.18.so
#15 0x00007ffff7a3e01b in php_module_shutdown () from /usr/lib64/libphp_common-5.3.18.so
#16 0x0000000000403406 in main ()
(gdb)

-- 
Arkadiusz Mi?kiewicz, arekm / maven.pl



From nmav at gnutls.org  Sat Nov 24 11:03:48 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 24 Nov 2012 11:03:48 +0100
Subject: gnutls 3.1.0 -> 3.1.4 wMNAF-based multiplication change and a
	problem
In-Reply-To: <201211240935.53313.arekm@maven.pl>
References: <201211232352.50000.arekm@maven.pl> <50B07EED.4040802@gnutls.org>
	<201211240935.53313.arekm@maven.pl>
Message-ID: <50B09B84.1020605@gnutls.org>

On 11/24/2012 09:35 AM, Arkadiusz Mi?kiewicz wrote:

>>> Uninstalling php gmp module and the problem is gone. My curl uses gnutls.
>>>
>>> The fact that I need gmp php module to reproduce makes me wonder
>>> if there is some global state (maybe in gmp) that's overwritten by
>>> gnutls?
>>>
>>> Any ideas/hints on what can be going on here?
>>
>> Hello,
>>  Could it be that the gmp module uses some conflicting gmp library
>> version? (check whether you have multiple gmp libraries in your system).
> 
> There is only one gmp library in my system (and php doesn't have any bundled 
> library).
> 
> Now I see that php gmp module uses:
> 
> mp_set_memory_functions(gmp_emalloc, gmp_erealloc, gmp_efree);

> gmp_exxx are functions that use Zend memory management code.

It seems then that you've found the reason of the crash. If this is
called prior to gnutls being initialized you shouldn't have any issue as
well.

regards,
Nikos



From nmav at gnutls.org  Sat Nov 24 18:53:28 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 24 Nov 2012 18:53:28 +0100
Subject: gnutls 3.1.5
Message-ID: <50B10998.8090402@gnutls.org>

Hello,
 I've just released gnutls 3.1.5. This release adds support for UCS2
encoded DNs, improvements in smart card key generation and few bug-fixes.

* Version 3.1.5 (released 2012-11-24)

** libgnutls: Added functions to parse the certificates policies
extension.

** libgnutls: Handle BMPString (UCS-2) encoding in the Distinguished
Name by translating it to UTF-8 (works on windows or systems with  iconv).

** libgnutls: Added PKCS #11 key generation function that returns the
public key on generation.

** libgnutls: Corrected bug in priority string parsing, that mostly
affected combined levels. Patch by Tim Kosse.

** certtool: The --pubkey-info option can be combined with the
--load-privkey or --load-request to print the corresponding public keys.

** certtool: It is able to set certificate policies via a template.

** certtool: Added --hex-numbers option which prints big numbers in an
easier to parse format.

** p11tool: After key generation, outputs the public key (useful in
tokens that do not store the public key).

** danetool: It is being built even without libgnutls-dane (the --check
functionality is disabled though).

** API and ABI modifications:
gnutls_pkcs11_privkey_generate2: Added
gnutls_x509_crt_get_policy: Added
gnutls_x509_crt_set_policy: Added
gnutls_x509_policy_release: Added
gnutls_pubkey_import_x509_crq: Added
gnutls_pubkey_print: Added
GNUTLS_CRT_PRINT_FULL_NUMBERS: Added


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

GnuTLS may be downloaded from one of the GNU mirror sites or directly
>From <ftp://ftp.gnu.org/gnu/gnutls/>.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the XZ compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.xz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.xz

Here are the LZIP compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.lz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.xz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.xz.sig

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.lz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.5.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos



From troy.heron at hixxy.org  Tue Nov 27 08:01:49 2012
From: troy.heron at hixxy.org (Troy Heron)
Date: Tue, 27 Nov 2012 17:01:49 +1000
Subject: Version nettle became default backend
Message-ID: <CAMy2XzBfBqNR3PG34cDoAXNQitC7e3gXg3fDdH6PaaS-3mU6JA@mail.gmail.com>

Hello,

I'm just looking to find out which version gnutls changed the default
cryptographic backend over from gcrypt to nettle?

Thanks,
Troy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20121127/5f1fa4e5/attachment.htm>

From dkg at fifthhorseman.net  Fri Nov 30 21:31:18 2012
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 30 Nov 2012 15:31:18 -0500
Subject: gnutls4win for 2.12.x or 3.x?
Message-ID: <50B91796.90103@fifthhorseman.net>

hey folks--

Simon's gnutls4win packages [0] look like the latest version is 2.10.1
[1].  But according to the homepage [2], the latest stable versions are
2.12.21 and 3.0.26 (and then there's 3.1.5 as well).

How are the gnutls4win packages maintained?

I note that the build instructions at [0] suggest using CVS to do the
checkout.  Do we need to transition gnutls4win to git as well?

I normally wouldn't bother with this, but i've got a couple people i'm
trying to support who insist on using windows and have some kind of
network/TLS failures, and i wouldn't mind asking them to debug using
some decent, recent tools.

	--dkg

[0] http://www.josefsson.org/gnutls4win/
[1] http://www.josefsson.org/gnutls4win/gnutls-2.10.1.exe
[2] http://gnutls.org/