From gregs at sloop.net  Thu May 23 00:57:27 2019
From: gregs at sloop.net (Gregory Sloop)
Date: Wed, 22 May 2019 15:57:27 -0700
Subject: [gnutls-help] Server and client OID
Message-ID: <36176498.20190522155727@sloop.net>

I am using certtool to create some certificates and keys.
These certs and keys will be used on Windows systems - and I've run into some confusion.

As far as I can tell, MS [and Cisco and others] expect the OID 1.3.6.1.5.5.7.3.1 to be a "server" certificate.

However, from the GNUTLS docs for certtool, I see this:

# Whether this certificate will be used for a TLS client;
# this sets the id-kp-serverAuth (1.3.6.1.5.5.7.3.1) of 
# extended key usage.
tls_www_client

# Whether this certificate will be used for a TLS server;
# This sets the id-kp-clientAuth (1.3.6.1.5.5.7.3.2) of 
# extended key usage.
tls_www_server

Since I've seen 1.3.6.1.5.5.7.3.1 defined as a *server* EKU everywhere I've found from google searches, I pretty sure this is the correct *server* OID.

So, I guess the core question is:
Which OID is set for which keyword?
If I use "tls_www_client" in my template, is 1.3.6.1.5.5.7.3.1 going to be set, or is it _really_ 1.3.6.1.5.5.7.3.2?
And clearly related; If I use "tls_www_server" in my template, is 1.3.6.1.5.5.7.3.2 going to be set, or is it _really_ 1.3.6.1.5.5.7.3.1?

