From nmav at gnutls.org  Wed Jul  6 09:21:36 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 06 Jul 2016 09:21:36 +0200
Subject: [gnutls-help] gnutls 3.4.14
Message-ID: <1467789696.7018.7.camel@gnutls.org>

Hello,?
?I've just released gnutls 3.4.14. This is a bug fix release of the
current stable branch, which addresses a vulnerability on systems
which utilize gnutls with the p11-kit trust module -see
http://www.gnutls.org/security.html#GNUTLS-SA-2016-2

* Version 3.4.14 (released 2016-06-06)

** libgnutls: Address issue when utilizing the p11-kit trust store
???for certificate verification (GNUTLS-SA-2016-2).

** libgnutls: Fixed DTLS handshake packet reconstruction. Reported by
???Guillaume Roguez.

** libgnutls: Fixed issues with PKCS#11 reading of sensitive objects
???from SafeNet Network HSM. Reported by Anthony Alba.

** libgnutls: Corrected the writing of PKCS#11 CKA_SERIAL_NUMBER.
? ?Report and fix by Stanislav ?idek.

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

Here are OpenPGP detached signatures signed using key 0x96865171:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.14.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  Wed Jul  6 09:21:43 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 06 Jul 2016 09:21:43 +0200
Subject: [gnutls-help] gnutls 3.5.2
Message-ID: <1467789703.7018.8.camel@gnutls.org>

Hello,?
?I've just released gnutls 3.5.2. This is a bugfix release for
the 3.5.x branch, which also addresses a vulnerability on systems
which utilize gnutls with the p11-kit trust module.

* Version 3.5.2 (released 2016-06-06)

** libgnutls: Address issue when utilizing the p11-kit trust store
???for certificate verification (GNUTLS-SA-2016-2).

** libgnutls: Fixed DTLS handshake packet reconstruction. Reported by
???Guillaume Roguez.

** libgnutls: Fixed issues with PKCS#11 reading of sensitive objects
???from SafeNet Network HSM. Reported by Anthony Alba in #108.

** libgnutls: Corrected the writing of PKCS#11 CKA_SERIAL_NUMBER.
? ?Report and fix by Stanislav ?idek.

** libgnutls: Added AES-GCM optimizations using the AVX and MOVBE
???instructions. Uses Andy Polyakov's assembly code.

** 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.5/gnutls-3.5.2.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.2.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  Wed Jul  6 09:21:19 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 06 Jul 2016 09:21:19 +0200
Subject: [gnutls-help] gnutls 3.3.24
Message-ID: <1467789679.7018.6.camel@gnutls.org>

Hello,?
?I've just released gnutls 3.3.24. This is a bug-fix release on
the previous stable branch which also addresses a vulnerability on
systems which utilize gnutls with the p11-kit trust module -see
http://www.gnutls.org/security.html#GNUTLS-SA-2016-2

* Version 3.3.24 (released 2016-06-06)

** libgnutls: Address issue when utilizing the p11-kit trust store
???for certificate verification (GNUTLS-SA-2016-2).

** libgnutls: when generating private keys mark the public key as not
???private.

** libgnutls: use secure_getenv() where available to obtain environment
???variables.

** libgnutls: Fixed DTLS handshake packet reconstruction. Reported by
???Guillaume Roguez.

** libgnutls: Fixed issues with PKCS#11 reading of sensitive objects
???from SafeNet Network HSM. Reported by Anthony Alba.

** libgnutls: Corrected reading and writing of PKCS#11
? ?CKA_SERIAL_NUMBER. Report and fix by Stanislav ?idek.

** libgnutls: Enhanced the priority functions to understand -VERS-ALL
? ?keyword to allow compatibility of priority strings between 3.4.x
? ?and 3.3.x.

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

Here are OpenPGP detached signatures signed using key 0x96865171:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.24.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 rudi at droho.nl  Thu Jul  7 23:29:08 2016
From: rudi at droho.nl (Rudi van Houten)
Date: Thu, 7 Jul 2016 23:29:08 +0200
Subject: [gnutls-help] install gnutls failed on MacOSX 10.11.5 (El Capitan)
Message-ID: <2F2FAC00-D782-4A17-B014-E2D5F0EC620A@droho.nl>

Hallo,
I try to install gnutls, needed for wget.
GnuTLS needs libgmp (no problem) and libnettle, and that seems
a problem.
I installed the youngest libnettle that I found (3.2) but the gnutls
configure scripts complains about not finding nettle-3.1.

I also tried with nettle versions 3.0 and 3.1, SAME RESULT, NO SUCCESS.

The 'make install' in nettle babbles about libnettle.6

What can I do to get gnutls correctly compiled and installed?

thanks for advice, I retired 10 years ago as unix system administrator and
thought this should be a routine job. But no ....... HELP!!

tail from make install in libnettle-3.2:
-----
echo timestamp > stamp-h
./install-sh -c -d /usr/local/lib
for f in libnettle.a ; do \
          /usr/bin/install -c -m 644 $f /usr/local/lib ; \
        done
./install-sh -c -d /usr/local/lib/pkgconfig
for f in nettle.pc  ; do \
          /usr/bin/install -c -m 644 "$f" /usr/local/lib/pkgconfig ; \
        done
./install-sh -c -d /usr/local/lib
/usr/bin/install -c -m 644 libnettle.dylib /usr/local/lib/libnettle.6.2.dylib
[ -z "libnettle.6.dylib" ] \
                || (cd /usr/local/lib \
                && rm -f libnettle.6.dylib libnettle.dylib \
                && ln -s libnettle.6.2.dylib libnettle.6.dylib \
                && ln -s libnettle.6.2.dylib libnettle.dylib)
set -e; for d in tools testsuite examples; do \
          echo "Making install in $d" ; (cd $d && /Applications/Xcode.app/Contents/Developer/usr/bin/make install); done
Making install in tools
.././install-sh -c -d /usr/local/bin
for f in sexp-conv nettle-hash nettle-pbkdf2 nettle-lfib-stream  ; do \
          /usr/bin/install -c $f /usr/local/bin ; \
        done
Making install in testsuite
true
Making install in examples
true
houten at goudreinet (738)>

===============================================================
tail from ./configure in gnutls-3.5.2
-----
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for bison... bison -y
checking for a sed that does not truncate output... /usr/bin/sed
checking whether to build with code coverage support... no
checking for autogen... :
configure: WARNING:
***
*** autogen not found. Will not link against libopts.
***
checking for inline... inline
checking for ANSI C header files... (cached) yes
checking cpuid.h usability... yes
checking cpuid.h presence... yes
checking for cpuid.h... yes
checking for getrandom... no
checking for getentropy... no
checking for NETTLE... no
configure: error:
  ***
  *** Libnettle 3.1 was not found.

houten at goudreinet (746)>


-- 
Rudi van Houten -- Netherlands
:-) Fantasy is given mankind to make amends for what he is not,
    and a sense of humour as consolation for what he is.





From nmav at gnutls.org  Fri Jul  8 16:29:38 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 8 Jul 2016 16:29:38 +0200
Subject: [gnutls-help] install gnutls failed on MacOSX 10.11.5 (El
	Capitan)
