From markb at lowsnr.net  Sun Apr  3 08:52:39 2016
From: markb at lowsnr.net (Mark Brown)
Date: Sun, 3 Apr 2016 15:52:39 +0900
Subject: [gnutls-devel] Difference between 'tools' and 'libraries' for
	GNUtls development?
Message-ID: <5700BDB7.3040308@lowsnr.net>

Greetings,

I am trying to build GNUtls from the latest sources, and have the
following observations.

(1) Dependencies

There are two types of dependency:
- tools needed to build GNUtls (compilers, make and the like)
- external libraries that GNUtls may require

The section "Development" on the page http://gnutls.org/devel.html
refers to development *tools* in README-alpha
(https://gitlab.com/gnutls/gnutls/blob/master/README-alpha.md).
There is no mention of the libraries required to build GNUtls.

However, README-alpha.md includes libtasn1 and libidn. Are actually
tools, or are they libraries?

Also, GMP is needed to build GNUtls but is not listed anywhere.

It would be nice to distinguish between tools and libraries, and to
include GMP for completeness.

(2) Build instructions

The commands listed on http://gnutls.org/devel.html are not consistent
with the contents of README-alpha.md. Specifically, the former specifies
'make autoreconf' while the latter specifies 'make bootstrap'. Which is
correct? (The two sources should also be made consistent.)

Also, since GMP is required, it should be included in the list of
packages to install in README-alpha.md.


Best regards,
Mark Brown.



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

From nmav at gnutls.org  Tue Apr  5 08:49:11 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 5 Apr 2016 08:49:11 +0200
Subject: [gnutls-devel] Difference between 'tools' and 'libraries' for
 GNUtls development?
In-Reply-To: <5700BDB7.3040308@lowsnr.net>
References: <5700BDB7.3040308@lowsnr.net>
Message-ID: <CAJU7zaJBu1RXHsXsF3=G0xd83=7DrqTMbJERB9xugqeU7eNVPg@mail.gmail.com>

On Sun, Apr 3, 2016 at 8:52 AM, Mark Brown <markb at lowsnr.net> wrote:
> Greetings,
>
> I am trying to build GNUtls from the latest sources, and have the
> following observations.
>
> (1) Dependencies
>
> There are two types of dependency:
> - tools needed to build GNUtls (compilers, make and the like)
> - external libraries that GNUtls may require
> The section "Development" on the page http://gnutls.org/devel.html
> refers to development *tools* in README-alpha
> (https://gitlab.com/gnutls/gnutls/blob/master/README-alpha.md).
> There is no mention of the libraries required to build GNUtls.

Hi,
 It doesn't separate between libraries and tools because in the end
both are simply packages you install in your distribution.

> However, README-alpha.md includes libtasn1 and libidn. Are actually
> tools, or are they libraries?

libtasn1 is both, libidn is a library.

> Also, GMP is needed to build GNUtls but is not listed anywhere.

GMP is a nettle dependency so it is used indirectly only. That's why
it is not listed.

> It would be nice to distinguish between tools and libraries, and to
> include GMP for completeness.

What would be the benefit? It may be that I'm too accustomed to a
typical Linux system where everything is package. Nevertheless, feel
free to send a patch which does this separation if that would ease
your work-flow.

> (2) Build instructions
>
> The commands listed on http://gnutls.org/devel.html are not consistent
> with the contents of README-alpha.md. Specifically, the former specifies
> 'make autoreconf' while the latter specifies 'make bootstrap'. Which is
> correct? (The two sources should also be made consistent.)

Both are correct. I'll make them consistent though. Thanks.

regards,
Nikos


From nmav at gnutls.org  Mon Apr 11 09:21:44 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 11 Apr 2016 09:21:44 +0200
Subject: [gnutls-devel] gnutls 3.4.11
Message-ID: <1460359304.1786.13.camel@gnutls.org>

Hello, 
 I've just released gnutls 3.4.11. This is a bug fix release of the
current stable branch.

* Version 3.4.11 (released 2016-04-11)

** libgnutls: Fixes in gnutls_record_get/set_state() with DTLS. 
   Reported by Fridolin Pokorny.

** libgnutls: Fixes in DSA key generation under PKCS #11. Report and
   patches by Jan Vcelak.

** libgnutls: Corrected behavior of ALPN extension parsing during
   session resumption. Report and patches by Yuriy M. Kaminskiy.

** libgnutls: Corrected regression (since 3.4.0) in 
   gnutls_server_name_set() which caused it not to accept non-null-
   terminated hostnames. Reported by Tim Ruehsen.

** libgnutls: Corrected printing of the IP Adress name constraints.

** ocsptool: use HTTP/1.0 for requests. This avoids issue with servers
   serving chunk encoding which ocsptool doesn't support. Reported by
   Thomas Klute.

** certtool: do not require a CA for OCSP signing tag. This follows the
   recommendations in RFC6960 in 4.2.2.2 which allow a CA to delegate
   OCSP signing to another certificate without requiring it to be a CA.
   Reported by Thomas Klute.


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


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

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.??A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.11.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.11.tar.xz.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 n.mavrogiannopoulos at gmail.com  Wed Apr 13 20:55:18 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 13 Apr 2016 20:55:18 +0200
Subject: [gnutls-devel] dropping crywrap from gnutls 3.5.0
Message-ID: <1460573718.3531.13.camel@gmail.com>

Hi,
?Are there any objections in dropping crywrap from gnutls 3.5.0? I have
never managed to enhance this application as I wanted to and there far
better alternatives. Unless there are any objections I intend to move
it to github [0], and let it rest.

regards,
Nikos

[0].?https://github.com/nmav/crywrap



From cernekee at gmail.com  Sun Apr 17 20:12:18 2016
From: cernekee at gmail.com (Kevin Cernekee)
Date: Sun, 17 Apr 2016 11:12:18 -0700
Subject: [gnutls-devel] [PATCH] Fix library build on Chrome Native Client
	(NaCl)
Message-ID: <1460916738-20492-1-git-send-email-cernekee@gmail.com>

GnuTLS seems to mostly work under NaCl, but two items needed to be
patched:

1) Automatically running gnutls_global_init() from the library
constructor won't work, because /dev/urandom isn't available until
the app initializes libnacl_io.  If the app wants to use the
nacl_io_init_ppapi() API, this can only be called once the PP_Instance
object is created, which happens after the library constructor runs.

2) Some supported toolchains define DT_UNKNOWN but do not define
_DIRENT_HAVE_D_TYPE (and do not have the d_type field).  On other
platforms GnuTLS may need to second-guess what the library is reporting,
but on NaCl this is unsafe.

