From nmav at gnutls.org Sun Dec 1 22:48:32 2019
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 01 Dec 2019 22:48:32 +0100
Subject: [gnutls-help] gnutls 3.6.11
Message-ID: <550186432be545f624b14e102932df7fc67621b0.camel@gnutls.org>
Hello,
I've just released gnutls 3.6.11. This is a bug fix release on the
stable 3.6.x branch.
I'd like to thank everyone who contributed in this release:
Dmitry Eremin-Solenikov, Tim R?hsen, Daiki Ueno, Tom Vrancken,
Fiona Klute, Ludovic Court?s, Andreas Metzler, Nia Alarie, Bj?rn Jacke,
Karsten Ohme, G?nther Deschner, Miroslav Lichvar and Ricardo M.
Correia.
The detailed list of changes follows; they can be seen in more detail
in our milestone tracker:
https://gitlab.com/gnutls/gnutls/-/milestones/25
Changes
=======
* Version 3.6.11 (released 2019-12-01)
** libgnutls: Use KERN_ARND for the system random number generator on
NetBSD.
This syscall provides an endless stream of random numbers from the kernel's
ChaCha20-based random number generator, without blocking or requiring an open file
descriptor.
** libgnutls: Corrected issue with TLS 1.2 session ticket handling as
client during resumption (#841).
** libgnutls: gnutls_base64_decode2() succeeds decoding the empty string
to the empty string. This is a behavioral change of the API but it conforms
to the RFC4648 expectations (#834).
** libgnutls: Fixed AES-CFB8 implementation, when input is shorter than
the block size. Fix backported from nettle.
** certtool: CRL distribution points will be set in CA certificates even
when non self-signed (#765).
** gnutls-cli/serv: added raw public-key handling capabilities (RFC7250).
Key material can be set via the --rawpkkeyfile and --rawpkfile flags.
** API and ABI modifications:
No changes since last version.
Getting the Software
====================
GnuTLS may be downloaded directly from .
A list of GnuTLS mirrors can be found at
Here are the XZ compressed sources:
https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.11.tar.xz
Here are OpenPGP detached signatures signed using key 0x96865171:
https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.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 gnutls.org>
uid Nikos Mavrogiannopoulos
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 Mon Dec 2 13:40:10 2019
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 2 Dec 2019 13:40:10 +0100
Subject: [gnutls-help] full-chain ocsp stapling
In-Reply-To: <7fe00e63-93e2-0e10-7e86-c881039e1c55@wizmail.org>
References: <8b2c1cd1-082c-8f93-5fe5-56e1b5799bfb@wizmail.org>
<7fe00e63-93e2-0e10-7e86-c881039e1c55@wizmail.org>
Message-ID:
Hi,
Isn't that the same as https://gitlab.com/gnutls/gnutls/issues/829 ?
regards,
Nikos
On Sun, Nov 24, 2019 at 6:44 PM Jeremy Harris wrote:
>
> On 10/11/2019 20:45, Jeremy Harris wrote:
> > GnuTLS 3.6.8
> >
> > I'm testing $subject using a 3-layer cert chain, and stapled ocsp
> > under TLS1.3 for which the middle item is non-valid.
> ...
> > but gnutls_ocsp_status_request_is_checked(state->session, 0) returns
> > nonzero (meaning "valid").
> >
> > I'm not quite clear what level of validity is being described here.
> > Should it be checking that the OCSP response indicates non-revoked
> > certificates, for all cert-chain elements covered? Or is it only
> > saying that the stapled information is well-constructed and signed
> > (meaning that I should be taking more actions to validate the
> > certs; if so, what)?
>
> No answers on this?
> --
> Cheers,
> Jeremy
>
> _______________________________________________
> Gnutls-help mailing list
> Gnutls-help at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-help
From jgh at wizmail.org Mon Dec 2 16:48:56 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Mon, 2 Dec 2019 15:48:56 +0000
Subject: [gnutls-help] full-chain ocsp stapling
In-Reply-To:
References: <8b2c1cd1-082c-8f93-5fe5-56e1b5799bfb@wizmail.org>
<7fe00e63-93e2-0e10-7e86-c881039e1c55@wizmail.org>
Message-ID:
On 02/12/2019 12:40, Nikos Mavrogiannopoulos wrote:
> Isn't that the same as https://gitlab.com/gnutls/gnutls/issues/829 ?
No; that was asking how the server could tell if the client
requested stapling.
This is a problem where an apparently invalid stapling (from the server)
is being regarded as valid by the client.
--
Cheers,
Jeremy
From nmav at gnutls.org Mon Dec 2 17:55:46 2019
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 2 Dec 2019 17:55:46 +0100
Subject: [gnutls-help] full-chain ocsp stapling
In-Reply-To:
References: <8b2c1cd1-082c-8f93-5fe5-56e1b5799bfb@wizmail.org>
<7fe00e63-93e2-0e10-7e86-c881039e1c55@wizmail.org>
Message-ID:
Could report it as an issue and attach a reproducer to it? There are
few ocsp tests in `tests/` that can serve as an inspiration for one.
regards,
Nikos
On Mon, Dec 2, 2019 at 4:49 PM Jeremy Harris wrote:
>
> On 02/12/2019 12:40, Nikos Mavrogiannopoulos wrote:
> > Isn't that the same as https://gitlab.com/gnutls/gnutls/issues/829 ?
>
> No; that was asking how the server could tell if the client
> requested stapling.
>
> This is a problem where an apparently invalid stapling (from the server)
> is being regarded as valid by the client.
> --
> Cheers,
> Jeremy
>
> _______________________________________________
> Gnutls-help mailing list
> Gnutls-help at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-help
From nicolas at babelouest.org Thu Dec 5 17:21:00 2019
From: nicolas at babelouest.org (Nicolas Mora)
Date: Thu, 05 Dec 2019 16:21:00 +0000
Subject: [gnutls-help] certtool and add_extension
Message-ID: <8b048b154f4810235388f3bc9a5ce401@babelouest.org>
Hello,
In some tests procedures, I need to add the following extension to signing certificates:
key: 1.3.6.1.4.1.45724.1.1.4
value: a 16 bytes value
According to certtool documentation [1], I must use add_extension with an octet string:
add_extension = "1.2.3.4 octet_string(0x0AAB01ACFE)"
In my case, the add_extension parameter would be:
add_extension = "1.3.6.1.4.1.45724.1.1.4 octet_string(0x0410CD8C395C26EDEEDE653B00797D03CA3C)"
Although, the generated certificate doesn't include the extension "1.3.6.1.4.1.45724.1.1.4"
You can see the template file I use here: https://github.com/babelouest/glewlwyd/blob/master/test/cert/template-client-packed.cfg
Is there a something I missed when using the certtool command?
Thanks in advance
/Nicolas
[1] - https://www.gnutls.org/manual/html_node/certtool-Invocation.html
From nmav at gnutls.org Fri Dec 6 10:54:22 2019
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 6 Dec 2019 10:54:22 +0100
Subject: [gnutls-help] certtool and add_extension
In-Reply-To: <8b048b154f4810235388f3bc9a5ce401@babelouest.org>
References: <8b048b154f4810235388f3bc9a5ce401@babelouest.org>
Message-ID:
Hi,
You may want to check your gnutls version. This template option was
added at 3.5.3.
regards,
Nikos
On Thu, Dec 5, 2019 at 5:59 PM Nicolas Mora wrote:
>
> Hello,
>
> In some tests procedures, I need to add the following extension to signing certificates:
> key: 1.3.6.1.4.1.45724.1.1.4
> value: a 16 bytes value
>
> According to certtool documentation [1], I must use add_extension with an octet string:
> add_extension = "1.2.3.4 octet_string(0x0AAB01ACFE)"
>
> In my case, the add_extension parameter would be:
> add_extension = "1.3.6.1.4.1.45724.1.1.4 octet_string(0x0410CD8C395C26EDEEDE653B00797D03CA3C)"
>
> Although, the generated certificate doesn't include the extension "1.3.6.1.4.1.45724.1.1.4"
>
> You can see the template file I use here: https://github.com/babelouest/glewlwyd/blob/master/test/cert/template-client-packed.cfg
>
> Is there a something I missed when using the certtool command?
>
> Thanks in advance
>
> /Nicolas
>
> [1] - https://www.gnutls.org/manual/html_node/certtool-Invocation.html
>
> _______________________________________________
> Gnutls-help mailing list
> Gnutls-help at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-help
From nicolas at babelouest.org Fri Dec 6 15:57:00 2019
From: nicolas at babelouest.org (Nicolas Mora)
Date: Fri, 06 Dec 2019 14:57:00 +0000
Subject: [gnutls-help] certtool and add_extension
In-Reply-To:
References:
<8b048b154f4810235388f3bc9a5ce401@babelouest.org>
Message-ID:
Hello,
6 d?cembre 2019 04:54 "Nikos Mavrogiannopoulos" a ?crit:
> You may want to check your gnutls version. This template option was
> added at 3.5.3.
>
Nevertheless, I use a Debian Buster with gnutls 3.6.7
Here is a gist with the script and template files I use for my demonstration:
https://gist.github.com/babelouest/0c5076462d52f8ecf7c33c9862681687
The log file output is attached, and more specifically, the client certificate output is:
Generating a signed certificate...
X.509 Certificate Information:
Version: 3
Serial Number (hex): 736c577633f2962c130569396e9c8532394975ea
Validity:
Not Before: Fri Dec 06 14:30:20 UTC 2019
Not After: Fri Nov 20 14:30:20 UTC 2020
Subject: C=CA,O=babelouest,OU=Authenticator Attestation,CN=glewlwyd_packed
Subject Public Key Algorithm: EC/ECDSA
Algorithm Security Level: High (256 bits)
Curve: SECP256R1
X:
3d:ca:36:10:58:e0:f0:49:cc:61:47:57:ac:ee:83:60
45:29:c2:23:ab:50:1f:00:50:1b:9e:8e:51:e4:e7:8d
Y:
58:e4:9c:5f:81:c0:dd:d7:44:8b:c9:a2:b4:04:48:16
d0:f1:86:46:d2:b5:2b:be:9b:f5:ce:76:af:3a:65:e7
Extensions:
Basic Constraints (critical):
Certificate Authority (CA): FALSE
Key Usage (critical):
Digital signature.
Subject Key Identifier (not critical):
945473da3bfe497d2b712dc3cef6e4a692be8b29
Authority Key Identifier (not critical):
6e245f7b8f84bb602631dc9b3a33af2fb58670f3
Other Information:
Public Key ID:
sha1:945473da3bfe497d2b712dc3cef6e4a692be8b29
sha256:9cccc45cc2996175ed3567a0033ef413309228d78b5364b8270ad962f14d49a0
Public Key PIN:
pin-sha256:nMzEXMKZYXXtNWegAz70EzCSKNeLU2S4JwrZYvFNSaA=
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: extension.log
URL:
From ametzler at bebt.de Sat Dec 7 14:07:53 2019
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 7 Dec 2019 14:07:53 +0100
Subject: [gnutls-help] nettle_cfb8_decrypt and nettle 5.1
Message-ID: <20191207130753.GA1435@argenau.bebt.de>
Hello,
gnutls 3.6.11 introduces this change in
98ac6220bdef67ba1153dc515613e4582e1419a2 "nettle: use included CFB8
implementation if nettle is 3.5":
configure.ac
# Check if nettle has CFB8 support
+if test -z "$ac_cv_func_nettle_cfb8_encrypt"; then
+ # nettle_cfb8_decrypt in nettle 3.5 is known to be broken
+ ver=`$PKG_CONFIG --modversion nettle`
+ if expr "$ver" : '^3\.5\b' >/dev/null; then
+ ac_cv_func_nettle_cfb8_encrypt=no
+ fi
+fi
Which versions of nettle are broken? Is there a fixed release?
The "expr" test hits not only for 3.5 but also for 3.5.1.
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 nmav at gnutls.org Tue Dec 10 15:15:26 2019
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 10 Dec 2019 15:15:26 +0100
Subject: [gnutls-help] nettle_cfb8_decrypt and nettle 5.1
In-Reply-To: <20191207130753.GA1435@argenau.bebt.de>
References: <20191207130753.GA1435@argenau.bebt.de>
Message-ID:
On Sat, Dec 7, 2019 at 2:26 PM Andreas Metzler wrote:
>
> Hello,
>
> gnutls 3.6.11 introduces this change in
> 98ac6220bdef67ba1153dc515613e4582e1419a2 "nettle: use included CFB8
> implementation if nettle is 3.5":
>
> configure.ac
> # Check if nettle has CFB8 support
> +if test -z "$ac_cv_func_nettle_cfb8_encrypt"; then
> + # nettle_cfb8_decrypt in nettle 3.5 is known to be broken
> + ver=`$PKG_CONFIG --modversion nettle`
> + if expr "$ver" : '^3\.5\b' >/dev/null; then
> + ac_cv_func_nettle_cfb8_encrypt=no
> + fi
> +fi
>
> Which versions of nettle are broken? Is there a fixed release?
> The "expr" test hits not only for 3.5 but also for 3.5.1.
I believe it is every released version of nettle which includes cfb8.
I think the 3.5.x match is intentional as the .1 releases in nettle
are made only for targeted fixes and may not include the cfb8 fix.
regards,
Nikos
From nmav at gnutls.org Tue Dec 10 15:22:35 2019
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 10 Dec 2019 15:22:35 +0100
Subject: [gnutls-help] certtool and add_extension
In-Reply-To:
References: <8b048b154f4810235388f3bc9a5ce401@babelouest.org>
Message-ID:
Could you minimize the commands needed to reproduce the issue you are
describing?
If I do:
$ echo add_extension = "7.0.1.5 octet_string(CAFEBEAF) >>tmpl
$ certtool --generate-privkey --outfile key
$ certtool --generate-self-signed --template tmpl --load-privkey key
I see:
Unknown extension 7.0.1.5 (not critical):
ASCII: ......
Hexdump: 0404cafebeaf
regards,
Nikos
On Fri, Dec 6, 2019 at 3:57 PM Nicolas Mora wrote:
>
> Hello,
>
> 6 d?cembre 2019 04:54 "Nikos Mavrogiannopoulos" a ?crit:
>
> > You may want to check your gnutls version. This template option was
> > added at 3.5.3.
> >
> Nevertheless, I use a Debian Buster with gnutls 3.6.7
>
> Here is a gist with the script and template files I use for my demonstration:
> https://gist.github.com/babelouest/0c5076462d52f8ecf7c33c9862681687
>
> The log file output is attached, and more specifically, the client certificate output is:
>
> Generating a signed certificate...
> X.509 Certificate Information:
> Version: 3
> Serial Number (hex): 736c577633f2962c130569396e9c8532394975ea
> Validity:
> Not Before: Fri Dec 06 14:30:20 UTC 2019
> Not After: Fri Nov 20 14:30:20 UTC 2020
> Subject: C=CA,O=babelouest,OU=Authenticator Attestation,CN=glewlwyd_packed
> Subject Public Key Algorithm: EC/ECDSA
> Algorithm Security Level: High (256 bits)
> Curve: SECP256R1
> X:
> 3d:ca:36:10:58:e0:f0:49:cc:61:47:57:ac:ee:83:60
> 45:29:c2:23:ab:50:1f:00:50:1b:9e:8e:51:e4:e7:8d
> Y:
> 58:e4:9c:5f:81:c0:dd:d7:44:8b:c9:a2:b4:04:48:16
> d0:f1:86:46:d2:b5:2b:be:9b:f5:ce:76:af:3a:65:e7
> Extensions:
> Basic Constraints (critical):
> Certificate Authority (CA): FALSE
> Key Usage (critical):
> Digital signature.
> Subject Key Identifier (not critical):
> 945473da3bfe497d2b712dc3cef6e4a692be8b29
> Authority Key Identifier (not critical):
> 6e245f7b8f84bb602631dc9b3a33af2fb58670f3
> Other Information:
> Public Key ID:
> sha1:945473da3bfe497d2b712dc3cef6e4a692be8b29
> sha256:9cccc45cc2996175ed3567a0033ef413309228d78b5364b8270ad962f14d49a0
> Public Key PIN:
> pin-sha256:nMzEXMKZYXXtNWegAz70EzCSKNeLU2S4JwrZYvFNSaA=
From ametzler at bebt.de Tue Dec 10 19:23:02 2019
From: ametzler at bebt.de (Andreas Metzler)
Date: Tue, 10 Dec 2019 19:23:02 +0100
Subject: [gnutls-help] nettle_cfb8_decrypt and nettle 5.1
In-Reply-To:
References: <20191207130753.GA1435@argenau.bebt.de>
Message-ID: <20191210182302.GB1711@argenau.bebt.de>
On 2019-12-10 Nikos Mavrogiannopoulos wrote:
> On Sat, Dec 7, 2019 at 2:26 PM Andreas Metzler wrote:
> > gnutls 3.6.11 introduces this change in
> > 98ac6220bdef67ba1153dc515613e4582e1419a2 "nettle: use included CFB8
> > implementation if nettle is 3.5":
> >
> > configure.ac
> > # Check if nettle has CFB8 support
> > +if test -z "$ac_cv_func_nettle_cfb8_encrypt"; then
> > + # nettle_cfb8_decrypt in nettle 3.5 is known to be broken
> > + ver=`$PKG_CONFIG --modversion nettle`
> > + if expr "$ver" : '^3\.5\b' >/dev/null; then
> > + ac_cv_func_nettle_cfb8_encrypt=no
> > + fi
> > +fi
> > Which versions of nettle are broken? Is there a fixed release?
> > The "expr" test hits not only for 3.5 but also for 3.5.1.
> I believe it is every released version of nettle which includes cfb8.
> I think the 3.5.x match is intentional as the .1 releases in nettle
> are made only for targeted fixes and may not include the cfb8 fix.
Hello,
okay. I was asking because 3.5.1 /was/ released. But as you suspected
there is no cf8 change included.
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 nicolas at babelouest.org Wed Dec 11 15:48:30 2019
From: nicolas at babelouest.org (Nicolas Mora)
Date: Wed, 11 Dec 2019 14:48:30 +0000
Subject: [gnutls-help] certtool and add_extension
In-Reply-To:
References:
<8b048b154f4810235388f3bc9a5ce401@babelouest.org>
Message-ID: <6f8904bbb7968b7ecce8a0e237856429@babelouest.org>
10 d?cembre 2019 09:22 "Nikos Mavrogiannopoulos" a ?crit:
> Could you minimize the commands needed to reproduce the issue you are
> describing?
>
Here is a minimal set of commands to reproduce the problem:
# Generate the ca certificate
echo add_extension = "1.3.6.1.4.1.45724.1.1.4 octet_string(0x0410CD8C395C26EDEEDE653B00797D03CA3C)" >>tmpl
certtool --generate-privkey --outfile ca.key
certtool --generate-self-signed --load-privkey ca.key --outfile ca.cert --template tmpl
# generate the client key
certtool --generate-privkey --outfile signed.key
# Example 1: create a signed certificate without request
certtool --generate-certificate --load-privkey signed.key --outfile signed.cert --load-ca-certificate ca.cert --load-ca-privkey ca.key --template tmpl
# Example 2: create a signed certificate with request
certtool --generate-request --load-privkey signed.key --outfile signed-r.csr --template tmpl
certtool --generate-certificate --load-request signed-r.csr --load-privkey signed.key --outfile signed-r.cert --load-ca-certificate ca.cert --load-ca-privkey ca.key --template tmpl
On the example 1, if I create a certificate signed with the ca.cert file without generating the request file first, the signed certificate contains the extension.
On the example 2, if I create a certificate signed with the ca.cert file using the request, the signed certificate doesn't contain the extension
/Nicolas
From nmav at gnutls.org Thu Dec 12 07:07:11 2019
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 12 Dec 2019 07:07:11 +0100
Subject: [gnutls-help] certtool and add_extension
In-Reply-To: <6f8904bbb7968b7ecce8a0e237856429@babelouest.org>
References:
<8b048b154f4810235388f3bc9a5ce401@babelouest.org>
<6f8904bbb7968b7ecce8a0e237856429@babelouest.org>
Message-ID:
On Wed, 2019-12-11 at 14:48 +0000, Nicolas Mora wrote:
> 10 d?cembre 2019 09:22 "Nikos Mavrogiannopoulos" a
> ?crit:
>
> > Could you minimize the commands needed to reproduce the issue you
> > are
> > describing?
> >
> Here is a minimal set of commands to reproduce the problem:
>
> # Generate the ca certificate
> echo add_extension = "1.3.6.1.4.1.45724.1.1.4
> octet_string(0x0410CD8C395C26EDEEDE653B00797D03CA3C)" >>tmpl
> certtool --generate-privkey --outfile ca.key
> certtool --generate-self-signed --load-privkey ca.key --outfile
> ca.cert --template tmpl
>
> # generate the client key
> certtool --generate-privkey --outfile signed.key
>
> # Example 1: create a signed certificate without request
> certtool --generate-certificate --load-privkey signed.key --outfile
> signed.cert --load-ca-certificate ca.cert --load-ca-privkey ca.key --
> template tmpl
>
> # Example 2: create a signed certificate with request
> certtool --generate-request --load-privkey signed.key --outfile
> signed-r.csr --template tmpl
> certtool --generate-certificate --load-request signed-r.csr --load-
> privkey signed.key --outfile signed-r.cert --load-ca-certificate
> ca.cert --load-ca-privkey ca.key --template tmpl
>
> On the example 1, if I create a certificate signed with the ca.cert
> file without generating the request file first, the signed
> certificate contains the extension.
> On the example 2, if I create a certificate signed with the ca.cert
> file using the request, the signed certificate doesn't contain the
> extension
When generating a certificate from a certificate request you should
add:
honor_crq_extensions
to the template. Otherwise they are ignored.
regards,
Nikos
From nmav at gnutls.org Thu Dec 12 09:50:34 2019
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 12 Dec 2019 09:50:34 +0100
Subject: [gnutls-help] certtool and add_extension
In-Reply-To:
References:
<8b048b154f4810235388f3bc9a5ce401@babelouest.org>
<6f8904bbb7968b7ecce8a0e237856429@babelouest.org>
Message-ID:
Hmm, actually what was the intention? Was the intention to read the
extension from the certificate request, or to read the extension from
the certificate template on the last step?
On Thu, Dec 12, 2019 at 7:07 AM Nikos Mavrogiannopoulos wrote:
>
> On Wed, 2019-12-11 at 14:48 +0000, Nicolas Mora wrote:
> > 10 d?cembre 2019 09:22 "Nikos Mavrogiannopoulos" a
> > ?crit:
> >
> > > Could you minimize the commands needed to reproduce the issue you
> > > are
> > > describing?
> > >
> > Here is a minimal set of commands to reproduce the problem:
> >
> > # Generate the ca certificate
> > echo add_extension = "1.3.6.1.4.1.45724.1.1.4
> > octet_string(0x0410CD8C395C26EDEEDE653B00797D03CA3C)" >>tmpl
> > certtool --generate-privkey --outfile ca.key
> > certtool --generate-self-signed --load-privkey ca.key --outfile
> > ca.cert --template tmpl
> >
> > # generate the client key
> > certtool --generate-privkey --outfile signed.key
> >
> > # Example 1: create a signed certificate without request
> > certtool --generate-certificate --load-privkey signed.key --outfile
> > signed.cert --load-ca-certificate ca.cert --load-ca-privkey ca.key --
> > template tmpl
> >
> > # Example 2: create a signed certificate with request
> > certtool --generate-request --load-privkey signed.key --outfile
> > signed-r.csr --template tmpl
> > certtool --generate-certificate --load-request signed-r.csr --load-
> > privkey signed.key --outfile signed-r.cert --load-ca-certificate
> > ca.cert --load-ca-privkey ca.key --template tmpl
> >
> > On the example 1, if I create a certificate signed with the ca.cert
> > file without generating the request file first, the signed
> > certificate contains the extension.
> > On the example 2, if I create a certificate signed with the ca.cert
> > file using the request, the signed certificate doesn't contain the
> > extension
>
> When generating a certificate from a certificate request you should
> add:
> honor_crq_extensions
>
> to the template. Otherwise they are ignored.
>
> regards,
> Nikos
>
>
From xnox at ubuntu.com Mon Dec 16 03:46:37 2019
From: xnox at ubuntu.com (Dimitri John Ledkov)
Date: Mon, 16 Dec 2019 02:46:37 +0000
Subject: [gnutls-help] "built-in" gnutls config,
with optional-only config file on disk
Message-ID:
In Ubuntu, gnutls default priority is set to "NORMAL", however, I kind
of like how on Fedora it is set to "@SYSTEM" and then a system config
file defines what that actually means. Allowing users to override that
system-wide.
However, there are a few issues with that. It creates a hard
dependency between libgnutls and config file on disk, and said config
file must always specify [priorities] SYSTEM=, as otherwise setting
default priorities fails. (and apparmor profile must allow reading
said config, etc.)
Prime example, gnutls testuite fails, as it uses a custom
tests/system.prio without SYSTEM= specified. And for example, one can
see in Fedora spec file that 'echo SYSTEM=NORMAL >> tests/system.prio'
is done to unbreak the testsuite.
It also means, that if one copies all the library dependencies of an
app, without the config file into chroot/initrd/container/etc one may
get non-working gnutls, or the one that behaves differently.
Is there a way to provide built-in compiled defaults that operate with
or without a config file on disk? I.e. something like use @SYSTEM if
exists, otherwise fallback to "NORMAL"? That way, with or without
config, default behaviour is the same, setting default-priority always
works and users can still override it.
What about for the other overrides? I.e. can one somehow compile-in
default [overrides] that is used, unless system config specifies one?
I.e. built-in config specifying [overrides] disabled-versions=tls1.0,
with users able to turn it back on by creating the config and
specifying like empty [overrides] paragraph, or like using
reenable-versions=tls1.0.
Maybe I am overthinking all of this, and what I really want is simply
support for
[overrides]
default-priority-string = NORMAL
Whilst the library itself is compiled with something stronger, i.e.
--with-default-priority-string='NORMAL:-VERS-TLS1.0'.
--
Regards,
Dimitri.
From nmav at gnutls.org Mon Dec 16 21:22:56 2019
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 16 Dec 2019 21:22:56 +0100
Subject: [gnutls-help] "built-in" gnutls config,
with optional-only config file on disk
In-Reply-To:
References:
Message-ID:
On Mon, Dec 16, 2019 at 4:17 AM Dimitri John Ledkov wrote:
>
> In Ubuntu, gnutls default priority is set to "NORMAL", however, I kind
> of like how on Fedora it is set to "@SYSTEM" and then a system config
> file defines what that actually means. Allowing users to override that
> system-wide.
>
> However, there are a few issues with that. It creates a hard
> dependency between libgnutls and config file on disk, and said config
> file must always specify [priorities] SYSTEM=, as otherwise setting
> default priorities fails. (and apparmor profile must allow reading
> said config, etc.)
> Prime example, gnutls testuite fails, as it uses a custom
> tests/system.prio without SYSTEM= specified. And for example, one can
> see in Fedora spec file that 'echo SYSTEM=NORMAL >> tests/system.prio'
> is done to unbreak the testsuite.
>
> It also means, that if one copies all the library dependencies of an
> app, without the config file into chroot/initrd/container/etc one may
> get non-working gnutls, or the one that behaves differently.
>
> Is there a way to provide built-in compiled defaults that operate with
> or without a config file on disk? I.e. something like use @SYSTEM if
> exists, otherwise fallback to "NORMAL"? That way, with or without
> config, default behaviour is the same, setting default-priority always
> works and users can still override it.
I believe you can do what you describe by specifying a priority string
to applications as "@SYSTEM,NORMAL". With that, the fallback policy
will be the default NORMAL. However that has the drawback that you
cannot know which profile each application will be using. It would be
quite difficult to tell the system state and the expected outcome of a
connection.
> What about for the other overrides? I.e. can one somehow compile-in
> default [overrides] that is used, unless system config specifies one?
> I.e. built-in config specifying [overrides] disabled-versions=tls1.0,
> with users able to turn it back on by creating the config and
> specifying like empty [overrides] paragraph, or like using
> reenable-versions=tls1.0.
>
> Maybe I am overthinking all of this, and what I really want is simply
> support for
> [overrides]
> default-priority-string = NORMAL
> Whilst the library itself is compiled with something stronger, i.e.
> --with-default-priority-string='NORMAL:-VERS-TLS1.0'.
That sounds like something reasonable. There is an ongoing coversation
on how to handle national standards like GOST with a similar mechanism
at:
https://gitlab.com/gnutls/gnutls/merge_requests/1119
Would you like to move that discussion there so that we combine the
requirements?
regards,
Nikos
From xnox at ubuntu.com Tue Dec 31 16:48:13 2019
From: xnox at ubuntu.com (Dimitri John Ledkov)
Date: Tue, 31 Dec 2019 15:48:13 +0000
Subject: [gnutls-help] "built-in" gnutls config,
with optional-only config file on disk
In-Reply-To:
References:
Message-ID:
On Mon, 16 Dec 2019 at 20:23, Nikos Mavrogiannopoulos wrote:
>
> On Mon, Dec 16, 2019 at 4:17 AM Dimitri John Ledkov wrote:
> >
> > In Ubuntu, gnutls default priority is set to "NORMAL", however, I kind
> > of like how on Fedora it is set to "@SYSTEM" and then a system config
> > file defines what that actually means. Allowing users to override that
> > system-wide.
> >
> > However, there are a few issues with that. It creates a hard
> > dependency between libgnutls and config file on disk, and said config
> > file must always specify [priorities] SYSTEM=, as otherwise setting
> > default priorities fails. (and apparmor profile must allow reading
> > said config, etc.)
> > Prime example, gnutls testuite fails, as it uses a custom
> > tests/system.prio without SYSTEM= specified. And for example, one can
> > see in Fedora spec file that 'echo SYSTEM=NORMAL >> tests/system.prio'
> > is done to unbreak the testsuite.
> >
> > It also means, that if one copies all the library dependencies of an
> > app, without the config file into chroot/initrd/container/etc one may
> > get non-working gnutls, or the one that behaves differently.
> >
> > Is there a way to provide built-in compiled defaults that operate with
> > or without a config file on disk? I.e. something like use @SYSTEM if
> > exists, otherwise fallback to "NORMAL"? That way, with or without
> > config, default behaviour is the same, setting default-priority always
> > works and users can still override it.
>
> I believe you can do what you describe by specifying a priority string
> to applications as "@SYSTEM,NORMAL". With that, the fallback policy
> will be the default NORMAL. However that has the drawback that you
> cannot know which profile each application will be using. It would be
> quite difficult to tell the system state and the expected outcome of a
> connection.
>
Just that works, but it's not that useful. What I reallly wanted was
something like:
@ SYSTEM,NORMAL%PROFILE_MEDIUM
But that fails....
|<2>| cfg: system priority /etc/gnutls/config has not changed
|<2>| resolved 'SYSTEM' to '', next 'NORMAL%PROFILE_MEDIUM'
|<2>| cfg: system priority /etc/gnutls/config has not changed
|<2>| resolved 'NORMAL%PROFILE_MEDIUM' to '', next ''
|<2>| unable to resolve @SYSTEM,NORMAL%PROFILE_MEDIUM
I can do @SYSTEM,NORMAL:%PROFILE_MEDIUM but that is not quite the
same, as it resolves to NORMAL:%PROFILE_MEDIUM or
SYSTEM:%PROFILE_MEDIUM. I.e. people will not be able to negate
%PROFILE_MEDIUM.
I.e. users can only prepend, but not append things.
I kind of wish for
--priority='NORMAL:%PROFILE_MEDIUM:@SYSTEM,NONE'
But that too fails to parse with:
Syntax error at: @SYSTEM,NONE
> > What about for the other overrides? I.e. can one somehow compile-in
> > default [overrides] that is used, unless system config specifies one?
> > I.e. built-in config specifying [overrides] disabled-versions=tls1.0,
> > with users able to turn it back on by creating the config and
> > specifying like empty [overrides] paragraph, or like using
> > reenable-versions=tls1.0.
> >
> > Maybe I am overthinking all of this, and what I really want is simply
> > support for
> > [overrides]
> > default-priority-string = NORMAL
> > Whilst the library itself is compiled with something stronger, i.e.
> > --with-default-priority-string='NORMAL:-VERS-TLS1.0'.
>
> That sounds like something reasonable. There is an ongoing coversation
> on how to handle national standards like GOST with a similar mechanism
> at:
> https://gitlab.com/gnutls/gnutls/merge_requests/1119
> Would you like to move that discussion there so that we combine the
> requirements?
Possibly. At the moment I do not see any better way than to introduce
[overrides]default-priority-string in the config file. As I want
NORMAL:-VERS-TLS1.0:-VERS-TLS1.1:%PROFILE_MEDIUM as the compiled-in
default but a way for users to override this behaviour in a config
file, which I don't see a way to do at the moment.
Also there isn't a compiled-in default for the [overrides]
verify-profile key, nor for the compiled-in [overrides]
disabled-version key, nor a way to reenable compiled-in
disabled-versions.
Imho, any library should have sensible compiled-in defaults, which can
be overridden with config files, such that one can have "available,
but disabled by default" algos / protocol version / profile levels /
etc, which users can opt-into anyway. This is separete to choosing to
not even compile unwanted protocol versions (i.e. just disable tls1.3
at build time, and not include that functionality in the library at
all).
I wonder if as a distribution, I should be changing what "NORMAL"
means. And compile gnutls with @SYSTEM,NORMAL, and change such that
NORMAL means TLS1.2+ %PROFILE_MEDIUM with a distro patch.
--
Regards,
Dimitri.