In-Reply-To: <2F2FAC00-D782-4A17-B014-E2D5F0EC620A@droho.nl>
References: <2F2FAC00-D782-4A17-B014-E2D5F0EC620A@droho.nl>
Message-ID: <CAJU7za+8F5x4iZZZjSX01=KiePd=HcN7hgb_y5k+q6u8cF0sxg@mail.gmail.com>

On Thu, Jul 7, 2016 at 11:29 PM, Rudi van Houten <rudi at droho.nl> wrote:
> Hallo,
> I try to install gnutls, needed for wget.
> GnuTLS needs libgmp (no problem) and libnettle, and that seems
> a problem.
> I installed the youngest libnettle that I found (3.2) but the gnutls
> configure scripts complains about not finding nettle-3.1.

Most likely pkg-config doesn't detect the library. You need to
override NETTLE_LIBS and NETTLE_CFLAGS with the right ones.

regards,
Nikos


From hramrach at gmail.com  Wed Jul 13 16:20:24 2016
From: hramrach at gmail.com (Michal Suchanek)
Date: Wed, 13 Jul 2016 16:20:24 +0200
Subject: [gnutls-help] SSL priority and handshake error
Message-ID: <CAOMqctS6g+favq=LHLmTK3iH_WOqkFbRJFsg3mDhSONxAL92eQ@mail.gmail.com>

Hello,

I tried to dust off a piece of old GnuTLS code and I get this error:

./httpfs2-ssl: SSL init: loaded 173 CA certificate(s).
Thread main initializing SSL socket.
./httpfs2-ssl: invalid SSL priority
 NORMAL
 ^
./httpfs2-ssl: sourceforge.net:443 - ./httpfs2-ssl: SSL connection
failed: -12 Handshake failed.

The code was developed with older GnuTLS on Debian 7. The requirements
say GnuTLS >= 2.10.

It is difficult to install such an old version of GnuTLS without
breaking my system.

However, Debian still carries 2.12.20-8+deb7u5 which gives different error:

./httpfs2-ssl: SSL init: loaded 173 CA certificate(s).
Thread main initializing SSL socket.
./httpfs2-ssl: sourceforge.net:443 - ./httpfs2-ssl: SSL connection
failed: -12 Handshake failed.

3.x version available in Debian (3.5.2-1, 3.4.14-1, 3.4.13-1,
3.3.8-6+deb8u3) all have this issue.

The problem is that the r = gnutls_priority_set_direct(url->ss, ps,
&errp); line sets errp even when no error is reported.

Extra line if (!r) errp = NULL; is required to provide correct
diagnostics in GnuTLS 3.x.

So now that this turns out to be a hanshake error how do you diagnose these?

Is there some sample code for printing intelligible diagnostic in the
event handshake fails?

Thanks

Michal