For GnuTLS 3.4.x I'm carrying this as an out-of-tree patch[1], but it
would be nice if it was incorporated into 3.5.x.

Builds of the tools (certtool and such) under NaCl are untested and
probably require additional work.

[1] https://codereview.chromium.org/1892223002
---
 lib/global.c            | 8 ++++++++
 lib/x509/verify-high2.c | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/lib/global.c b/lib/global.c
index f55851e7ea94..96c48ae040b0 100644
--- a/lib/global.c
+++ b/lib/global.c
@@ -57,7 +57,15 @@
 int __attribute__((weak)) _gnutls_global_init_skip(void);
 int _gnutls_global_init_skip(void)
 {
+#ifdef __native_client__
+	/* _gnutls_rnd_init() will fail if nacl_io_init() or
+	 * nacl_io_init_ppapi() has not run yet.  Only the app can invoke
+	 * the latter function (and only one can be called).
+	 */
+	return 1;
+#else
 	return 0;
+#endif
 }
 #else
 inline static int _gnutls_global_init_skip(void)
diff --git a/lib/x509/verify-high2.c b/lib/x509/verify-high2.c
index e79aedc72de4..96f0ff6c274b 100644
--- a/lib/x509/verify-high2.c
+++ b/lib/x509/verify-high2.c
@@ -37,7 +37,7 @@
 
 #include <dirent.h>
 
