From rick at openfortress.nl  Mon May  2 08:14:09 2016
From: rick at openfortress.nl (Rick van Rein)
Date: Mon, 02 May 2016 08:14:09 +0200
Subject: [gnutls-devel] RFC 7250 and API change
In-Reply-To: <57223D85.7080702@openfortress.nl>
References: <57223D85.7080702@openfortress.nl>
Message-ID: <5726F031.8030109@openfortress.nl>

Hello Nikos,

Tom and I are working on
https://tools.ietf.org/html/draft-vanrein-tls-kdh-03
which implements Kerberos tickets as you suggested, per RFC 7250.

What we run into is probably a break with the GnuTLS API, and we'd like
to hear
your opinion on this.

The call to gnutls_certificate_type_get() seems to make an implicit
assumption
that the same certificate type is used in both directions, but with RFC 7250
(which we are now adding) there is a possibility that these are different.
Applications of GnuTLS might not be aware of this having been added to
GnuTLS,
and may end up being confused.

We see various ways to deal with this, but none of them is pretty. 
Could you
tell us what your preferred approach would be?

Thanks,
Rick & Tom
ARPA2 TLS-KDH crew





From nmav at gnutls.org  Mon May  2 09:22:54 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 2 May 2016 09:22:54 +0200
Subject: [gnutls-devel] RFC 7250 and API change
In-Reply-To: <5726F031.8030109@openfortress.nl>
References: <57223D85.7080702@openfortress.nl>
 <5726F031.8030109@openfortress.nl>
Message-ID: <CAJU7zaLrfjyjFUz1n35QKKdAQuPxO=x0r0+wsi3az54ypo=CPg@mail.gmail.com>

On Mon, May 2, 2016 at 8:14 AM, Rick van Rein <rick at openfortress.nl> wrote:
> Hello Nikos,
> Tom and I are working on
> https://tools.ietf.org/html/draft-vanrein-tls-kdh-03
> which implements Kerberos tickets as you suggested, per RFC 7250.
> What we run into is probably a break with the GnuTLS API, and we'd like
> to hear > your opinion on this.
>
> The call to gnutls_certificate_type_get() seems to make an implicit
> assumption
> that the same certificate type is used in both directions, but with RFC 7250
> (which we are now adding) there is a possibility that these are different.
> Applications of GnuTLS might not be aware of this having been added to
> GnuTLS, and may end up being confused.

I think the best approach would be by introducing a new API (e.g.,
gnutls_certificate_type_get2()) which will allow specifying direction
or report for both directions. I think that old applications should
not be an issue because any such extension that enables different
certificate types per direction would have to be enabled explicitly
via a flag for a example to gnutls_init(). I haven't thought of it
much though. Does the above make sense?

regards,
Nikos


From rick at openfortress.nl  Mon May  2 09:48:15 2016
From: rick at openfortress.nl (Rick van Rein)
Date: Mon, 02 May 2016 09:48:15 +0200
Subject: [gnutls-devel] RFC 7250 and API change
In-Reply-To: <CAJU7zaLrfjyjFUz1n35QKKdAQuPxO=x0r0+wsi3az54ypo=CPg@mail.gmail.com>
References: <57223D85.7080702@openfortress.nl>
 <5726F031.8030109@openfortress.nl>
 <CAJU7zaLrfjyjFUz1n35QKKdAQuPxO=x0r0+wsi3az54ypo=CPg@mail.gmail.com>
Message-ID: <5727063F.9060305@openfortress.nl>

Hi Nikos,

Thanks for sharing your thoughts.

Relying on an explicit indication from the application that it can handle RFC 7250 does avoid problems in applications.  Its downside is that the acceptance of RFC 7250 is an explicit choice, and will require that explicit choice forever.  Or do you see a future path of phasing out gnutls_certificate_type_get() in favour of separate client/server certtypes?

Another form of explicit indiciation could be the priority string, by the way.  That would combine nicely with a migration to independent client/server certtypes, with a change to the default CTYPE-xxx changes; as soon as CTYPE-RAW and/or CTYPE-KRB are mentioned, it ought to be clear that client and server can each have their own certtype.  A remaining concern would be what to do with CTYPE-ALL though.


Cheers,
 -Rick


From nmav at gnutls.org  Mon May  2 12:20:43 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 2 May 2016 12:20:43 +0200
Subject: [gnutls-devel] RFC 7250 and API change
In-Reply-To: <5727063F.9060305@openfortress.nl>
References: <57223D85.7080702@openfortress.nl>
 <5726F031.8030109@openfortress.nl>
 <CAJU7zaLrfjyjFUz1n35QKKdAQuPxO=x0r0+wsi3az54ypo=CPg@mail.gmail.com>
 <5727063F.9060305@openfortress.nl>
Message-ID: <CAJU7zaLm1e=dORJ1kDh+c+ZYaird+hgT=8dJgiQB27isMjWPMw@mail.gmail.com>

On Mon, May 2, 2016 at 9:48 AM, Rick van Rein <rick at openfortress.nl> wrote:
> Hi Nikos,

> Thanks for sharing your thoughts.
> Relying on an explicit indication from the application that it can handle RFC 7250 does avoid problems in applications.  Its downside is that the acceptance of RFC 7250 is an explicit choice, and will require that explicit choice forever.  Or do you see a future path of phasing out gnutls_certificate_type_get() in favour of separate client/server certtypes?

I think that the explicit acceptance is mandated by the nature of the
change rfc7250 brings. Applications which assume that certificates
types are the same for client and server cannot be changed by a user
configurable string or option. At best they will fail with an error,
while at worst they may even crash on unexpected input from gnutls.

> Another form of explicit indiciation could be the priority string, by the way.  That would combine nicely with a migration to independent client/server certtypes, with a change to the default CTYPE-xxx changes; as soon as CTYPE-RAW and/or CTYPE-KRB are mentioned, it ought to be clear that client and server can each have their own certtype.  A remaining concern would be what to do with CTYPE-ALL though.

I believe we can easily switch from CTYPE-X509 to CTYPE-RAW or KRB,
because of the existing support for openpgp keys, but the asymmetric
certificate negotiation, is not something the current API can
accommodate without the application being explicitly modified for it.

However, even if we could avoid that explicit enabling, would that
really help? I mean is there an application which can transparently
moved to CTYPE-RAW for client and CTYPE-X509 for server keys without a
change?

regards,
Nikos