I *assume* what really happens is:
tls_www_server = 1.3.6.1.5.5.7.3.1
tls_www_client = 1.3.6.1.5.5.7.3.2
[Which is the reverse of the documentation for certtool; see: https://gnutls.org/manual/html_node/certtool-Invocation.html ]

But I want to verify that the comments in the docs are backwards before I assume that 


---
If it matters, and perhaps it does - in this particular case, I'm generating ca/certs/keys for a Wifi EAP-TLS setup. I assume that the FreeRadius server needs a cert with OID 1.3.6.1.5.5.7.3.1, and the client certs need 1.3.6.1.5.5.7.3.2 [and should *NOT* contain 1.3.6.1.5.5.7.3.1. That way, a client cert couldn't be used to spoof/impersonate the server on a rogue Radius server. Yes, I understand that would take some doing, and isn't likely - but no sense in having any additional exposure.] 

This is why having the correct OID's and only the correct OID's is important - and thus the above query.

TIA
-Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20190522/78e26af3/attachment.html>

From nmav at gnutls.org  Thu May 23 21:35:03 2019
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 23 May 2019 21:35:03 +0200
Subject: [gnutls-help] Server and client OID
In-Reply-To: <36176498.20190522155727@sloop.net>
References: <36176498.20190522155727@sloop.net>
Message-ID: <CAJU7za+GQUSDwSDikLhS92Mv7LUHvX-y+sHi=7NtQwORJU8YAw@mail.gmail.com>

On Thu, May 23, 2019 at 1:17 AM Gregory Sloop <gregs at sloop.net> wrote:
>
> I am using certtool to create some certificates and keys.
> These certs and keys will be used on Windows systems - and I've run into some confusion.
>
> As far as I can tell, MS [and Cisco and others] expect the OID 1.3.6.1.5.5.7.3.1 to be a "server" certificate.
>
> However, from the GNUTLS docs for certtool, I see this:
>
> # Whether this certificate will be used for a TLS client;
> # this sets the id-kp-serverAuth (1.3.6.1.5.5.7.3.1) of
> # extended key usage.
> tls_www_client
>
> # Whether this certificate will be used for a TLS server;
> # This sets the id-kp-clientAuth (1.3.6.1.5.5.7.3.2) of
> # extended key usage.
> tls_www_server

Hi,
 Thank you for bringing this up. It seems that the comments in the
configuration file are incorrect. Checking the OIDs set by these two
options, they are reversed and match what you mention above.

regards,
Nikos


From gregs at sloop.net  Fri May 24 02:11:05 2019
From: gregs at sloop.net (Gregory Sloop)
Date: Thu, 23 May 2019 17:11:05 -0700
Subject: [gnutls-help] Server and client OID
In-Reply-To: <CAJU7za+GQUSDwSDikLhS92Mv7LUHvX-y+sHi=7NtQwORJU8YAw@mail.gmail.com>
References: <36176498.20190522155727@sloop.net> 
 <CAJU7za+GQUSDwSDikLhS92Mv7LUHvX-y+sHi=7NtQwORJU8YAw@mail.gmail.com>
Message-ID: <154932114.20190523171105@sloop.net>



NM> On Thu, May 23, 2019 at 1:17 AM Gregory Sloop <gregs at sloop.net> wrote:

>> I am using certtool to create some certificates and keys.
>> These certs and keys will be used on Windows systems - and I've run into some confusion.

>> As far as I can tell, MS [and Cisco and others] expect the OID 1.3.6.1.5.5.7.3.1 to be a "server" certificate.

>> However, from the GNUTLS docs for certtool, I see this:

>> # Whether this certificate will be used for a TLS client;
>> # this sets the id-kp-serverAuth (1.3.6.1.5.5.7.3.1) of
>> # extended key usage.
>> tls_www_client

>> # Whether this certificate will be used for a TLS server;
>> # This sets the id-kp-clientAuth (1.3.6.1.5.5.7.3.2) of
>> # extended key usage.
>> tls_www_server

NM> Hi,
NM>  Thank you for bringing this up. It seems that the comments in the
NM> configuration file are incorrect. Checking the OIDs set by these two
NM> options, they are reversed and match what you mention above.

NM> regards,
NM> Nikos

Thanks, I was pretty sure, as I did review some certs I created with another tool and it was as I expected - but I wanted to do it a second time, being super careful to be sure I was right. It's great to get your confirmation! Now I don't need to do that.

Thanks for fixing it in the comments/docs for a future version!
It looks like it's in the docs too:
https://www.gnutls.org/manual/gnutls.html

..and thanks for a great tool! [I should say that part first!!! Seriously, I really do appreciate your work!]

-Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20190523/e2b11bde/attachment-0001.html>

From gregs at sloop.net  Fri May 24 02:24:18 2019
From: gregs at sloop.net (Gregory Sloop)
Date: Thu, 23 May 2019 17:24:18 -0700
Subject: [gnutls-help] Server and client OID
In-Reply-To: <154932114.20190523171105@sloop.net>
References: <36176498.20190522155727@sloop.net>  
 <CAJU7za+GQUSDwSDikLhS92Mv7LUHvX-y+sHi=7NtQwORJU8YAw@mail.gmail.com>
 <154932114.20190523171105@sloop.net>
Message-ID: <548221132.20190523172418@sloop.net>


It looks like it's in the docs too:
https://www.gnutls.org/manual/gnutls.html

Sigh. Strike that.
It would be a good thing for me to pay a bit more attention.
It's correct in that linked doc.

So, perhaps it's only wrong in certool template comments.

-Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20190523/2c336f19/attachment.html>

From nmav at gnutls.org  Tue May 28 07:40:09 2019
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 28 May 2019 07:40:09 +0200
Subject: [gnutls-help] gnutls 3.6.8
Message-ID: <ed93adf41b56290e13ec06627a4fb4f680793498.camel@gnutls.org>

Hello, 
 I've just released gnutls 3.6.8. This is a bug fix release on the
stable 3.6.x branch.

I'd like to thank everyone who contributed in this release:
Aleksei Nikiforov, Alon Bar-Lev, Andreas Metzler, Bernhard M.
Wiedemann, Daiki Ueno, Daniel Schaefer, Dmitry Eremin-Solenikov,
Elta Koepp, Kenneth J. Miller, Maciej S. Szmigiero, Marius Bakke
Simo Sorce and Tim R?hsen.

The detailed list of changes follows; they can be seen in more detail
in our milestone tracker:
https://gitlab.com/gnutls/gnutls/milestones/21


Changes
=======

* Version 3.6.8 (released 2019-05-28)

** libgnutls: Added gnutls_prf_early() function to retrieve early keying
   material (#329)

** libgnutls: Added support for AES-XTS cipher (#354)

** libgnutls: Fix calculation of Streebog digests (incorrect carry operation in
   512 bit addition)

** libgnutls: During Diffie-Hellman operations in TLS, verify that the peer's
   public key is on the right subgroup (y^q=1 mod p), when q is available (under
   TLS 1.3 and under earlier versions when RFC7919 parameters are used).

** libgnutls: the gnutls_srp_set_server_credentials_function can now be used
   with the 8192 parameters as well (#995).

** libgnutls: Fixed bug preventing the use of gnutls_pubkey_verify_data2() and
   gnutls_pubkey_verify_hash2() with the GNUTLS_VERIFY_DISABLE_CA_SIGN flag (#754)

** libgnutls: The priority string option %ALLOW_SMALL_RECORDS was added to allow
   clients to communicate with the server advertising smaller limits than 512

** libgnutls: Apply STD3 ASCII rules in gnutls_idna_map() to prevent
   hostname/domain crafting via IDNA conversion (#720)

** certtool: allow the digital signature key usage flag in CA certificates.
   Previously certtool would ignore this flag for CA certificates even if
   specified (#767)

** gnutls-cli/serv: added the --keymatexport and --keymatexportsize options.
   These allow testing the RFC5705 using these tools.

** API and ABI modifications:
gnutls_prf_early: Added
gnutls_record_set_max_recv_size: Added
gnutls_dh_params_import_raw3: Added
gnutls_ffdhe_2048_group_q: Added
gnutls_ffdhe_3072_group_q: Added
gnutls_ffdhe_4096_group_q: Added
gnutls_ffdhe_6144_group_q: Added
gnutls_ffdhe_8192_group_q: Added


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:

  https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.8.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

  https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.8.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 ametzler at bebt.de  Thu May 30 11:25:43 2019
From: ametzler at bebt.de (Andreas Metzler)
Date: Thu, 30 May 2019 11:25:43 +0200
Subject: [gnutls-help] 3.6.8 - no pdf files in tarball
Message-ID: <20190530092527.GB1401@argenau.bebt.de>

Hello,

the tarball for 3.6.8 does not include pdf versions of the documentation
(but an empty '*.pdf' file):

ametzler at argenau:/tmp/GNUTLS$ find gnutls-3.6.7 gnutls-3.6.8 -name '*.pdf' -printf '%h/%f %k KB\n'
gnutls-3.6.7/doc/gnutls-guile.pdf 240 KB
gnutls-3.6.7/doc/gnutls.pdf 2208 KB
gnutls-3.6.8/doc/*.pdf 0 KB

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  Thu May 30 14:35:46 2019
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 30 May 2019 14:35:46 +0200
Subject: [gnutls-help] 3.6.8 - no pdf files in tarball
In-Reply-To: <20190530092527.GB1401@argenau.bebt.de>
References: <20190530092527.GB1401@argenau.bebt.de>
Message-ID: <CAJU7zaJ1ibsDe-reD5V2JBHx55rKjDVfn=athwKjZG=wwW+jiA@mail.gmail.com>

On Thu, May 30, 2019 at 11:27 AM Andreas Metzler <ametzler at bebt.de> wrote:
>
> Hello,
>
> the tarball for 3.6.8 does not include pdf versions of the documentation
> (but an empty '*.pdf' file):
>
> ametzler at argenau:/tmp/GNUTLS$ find gnutls-3.6.7 gnutls-3.6.8 -name '*.pdf' -printf '%h/%f %k KB\n'
> gnutls-3.6.7/doc/gnutls-guile.pdf 240 KB
> gnutls-3.6.7/doc/gnutls.pdf 2208 KB
> gnutls-3.6.8/doc/*.pdf 0 KB

Thanks. In order to do the release I've removed the pdf generation
because I had troubles generating these pdfs (texinfo fails on my
release system). However that saved some bytes already, and since
these manuals are already online, I found it a good idea to do it
permanently. Does it cause an issue from your side?

About the '*.pdf' I have no idea why is that.

regards,
Nikos


From ametzler at bebt.de  Thu May 30 16:03:22 2019
From: ametzler at bebt.de (Andreas Metzler)
Date: Thu, 30 May 2019 16:03:22 +0200
Subject: [gnutls-help] 3.6.8 - no pdf files in tarball
In-Reply-To: <CAJU7zaJ1ibsDe-reD5V2JBHx55rKjDVfn=athwKjZG=wwW+jiA@mail.gmail.com>
References: <20190530092527.GB1401@argenau.bebt.de>
 <CAJU7zaJ1ibsDe-reD5V2JBHx55rKjDVfn=athwKjZG=wwW+jiA@mail.gmail.com>
Message-ID: <20190530140322.GG1401@argenau.bebt.de>

On 2019-05-30 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Thu, May 30, 2019 at 11:27 AM Andreas Metzler <ametzler at bebt.de> wrote:
> > the tarball for 3.6.8 does not include pdf versions of the documentation
> > (but an empty '*.pdf' file):

> Thanks. In order to do the release I've removed the pdf generation
> because I had troubles generating these pdfs (texinfo fails on my
> release system). However that saved some bytes already, and since
> these manuals are already online, I found it a good idea to do it
> permanently. Does it cause an issue from your side?

Hi Nikos,

No, it does not cause any issues. I just thought it was strange, and was
wondering whether this was an oversight or done intentionally.

thanks, 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'