-#ifndef _DIRENT_HAVE_D_TYPE
+#if !defined(_DIRENT_HAVE_D_TYPE) && !defined(__native_client__)
 # ifdef DT_UNKNOWN
 #  define _DIRENT_HAVE_D_TYPE
 # endif
-- 
2.8.0.rc3.226.g39d4020



From nmav at gnutls.org  Mon Apr 18 15:27:54 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 18 Apr 2016 15:27:54 +0200
Subject: [gnutls-devel] [PATCH] Fix library build on Chrome Native
	Client (NaCl)
In-Reply-To: <1460916738-20492-1-git-send-email-cernekee@gmail.com>
References: <1460916738-20492-1-git-send-email-cernekee@gmail.com>
Message-ID: <CAJU7zaLHPosG3+pzw__k_w-WvdTNV2JYjPjb0tB9Oroc7SzSjw@mail.gmail.com>

Hi Kevin,
 (1) is very tricky. If we go that path the implicit initialization of
the library goes away. Is there some way to avoid it? E.g., can we
rely on getrandom() does nacl support it?

I've applied (2) in separate.

regards,
Nikos

On Sun, Apr 17, 2016 at 8:12 PM, Kevin Cernekee <cernekee at gmail.com> wrote:
> GnuTLS seems to mostly work under NaCl, but two items needed to be
> patched:
>
> 1) Automatically running gnutls_global_init() from the library
> constructor won't work, because /dev/urandom isn't available until
> the app initializes libnacl_io.  If the app wants to use the
> nacl_io_init_ppapi() API, this can only be called once the PP_Instance
> object is created, which happens after the library constructor runs.
>
> 2) Some supported toolchains define DT_UNKNOWN but do not define
> _DIRENT_HAVE_D_TYPE (and do not have the d_type field).  On other
> platforms GnuTLS may need to second-guess what the library is reporting,
> but on NaCl this is unsafe.
>
> For GnuTLS 3.4.x I'm carrying this as an out-of-tree patch[1], but it
> would be nice if it was incorporated into 3.5.x.
>
> Builds of the tools (certtool and such) under NaCl are untested and
> probably require additional work.
>
> [1] https://codereview.chromium.org/1892223002
> ---
>  lib/global.c            | 8 ++++++++
>  lib/x509/verify-high2.c | 2 +-
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/lib/global.c b/lib/global.c
> index f55851e7ea94..96c48ae040b0 100644
> --- a/lib/global.c
> +++ b/lib/global.c
> @@ -57,7 +57,15 @@
>  int __attribute__((weak)) _gnutls_global_init_skip(void);
>  int _gnutls_global_init_skip(void)
>  {
> +#ifdef __native_client__
> +       /* _gnutls_rnd_init() will fail if nacl_io_init() or
> +        * nacl_io_init_ppapi() has not run yet.  Only the app can invoke
> +        * the latter function (and only one can be called).
> +        */
> +       return 1;
> +#else
>         return 0;
> +#endif
>  }
>  #else
>  inline static int _gnutls_global_init_skip(void)
> diff --git a/lib/x509/verify-high2.c b/lib/x509/verify-high2.c
> index e79aedc72de4..96f0ff6c274b 100644
> --- a/lib/x509/verify-high2.c
> +++ b/lib/x509/verify-high2.c
> @@ -37,7 +37,7 @@
>
>  #include <dirent.h>
>
> -#ifndef _DIRENT_HAVE_D_TYPE
> +#if !defined(_DIRENT_HAVE_D_TYPE) && !defined(__native_client__)
>  # ifdef DT_UNKNOWN
>  #  define _DIRENT_HAVE_D_TYPE
>  # endif
> --
> 2.8.0.rc3.226.g39d4020
>