The code in question looks like this (ripped from some example):

        /* Make SSL connection. */
        int r = 0;
        const char * ps = "NORMAL"; /* FIXME allow user setting */
        const char * errp = NULL;
        if (!url->ssl_initialized) {
            r = gnutls_global_init();
            if (!r)
                r = gnutls_certificate_allocate_credentials
(&url->sc); /* docs suggest to share creds */
            if (url->cafile) {
                if (!r)
                    r = gnutls_certificate_set_x509_trust_file
(url->sc, url->cafile, GNUTLS_X509_FMT_PEM);
                if (r>0)
                    fprintf(stderr, "%s: SSL init: loaded %i CA
certificate(s).\n", argv0, r);
                if (r>0) r = 0;
            }
            if (!r)
                gnutls_certificate_set_verify_function (url->sc,
verify_certificate_callback);
            gnutls_certificate_set_verify_flags (url->sc,
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT /* suggested */
                    | url->md5 | url->md2 ); /* oprional for old cert compat */
            if (!r) url->ssl_initialized = 1;
            gnutls_global_set_log_level((int)url->ssl_log_level);
            gnutls_global_set_log_function(&logfunc);
        }
        if (r) {
            ssl_error(r, url->ss, "SSL init");
            return -1;
        }

        fprintf(stderr, "Thread %s initializing SSL socket.\n", url->tname);
        r = gnutls_init(&url->ss, GNUTLS_CLIENT);
        if (!r) gnutls_session_set_ptr(url->ss, url); /* used in cert
verifier */
        if (!r) r = gnutls_priority_set_direct(url->ss, ps, &errp);
        if (!r) errp = NULL;
        //if (!r) gnutls_set_default_priority(url->ss);
        if (!r) r = gnutls_credentials_set(url->ss,
GNUTLS_CRD_CERTIFICATE, url->sc);
        if (!r) gnutls_transport_set_ptr(url->ss,
(gnutls_transport_ptr_t) (intptr_t) url->sockfd);
        if (!r) r = gnutls_handshake (url->ss); /* FIXME
gnutls_error_is_fatal is recommended here */
        if (r) {
            close(url->sockfd);
            if (errp) fprintf(stderr, "%s: invalid SSL priority\n %s\n
%*s\n", argv0, ps, (int)(errp - ps), "^");
            fprintf(stderr, "%s: %s:%d - ", argv0, url->host, url->port);
            ssl_error(r, url->ss, "SSL connection failed");
            fprintf(stderr, "Thread %s closing SSL socket.\n", url->tname);
            gnutls_deinit(url->ss);
            errno = EIO;
            return -1;
        }


From hramrach at gmail.com  Wed Jul 13 17:44:44 2016
From: hramrach at gmail.com (Michal Suchanek)
Date: Wed, 13 Jul 2016 17:44:44 +0200
Subject: [gnutls-help] SSL priority and handshake error
In-Reply-To: <CAOMqctS6g+favq=LHLmTK3iH_WOqkFbRJFsg3mDhSONxAL92eQ@mail.gmail.com>
References: <CAOMqctS6g+favq=LHLmTK3iH_WOqkFbRJFsg3mDhSONxAL92eQ@mail.gmail.com>
Message-ID: <CAOMqctSQ_SgXaUVEDKyoKzSVT2BN1q_ZApAJAj9sL=pVv3hBYQ@mail.gmail.com>

On 13 July 2016 at 16:20, Michal Suchanek <hramrach at gmail.com> wrote:
> Hello,
>
> I tried to dust off a piece of old GnuTLS code and I get this error:
>
> ./httpfs2-ssl: SSL init: loaded 173 CA certificate(s).
> Thread main initializing SSL socket.
> ./httpfs2-ssl: invalid SSL priority
>  NORMAL
>  ^
> ./httpfs2-ssl: sourceforge.net:443 - ./httpfs2-ssl: SSL connection
> failed: -12 Handshake failed.
>
> The code was developed with older GnuTLS on Debian 7. The requirements
> say GnuTLS >= 2.10.
>
> It is difficult to install such an old version of GnuTLS without
> breaking my system.
>
> However, Debian still carries 2.12.20-8+deb7u5 which gives different error:
>
> ./httpfs2-ssl: SSL init: loaded 173 CA certificate(s).
> Thread main initializing SSL socket.
> ./httpfs2-ssl: sourceforge.net:443 - ./httpfs2-ssl: SSL connection
> failed: -12 Handshake failed.
>
> 3.x version available in Debian (3.5.2-1, 3.4.14-1, 3.4.13-1,
> 3.3.8-6+deb8u3) all have this issue.
>
> The problem is that the r = gnutls_priority_set_direct(url->ss, ps,
> &errp); line sets errp even when no error is reported.
>
> Extra line if (!r) errp = NULL; is required to provide correct
> diagnostics in GnuTLS 3.x.
>
> So now that this turns out to be a hanshake error how do you diagnose these?
>
> Is there some sample code for printing intelligible diagnostic in the
> event handshake fails?

Upping the debug level shows that server does not like the handshake :/
./httpfs2-ssl: SSL init: loaded 173 CA certificate(s).
REC[0xd05650]: Allocating epoch #0
ASSERT: gnutls_constate.c:695
REC[0xd05650]: Allocating epoch #1
HSK[0xd05650]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256
HSK[0xd05650]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256
HSK[0xd05650]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256
HSK[0xd05650]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256
HSK[0xd05650]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
HSK[0xd05650]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256
HSK[0xd05650]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256
HSK[0xd05650]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
HSK[0xd05650]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
HSK[0xd05650]: Keeping ciphersuite: RSA_ARCFOUR_MD5
EXT[0xd05650]: Sending extension SAFE RENEGOTIATION (1 bytes)
EXT[SIGA]: sent signature algo (4.2) DSA-SHA256
EXT[SIGA]: sent signature algo (4.1) RSA-SHA256
EXT[SIGA]: sent signature algo (2.1) RSA-SHA1
EXT[SIGA]: sent signature algo (2.2) DSA-SHA1
EXT[0xd05650]: Sending extension SIGNATURE ALGORITHMS (10 bytes)
HSK[0xd05650]: CLIENT HELLO was sent [112 bytes]
REC[0xd05650]: Sending Packet[0] Handshake(22) with length: 112
REC[0xd05650]: Sent Packet[1] Handshake(22) with length: 117
REC[0xd05650]: Expected Packet[0] Handshake(22) with length: 1
REC[0xd05650]: Received Packet[0] Alert(21) with length: 2
REC[0xd05650]: Decrypted Packet[0] Alert(21) with length: 2
REC[0xd05650]: Alert[2|40] - Handshake failed - was received
ASSERT: gnutls_record.c:726
ASSERT: gnutls_record.c:1122
ASSERT: gnutls_handshake.c:2762

$ ldd ./httpfs2-ssl
    linux-vdso.so.1 (0x00007ffcad175000)
    libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007fe20ff38000)
    libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26
(0x00007fe20fc78000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe20f8d4000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe20f6d0000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fe20f4b3000)
    libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3
(0x00007fe20f2a2000)
    libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11
(0x00007fe20f023000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe20ee08000)
    libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
(0x00007fe20eba3000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe210176000)
    libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0
(0x00007fe20e98f000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fe20e786000)


From ossman at cendio.se  Fri Jul 15 12:01:55 2016
From: ossman at cendio.se (Pierre Ossman)
Date: Fri, 15 Jul 2016 12:01:55 +0200
Subject: [gnutls-help] RFC4514 compliance in gnutls_x509_crt_get_dn()?
Message-ID: <0eebafba-7ef4-faef-6244-0b7123d971cc@cendio.se>

Hi,

I was looking at gnutls_x509_crt_get_dn() as a way to generate string 
representations of DNs according to RFC4514. But there are two things 
that strike me as being out of spec:

  - The order of RDNs is wrong. GnuTLS outputs them first-to-last, but 
RFC4514 states:

    "...the output consists of the string encodings of each
    RelativeDistinguishedName in the RDNSequence (according to Section
    2.2), starting with the last element of the sequence and moving
    backwards toward the first."

    You can also see this in their examples:

    "UID=jsmith,DC=example,DC=net"

    The leaf being first, rather than last.

  - The oid list includes some things not in the IANA registry. E.g. 
1.3.6.1.4.1.311.60.2.1.3 and XmppAddr.

The oid list also seems a bit arbitrary, which could make 
interoperability a bit annoying. :/

Thoughts?

Regards
-- 
Pierre Ossman           Software Development
Cendio AB		https://cendio.com
Teknikringen 8		https://twitter.com/ThinLinc
583 30 Link?ping	https://facebook.com/ThinLinc
Phone: +46-13-214600	https://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


From nmav at gnutls.org  Fri Jul 15 13:43:04 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 15 Jul 2016 13:43:04 +0200
Subject: [gnutls-help] RFC4514 compliance in gnutls_x509_crt_get_dn()?
In-Reply-To: <0eebafba-7ef4-faef-6244-0b7123d971cc@cendio.se>
References: <0eebafba-7ef4-faef-6244-0b7123d971cc@cendio.se>
Message-ID: <CAJU7zaKtNCZcLuxA9TWZWnhoiqws+Pw_iXTtLgF8J3b96Ms05Q@mail.gmail.com>

On Fri, Jul 15, 2016 at 12:01 PM, Pierre Ossman <ossman at cendio.se> wrote:
> Hi,
>
> I was looking at gnutls_x509_crt_get_dn() as a way to generate string
> representations of DNs according to RFC4514. But there are two things that
> strike me as being out of spec:
>  - The order of RDNs is wrong. GnuTLS outputs them first-to-last, but
> RFC4514 states:

It seems you are right, indeed, the strings output by gnutls is first
to last. Would you be interested in fixing that, or contribute a unit
test for various encodings and their expected output string (similarly
to tests/base64.c)?

>  - The oid list includes some things not in the IANA registry. E.g.
> 1.3.6.1.4.1.311.60.2.1.3 and XmppAddr.

Is that really an issue?

> The oid list also seems a bit arbitrary, which could make interoperability a
> bit annoying. :/

It is based on what we currently see in PKIX certificates. What kind
of interoperability are you concerned of?

regards,
Nikos


From ossman at cendio.se  Fri Jul 15 13:53:39 2016
From: ossman at cendio.se (Pierre Ossman)
Date: Fri, 15 Jul 2016 13:53:39 +0200
Subject: [gnutls-help] RFC4514 compliance in gnutls_x509_crt_get_dn()?
In-Reply-To: <CAJU7zaKtNCZcLuxA9TWZWnhoiqws+Pw_iXTtLgF8J3b96Ms05Q@mail.gmail.com>
References: <0eebafba-7ef4-faef-6244-0b7123d971cc@cendio.se>
 <CAJU7zaKtNCZcLuxA9TWZWnhoiqws+Pw_iXTtLgF8J3b96Ms05Q@mail.gmail.com>
Message-ID: <025ce689-353d-0d39-61a8-84bd780dfc4d@cendio.se>

On 15/07/16 13:43, Nikos Mavrogiannopoulos wrote:
> On Fri, Jul 15, 2016 at 12:01 PM, Pierre Ossman <ossman at cendio.se> wrote:
>> Hi,
>>
>> I was looking at gnutls_x509_crt_get_dn() as a way to generate string
>> representations of DNs according to RFC4514. But there are two things that
>> strike me as being out of spec:
>>  - The order of RDNs is wrong. GnuTLS outputs them first-to-last, but
>> RFC4514 states:
>
> It seems you are right, indeed, the strings output by gnutls is first
> to last. Would you be interested in fixing that, or contribute a unit
> test for various encodings and their expected output string (similarly
> to tests/base64.c)?
>

I could have a look. But it would most likely be a few weeks away. I'm 
just about to head off for some time off.

>>  - The oid list includes some things not in the IANA registry. E.g.
>> 1.3.6.1.4.1.311.60.2.1.3 and XmppAddr.
>
> Is that really an issue?
>

It can be. See below.

>> The oid list also seems a bit arbitrary, which could make interoperability a
>> bit annoying. :/
>
> It is based on what we currently see in PKIX certificates. What kind
> of interoperability are you concerned of?
>

Our usage is to transport the subject name over an existing system in 
place of the user name. Hence the need to encode it in to some string 
form. Rather than just do a hex encode, we figured RFC4514 would fit the 
purpose and also make the encoded result fairly readable (in logs and such).

But for it to work the receiver needs to be able to decode it back to 
some data structure. In practice that means it needs to know more 
attribute types than the sender. So if the sender would e.g. send 
"XmppAddr=foo at example.com", then a strict RFC 4514 receiver would have 
no idea how to turn that back in to an ASN.1 structure for comparison 
with the local database.

I'm starting to think that the safe approach is that the sender only 
uses the minimal list specified in RFC 4514.

Regards
-- 
Pierre Ossman           Software Development
Cendio AB		https://cendio.com
Teknikringen 8		https://twitter.com/ThinLinc
583 30 Link?ping	https://facebook.com/ThinLinc
Phone: +46-13-214600	https://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


From nmav at gnutls.org  Fri Jul 15 14:16:25 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 15 Jul 2016 14:16:25 +0200
Subject: [gnutls-help] RFC4514 compliance in gnutls_x509_crt_get_dn()?
In-Reply-To: <025ce689-353d-0d39-61a8-84bd780dfc4d@cendio.se>
References: <0eebafba-7ef4-faef-6244-0b7123d971cc@cendio.se>
 <CAJU7zaKtNCZcLuxA9TWZWnhoiqws+Pw_iXTtLgF8J3b96Ms05Q@mail.gmail.com>
 <025ce689-353d-0d39-61a8-84bd780dfc4d@cendio.se>
Message-ID: <CAJU7za+ogNSHuHrLw5j6n1Jxx0sgWw4DBfLR4kc=vWwcvmJyPQ@mail.gmail.com>

On Fri, Jul 15, 2016 at 1:53 PM, Pierre Ossman <ossman at cendio.se> wrote:
>>> The oid list also seems a bit arbitrary, which could make
>>> interoperability a
>>> bit annoying. :/
>> It is based on what we currently see in PKIX certificates. What kind
>> of interoperability are you concerned of?
> Our usage is to transport the subject name over an existing system in place
> of the user name. Hence the need to encode it in to some string form. Rather
> than just do a hex encode, we figured RFC4514 would fit the purpose and also
> make the encoded result fairly readable (in logs and such).
>
> But for it to work the receiver needs to be able to decode it back to some
> data structure. In practice that means it needs to know more attribute types
> than the sender. So if the sender would e.g. send
> "XmppAddr=foo at example.com", then a strict RFC 4514 receiver would have no
> idea how to turn that back in to an ASN.1 structure for comparison with the
> local database.
>
> I'm starting to think that the safe approach is that the sender only uses
> the minimal list specified in RFC 4514.

That makes sense, although I'm not sure that you could indeed use
these to go back and forth to ASN.1, for the reasons you mentioned.
Even if we fix the order (which is a good thing, so I've tracked that
in [0]), we will always want to make human-readable common fields
present in certificates, so there will be non-standard fields in the
gnutls' output functions. That could be addressed however by having
the reverse of gnutls_x509_dn_oid_name() made available which will
translate a known name to an OID. Would that be sufficient?

regards,
Nikos

[0]. https://gitlab.com/gnutls/gnutls/issues/111


From ossman at cendio.se  Fri Jul 15 14:32:08 2016
From: ossman at cendio.se (Pierre Ossman)
Date: Fri, 15 Jul 2016 14:32:08 +0200
Subject: [gnutls-help] RFC4514 compliance in gnutls_x509_crt_get_dn()?
In-Reply-To: <CAJU7za+ogNSHuHrLw5j6n1Jxx0sgWw4DBfLR4kc=vWwcvmJyPQ@mail.gmail.com>
References: <0eebafba-7ef4-faef-6244-0b7123d971cc@cendio.se>
 <CAJU7zaKtNCZcLuxA9TWZWnhoiqws+Pw_iXTtLgF8J3b96Ms05Q@mail.gmail.com>
 <025ce689-353d-0d39-61a8-84bd780dfc4d@cendio.se>
 <CAJU7za+ogNSHuHrLw5j6n1Jxx0sgWw4DBfLR4kc=vWwcvmJyPQ@mail.gmail.com>
Message-ID: <91f08f92-f0a1-2ee5-f88b-2435bbcb7785@cendio.se>

On 15/07/16 14:16, Nikos Mavrogiannopoulos wrote:
>
> That makes sense, although I'm not sure that you could indeed use
> these to go back and forth to ASN.1, for the reasons you mentioned.
> Even if we fix the order (which is a good thing, so I've tracked that
> in [0]), we will always want to make human-readable common fields
> present in certificates, so there will be non-standard fields in the
> gnutls' output functions. That could be addressed however by having
> the reverse of gnutls_x509_dn_oid_name() made available which will
> translate a known name to an OID. Would that be sufficient?
>

As a back up plan, yes. But that would mean that we specify the system 
as "send the DN encoded as GnuTLS version x.y.z does it", rather than a 
formal standard like RFC4514. The latter would be preferred if possible. 
But it isn't perfect, so we are still tossing around ideas.

As far as RFC4514 vs other human-readable, you could mark the OIDs in 
the list as being RFC4514 compliant or not. Separate functions could 
then be provided depending on if you want something with strict 
adherence to the RFC, or just something nice to present to the user.

(Btw. if I'm reading the code correctly then GnuTLS currently cannot 
fully parse its own output. Handling of the #<hex> fallback for values 
currently just returns a parse error.)

Rgds
-- 
Pierre Ossman           Software Development
Cendio AB		https://cendio.com
Teknikringen 8		https://twitter.com/ThinLinc
583 30 Link?ping	https://facebook.com/ThinLinc
Phone: +46-13-214600	https://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


From jonetsu at teksavvy.com  Fri Jul 15 23:40:20 2016
From: jonetsu at teksavvy.com (jonetsu)
Date: Fri, 15 Jul 2016 17:40:20 -0400
Subject: [gnutls-help] 'continuous random number generator test in 4.9.2' ?
Message-ID: <88e8c10bfff185c29bc7aaf678c3983f@teksavvy.com>

Hello,

I would like to find out how the RNG test is organized.? The following statement in nettle/int/drbg-aes.c is puzzling:

At line 147:

??? /* Throw the first block generated. FIPS 140-2 requirement (see 
??? ?* the continuous random number generator test in 4.9.2)
??? ?*/
??? if (ctx->prev_block_present == 0) {
??? ??? INCREMENT(sizeof(ctx->v), ctx->v);
??? ??? aes_encrypt(&ctx->key, AES_BLOCK_SIZE, ctx->prev_block, ctx->v);

??? ??? ctx->prev_block_present = 1;
??? }

What does '4.9.2' mean ?

Thanks.





From nmav at gnutls.org  Sun Jul 17 09:47:33 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 17 Jul 2016 09:47:33 +0200
Subject: [gnutls-help] RFC4514 compliance in gnutls_x509_crt_get_dn()?
In-Reply-To: <91f08f92-f0a1-2ee5-f88b-2435bbcb7785@cendio.se>
References: <0eebafba-7ef4-faef-6244-0b7123d971cc@cendio.se>
 <CAJU7zaKtNCZcLuxA9TWZWnhoiqws+Pw_iXTtLgF8J3b96Ms05Q@mail.gmail.com>
 <025ce689-353d-0d39-61a8-84bd780dfc4d@cendio.se>
 <CAJU7za+ogNSHuHrLw5j6n1Jxx0sgWw4DBfLR4kc=vWwcvmJyPQ@mail.gmail.com>
 <91f08f92-f0a1-2ee5-f88b-2435bbcb7785@cendio.se>
Message-ID: <1468741653.11011.5.camel@gnutls.org>

On Fri, 2016-07-15 at 14:32 +0200, Pierre Ossman wrote:

> As far as RFC4514 vs other human-readable, you could mark the OIDs
> in?
> the list as being RFC4514 compliant or not. Separate functions could?
> then be provided depending on if you want something with strict?
> adherence to the RFC, or just something nice to present to the user.

That could be an option, but we have to see who would be the consumer
of such API. Why would this be used today? DNs are being deprecated
over PKIX and the subjectAlternativeName is the only way to specify
names (for end-certificates) today. Are there use cases of certificate
DNs today that I am missing?

> (Btw. if I'm reading the code correctly then GnuTLS currently cannot?
> fully parse its own output. Handling of the #<hex> fallback for
> values currently just returns a parse error.)

Could be. Which functions do you refer to?

regards,
Nikos



From n.mavrogiannopoulos at gmail.com  Sun Jul 17 09:49:21 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sun, 17 Jul 2016 09:49:21 +0200
Subject: [gnutls-help] 'continuous random number generator test in
 4.9.2' ?
In-Reply-To: <88e8c10bfff185c29bc7aaf678c3983f@teksavvy.com>
References: <88e8c10bfff185c29bc7aaf678c3983f@teksavvy.com>
Message-ID: <1468741761.11011.6.camel@gmail.com>

On Fri, 2016-07-15 at 17:40 -0400, jonetsu wrote:

> ??? /* Throw the first block generated. FIPS 140-2 requirement (see?
> ??? ?* the continuous random number generator test in 4.9.2)
> ??? ?*/
> What does '4.9.2' mean ?

That is section 4.9.2 of the FIPS140-2 document.

regards,
Nikos



From jonetsu at teksavvy.com  Sun Jul 17 17:46:04 2016
From: jonetsu at teksavvy.com (jonetsu at teksavvy.com)
Date: Sun, 17 Jul 2016 11:46:04 -0400
Subject: [gnutls-help] 'continuous random number generator test in
 4.9.2' ?
In-Reply-To: <1468741761.11011.6.camel@gmail.com>
References: <88e8c10bfff185c29bc7aaf678c3983f@teksavvy.com>
 <1468741761.11011.6.camel@gmail.com>
Message-ID: <20160717114604.04d82ff5@mevla>

On Sun, 17 Jul 2016 09:49:21 +0200
Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:

> On Fri, 2016-07-15 at 17:40 -0400, jonetsu wrote:
> 
> > ??? /* Throw the first block generated. FIPS 140-2 requirement (see?
> > ??? ?* the continuous random number generator test in 4.9.2)
> > ??? ?*/
> > What does '4.9.2' mean ?
 
> That is section 4.9.2 of the FIPS140-2 document.

OK.  Can you comment about how the code proceeds to implement the
continuous test ? - thanks.




From ondrej at sury.org  Sun Jul 17 22:49:19 2016
From: ondrej at sury.org (=?UTF-8?Q?Ond=C5=99ej=20Sur=C3=BD?=)
Date: Sun, 17 Jul 2016 22:49:19 +0200
Subject: [gnutls-help] HPKH style (pin-sha256) peer verification in
 gnutls_certificate_verify_function callback
Message-ID: <1468788559.136785.668816689.7921E979@webmail.messagingengine.com>

Hey,

during the IETF hackathon I implemented DNS over TLS (RFC 7858) for kdig
utility in Knot DNS[1] and now I am implementing the different TLS
Privacy Profiles (Section 4).

Using the excellent examples and documentation[*] I was able to
implement:

- Opportunistic Privacy Profile (just return 0)
- hostname verification with system ca-file
- custom ca-file

and now I would like to implement verification of pin-sha256
user-provided values. Could you please guide me to a place where I
should start looking? Is there already some other program that
implemented HSTS/HPKP using GnuTLS? And if not than a pointer to
documentation for SPKI retrieval would be nice (not quite sure
https://www.gnutls.org/manual/html_node/X509-certificate-API.html is the
right place and what function am I looking for).

* - please bear in mind this is my first code longer than few lines in
years... and my first encounter with GnuTLS programming, so be nice to
me

1. https://gitlab.labs.nic.cz/labs/knot/commits/dns-over-tls

Cheers,
-- 
Ond?ej Sur? <ondrej at sury.org>
Knot DNS (https://www.knot-dns.cz/) ? a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) ? secure, privacy-aware,
fast DNS(SEC) resolver
V?e pro chleba (https://vseprochleba.cz) ? Pot?eby pro pe?en? chleba
v?eho druhu


From nmav at gnutls.org  Mon Jul 18 21:26:26 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 18 Jul 2016 21:26:26 +0200
Subject: [gnutls-help] HPKH style (pin-sha256) peer verification in
 gnutls_certificate_verify_function callback
In-Reply-To: <1468788559.136785.668816689.7921E979@webmail.messagingengine.com>
References: <1468788559.136785.668816689.7921E979@webmail.messagingengine.com>
Message-ID: <1468869986.2835.8.camel@gnutls.org>

On Sun, 2016-07-17 at 22:49 +0200, Ond?ej Sur? wrote:
> Hey,
> 
> during the IETF hackathon I implemented DNS over TLS (RFC 7858) for
> kdig
> utility in Knot DNS[1] and now I am implementing the different TLS
> Privacy Profiles (Section 4).
> 
> Using the excellent examples and documentation[*] I was able to
> implement:
> 
> - Opportunistic Privacy Profile (just return 0)
> - hostname verification with system ca-file
> - custom ca-file
> 
> and now I would like to implement verification of pin-sha256
> user-provided values. Could you please guide me to a place where I
> should start looking? Is there already some other program that
> implemented HSTS/HPKP using GnuTLS?
>  And if not than a pointer to
> documentation for SPKI retrieval would be nice (not quite sure
> https://www.gnutls.org/manual/html_node/X509-certificate-API.html is
> the
> right place and what function am I looking for).

If what you want to is to obtain the DER SPKI format you can import the
certificate to gnutls_pubkey_t structure and export that one to get
the DER SPKI. The gnutls_pubkey_import_x509_raw() is the function you
most likely neeed.

Not sure if it is related to your use case, but there is the trust on
first use API which can be used to pin certificates and keys
(i.e.,?gnutls_store_pubkey and ?gnutls_verify_stored_pubkey).

regards,
Nikos



From n.mavrogiannopoulos at gmail.com  Mon Jul 18 21:28:03 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 18 Jul 2016 21:28:03 +0200
Subject: [gnutls-help] Building Gnutls for Android
In-Reply-To: <CABx6ir7=8K=APTDRLkf44foH_Yd_xzD2b+7Td8kAD5z8HB_7mA@mail.gmail.com>
References: <mailman.686.1468856549.21746.gnutls-help@lists.gnutls.org>
 <CABx6ir7=8K=APTDRLkf44foH_Yd_xzD2b+7Td8kAD5z8HB_7mA@mail.gmail.com>
Message-ID: <1468870083.2835.10.camel@gmail.com>

On Mon, 2016-07-18 at 09:01 -0700, Noha Taha wrote:
> I'm not sure why the message was rejected, this is the email listed
> here for gnutls support.

Hi, you have to be subscribed to be able to post. For android you may
want to check the openconnect app for android in github which uses
gnutls.

regards,
Nikos

> ---------- Forwarded message ----------
> From: Noha Taha &lt;noha.taha at gmail.com&gt;
> To: gnutls-help at lists.gnutls.org
> Cc:?
> Date: Mon, 18 Jul 2016 08:05:54 -0700
> Subject: Building Gnutls for Android
> Hello,
> I''m wondering if there is a way to build the Gnutls library for
> Android.
> Thank you,
> Noha


From ondrej at sury.org  Mon Jul 18 23:20:34 2016
From: ondrej at sury.org (=?UTF-8?Q?Ond=C5=99ej=20Sur=C3=BD?=)
Date: Mon, 18 Jul 2016 23:20:34 +0200
Subject: [gnutls-help] HPKH style (pin-sha256) peer verification in
 gnutls_certificate_verify_function callback
In-Reply-To: <1468869986.2835.8.camel@gnutls.org>
References: <1468788559.136785.668816689.7921E979@webmail.messagingengine.com>
 <1468869986.2835.8.camel@gnutls.org>
Message-ID: <1468876834.2069391.669930665.218CBF3C@webmail.messagingengine.com>

Nikos,

thanks for the tips, I ended up using gnutls_certificate_get_peers and
iterating the list with gnutls_x509_crt_import.

JFTR the full implementation starts here:
https://gitlab.labs.nic.cz/labs/knot/blob/dns-over-tls/src/utils/common/netio.c#L262
and looks like this:


				if (gnutls_certificate_type_get(session)
				!= GNUTLS_CRT_X509) { \
					ERR("Invalid certificate
					type\n");
					return
					GNUTLS_E_CERTIFICATE_ERROR;
				}
				
				raw_certificate_list =
				gnutls_certificate_get_peers(session,
				&raw_certificate_list_size);
				if (raw_certificate_list == NULL ||
				raw_certificate_list_size == 0) {
					ERR("Certificate list is
					empty\n");
					return
					GNUTLS_E_NO_CERTIFICATE_FOUND;
				}

				uint8_t sha256[64] = { 0 };
				size_t sha256_len;

				for (int i = 0; i <
				raw_certificate_list_size; i++) {
					ret =
					gnutls_x509_crt_init(&certificate);
					if (ret < 0) {
						return ret;
					}

					ret =
					gnutls_x509_crt_import(certificate,
								     &raw_certificate_list[i],
								     GNUTLS_X509_FMT_DER);
					if (ret < 0) {
						gnutls_x509_crt_deinit(certificate);
						return ret;
					}

					sha256_len = sizeof(sha256);
					ret =
					gnutls_x509_crt_get_key_id(certificate,
					GNUTLS_KEYID_USE_SHA256, sha256,
					&sha256_len);
					if (ret < 0) {
						gnutls_x509_crt_deinit(certificate);
						return ret;
					}

					if (memcmp(sha256, pin,
					sha256_len) == 0) {
						pin_seen = 1;
						INFO("Matched
						certificate using
						pin-sha256=\"%s\"\n",
						value);
					}
					gnutls_x509_crt_deinit(certificate);
				}

And this is inside the verify_certificate callback function.

The TOFU is not really usable here, but the next thing I might look into
is DANE authentication
(https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/?include_text=1
Section 9.2)

As a side note, I am really impress with the ease I was able to start
implementing things in gnutls, especially the clarity of the API and the
documentation. Really great job!

Cheers,
-- 
Ond?ej Sur? <ondrej at sury.org>
Knot DNS (https://www.knot-dns.cz/) ? a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) ? secure, privacy-aware,
fast DNS(SEC) resolver
V?e pro chleba (https://vseprochleba.cz) ? Pot?eby pro pe?en? chleba
v?eho druhu

On Mon, Jul 18, 2016, at 21:26, Nikos Mavrogiannopoulos wrote:
> On Sun, 2016-07-17 at 22:49 +0200, Ond?ej Sur? wrote:
> > Hey,
> > 
> > during the IETF hackathon I implemented DNS over TLS (RFC 7858) for
> > kdig
> > utility in Knot DNS[1] and now I am implementing the different TLS
> > Privacy Profiles (Section 4).
> > 
> > Using the excellent examples and documentation[*] I was able to
> > implement:
> > 
> > - Opportunistic Privacy Profile (just return 0)
> > - hostname verification with system ca-file
> > - custom ca-file
> > 
> > and now I would like to implement verification of pin-sha256
> > user-provided values. Could you please guide me to a place where I
> > should start looking? Is there already some other program that
> > implemented HSTS/HPKP using GnuTLS?
> >  And if not than a pointer to
> > documentation for SPKI retrieval would be nice (not quite sure
> > https://www.gnutls.org/manual/html_node/X509-certificate-API.html is
> > the
> > right place and what function am I looking for).
> 
> If what you want to is to obtain the DER SPKI format you can import the
> certificate to gnutls_pubkey_t structure and export that one to get
> the DER SPKI. The gnutls_pubkey_import_x509_raw() is the function you
> most likely neeed.
> 
> Not sure if it is related to your use case, but there is the trust on
> first use API which can be used to pin certificates and keys
> (i.e.,?gnutls_store_pubkey and ?gnutls_verify_stored_pubkey).
> 
> regards,
> Nikos
> 


From ossman at cendio.se  Tue Jul 19 13:31:10 2016
From: ossman at cendio.se (Pierre Ossman)
Date: Tue, 19 Jul 2016 13:31:10 +0200
Subject: [gnutls-help] RFC4514 compliance in gnutls_x509_crt_get_dn()?
In-Reply-To: <1468741653.11011.5.camel@gnutls.org>
References: <0eebafba-7ef4-faef-6244-0b7123d971cc@cendio.se>
 <CAJU7zaKtNCZcLuxA9TWZWnhoiqws+Pw_iXTtLgF8J3b96Ms05Q@mail.gmail.com>
 <025ce689-353d-0d39-61a8-84bd780dfc4d@cendio.se>
 <CAJU7za+ogNSHuHrLw5j6n1Jxx0sgWw4DBfLR4kc=vWwcvmJyPQ@mail.gmail.com>
 <91f08f92-f0a1-2ee5-f88b-2435bbcb7785@cendio.se>
 <1468741653.11011.5.camel@gnutls.org>
Message-ID: <4f6f4ebe-b92f-c3bc-9657-f91ce20c479f@cendio.se>

On 17/07/16 09:47, Nikos Mavrogiannopoulos wrote:
> On Fri, 2016-07-15 at 14:32 +0200, Pierre Ossman wrote:
>
>> As far as RFC4514 vs other human-readable, you could mark the OIDs
>> in
>> the list as being RFC4514 compliant or not. Separate functions could
>> then be provided depending on if you want something with strict
>> adherence to the RFC, or just something nice to present to the user.
>
> That could be an option, but we have to see who would be the consumer
> of such API. Why would this be used today? DNs are being deprecated
> over PKIX and the subjectAlternativeName is the only way to specify
> names (for end-certificates) today. Are there use cases of certificate
> DNs today that I am missing?
>

Except for ours, none that I know of. And you're right, the proper way 
to handle this is using more structured data. So any use case would most 
likely be similar to ours, where you're trying to make things work over 
an existing string based system.

>> (Btw. if I'm reading the code correctly then GnuTLS currently cannot
>> fully parse its own output. Handling of the #<hex> fallback for
>> values currently just returns a parse error.)
>
> Could be. Which functions do you refer to?
>

https://gitlab.com/gnutls/gnutls/blob/master/lib/x509/x509_dn.c#L76

Regards
-- 
Pierre Ossman           Software Development
Cendio AB		https://cendio.com
Teknikringen 8		https://twitter.com/ThinLinc
583 30 Link?ping	https://facebook.com/ThinLinc
Phone: +46-13-214600	https://plus.google.com/+CendioThinLinc

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


From nmav at gnutls.org  Tue Jul 19 16:41:28 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 19 Jul 2016 16:41:28 +0200
Subject: [gnutls-help] RFC4514 compliance in gnutls_x509_crt_get_dn()?
In-Reply-To: <4f6f4ebe-b92f-c3bc-9657-f91ce20c479f@cendio.se>
References: <0eebafba-7ef4-faef-6244-0b7123d971cc@cendio.se>
 <CAJU7zaKtNCZcLuxA9TWZWnhoiqws+Pw_iXTtLgF8J3b96Ms05Q@mail.gmail.com>
 <025ce689-353d-0d39-61a8-84bd780dfc4d@cendio.se>
 <CAJU7za+ogNSHuHrLw5j6n1Jxx0sgWw4DBfLR4kc=vWwcvmJyPQ@mail.gmail.com>
 <91f08f92-f0a1-2ee5-f88b-2435bbcb7785@cendio.se>
 <1468741653.11011.5.camel@gnutls.org>
 <4f6f4ebe-b92f-c3bc-9657-f91ce20c479f@cendio.se>
Message-ID: <CAJU7zaLwmz=jSP3Sb5LmDOUktNtUkGmXRjWugxGS2umfxtu_cw@mail.gmail.com>

On Tue, Jul 19, 2016 at 1:31 PM, Pierre Ossman <ossman at cendio.se> wrote:
>> That could be an option, but we have to see who would be the consumer
>> of such API. Why would this be used today? DNs are being deprecated
>> over PKIX and the subjectAlternativeName is the only way to specify
>> names (for end-certificates) today. Are there use cases of certificate
>> DNs today that I am missing?
> Except for ours, none that I know of. And you're right, the proper way to
> handle this is using more structured data. So any use case would most likely
> be similar to ours, where you're trying to make things work over an existing
> string based system.

Based on your previous comments, I have made some improvements in the
DN handling API, but I haven't yet made changes for the parsing in
reverse of the rdn field. It is more complicated as it seems, since it
affects both directions, DER->string and string -> DER, and the former
is not straightforward to achieve. So will not proceed with the
reversing of the output for DER->string (I've attached a demo patch at
[0]), unless of course you send patch that handles both string->DER
and DER->string in a clean way.

Nevertheless, I've given a second look at RFC4514, and noticed that
cannot be used the way you intend to. If you see section 2.2 the
RelativeDistinguishedName DER->string mapping is in any (arbitrary)
order. While it is not common to have DNs with multiple
RelativeDistinguishedName elements in a sequence, it is a case that
any DER->string and string->DER mappings cannot handle in a
deterministic way. My advice... stay away from the DN :)

regards,
Nikos

[0]. https://gitlab.com/gnutls/gnutls/issues/111


From dank at kegel.com  Thu Jul 28 00:29:28 2016
From: dank at kegel.com (Dan Kegel)
Date: Wed, 27 Jul 2016 15:29:28 -0700
Subject: [gnutls-help] Trouble with wildcard cert on servers without FQDNs?
Message-ID: <CAPF-yOZ117KEoODD0wVd0-kDyZmHBsrHLDJQCdSb2gee7Fyywg@mail.gmail.com>

The script http://kegel.com/wildcard-bug.sh.txt demonstrates
generating a wildcard cert
on ubuntu using openssh, and using it with gnutls.  Works great on a
real machine with
a real FQDN.  But if I run it on a container without a FQDN,
gnutls-cli refuses to trust the server.

What's going on here?  Are servers only trusted if the client can look
up the server's primary name in DNS?

Sorry for the ugly script, I'm not fluent in certificates.


From nmav at gnutls.org  Thu Jul 28 08:48:50 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 28 Jul 2016 08:48:50 +0200
Subject: [gnutls-help] Trouble with wildcard cert on servers without
	FQDNs?
In-Reply-To: <CAPF-yOZ117KEoODD0wVd0-kDyZmHBsrHLDJQCdSb2gee7Fyywg@mail.gmail.com>
References: <CAPF-yOZ117KEoODD0wVd0-kDyZmHBsrHLDJQCdSb2gee7Fyywg@mail.gmail.com>
Message-ID: <CAJU7zaLOk0CV2y7m8V7WeJ=erOA6PxtYXVEup+zbUmdSr4G9hQ@mail.gmail.com>

On Thu, Jul 28, 2016 at 12:29 AM, Dan Kegel <dank at kegel.com> wrote:
> The script http://kegel.com/wildcard-bug.sh.txt demonstrates
> generating a wildcard cert
> on ubuntu using openssh, and using it with gnutls.  Works great on a
> real machine with
> a real FQDN.  But if I run it on a container without a FQDN,
> gnutls-cli refuses to trust the server.
> What's going on here?  Are servers only trusted if the client can look
> up the server's primary name in DNS?

Most likely your container doesn't contain the root certificates
needed for gnutls to verify servers. You'll need to install the
package that contains them.

regards,
Nikos


From dank at kegel.com  Fri Jul 29 15:51:02 2016
From: dank at kegel.com (Dan Kegel)
Date: Fri, 29 Jul 2016 06:51:02 -0700
Subject: [gnutls-help] Trouble with wildcard cert on servers without
	FQDNs?
In-Reply-To: <CAPF-yOZtAQ4Lfg1EZGDMSQV71_YRH5SS47uKxCGmOwGRKYPOiw@mail.gmail.com>
References: <CAPF-yOZ117KEoODD0wVd0-kDyZmHBsrHLDJQCdSb2gee7Fyywg@mail.gmail.com>
 <CAJU7zaLOk0CV2y7m8V7WeJ=erOA6PxtYXVEup+zbUmdSr4G9hQ@mail.gmail.com>
 <CAPF-yOZtAQ4Lfg1EZGDMSQV71_YRH5SS47uKxCGmOwGRKYPOiw@mail.gmail.com>
Message-ID: <CAPF-yObN2xYtfK8QvOMTCxbsi9ZH4bjL23c3QeQ_eibyTrkuUw@mail.gmail.com>

Ha!  Thank you, that makes sense!  I'll give that a shot.

On Jul 27, 2016 11:49 PM, "Nikos Mavrogiannopoulos" <nmav at gnutls.org> wrote:

On Thu, Jul 28, 2016 at 12:29 AM, Dan Kegel <dank at kegel.com> wrote:
> The script http://kegel.com/wildcard-bug.sh.txt demonstrates
> generating a wildcard cert
> on ubuntu using openssh, and using it with gnutls.  Works great on a
> real machine with
> a real FQDN.  But if I run it on a container without a FQDN,
> gnutls-cli refuses to trust the server.
> What's going on here?  Are servers only trusted if the client can look
> up the server's primary name in DNS?

Most likely your container doesn't contain the root certificates
needed for gnutls to verify servers. You'll need to install the
package that contains them.

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160729/56c96baf/attachment-0001.html>

From dank at kegel.com  Fri Jul 29 18:04:37 2016
From: dank at kegel.com (Dan Kegel)
Date: Fri, 29 Jul 2016 09:04:37 -0700
Subject: [gnutls-help] Trouble with wildcard cert on servers without
	FQDNs?
In-Reply-To: <CAPF-yObN2xYtfK8QvOMTCxbsi9ZH4bjL23c3QeQ_eibyTrkuUw@mail.gmail.com>
References: <CAPF-yOZ117KEoODD0wVd0-kDyZmHBsrHLDJQCdSb2gee7Fyywg@mail.gmail.com>
 <CAJU7zaLOk0CV2y7m8V7WeJ=erOA6PxtYXVEup+zbUmdSr4G9hQ@mail.gmail.com>
 <CAPF-yOZtAQ4Lfg1EZGDMSQV71_YRH5SS47uKxCGmOwGRKYPOiw@mail.gmail.com>
 <CAPF-yObN2xYtfK8QvOMTCxbsi9ZH4bjL23c3QeQ_eibyTrkuUw@mail.gmail.com>
Message-ID: <CAPF-yOZhwOt-R5w7_5GUjOmxscr67uzxqYTG+0rgGHW8u1t+UA@mail.gmail.com>

No, that wasn't it.  The test script fails even when the ubuntu
package ca-certificates is installed.
And the test script is all self-signed anyway, there's no outside
server involved.
In fact, it fails on my laptop, which has all the certs a normal user needs.

The script works fine without the wildcard, too, even in the clean container.
It really does feel like the wildcard triggers some surprising
requirement in gnutls.
Maybe I should try registering a FQDN for my laptop and see if that helps :-)


On Fri, Jul 29, 2016 at 6:51 AM, Dan Kegel <dank at kegel.com> wrote:
> Ha!  Thank you, that makes sense!  I'll give that a shot.
>
>
> On Jul 27, 2016 11:49 PM, "Nikos Mavrogiannopoulos" <nmav at gnutls.org> wrote:
>
> On Thu, Jul 28, 2016 at 12:29 AM, Dan Kegel <dank at kegel.com> wrote:
>> The script http://kegel.com/wildcard-bug.sh.txt demonstrates
>> generating a wildcard cert
>> on ubuntu using openssh, and using it with gnutls.  Works great on a
>> real machine with
>> a real FQDN.  But if I run it on a container without a FQDN,
>> gnutls-cli refuses to trust the server.
>> What's going on here?  Are servers only trusted if the client can look
>> up the server's primary name in DNS?
>
> Most likely your container doesn't contain the root certificates
> needed for gnutls to verify servers. You'll need to install the
> package that contains them.
>
> regards,
> Nikos
>
>


From nmav at gnutls.org  Fri Jul 29 18:17:35 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 29 Jul 2016 18:17:35 +0200
Subject: [gnutls-help] Trouble with wildcard cert on servers without
	FQDNs?
In-Reply-To: <CAPF-yOZhwOt-R5w7_5GUjOmxscr67uzxqYTG+0rgGHW8u1t+UA@mail.gmail.com>
References: <CAPF-yOZ117KEoODD0wVd0-kDyZmHBsrHLDJQCdSb2gee7Fyywg@mail.gmail.com>
 <CAJU7zaLOk0CV2y7m8V7WeJ=erOA6PxtYXVEup+zbUmdSr4G9hQ@mail.gmail.com>
 <CAPF-yOZtAQ4Lfg1EZGDMSQV71_YRH5SS47uKxCGmOwGRKYPOiw@mail.gmail.com>
 <CAPF-yObN2xYtfK8QvOMTCxbsi9ZH4bjL23c3QeQ_eibyTrkuUw@mail.gmail.com>
 <CAPF-yOZhwOt-R5w7_5GUjOmxscr67uzxqYTG+0rgGHW8u1t+UA@mail.gmail.com>
Message-ID: <CAJU7za+D3v0NemcKouoFsSaAsXekZji_jozYO56edh9Uc0dHEQ@mail.gmail.com>

On Fri, Jul 29, 2016 at 6:04 PM, Dan Kegel <dank at kegel.com> wrote:
> No, that wasn't it.  The test script fails even when the ubuntu
> package ca-certificates is installed.
> And the test script is all self-signed anyway, there's no outside
> server involved.
> In fact, it fails on my laptop, which has all the certs a normal user needs.
>
> The script works fine without the wildcard, too, even in the clean container.
> It really does feel like the wildcard triggers some surprising
> requirement in gnutls.
> Maybe I should try registering a FQDN for my laptop and see if that helps :-)

I doubt that has anything to do with it. What error messages do you
get from gnutls? Did you try setting GNUTLS_DEBUG_LEVEL=9?

regards,
Nikos