From rick at openfortress.nl  Mon May  2 12:53:22 2016
From: rick at openfortress.nl (Rick van Rein)
Date: Mon, 02 May 2016 12:53:22 +0200
Subject: [gnutls-devel] RFC 7250 and API change
In-Reply-To: <CAJU7zaLm1e=dORJ1kDh+c+ZYaird+hgT=8dJgiQB27isMjWPMw@mail.gmail.com>
References: <57223D85.7080702@openfortress.nl>
 <5726F031.8030109@openfortress.nl>
 <CAJU7zaLrfjyjFUz1n35QKKdAQuPxO=x0r0+wsi3az54ypo=CPg@mail.gmail.com>
 <5727063F.9060305@openfortress.nl>
 <CAJU7zaLm1e=dORJ1kDh+c+ZYaird+hgT=8dJgiQB27isMjWPMw@mail.gmail.com>
Message-ID: <572731A2.4000700@openfortress.nl>

Hey Nikos!

> I believe we can easily switch from CTYPE-X509 to CTYPE-RAW or KRB,
> because of the existing support for openpgp keys, but the asymmetric
> certificate negotiation, is not something the current API can
> accommodate without the application being explicitly modified for it.

As stated in this thread's subject ;-)

> However, even if we could avoid that explicit enabling, would that
> really help? I mean is there an application which can transparently
> moved to CTYPE-RAW for client and CTYPE-X509 for server keys without a
> change?

I wrote a certs cred callback for the TLS Pool before looking at RFC 7250.
It simply requests the bidir certtype and delivers what is being asked.
Had it requested the client certtype, then it would have automatically
do what it needed to do.  That is the one change that would have to be
made.  But it's only going to show up everywhere when the bidir certtype
getter stops being linkable; then app developers must choose which to
use.  And from that point on, yes the applications ought to be ready
for it, I'd say.

But that's breaking an API, and this is harsh.  As I said, no really
convenient solutions.  (Another being to have to provide an indicator
forever and ever.)

-Rick


From nmav at gnutls.org  Mon May  9 10:42:54 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 09 May 2016 10:42:54 +0200
Subject: [gnutls-devel] GnuTLS 3.5.0 released
Message-ID: <1462783374.30519.8.camel@gnutls.org>

We are proud to announce a new GnuTLS release: Version 3.5.0.

GnuTLS is a modern C library that implements the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.??GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and as well as Windows.

The GnuTLS library is distributed under the terms of the GNU Lesser
General Public License version 2 (or later).??The OpenSSL compatibility
library, the self tests and the command line tools are all distributed
under the GNU General Public License version 3.0 (or later).??The
manual is distributed under the GNU Free Documentation License version
1.3 (or later).

The project pages of the library are available at:
http://www.gnutls.org/


What's New
==========

Version 3.5.0 is the first stable release on the 3.5.x branch and is
the result of a year of planning and work [0] on the git master branch.
The GnuTLS 3.5.x branch is marked as stable-next, meaning it is
considered of stable quality but does not yet replace the current
stable releases based on 3.4.0, which will continue to be supported.

An extended summary of the most important changes is available at:
http://nmav.gnutls.org/2016/05/gnutls-3-5-0.html


[0]. https://gitlab.com/gnutls/gnutls/milestones/4



* Version 3.5.0 (released 2016-05-09)

** libgnutls: Added SHA3 based signing algorithms for DSA, RSA and
? ?ECDSA.

** libgnutls: Added support for curve X25519 (RFC 7748,?
? ?draft-ietf-tls-rfc4492bis-07). This curve is disabled by default as
? ?it is still on specification status. It can be enabled using the
? ?priority string modifier +CURVE-X25519.