From cernekee at gmail.com  Tue Apr 19 02:05:18 2016
From: cernekee at gmail.com (Kevin Cernekee)
Date: Mon, 18 Apr 2016 17:05:18 -0700
Subject: [gnutls-devel] [PATCH] Fix library build on Chrome Native
	Client (NaCl)
In-Reply-To: <CAJU7zaLHPosG3+pzw__k_w-WvdTNV2JYjPjb0tB9Oroc7SzSjw@mail.gmail.com>
References: <1460916738-20492-1-git-send-email-cernekee@gmail.com>
 <CAJU7zaLHPosG3+pzw__k_w-WvdTNV2JYjPjb0tB9Oroc7SzSjw@mail.gmail.com>
Message-ID: <CAJiQ=7AWttBvOJk9yH4f8-Mcwq247H21oV4Xs0NgpoqqJ4-0_w@mail.gmail.com>

On Mon, Apr 18, 2016 at 6:27 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> Hi Kevin,
>  (1) is very tricky. If we go that path the implicit initialization of
> the library goes away. Is there some way to avoid it? E.g., can we
> rely on getrandom() does nacl support it?

It isn't currently supported, but I can propose adding it to
libnacl_io if we know that GnuTLS won't actually call it until the app
calls a GnuTLS function.  In that sense it would have the same
restrictions as file operations, but since _rnd_system_entropy_init()
doesn't perform any I/O, it avoids the initial problem.

Would that work?

Checking to see if there are other things happening in the library
constructor that require libnacl_io: there are a few calls to open
/dev/crypto, FIPS related files, etc.  The open() calls will return
ENOSYS prior to initialization, which should be fine for those.  Can
you think of any other dependencies?


From nmav at gnutls.org  Tue Apr 19 11:11:31 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 19 Apr 2016 11:11:31 +0200
Subject: [gnutls-devel] [PATCH] Fix library build on Chrome Native
	Client (NaCl)
In-Reply-To: <CAJiQ=7AWttBvOJk9yH4f8-Mcwq247H21oV4Xs0NgpoqqJ4-0_w@mail.gmail.com>
References: <1460916738-20492-1-git-send-email-cernekee@gmail.com>
 <CAJU7zaLHPosG3+pzw__k_w-WvdTNV2JYjPjb0tB9Oroc7SzSjw@mail.gmail.com>
 <CAJiQ=7AWttBvOJk9yH4f8-Mcwq247H21oV4Xs0NgpoqqJ4-0_w@mail.gmail.com>
Message-ID: <CAJU7zaLZmvb5vO9KC+EBuaR9jX1rTvAYx2fTLKkYR-AnUwAufA@mail.gmail.com>

On Tue, Apr 19, 2016 at 2:05 AM, Kevin Cernekee <cernekee at gmail.com> wrote:
> On Mon, Apr 18, 2016 at 6:27 AM, Nikos Mavrogiannopoulos
> <nmav at gnutls.org> wrote:
>> Hi Kevin,
>>  (1) is very tricky. If we go that path the implicit initialization of
>> the library goes away. Is there some way to avoid it? E.g., can we
>> rely on getrandom() does nacl support it?
>
> It isn't currently supported, but I can propose adding it to
> libnacl_io if we know that GnuTLS won't actually call it until the app
> calls a GnuTLS function.  In that sense it would have the same
> restrictions as file operations, but since _rnd_system_entropy_init()
> doesn't perform any I/O, it avoids the initial problem.
> Would that work?

It would, no randomness is needed at the constructor. Only
initialization happens and getrandom() doesn't require that. A simple
getrandom() on kernels that don't support it could be implemented by
opening reading and closing /dev/unrandom. That could also be part of
gnutls with a special compilation option, but I don't quite like
having many options as they will pretty much be untested.

> Checking to see if there are other things happening in the library
> constructor that require libnacl_io: there are a few calls to open
> /dev/crypto, FIPS related files, etc.  The open() calls will return
> ENOSYS prior to initialization, which should be fine for those.  Can
> you think of any other dependencies?

I don't believe there are any other.


From ametzler at bebt.de  Sat Apr 23 15:32:26 2016
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 23 Apr 2016 15:32:26 +0200
Subject: [gnutls-devel] 3.3.19 / 3.4.7 Guile related testsuite segfaults
In-Reply-To: <20151124184945.GB4525@downhill.g.la>
References: <20151124184945.GB4525@downhill.g.la>
Message-ID: <20160423133226.GC1314@argenau.bebt.de>

On 2015-11-24 Andreas Metzler <ametzler at bebt.de> wrote:
> on amd64 there are segfaults in the guile testsuite:
[...]

Later 3.4 series seemed to work, 3.4.11 got stuck when running the
testsuite. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821457

I will probably drop guile support in Debian/unstable, there are no
depending packages.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From ludo at gnu.org  Mon Apr 25 10:23:54 2016
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Mon, 25 Apr 2016 10:23:54 +0200
Subject: [gnutls-devel] 3.3.19 / 3.4.7 Guile related testsuite segfaults
In-Reply-To: <20160423133226.GC1314@argenau.bebt.de> (Andreas Metzler's
 message of "Sat, 23 Apr 2016 15:32:26 +0200")
References: <20151124184945.GB4525@downhill.g.la>
 <20160423133226.GC1314@argenau.bebt.de>
Message-ID: <87fuuaayg5.fsf@gnu.org>

Andreas Metzler <ametzler at bebt.de> skribis:

> Later 3.4 series seemed to work, 3.4.11 got stuck when running the
> testsuite. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821457
>
> I will probably drop guile support in Debian/unstable, there are no
> depending packages.

This is sad, but I understand the frustration.

My latest notes on this topic:

  http://lists.gnutls.org/pipermail/gnutls-devel/2015-December/007820.html

The difficulty is that I would be unable to reproduce the issue as soon
as I add debugging statements and such.  :-/

Ludo?.


From martin at martin.st  Wed Apr 27 10:41:29 2016
From: martin at martin.st (=?ISO-8859-15?Q?Martin_Storsj=F6?=)
Date: Wed, 27 Apr 2016 11:41:29 +0300 (EEST)
Subject: [gnutls-devel] Mandatory to honor DN in server certificate requests?
Message-ID: <alpine.DEB.2.11.1604271125520.25342@cone.martin.st>

Hi,

I'm looking into an issue in using gnutls to do a DTLS handshake with 
browsers (for use with WebRTC).

If the server side of the handshake is firefox, with manually installed 
custom CAs in the browser (unrelated to the WebRTC setup at hand), the 
Certificate Request record from the server contains a nonzero list of CAs, 
listing the manually installed custom CAs.

The client side of the handshake only has got a self-signed certificate 
(completely unrelated to whatever extra CAs might be installed in the 
browser). Now since the client certificates don't match the DNs listed in 
the certificate request, gnutls doesn't pick any certificate to send at 
all, and sends an empty certificate record back.

(For comparison, if the client side is handled by openssl, it ignores the 
DNs here and just sends whatever client certificate that has been 
provided, regardless if this matches the certificate request.)

I guess this is a pretty uncommon scenario, since most users don't have 
manually installed CAs though.


I'm not completely sure which party is at fault here; I don't see RFC 5246 
clearly saying that if the list of CAs in the certificate request is 
non-empty, the response MUST match it, I only read this:

    certificate_authorities
       A list of the distinguished names [X501] of acceptable
       certificate_authorities, represented in DER-encoded format.  These
       distinguished names may specify a desired distinguished name for a
       root CA or for a subordinate CA; thus, this message can be used to
       describe known roots as well as a desired authorization space.  If
       the certificate_authorities list is empty, then the client MAY
       send any certificate of the appropriate ClientCertificateType,
       unless there is some external arrangement to the contrary.