** libgnutls: Added support for TLS false start?
? ?(draft-ietf-tls-falsestart-01) by introducing gnutls_init() flag
? ?GNUTLS_ENABLE_FALSE_START (#73).

** libgnutls: Added new APIs to access the FIPS186-4 (Shawe-Taylor
? ?based) provable RSA and DSA parameter generation from a seed.

** libgnutls: The CHACHA20-POLY1305 ciphersuite is enabled by default.
? ?This cipher is prioritized after AES-GCM.

** libgnutls: On a rehandshake ensure that the certificate of the peer
? ?or its username remains the same as in previous handshakes. That is
? ?to protect applications which do not check user credentials on
? ?rehandshakes. The threat to address depends on the application
? ?protocol. Primarily it protects against applications which
? ?authenticate the peer initially and perform accounting using the
? ?session's information, from being misled by a rehandshake which
? ?switches the peer's identity. Applications can disable this
? ?protection by using the %GNUTLS_ALLOW_ID_CHANGE flag in
? ?gnutls_init().

** libgnutls: Be strict in TLS extension decoding. That is, do not
? ?tolerate parsing errors in the extensions field and treat it as a
? ?typical Hello message structure. Reported by Hubert Kario (#40).

** libgnutls: Old and unsupported version numbers in client hellos are
???rejected with a "protocol_version" alert message. Reported by Hubert
???Kario (#42).

** libgnutls: Lifted the limitation of calling the
? ?gnutls_session_get_data*() functions, only on non-resumed sessions.?
? ?This brings the API in par with its usage (#79).

** libgnutls: Follow RFC5280 strictly in name constraints computation.
? ?The permitted subtrees is intersected with any previous values.?
? ?Report and patch by Daiki Ueno.

** libgnutls: Enforce the RFC 7627 (extended master secret)
? ?requirements on session resumption. Reported by Hubert Kario (#69).

** libgnutls: Consider the max-record TLS extension even when under
? ?DTLS. Reported by Peter Dettman (#61).

** libgnutls: Replaced writev() system call with sendmsg().

** libgnutls: Replaced select() system call with poll() on POSIX
? ?systems.

** libgnutls: Preload the system priority file on library load. This
? ?allows applications that chroot() to also use the system priorities.

** libgnutls: Applications are allowed to override the built-in key and
???certificate URLs.

** libgnutls: The gnutls.h header marks constant and pure functions
? ?explictly.

** certtool: Added the ability to sign certificates using SHA3.

** certtool: Added the --provable and --verify-allow-broken options.

** gnutls-cli: The --dane option will cause verification failure if
? ?gnutls is not compiled with DANE support.

** crywrap: The tool was unbundled from gnutls' distribution. It can be
? ?found at?https://github.com/nmav/crywrap

** guile: .go files are now built and installed

** guile: Fix compatibility issue of the test suite with Guile 2.1

** guile: When --with-guile-site-dir is passed, modules are installed
? ?in a versioned directory, typically $(datadir)/guile/site/2.0

** guile: Tests no longer leave zombie processes behind

** API and ABI modifications:
GNUTLS_FORCE_CLIENT_CERT: Added
GNUTLS_ENABLE_FALSE_START: Added
GNUTLS_INDEFINITE_TIMEOUT: Added
GNUTLS_ALPN_SERVER_PRECEDENCE: Added
GNUTLS_E_ASN1_EMBEDDED_NULL_IN_STRING: Added
GNUTLS_E_HANDSHAKE_DURING_FALSE_START: Added
gnutls_check_version_numeric: Added
gnutls_x509_crt_equals: Added
gnutls_x509_crt_equals2: Added
gnutls_x509_crt_set_subject_alt_othername: Added
gnutls_x509_crt_set_issuer_alt_othername: Added
gnutls_x509_crt_get_signature_oid: Added
gnutls_x509_crt_get_pk_oid: Added
gnutls_x509_crq_set_subject_alt_othername: Added
gnutls_x509_crq_get_pk_oid: Added
gnutls_x509_crq_get_signature_oid: Added
gnutls_x509_crl_get_signature_oid: Added
gnutls_x509_privkey_generate2: Added
gnutls_x509_privkey_get_seed: Added
gnutls_x509_privkey_verify_seed: Added
gnutls_privkey_generate2: Added
gnutls_privkey_get_seed: Added
gnutls_privkey_verify_seed: Added
gnutls_decode_ber_digest_info: Added
gnutls_encode_ber_digest_info: Added
gnutls_dh_params_import_dsa: Added
gnutls_session_get_master_secret: Added


Community
=========

If you need help to use GnuTLS, or want to help others, you are invited
to join our help-gnutls mailing list, see:

? http://lists.gnutls.org/mailman/listinfo/gnutls-help

If you wish to participate in the development of GnuTLS, you are
invited
to join our gnutls-dev mailing list, see:

? http://lists.gnutls.org/mailman/listinfo/gnutls-dev

Internationalization
====================

The GnuTLS library messages have been translated into Czech, Dutch,
French, German, Italian, Malay, Polish, Simplified Chinese, Swedish,
and Vietnamese.??We welcome the addition of more translations.


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 and LZIP compressed sources:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.0.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.0.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  Mon May  9 19:56:32 2016
From: ametzler at bebt.de (Andreas Metzler)
Date: Mon, 9 May 2016 19:56:32 +0200
Subject: [gnutls-devel] GnuTLS 3.5.0 - build-error in openssl wrapper
Message-ID: <20160509175632.GB1344@argenau.bebt.de>

Hello,

due to the header rearrangement the openssl wrapper fails to build.

This seems to work:
---------------------
--- gnutls28-3.5.0.orig/extra/openssl_compat.c
+++ gnutls28-3.5.0/extra/openssl_compat.c
@@ -26,8 +26,6 @@
 
 #include "gnutls_int.h"
 
-#include <gnutls_global.h>
-#include <gnutls_errors.h>
 #include <string.h>		/* memset */
 #include <x509/x509_int.h>
 #include <libtasn1.h>
---------------------

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 May 10 09:23:31 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 10 May 2016 09:23:31 +0200
Subject: [gnutls-devel] GnuTLS 3.5.0 - build-error in openssl wrapper
In-Reply-To: <20160509175632.GB1344@argenau.bebt.de>
References: <20160509175632.GB1344@argenau.bebt.de>
Message-ID: <CAJU7zaJSFTROkuOtLOMAa9N4Lb+DbQps6yjr3tTvqBwO+aZBQw@mail.gmail.com>

Applied, thank you.

On Mon, May 9, 2016 at 7:56 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> Hello,
>
> due to the header rearrangement the openssl wrapper fails to build.
>
> This seems to work:
> ---------------------
> --- gnutls28-3.5.0.orig/extra/openssl_compat.c
> +++ gnutls28-3.5.0/extra/openssl_compat.c
> @@ -26,8 +26,6 @@
>
>  #include "gnutls_int.h"
>
> -#include <gnutls_global.h>
> -#include <gnutls_errors.h>
>  #include <string.h>            /* memset */
>  #include <x509/x509_int.h>
>  #include <libtasn1.h>
> ---------------------
>
> 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'
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-devel


From nmav at gnutls.org  Fri May 20 07:46:23 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 20 May 2016 07:46:23 +0200
Subject: [gnutls-devel] gnutls 3.4.12
Message-ID: <1463723183.1970.4.camel@gnutls.org>

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

* Version 3.4.12 (released 2016-05-20)

** libgnutls: The CHACHA20-POLY1305 ciphersuite is enabled by default.
? ?This cipher is prioritized after AES-GCM.

** libgnutls: Fixes in gnutls_privkey_import_ecc_raw().

** libgnutls: Fixed gnutls_pkcs11_get_raw_issuer() usage with the
???GNUTLS_PKCS11_OBJ_FLAG_OVERWRITE_TRUSTMOD_EXT flag. Previously that
???operation could fail on certain PKCS#11 modules.

** libgnutls: gnutls_pkcs11_obj_import_url() and
? ?gnutls_x509_crt_import_url() can accept the?
? ?GNUTLS_PKCS11_OBJ_FLAG_OVERWRITE_TRUSTMOD_EXT flag.

** libgnutls: gnutls_certificate_set_key() was enhanced to import the
? ?DNS name of the certificates if the provided names are NULL.

** libgnutls: when receiving SNI names, only save and expose to
? ?application the supported DNS names.

** libgnutls: when importing the certificate names at the
???gnutls_certificate_set* functions, only consider the CN as a
? ?fallback if DNS names are provided via the alternative name
? ?extension.

** gnutls-cli: on OCSP verification do not fail if we have a single
? ?valid reply. Report and reproducer by Thomas Klute.

** libgnutls: The GNUTLS_KEYLOGFILE environment variable can be used to
???log session keys in client side. These session keys are compatible
? ?with the NSS Key Log Format and can be used to decrypt the session
? ?for debugging using wireshark.

** 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.12.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.12.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 nmav at gnutls.org  Fri May 20 07:50:14 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 20 May 2016 07:50:14 +0200
Subject: [gnutls-devel] gnutls 3.3.23
Message-ID: <1463723414.1970.6.camel@gnutls.org>

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

* Version 3.3.23 (released 2016-05-20)

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

** libgnutls: Properly print the IP Adress name constraints.

** libgnutls: Fixes in gnutls_privkey_import_ecc_raw().

** libgnutls: Fixed gnutls_pkcs11_get_raw_issuer() usage with the
???GNUTLS_PKCS11_OBJ_FLAG_OVERWRITE_TRUSTMOD_EXT flag. Previously that
???operation could fail on certain PKCS#11 modules.

** libgnutls: gnutls_pkcs11_obj_import_url() and
? ?gnutls_x509_crt_import_pkcs11_url() can accept the
? ?GNUTLS_PKCS11_OBJ_FLAG_OVERWRITE_TRUSTMOD_EXT flag.

** libgnutls: gnutls_certificate_set_key() was enhanced to import the
? ?DNS name of the certificates if the provided names are NULL.

** libgnutls: when receiving SNI names, only save and expose to
? ?application the supported DNS names.

** libgnutls: when importing the certificate names at the
???gnutls_certificate_set* functions, only consider the CN as a
? ?fallback if DNS names are provided via the alternative name
? ?extension.

** 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.

** gnutls-cli: on OCSP verification do not fail if we have a single
? ?valid reply. Report and reproducer 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.3/gnutls-3.3.23.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.23.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 tim.ruehsen at gmx.de  Fri May 20 12:49:35 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Fri, 20 May 2016 12:49:35 +0200
Subject: [gnutls-devel] Support for OCSP Must-staple ?
Message-ID: <7143243.RrO4Tg8rEH@blitz-lx>

Hi Nikos,

do you have any plans to implement/support RFC7633 in the near future ?

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160520/e70a3f94/attachment.sig>

From nmav at gnutls.org  Fri May 20 14:30:44 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 20 May 2016 14:30:44 +0200
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <7143243.RrO4Tg8rEH@blitz-lx>
References: <7143243.RrO4Tg8rEH@blitz-lx>
Message-ID: <CAJU7za+LnRPnsrwp3a27gbA0C0S=K8ktU=VfW7kQoxyyRJm-_g@mail.gmail.com>

On Fri, May 20, 2016 at 12:49 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> Hi Nikos,
> do you have any plans to implement/support RFC7633 in the near future ?

That sounds like a very good thing to have overall, and we can include
it in the 3.5.x releases. Tim (in CC) has a set of patches [1], but
unless I missed it there was no final version submitted. Tim would you
be interested in completing the submission? I've created a ticket at
[0] to make sure that this doesn't get under my radar.

regards,
Nikos

[1]. http://comments.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/8401
[0]. https://gitlab.com/gnutls/gnutls/issues/98


From jgh at wizmail.org  Fri May 20 14:02:17 2016
From: jgh at wizmail.org (Jeremy Harris)
Date: Fri, 20 May 2016 13:02:17 +0100
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <7143243.RrO4Tg8rEH@blitz-lx>
References: <7143243.RrO4Tg8rEH@blitz-lx>
Message-ID: <86972a98-8e3b-51bc-04a7-9858c7454fdb@wizmail.org>

On 20/05/16 11:49, Tim Ruehsen wrote:
> do you have any plans to implement/support RFC7633 in the near future ?

While we're asking, how about rfc6961 (full-chain staple) also?
-- 
Cheers,
  Jeremy



From tim.ruehsen at gmx.de  Fri May 20 15:28:31 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Fri, 20 May 2016 15:28:31 +0200
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <86972a98-8e3b-51bc-04a7-9858c7454fdb@wizmail.org>
References: <7143243.RrO4Tg8rEH@blitz-lx>
 <86972a98-8e3b-51bc-04a7-9858c7454fdb@wizmail.org>
Message-ID: <3270343.9oYCRCvTaW@blitz-lx>

On Friday 20 May 2016 13:02:17 Jeremy Harris wrote:
> On 20/05/16 11:49, Tim Ruehsen wrote:
> > do you have any plans to implement/support RFC7633 in the near future ?
> 
> While we're asking, how about rfc6961 (full-chain staple) also?

From my todo list ;-)

    add OCSP multi-stapling by simply merging the OCSP answers into one ASN.1 
file. gnutls-cli has to extended for that, the low-level stuff should be done 
in 3.4 branch.
    add OCSP multi-stapling to gnutls-serv, so we can test gnutls-cli with 
gnutls-serv.
    add support for this file in modgnutls of Apache, it should be straight 
forward. the GNUTLS API should be ready for doing that.
    add OCSP multi-stapling to wget2. We can test with modgnutls or gnutls-
serv.


We had some discussion about it on this list one or two years ago.
But tasks are always interrupted by higher priority tasks which are 
interrupted by ... never ending story :-(

Regarding the RFC6961... do you know of any implementation (library, client, 
server) ?
You'll find some discussions when searching for mozilla/rfc6961/ocsp... from 
what I read browser vendors doesn't like the overhead of multi-stapling. They 
go with a combination of single-stapling and caching.

So, before implementing RFC6961 you should investigate the usefulness and 
alternatives. And you should come with server support for Apache and Nginx.
Having working code for gnutls-cli and gnutls-serv could of course be a big 
advantage to get it rolling.

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160520/f1ce8c3c/attachment-0001.sig>

From nmav at gnutls.org  Fri May 20 17:32:35 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 20 May 2016 17:32:35 +0200
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <3270343.9oYCRCvTaW@blitz-lx>
References: <7143243.RrO4Tg8rEH@blitz-lx>
 <86972a98-8e3b-51bc-04a7-9858c7454fdb@wizmail.org>
 <3270343.9oYCRCvTaW@blitz-lx>
Message-ID: <CAJU7zaL-r3qb_gh79jrYatOJNA_42ogtfq6k_-msBnhDYNdwXw@mail.gmail.com>

On Fri, May 20, 2016 at 3:28 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> On Friday 20 May 2016 13:02:17 Jeremy Harris wrote:
>> On 20/05/16 11:49, Tim Ruehsen wrote:
>> > do you have any plans to implement/support RFC7633 in the near future ?
>>
>> While we're asking, how about rfc6961 (full-chain staple) also?
>
> From my todo list ;-)
>     add OCSP multi-stapling by simply merging the OCSP answers into one ASN.1
> file. gnutls-cli has to extended for that, the low-level stuff should be done
> in 3.4 branch.
>     add OCSP multi-stapling to gnutls-serv, so we can test gnutls-cli with
> gnutls-serv.
>     add support for this file in modgnutls of Apache, it should be straight
> forward. the GNUTLS API should be ready for doing that.
>     add OCSP multi-stapling to wget2. We can test with modgnutls or gnutls-
> serv.
> We had some discussion about it on this list one or two years ago.
> But tasks are always interrupted by higher priority tasks which are
> interrupted by ... never ending story :-(

That attempt is on the ocsp2 branch at:
https://gitlab.com/gnutls/gnutls/commits/ocsp2

I don't remember how far it was gone, or whether it can apply on
master, but I remember I didn't follow up because there were no other
implementations of it, nor any plans for it. I can see it is still
open at NSS and openssl. However, with the track OCSP stapling is
taking, this will become something required in the future. So if there
is someone to push for it and creates the required tooling (for an
admin to agreegate ocsp responses) I'm all for it to include it.

regards,
Nikos


From tim.ruehsen at gmx.de  Sat May 21 11:22:29 2016
From: tim.ruehsen at gmx.de (Tim =?ISO-8859-1?Q?R=FChsen?=)
Date: Sat, 21 May 2016 11:22:29 +0200
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <CAJU7zaL-r3qb_gh79jrYatOJNA_42ogtfq6k_-msBnhDYNdwXw@mail.gmail.com>
References: <7143243.RrO4Tg8rEH@blitz-lx> <3270343.9oYCRCvTaW@blitz-lx>
 <CAJU7zaL-r3qb_gh79jrYatOJNA_42ogtfq6k_-msBnhDYNdwXw@mail.gmail.com>
Message-ID: <3537830.sU1Fabnc3y@debian>

Am Freitag, 20. Mai 2016, 17:32:35 schrieb Nikos Mavrogiannopoulos:
> On Fri, May 20, 2016 at 3:28 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > On Friday 20 May 2016 13:02:17 Jeremy Harris wrote:
> >> On 20/05/16 11:49, Tim Ruehsen wrote:
> >> > do you have any plans to implement/support RFC7633 in the near future ?
> >> 
> >> While we're asking, how about rfc6961 (full-chain staple) also?
> > 
> > From my todo list ;-)
> > 
> >     add OCSP multi-stapling by simply merging the OCSP answers into one
> >     ASN.1
> > 
> > file. gnutls-cli has to extended for that, the low-level stuff should be
> > done in 3.4 branch.
> > 
> >     add OCSP multi-stapling to gnutls-serv, so we can test gnutls-cli with
> > 
> > gnutls-serv.
> > 
> >     add support for this file in modgnutls of Apache, it should be
> >     straight
> > 
> > forward. the GNUTLS API should be ready for doing that.
> > 
> >     add OCSP multi-stapling to wget2. We can test with modgnutls or
> >     gnutls-
> > 
> > serv.
> > We had some discussion about it on this list one or two years ago.
> > But tasks are always interrupted by higher priority tasks which are
> > interrupted by ... never ending story :-(
> 
> That attempt is on the ocsp2 branch at:
> https://gitlab.com/gnutls/gnutls/commits/ocsp2
> 
> I don't remember how far it was gone, or whether it can apply on
> master, but I remember I didn't follow up because there were no other
> implementations of it, nor any plans for it. I can see it is still
> open at NSS and openssl. However, with the track OCSP stapling is
> taking, this will become something required in the future. So if there
> is someone to push for it and creates the required tooling (for an
> admin to agreegate ocsp responses) I'm all for it to include it.

Could you rebase/merge ocsp2 onto/with master (or 3_4_x) ?
It seems to be not straight forward to me and you know your code.

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160521/2fac8689/attachment.sig>

From jkmalinen at gmail.com  Sat May 21 20:05:03 2016
From: jkmalinen at gmail.com (Jouni Malinen)
Date: Sat, 21 May 2016 21:05:03 +0300
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <CAJU7zaL-r3qb_gh79jrYatOJNA_42ogtfq6k_-msBnhDYNdwXw@mail.gmail.com>
References: <7143243.RrO4Tg8rEH@blitz-lx>
 <86972a98-8e3b-51bc-04a7-9858c7454fdb@wizmail.org>
 <3270343.9oYCRCvTaW@blitz-lx>
 <CAJU7zaL-r3qb_gh79jrYatOJNA_42ogtfq6k_-msBnhDYNdwXw@mail.gmail.com>
Message-ID: <CANe27j+fpvPbZggnWpi0FbMQxEv=pGSmoVspth1oJWnbYpwbNw@mail.gmail.com>

On Fri, May 20, 2016 at 6:32 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> That attempt is on the ocsp2 branch at:
> https://gitlab.com/gnutls/gnutls/commits/ocsp2
>
> I don't remember how far it was gone, or whether it can apply on
> master, but I remember I didn't follow up because there were no other
> implementations of it, nor any plans for it. I can see it is still
> open at NSS and openssl. However, with the track OCSP stapling is
> taking, this will become something required in the future. So if there
> is someone to push for it and creates the required tooling (for an
> admin to agreegate ocsp responses) I'm all for it to include it.

For quite some time, I was hoping to get ocsp_multi support available
in one or more of the common TLS libraries to be able to use this in
wpa_supplicant and hostapd. I ended up implementing an experimental
version in the internal TLS implementation in hostap.git for both the
server and client side so that I can at least test this functionality
with WPA2 and EAP authentication. Since I also added support for using
GnuTLS with server side OCSP stapling, I'd hope it would be relatively
simple addition to get this running for interop testing (hostapd with
GnuTLS as the EAP server and wpa_supplicant with the internal TLS
client implementation as the EAP peer) if the GnuTLS implementation is
expected to be in more or less functional state for OCSP stapling with
the RFC 6961 extensions. I have fully automated test cases for that
ready as well.

- Jouni


From nmav at gnutls.org  Mon May 23 09:43:35 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 23 May 2016 09:43:35 +0200
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <CANe27j+fpvPbZggnWpi0FbMQxEv=pGSmoVspth1oJWnbYpwbNw@mail.gmail.com>
References: <7143243.RrO4Tg8rEH@blitz-lx>
 <86972a98-8e3b-51bc-04a7-9858c7454fdb@wizmail.org>
 <3270343.9oYCRCvTaW@blitz-lx>
 <CAJU7zaL-r3qb_gh79jrYatOJNA_42ogtfq6k_-msBnhDYNdwXw@mail.gmail.com>
 <CANe27j+fpvPbZggnWpi0FbMQxEv=pGSmoVspth1oJWnbYpwbNw@mail.gmail.com>
Message-ID: <CAJU7za+8Bom4OtAdCXaBiaFvuA7_mzBvY=iR9RxvnOqUE1Wa5Q@mail.gmail.com>

On Sat, May 21, 2016 at 8:05 PM, Jouni Malinen <jkmalinen at gmail.com> wrote:
> For quite some time, I was hoping to get ocsp_multi support available
> in one or more of the common TLS libraries to be able to use this in
> wpa_supplicant and hostapd. I ended up implementing an experimental
> version in the internal TLS implementation in hostap.git for both the
> server and client side so that I can at least test this functionality
> with WPA2 and EAP authentication. Since I also added support for using
> GnuTLS with server side OCSP stapling, I'd hope it would be relatively
> simple addition to get this running for interop testing (hostapd with
> GnuTLS as the EAP server and wpa_supplicant with the internal TLS
> client implementation as the EAP peer) if the GnuTLS implementation is
> expected to be in more or less functional state for OCSP stapling with
> the RFC 6961 extensions. I have fully automated test cases for that
> ready as well.

That's very nice. It certainly helps me prioritise that higher. My
question is how do you have administrators to provide the multiple
responses in your implementation?

regards,
Nikos


From jkmalinen at gmail.com  Mon May 23 10:14:42 2016
From: jkmalinen at gmail.com (Jouni Malinen)
Date: Mon, 23 May 2016 11:14:42 +0300
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <CAJU7za+8Bom4OtAdCXaBiaFvuA7_mzBvY=iR9RxvnOqUE1Wa5Q@mail.gmail.com>
References: <7143243.RrO4Tg8rEH@blitz-lx>
 <86972a98-8e3b-51bc-04a7-9858c7454fdb@wizmail.org>
 <3270343.9oYCRCvTaW@blitz-lx>
 <CAJU7zaL-r3qb_gh79jrYatOJNA_42ogtfq6k_-msBnhDYNdwXw@mail.gmail.com>
 <CANe27j+fpvPbZggnWpi0FbMQxEv=pGSmoVspth1oJWnbYpwbNw@mail.gmail.com>
 <CAJU7za+8Bom4OtAdCXaBiaFvuA7_mzBvY=iR9RxvnOqUE1Wa5Q@mail.gmail.com>
Message-ID: <CANe27j+6R5F3DintioRdeMsoV9ipD1bd=bXKroCy7BgOYt1zOw@mail.gmail.com>

On Mon, May 23, 2016 at 10:43 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> That's very nice. It certainly helps me prioritise that higher. My
> question is how do you have administrators to provide the multiple
> responses in your implementation?

Since the main use case for hostapd as authentication server is
testing purposes, I'm simply using a file with the fixed responses
(DER encoded OCSPResponseList). Or well, the file can be replaced as
an update at runtime, but anyway, all the details on how to generate
the actual OCSP responses is out-of-scope for hostapd. For the
automated testing needs, I have the test script build this from two
OCSP responses

# Cached OCSP stapling response list (DER encoded OCSPResponseList)
# This is similar to ocsp_stapling_response, but the extended version defined in
# RFC 6961 to allow multiple OCSP responses to be provided.
#ocsp_stapling_response_multi=/tmp/ocsp-multi-cache.der

That reference to ocsp_stapling_response is the pre-RFC 6961 case of a
single response. The data in that file is exactly what I return from
the callback function registered with
gnutls_certificate_set_ocsp_status_request_function(). For ocsp_multi,
I'd need to either have the callback function return that DER encoded
OCSPResponseList or make the function convert it to whatever the
GnuTLS API needs for this on the server side.

- Jouni


From nmav at gnutls.org  Wed May 25 09:07:26 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 25 May 2016 09:07:26 +0200
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <3030f504-b81f-2003-4079-f7e19a8286c2@filezilla-project.org>
References: <7143243.RrO4Tg8rEH@blitz-lx>
 <CAJU7za+LnRPnsrwp3a27gbA0C0S=K8ktU=VfW7kQoxyyRJm-_g@mail.gmail.com>
 <3030f504-b81f-2003-4079-f7e19a8286c2@filezilla-project.org>
Message-ID: <CAJU7za+-2nGpR=L6tqm+vhReOTF5s_kNxCzbmZW2MRZfCw9=KQ@mail.gmail.com>

On Mon, May 23, 2016 at 11:50 PM, Tim Kosse
<tim.kosse at filezilla-project.org> wrote:
> Hi,
> sorry, I had too many other things to do and then forgot about this :(
> Please have a look at the attached patch series for everything I
> implemented so far.

Thank you. I'll try to take over this patch and fill the missing parts.

regards,
Nikos


From nmav at gnutls.org  Wed May 25 09:13:35 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 25 May 2016 09:13:35 +0200
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <3537830.sU1Fabnc3y@debian>
References: <7143243.RrO4Tg8rEH@blitz-lx> <3270343.9oYCRCvTaW@blitz-lx>
 <CAJU7zaL-r3qb_gh79jrYatOJNA_42ogtfq6k_-msBnhDYNdwXw@mail.gmail.com>
 <3537830.sU1Fabnc3y@debian>
Message-ID: <CAJU7zaLTvLKgtQPKXmuB_S0mSw7VSXiCvXcCO=oBHrNduQDGmw@mail.gmail.com>

On Sat, May 21, 2016 at 11:22 AM, Tim R?hsen <tim.ruehsen at gmx.de> wrote:
>> I don't remember how far it was gone, or whether it can apply on
>> master, but I remember I didn't follow up because there were no other
>> implementations of it, nor any plans for it. I can see it is still
>> open at NSS and openssl. However, with the track OCSP stapling is
>> taking, this will become something required in the future. So if there
>> is someone to push for it and creates the required tooling (for an
>> admin to agreegate ocsp responses) I'm all for it to include it.
> Could you rebase/merge ocsp2 onto/with master (or 3_4_x) ?
> It seems to be not straight forward to me and you know your code.

It is long time since this code was written and I have no idea on what
state it is. A rebase will most likely account for a rewrite, so I'll
postpone that for after Tim's OCSP-must staple patches are merged, and
I have some time to spend on it.

regards,
Nikos


From ametzler at bebt.de  Sun May 29 11:55:16 2016
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 29 May 2016 11:55:16 +0200
Subject: [gnutls-devel] [patch] typo fix
Message-ID: <20160529095516.GC1472@argenau.bebt.de>

Hello, 

find attached a trivial patch against GIT master to fix a typo found by
lintian.

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'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Typo-fix-auxilary-auxiliary.patch
Type: text/x-diff
Size: 634 bytes
Desc: not available
URL: </pipermail/attachments/20160529/1fa11874/attachment.patch>

From nmav at gnutls.org  Sun May 29 19:18:16 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 29 May 2016 19:18:16 +0200
Subject: [gnutls-devel] [patch] typo fix
In-Reply-To: <20160529095516.GC1472@argenau.bebt.de>
References: <20160529095516.GC1472@argenau.bebt.de>
Message-ID: <1464542296.5398.0.camel@gnutls.org>

On Sun, 2016-05-29 at 11:55 +0200, Andreas Metzler wrote:
> Hello,?
> 
> find attached a trivial patch against GIT master to fix a typo found
> by lintian.

Thank you. Applied.




From nmav at gnutls.org  Mon May 30 11:05:10 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 30 May 2016 11:05:10 +0200
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <CAJU7za+-2nGpR=L6tqm+vhReOTF5s_kNxCzbmZW2MRZfCw9=KQ@mail.gmail.com>
References: <7143243.RrO4Tg8rEH@blitz-lx>
 <CAJU7za+LnRPnsrwp3a27gbA0C0S=K8ktU=VfW7kQoxyyRJm-_g@mail.gmail.com>
 <3030f504-b81f-2003-4079-f7e19a8286c2@filezilla-project.org>
 <CAJU7za+-2nGpR=L6tqm+vhReOTF5s_kNxCzbmZW2MRZfCw9=KQ@mail.gmail.com>
Message-ID: <CAJU7zaLsMqWiCObzsv-Zgwbg0tOvcmCp_keMN5s8H8fQCduF_A@mail.gmail.com>

On Wed, May 25, 2016 at 9:07 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On Mon, May 23, 2016 at 11:50 PM, Tim Kosse
> <tim.kosse at filezilla-project.org> wrote:
>> Hi,
>> sorry, I had too many other things to do and then forgot about this :(
>> Please have a look at the attached patch series for everything I
>> implemented so far.
> Thank you. I'll try to take over this patch and fill the missing parts.

Do you happen to have a 3rd-party generated certificate with the
TLSFeature extension being present?

regards,
Nikos


From tim.kosse at filezilla-project.org  Mon May 30 11:43:54 2016
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Mon, 30 May 2016 11:43:54 +0200
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <CAJU7zaLsMqWiCObzsv-Zgwbg0tOvcmCp_keMN5s8H8fQCduF_A@mail.gmail.com>
References: <7143243.RrO4Tg8rEH@blitz-lx>
 <CAJU7za+LnRPnsrwp3a27gbA0C0S=K8ktU=VfW7kQoxyyRJm-_g@mail.gmail.com>
 <3030f504-b81f-2003-4079-f7e19a8286c2@filezilla-project.org>
 <CAJU7za+-2nGpR=L6tqm+vhReOTF5s_kNxCzbmZW2MRZfCw9=KQ@mail.gmail.com>
 <CAJU7zaLsMqWiCObzsv-Zgwbg0tOvcmCp_keMN5s8H8fQCduF_A@mail.gmail.com>
Message-ID: <f4f2fd51-fec6-1c74-6c46-3d2ecbef51b6@filezilla-project.org>

Hi,

unfortunately no. I used to test against
https://must-staple.serverhello.com/ but that site now seems to be offline.

Regards,
Tim

On 2016-05-30 11:05, Nikos Mavrogiannopoulos wrote:
> On Wed, May 25, 2016 at 9:07 AM, Nikos Mavrogiannopoulos
> <nmav at gnutls.org> wrote:
>> On Mon, May 23, 2016 at 11:50 PM, Tim Kosse
>> <tim.kosse at filezilla-project.org> wrote:
>>> Hi,
>>> sorry, I had too many other things to do and then forgot about this :(
>>> Please have a look at the attached patch series for everything I
>>> implemented so far.
>> Thank you. I'll try to take over this patch and fill the missing parts.
> 
> Do you happen to have a 3rd-party generated certificate with the
> TLSFeature extension being present?
> 
> regards,
> Nikos
> 


From tim.kosse at filezilla-project.org  Mon May 30 16:07:20 2016
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Mon, 30 May 2016 16:07:20 +0200
Subject: [gnutls-devel] DCO
Message-ID: <0c0326f7-4129-737a-3625-dffee659cece@filezilla-project.org>

Hi,

here's the DCO for my contributions:


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

Tim Kosse


From tim.ruehsen at gmx.de  Tue May 31 10:42:38 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Tue, 31 May 2016 10:42:38 +0200
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <CAJU7zaLsMqWiCObzsv-Zgwbg0tOvcmCp_keMN5s8H8fQCduF_A@mail.gmail.com>
References: <7143243.RrO4Tg8rEH@blitz-lx>
 <CAJU7za+-2nGpR=L6tqm+vhReOTF5s_kNxCzbmZW2MRZfCw9=KQ@mail.gmail.com>
 <CAJU7zaLsMqWiCObzsv-Zgwbg0tOvcmCp_keMN5s8H8fQCduF_A@mail.gmail.com>
Message-ID: <7920617.erErHS9Ips@blitz-lx>

Just found one: suche.org

                Unknown extension 1.3.6.1.5.5.7.1.24 (not critical):
                        ASCII: 0....
                        Hexdump: 3003020105

Tim

On Monday 30 May 2016 11:05:10 Nikos Mavrogiannopoulos wrote:
> On Wed, May 25, 2016 at 9:07 AM, Nikos Mavrogiannopoulos
> 
> <nmav at gnutls.org> wrote:
> > On Mon, May 23, 2016 at 11:50 PM, Tim Kosse
> > 
> > <tim.kosse at filezilla-project.org> wrote:
> >> Hi,
> >> sorry, I had too many other things to do and then forgot about this :(
> >> Please have a look at the attached patch series for everything I
> >> implemented so far.
> > 
> > Thank you. I'll try to take over this patch and fill the missing parts.
> 
> Do you happen to have a 3rd-party generated certificate with the
> TLSFeature extension being present?
> 
> regards,
> Nikos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160531/9d4e5e16/attachment-0001.sig>

From nmav at gnutls.org  Tue May 31 14:42:14 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 31 May 2016 14:42:14 +0200
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <7920617.erErHS9Ips@blitz-lx>
References: <7143243.RrO4Tg8rEH@blitz-lx>
 <CAJU7za+-2nGpR=L6tqm+vhReOTF5s_kNxCzbmZW2MRZfCw9=KQ@mail.gmail.com>
 <CAJU7zaLsMqWiCObzsv-Zgwbg0tOvcmCp_keMN5s8H8fQCduF_A@mail.gmail.com>
 <7920617.erErHS9Ips@blitz-lx>
Message-ID: <CAJU7zaKv1H1uqwZ8hcHBiM3Q-AV2eOSfk8rq22WsE17fXmYCvQ@mail.gmail.com>

On Tue, May 31, 2016 at 10:42 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> Just found one: suche.org
>
>                 Unknown extension 1.3.6.1.5.5.7.1.24 (not critical):
>                         ASCII: 0....
>                         Hexdump: 3003020105

Thank you. It seems it is correctly listed from certtool in master:
        TLS Features (not critical):
            Status Request(5)

However, I realized that this pkix extension is quite undefined. There
is no well-defined behavior for "status_request_v2" and that issue
will show up once (and if) the multiple ocsp responses get deployed.

I've sent a mail to the author of rfc7633 and saag [0], but it is
unknown whether anything productive will come out of it. Most likely
this TlsFeature extension will be used  with a single value (5) to
indicate for ocsp status request or the multi one.

regards,
Nikos

[0]. https://mailarchive.ietf.org/arch/msg/saag/52aBuwqIP30dIcIVCkDw6v59YN0


From tim.kosse at filezilla-project.org  Tue May 24 00:29:00 2016
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Mon, 23 May 2016 22:29:00 -0000
Subject: [gnutls-devel] Support for OCSP Must-staple ?
In-Reply-To: <CAJU7za+LnRPnsrwp3a27gbA0C0S=K8ktU=VfW7kQoxyyRJm-_g@mail.gmail.com>
References: <7143243.RrO4Tg8rEH@blitz-lx>
 <CAJU7za+LnRPnsrwp3a27gbA0C0S=K8ktU=VfW7kQoxyyRJm-_g@mail.gmail.com>
Message-ID: <3030f504-b81f-2003-4079-f7e19a8286c2@filezilla-project.org>

Hi,

sorry, I had too many other things to do and then forgot about this :(

Please have a look at the attached patch series for everything I
implemented so far.

If I remember correctly, the following things are still missing:
- More unit tests
- Copying of the feature extension data from CRQs into the generated
certificates
- Dealing with certificate chains as described in section 4.2.2 of RFC7633

Regards,
Tim

On 2016-05-20 14:30, Nikos Mavrogiannopoulos wrote:
> On Fri, May 20, 2016 at 12:49 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> Hi Nikos,
>> do you have any plans to implement/support RFC7633 in the near future ?
> 
> That sounds like a very good thing to have overall, and we can include
> it in the 3.5.x releases. Tim (in CC) has a set of patches [1], but
> unless I missed it there was no final version submitted. Tim would you
> be interested in completing the submission? I've created a ticket at
> [0] to make sure that this doesn't get under my radar.
> 
> regards,
> Nikos
> 
> [1]. http://comments.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/8401
> [0]. https://gitlab.com/gnutls/gnutls/issues/98
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0012-Fix-exporting-the-DER-for-the-tlsfeatures.patch
Type: text/x-patch
Size: 1294 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0022.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0013-Implement-setting-the-TLS-features-extension-on-cert.patch
Type: text/x-patch
Size: 3739 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0023.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0014-Honor-the-passed-type-in-get_tlsfeatures_set.patch
Type: text/x-patch
Size: 991 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0024.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0015-Add-functions-to-get-set-the-tlsfeatures-to-certific.patch
Type: text/x-patch
Size: 4583 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0025.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0016-Add-tlsfeatures-to-generated-certificate-requests.patch
Type: text/x-patch
Size: 633 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0026.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0017-Fix-indentation-of-features-when-printing-crq-detail.patch
Type: text/x-patch
Size: 1266 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0027.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0018-Fix-the-description-of-two-testcases.patch
Type: text/x-patch
Size: 1376 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0028.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0019-Move-call-to-terminate-until-after-printing-the-erro.patch
Type: text/x-patch
Size: 2740 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0029.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0020-Add-testcase-to-check-for-missing-status-request-fro.patch
Type: text/x-patch
Size: 10410 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0030.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0021-Reset-extensions_sent_size-only-at-start-of-handshak.patch
Type: text/x-patch
Size: 1679 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0031.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0022-Fix-memory-leaks.patch
Type: text/x-patch
Size: 1244 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0032.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-the-TLS-Features-extension-from-RFC-7633-to-the-.patch
Type: text/x-patch
Size: 1361 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0033.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Implement-functions-to-parse-the-TLSFeatures-X.509-e.patch
Type: text/x-patch
Size: 8263 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0034.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-If-we-have-sent-an-OCSP-status-request-and-have-not-.patch
Type: text/x-patch
Size: 3943 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0035.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Fix-a-typo-in-the-documentation-it-s-spelled-OCSP.patch
Type: text/x-patch
Size: 950 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0036.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-Use-_gnutls_extension_list_check-instead-of-manually.patch
Type: text/x-patch
Size: 1905 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0037.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-Add-gnutls_x509_crt_get_tlsfeatures-and-move-the-ver.patch
Type: text/x-patch
Size: 10188 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0038.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-Fix-datatypes-and-document-the-new-functions.patch
Type: text/x-patch
Size: 7559 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0039.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0008-Add-gnutls_x509_ext_export_tlsfeatures-to-convert-th.patch
Type: text/x-patch
Size: 2583 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0040.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0009-Implement-gnutls_x509_tlsfeatures_add-to-add-feature.patch
Type: text/x-patch
Size: 2055 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0041.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0010-Add-the-new-function-for-the-tlsfeatures-to-libgnutl.patch
Type: text/x-patch
Size: 1835 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0042.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0011-Implement-gnutls_x509_crt_set_tlsfeatures.patch
Type: text/x-patch
Size: 2012 bytes
Desc: not available
URL: </pipermail/attachments/20160523/01646018/attachment-0043.bin>