Is firefox at fault here (sending unrelated CAs as part of this handshake 
- e.g. chrome doesn't send any such), or does gnutls need an option for 
intentionally ignoring the requested CAs and sending whatever certificate 
is provided, letting the server decide whether it is acceptable?

// Martin


From nmav at gnutls.org  Thu Apr 28 08:20:19 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 28 Apr 2016 08:20:19 +0200
Subject: [gnutls-devel] Mandatory to honor DN in server certificate
	requests?
In-Reply-To: <alpine.DEB.2.11.1604271125520.25342@cone.martin.st>
References: <alpine.DEB.2.11.1604271125520.25342@cone.martin.st>
Message-ID: <CAJU7zaJ6suOb=Z45ombz1+TZ7GwE7KF5O6QQfrMv6HGXgv6DJw@mail.gmail.com>

On Wed, Apr 27, 2016 at 10:41 AM, Martin Storsj? <martin at martin.st> wrote:
> Hi,
> I'm looking into an issue in using gnutls to do a DTLS handshake with
> browsers (for use with WebRTC).
> If the server side of the handshake is firefox, with manually installed
> custom CAs in the browser (unrelated to the WebRTC setup at hand), the
> Certificate Request record from the server contains a nonzero list of CAs,
> listing the manually installed custom CAs.
> The client side of the handshake only has got a self-signed certificate
> (completely unrelated to whatever extra CAs might be installed in the
> browser). Now since the client certificates don't match the DNs listed in
> the certificate request, gnutls doesn't pick any certificate to send at all,
> and sends an empty certificate record back.
> (For comparison, if the client side is handled by openssl, it ignores the
> DNs here and just sends whatever client certificate that has been provided,
> regardless if this matches the certificate request.)
> I guess this is a pretty uncommon scenario, since most users don't have
> manually installed CAs though.

Well, if the server is asking a certificate from the user to
authenticate it specifies the exact CAs it trusts so that the client
will use a certificate from that CA to authenticate. In the tangible
world it is like entering a company A and the guard at front expects
you to authenticate using your company A ID.

> I'm not completely sure which party is at fault here; I don't see RFC 5246
> clearly saying that if the list of CAs in the certificate request is
> non-empty, the response MUST match it, I only read this:
>    certificate_authorities
>       A list of the distinguished names [X501] of acceptable
>       certificate_authorities, represented in DER-encoded format.  These
>       distinguished names may specify a desired distinguished name for a
>       root CA or for a subordinate CA; thus, this message can be used to
>       describe known roots as well as a desired authorization space.  If
>       the certificate_authorities list is empty, then the client MAY
>       send any certificate of the appropriate ClientCertificateType,
>       unless there is some external arrangement to the contrary.

It is not the TLS protocol which will specify that behavior but rather
the application protocol. gnutls takes the conservative approach and
does not reveal the ID of the client if it doesn't match the expected
ID from the server. That way if you mistakenly specified your
certificate from site A your ID will not be revealed just because site
B asked of a certificate as well.

> Is firefox at fault here (sending unrelated CAs as part of this handshake -
> e.g. chrome doesn't send any such), or does gnutls need an option for
> intentionally ignoring the requested CAs and sending whatever certificate is
> provided, letting the server decide whether it is acceptable?

If the server would accept a certificate not signed by anyone in his
accepted list, why not send an empty list instead? If there is a
common use-case or scenario that the current behavior don't handle we
may want to provision for it somehow.

Said that, note that this behavior is only with the "automatic"
handling of client certificates. If you want to force the client
sending a certificate you can utilize the callbacks instead.

regards,
Nikos


From martin at martin.st  Thu Apr 28 08:26:12 2016
From: martin at martin.st (=?ISO-8859-15?Q?Martin_Storsj=F6?=)
Date: Thu, 28 Apr 2016 09:26:12 +0300 (EEST)
Subject: [gnutls-devel] Mandatory to honor DN in server certificate
 requests?
In-Reply-To: <CAJU7zaJ6suOb=Z45ombz1+TZ7GwE7KF5O6QQfrMv6HGXgv6DJw@mail.gmail.com>
References: <alpine.DEB.2.11.1604271125520.25342@cone.martin.st>
 <CAJU7zaJ6suOb=Z45ombz1+TZ7GwE7KF5O6QQfrMv6HGXgv6DJw@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1604280924300.25342@cone.martin.st>

On Thu, 28 Apr 2016, Nikos Mavrogiannopoulos wrote:

> On Wed, Apr 27, 2016 at 10:41 AM, Martin Storsj? <martin at martin.st> wrote:
>
> It is not the TLS protocol which will specify that behavior but rather
> the application protocol. gnutls takes the conservative approach and
> does not reveal the ID of the client if it doesn't match the expected
> ID from the server. That way if you mistakenly specified your
> certificate from site A your ID will not be revealed just because site
> B asked of a certificate as well.

Ok, that sounds sensible.

>> Is firefox at fault here (sending unrelated CAs as part of this handshake -
>> e.g. chrome doesn't send any such), or does gnutls need an option for
>> intentionally ignoring the requested CAs and sending whatever certificate is
>> provided, letting the server decide whether it is acceptable?
>
> If the server would accept a certificate not signed by anyone in his
> accepted list, why not send an empty list instead?

Fair enough - I guess it sounds like I should file a bug with firefox 
then.

> If there is a common use-case or scenario that the current behavior 
> don't handle we may want to provision for it somehow.
>
> Said that, note that this behavior is only with the "automatic"
> handling of client certificates. If you want to force the client
> sending a certificate you can utilize the callbacks instead.

Ah, thanks for the hint! That's probably the best solution for me 
meanwhile.

// Martin

From martin at martin.st  Fri Apr 29 20:19:30 2016
From: martin at martin.st (=?ISO-8859-15?Q?Martin_Storsj=F6?=)
Date: Fri, 29 Apr 2016 21:19:30 +0300 (EEST)
Subject: [gnutls-devel] Mandatory to honor DN in server certificate
 requests?
In-Reply-To: <alpine.DEB.2.11.1604280924300.25342@cone.martin.st>
References: <alpine.DEB.2.11.1604271125520.25342@cone.martin.st>
 <CAJU7zaJ6suOb=Z45ombz1+TZ7GwE7KF5O6QQfrMv6HGXgv6DJw@mail.gmail.com>
 <alpine.DEB.2.11.1604280924300.25342@cone.martin.st>
Message-ID: <alpine.DEB.2.11.1604292115160.25342@cone.martin.st>

On Thu, 28 Apr 2016, Martin Storsj? wrote:

> On Thu, 28 Apr 2016, Nikos Mavrogiannopoulos wrote:
>
>> On Wed, Apr 27, 2016 at 10:41 AM, Martin Storsj? <martin at martin.st> wrote:
>> 
>> It is not the TLS protocol which will specify that behavior but rather
>> the application protocol. gnutls takes the conservative approach and
>> does not reveal the ID of the client if it doesn't match the expected
>> ID from the server. That way if you mistakenly specified your
>> certificate from site A your ID will not be revealed just because site
>> B asked of a certificate as well.
>
> Ok, that sounds sensible.
>
>>> Is firefox at fault here (sending unrelated CAs as part of this handshake 
>>> -
>>> e.g. chrome doesn't send any such), or does gnutls need an option for
>>> intentionally ignoring the requested CAs and sending whatever certificate 
>>> is
>>> provided, letting the server decide whether it is acceptable?
>> 
>> If the server would accept a certificate not signed by anyone in his
>> accepted list, why not send an empty list instead?
>
> Fair enough - I guess it sounds like I should file a bug with firefox then.

For the record, newer firefox versions (at least 48) seem to have fixed 
this issue as well, so no bug report was filed on my behalf.

// Martin