From msd at shore.net Thu Jul 2 20:50:19 2009 From: msd at shore.net (Mike Denning) Date: Thu, 2 Jul 2009 14:50:19 -0400 Subject: [Help-gnutls] building gnutls 2.8.1 on Solaris 10 Message-ID: I'm trying to build gnutls 2.8.1 on Solaris 10 I ran into an issue with cfg/shared.c which i was able to get by. Now i'm getting this error: Making all in examples gmake[4]: Entering directory `/usr/local/src/gnutls-2.8.1/doc/examples' /bin/bash ../../libtool --tag=CC --mode=link gcc -g -O2 -no-install -o ex-serv1 ex-serv1.o libexamples.la ../../lib/libgnutls.la ../../libextra/ libgnutls-extra.la ../../gl/libgnu.la -lsocket libtool: link: gcc -g -O2 -o ex-serv1 ex-serv1.o ./.libs/libexamples.a ../../lib/.libs/libgnutls.so -L/usr/local/lib ../../libextra/.libs/libgnutls-extra.so /usr/local/src/gnutls-2.8.1/lib/.libs/libgnutls.so -lz /usr/local/lib/libgcrypt.so /usr/local/lib/libgpg-error.so ../../gl/.libs/libgnu.a -lsocket -R/usr/local/src/gnutls-2.8.1/lib/.libs -R/usr/local/src/gnutls-2.8.1/libextra/.libs -R/usr/local/lib -R/usr/local/lib ld: warning: file /usr/local/src/gnutls-2.8.1/lib/.libs/libgnutls.so: linked to ../../lib/.libs/libgnutls.so: attempted multiple inclusion of file Undefined first referenced symbol in file inet_ntop ex-serv1.o (symbol belongs to implicit dependency /usr/lib/libnsl.so.1) ld: fatal: Symbol referencing errors. No output written to ex-serv1 collect2: ld returned 1 exit status gmake[4]: *** [ex-serv1] Error 1 gmake[4]: Leaving directory `/usr/local/src/gnutls-2.8.1/doc/examples' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/local/src/gnutls-2.8.1/doc' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/local/src/gnutls-2.8.1/doc' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/src/gnutls-2.8.1' gmake: *** [all] Error 2 Does anyone have any suggestions on what I can do? Thanks, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradh at frogmouth.net Sun Jul 5 08:04:17 2009 From: bradh at frogmouth.net (Brad Hards) Date: Sun, 5 Jul 2009 16:04:17 +1000 Subject: [Help-gnutls] Problem building from git Message-ID: <200907051604.18090.bradh@frogmouth.net> Hi, I'm trying to build gnutls from git (commit 762950f92f97f8fc71b9acdedce5872ba9c272f0), and having some trouble. Its a clean checkout, and I've followed README-alpha. I'm building with gcc (GCC) 4.4.0 20090506 (Red Hat 4.4.0-4) make bootstrap ended with: version: 2.9.2 shared 41:2:15 Host type: x86_64-unknown-linux-gnu Install prefix: /usr/local Compiler: gcc -std=gnu99 Warning flags: errors: -Werror warnings: -Wall -W -Wformat-security - Winit-self -Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wfloat-equal -Wdeclaration-after-statement -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes - Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wpacked - Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wlong-long -Wvla - Wvolatile-register-var -Wdisabled-optimization -Wstack-protector -Woverlength- strings -Wbuiltin-macro-redefined -Wmudflap -Wpacked-bitfield-compat -Wsync-nand -Wattributes -Wcoverage-mismatch -Wmultichar -Wunused-macros -Wno-missing- field-initializers -Wno-sign-compare -Wno-pointer-sign -Wno-unused-parameter - Wno-unused-parameter -Wno-stack-protector -fdiagnostics-show-option Library types: Shared=yes, Static=yes Valgrind: valgrind Guile wrappers: no C++ library: yes OpenSSL library: yes When I run make, it errors out with this: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./../gl -I./../gl - I./../includes -I./../includes -I./.. -I./../minitasn1 -Werror -Wframe-larger- than=2100 -Wall -W -Wformat-security -Winit-self -Wmissing-include-dirs - Wunused -Wunknown-pragmas -Wstrict-aliasing -Wfloat-equal -Wdeclaration-after- statement -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings - Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing- noreturn -Wmissing-format-attribute -Wpacked -Wredundant-decls -Wnested- externs -Winline -Winvalid-pch -Wlong-long -Wvla -Wvolatile-register-var - Wdisabled-optimization -Wstack-protector -Woverlength-strings -Wbuiltin-macro- redefined -Wmudflap -Wpacked-bitfield-compat -Wsync-nand -Wattributes -Wcoverage- mismatch -Wmultichar -Wunused-macros -Wno-missing-field-initializers -Wno-sign- compare -Wno-pointer-sign -Wno-unused-parameter -Wno-unused-parameter -Wno- stack-protector -fdiagnostics-show-option -g -O2 -MT crq.lo -MD -MP -MF .deps/crq.Tpo -c crq.c -fPIC -DPIC -o .libs/crq.o cc1: warnings being treated as errors crq.c: In function 'get_subject_alt_name': crq.c:1652: error: passing argument 5 of 'gnutls_x509_crq_get_extension_by_oid' from incompatible pointer type ./../includes/gnutls/x509.h:780: note: expected 'size_t *' but argument is of type 'unsigned int *' crq.c:1668: error: passing argument 5 of 'gnutls_x509_crq_get_extension_by_oid' from incompatible pointer type ./../includes/gnutls/x509.h:780: note: expected 'size_t *' but argument is of type 'unsigned int *' crq.c: In function 'gnutls_x509_crq_set_subject_alt_name': crq.c:1892: error: passing argument 5 of 'gnutls_x509_crq_get_extension_by_oid' from incompatible pointer type crq.c:1804: note: expected 'size_t *' but argument is of type 'unsigned int *' crq.c:1910: error: passing argument 5 of 'gnutls_x509_crq_get_extension_by_oid' from incompatible pointer type crq.c:1804: note: expected 'size_t *' but argument is of type 'unsigned int *' crq.c: In function 'gnutls_x509_crq_get_key_purpose_oid': crq.c:2088: error: passing argument 5 of 'gnutls_x509_crq_get_extension_by_oid' from incompatible pointer type crq.c:1804: note: expected 'size_t *' but argument is of type 'unsigned int *' crq.c:2104: error: passing argument 5 of 'gnutls_x509_crq_get_extension_by_oid' from incompatible pointer type crq.c:1804: note: expected 'size_t *' but argument is of type 'unsigned int *' crq.c: In function 'gnutls_x509_crq_set_key_purpose_oid': crq.c:2185: error: passing argument 5 of 'gnutls_x509_crq_get_extension_by_oid' from incompatible pointer type crq.c:1804: note: expected 'size_t *' but argument is of type 'unsigned int *' crq.c:2202: error: passing argument 5 of 'gnutls_x509_crq_get_extension_by_oid' from incompatible pointer type crq.c:1804: note: expected 'size_t *' but argument is of type 'unsigned int *' make[4]: *** [crq.lo] Error 1 make[4]: Leaving directory `/home/bradh/devel/gnutls/lib/x509' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/bradh/devel/gnutls/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/bradh/devel/gnutls/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/bradh/devel/gnutls' make: *** [all] Error 2 The problem would appear to be that size_t isn't the same as "unsigned int" (perhaps some 64 bit thing - the glibc headers are too confusing for me to divine today). Brad From bradh at frogmouth.net Tue Jul 7 11:49:51 2009 From: bradh at frogmouth.net (Brad Hards) Date: Tue, 7 Jul 2009 19:49:51 +1000 Subject: [Help-gnutls] Parsing certificate extensions and issuer alt names Message-ID: <200907071949.51751.bradh@frogmouth.net> Hi, I'm trying to provide a GnuTLS backend for the Qt Cryptographic Architecture. It is going OK (not really "going well", but I'm still making progress). I have a question about how to parse out something that doesn't really have support in GnuTLS. My need at the moment is to handle OID 2.5.29.32 (Certificate Policies) and OID 2.5.29.18 (Issuer Alternative Name). Issuer Alt Name is very similar to Subject Alt Name. So far, I think I need to use gnutls_x509_crt_get_extension_by_oid() to get the ASN.1, and then I need to decode it. Its the decoding bit that I'm uncertain about. I considered copying some of the get_subject_alt_name() code (from lib/x509/x509.c) but it seemed like quite a lot of code, and the duplication seemed undesirable. I had no idea about how to start the Certificate Policies. Any suggestions or hints? Brad From cr4yv3n at hotmail.com Fri Jul 10 04:21:37 2009 From: cr4yv3n at hotmail.com (cr4yv3n) Date: Thu, 9 Jul 2009 19:21:37 -0700 (PDT) Subject: [Help-gnutls] can't get libgnutls.so.13 to work Message-ID: <24420792.post@talk.nabble.com> Having problems getting gammu to build for Linux. The first time, I got the following errors: /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_get_dn_by_oid at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_get_peers at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_import at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_get_dn at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_cipher_get at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_check_hostname at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_get_activation_time at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_deinit at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_check_version at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_session_set_data at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_get_expiration_time at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_record_send at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_global_deinit at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_global_init at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_pk_algorithm_get_name at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_bye at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_set_verify_flags at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_record_recv at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_deinit at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_strerror at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_get_pk_algorithm at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_set_default_priority at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_cipher_get_name at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_verify_peers2 at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_get_issuer_dn at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_mac_get at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_allocate_credentials at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_session_get_data at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_credentials_set at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_compression_get_name at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_get_version at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_transport_set_ptr at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_x509_crt_init at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_handshake at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_set_x509_key_file at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_type_set_priority at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_mac_get_name at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_set_x509_trust_file at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_init at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_certificate_free_credentials at GNUTLS_1_3' /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined reference to `gnutls_compression_get at GNUTLS_1_3' collect2: ld returned 1 exit status make[3]: *** [gammu/gammu] Error 1 make[3]: Leaving directory `/media/SQ004126P01/CS/Python/PhoneTool/gammu-1.25.0/gammu-1.25.0/build-configure' make[2]: *** [gammu/CMakeFiles/gammu.dir/all] Error 2 make[2]: Leaving directory `/media/SQ004126P01/CS/Python/PhoneTool/gammu-1.25.0/gammu-1.25.0/build-configure' make[1]: *** [all] Error 2 make[1]: Leaving directory `/media/SQ004126P01/CS/Python/PhoneTool/gammu-1.25.0/gammu-1.25.0/build-configure' make: *** [all] Error 2 So, I tried recompiling curl and gnutls. Both built and installed fine. Then I re-ran ./configure and make and got the same problem. When I try to see if libgnutls.so.14 is on my system, I get the following: cr4yv3n at Andromeda /usr/lib $ ls -l libgnutls* -rw-r--r-- 1 root root 841144 2008-09-23 13:11 libgnutls.a -rw-r--r-- 1 root root 34098 2008-09-23 13:11 libgnutls-extra.a -rw-r--r-- 1 root root 987 2008-09-23 13:11 libgnutls-extra.la lrwxrwxrwx 1 root root 25 2008-09-23 13:11 libgnutls-extra.so -> libgnutls-extra.so.26.4.5 lrwxrwxrwx 1 root root 25 2008-09-23 13:11 libgnutls-extra.so.26 -> libgnutls-extra.so.26.4.5 -rwxr-xr-x 1 root root 22176 2008-09-23 13:11 libgnutls-extra.so.26.4.5 -rw-r--r-- 1 root root 903 2008-09-23 13:11 libgnutls.la -rw-r--r-- 1 root root 45784 2008-09-23 13:11 libgnutls-openssl.a -rw-r--r-- 1 root root 981 2008-09-23 13:11 libgnutls-openssl.la lrwxrwxrwx 1 root root 27 2008-09-23 13:11 libgnutls-openssl.so -> libgnutls-openssl.so.26.4.5 lrwxrwxrwx 1 root root 27 2008-09-23 13:11 libgnutls-openssl.so.26 -> libgnutls-openssl.so.26.4.5 -rwxr-xr-x 1 root root 37372 2008-09-23 13:11 libgnutls-openssl.so.26.4.5 lrwxrwxrwx 1 root root 19 2008-09-23 13:11 libgnutls.so -> libgnutls.so.26.4.5 lrwxrwxrwx 1 root root 12 2009-02-06 18:24 libgnutls.so.13 -> libgnutls.so lrwxrwxrwx 1 root root 19 2008-09-23 13:11 libgnutls.so.26 -> libgnutls.so.26.4.5 -rwxr-xr-x 1 root root 507620 2008-09-23 13:11 libgnutls.so.26.4.5 -rw-r--r-- 1 root root 72230 2008-09-23 13:11 libgnutlsxx.a -rw-r--r-- 1 root root 939 2008-09-23 13:11 libgnutlsxx.la lrwxrwxrwx 1 root root 21 2008-09-23 13:11 libgnutlsxx.so -> libgnutlsxx.so.26.4.5 lrwxrwxrwx 1 root root 21 2008-09-23 13:11 libgnutlsxx.so.26 -> libgnutlsxx.so.26.4.5 -rwxr-xr-x 1 root root 56876 2008-09-23 13:11 libgnutlsxx.so.26.4.5 Says it's there, and yet it STILL doesn't work. I didn't mind that much when this crashed Amarok, cupsd, and SAMBA because I didn't use some of these, and for others there were work arounds. But I'm doing a program for work that I need gammu to work for. I would greatly appreciate any help given. -- View this message in context: http://www.nabble.com/can%27t-get-libgnutls.so.13-to-work-tp24420792p24420792.html Sent from the Gnu - TLS mailing list archive at Nabble.com. From mrsam at courier-mta.com Fri Jul 10 04:37:53 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Thu, 09 Jul 2009 22:37:53 -0400 Subject: [Help-gnutls] can't get libgnutls.so.13 to work References: <24420792.post@talk.nabble.com> Message-ID: cr4yv3n writes: > > Having problems getting gammu to build for Linux. The first time, I got the > following errors: > > /usr/lib/gcc/i586-pc-linux-gnu/4.1.1/../../../libcurl.so: undefined > reference to `gnutls_x509_crt_get_dn_by_oid at GNUTLS_1_3' It would help for you to show the actual link line. > So, I tried recompiling curl and gnutls. Both built and installed fine. Then ? > -rwxr-xr-x 1 root root 507620 2008-09-23 13:11 libgnutls.so.26.4.5 > Says it's there, and yet it STILL doesn't work. Well, unless the clock on your machine is way slow, if you claim that you've just installed gnutls, this isn't what you just installed. "It's" been "there" all along, since September of last year. What's probably happening is that you have multiple, different versions of gnutls installed in different directories. Above is the version of GnuTLS that was installed by your distribution, and your custom-compiled version of GnuTLS probably went into /usr/local. Having multiple versions of GnuTLS on one system is always a recipe of confusion, and mild chaos. It's possible to have multiple versions installed in parallel -- I did that for some time -- but this requires a lot of tender loving care, and attention to detail. Don't, whatever you do, try to remove this stuff from /usr/lib. It's probably your distro's GnuTLS. If it gets removed, you may end up with an unbootable brick. Go through your machine, and take a careful inventory of what's where. If, as I suspect, your custom-compiled version of GnuTLS is really in /usr/local/lib, then if you want to build other software that uses it, you'll probably need to add extra compiler flags. Probably "-I /usr/local/include" for CPPFLAGS, to pick up the header files, and "-L /usr/local/lib -R /usr/local/lib" for LDFLAGS, to pick up the actual library. But that's just a guess -- hard to say what's the correct answer is for you -- it depends solely on what's really going on in your machine. You'll need to do some poking, first. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bradh at frogmouth.net Fri Jul 10 04:42:41 2009 From: bradh at frogmouth.net (Brad Hards) Date: Fri, 10 Jul 2009 12:42:41 +1000 Subject: [Help-gnutls] can't get libgnutls.so.13 to work In-Reply-To: <24420792.post@talk.nabble.com> References: <24420792.post@talk.nabble.com> Message-ID: <200907101242.41962.bradh@frogmouth.net> On Friday 10 July 2009 12:21:37 cr4yv3n wrote: > Having problems getting gammu to build for Linux. The first time, I got the > following errors: It might help if you explained a bit more about what you are doing. I'm not sure exactly which packages / hand-installed versions of which dependencies you've used at different times, and that makes it hard to figure out what is going on. > So, I tried recompiling curl and gnutls. Both built and installed fine. > Then I re-ran ./configure and make and got the same problem. When I try to > see if libgnutls.so.14 is on my system, I get the following: > > cr4yv3n at Andromeda /usr/lib $ ls -l libgnutls* > lrwxrwxrwx 1 root root 19 2008-09-23 13:11 libgnutls.so -> > libgnutls.so.26.4.5 > lrwxrwxrwx 1 root root 12 2009-02-06 18:24 libgnutls.so.13 -> > libgnutls.so > lrwxrwxrwx 1 root root 19 2008-09-23 13:11 libgnutls.so.26 -> > libgnutls.so.26.4.5 To me, it looks like you have two different versions of libgnutls installed. At a guess, libcurl is linked against the .so.13 version, but the dynamic linker is using the .so.26 version. > Says it's there, and yet it STILL doesn't work. Be reasonable. At least describe the error. Are you sure you have the right paths for the linker? What configure-time options are you passing? What environment variables are set? Brad From nmav at gnutls.org Mon Jul 13 08:33:48 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 13 Jul 2009 09:33:48 +0300 Subject: [Help-gnutls] Parsing certificate extensions and issuer alt names In-Reply-To: <200907071949.51751.bradh@frogmouth.net> References: <200907071949.51751.bradh@frogmouth.net> Message-ID: <4A5AD54C.6040108@gnutls.org> Brad Hards wrote: > Hi, > > I'm trying to provide a GnuTLS backend for the Qt Cryptographic Architecture. > > It is going OK (not really "going well", but I'm still making progress). > > I have a question about how to parse out something that doesn't really have > support in GnuTLS. My need at the moment is to handle OID 2.5.29.32 > (Certificate Policies) and OID 2.5.29.18 (Issuer Alternative Name). > > Issuer Alt Name is very similar to Subject Alt Name. > > So far, I think I need to use gnutls_x509_crt_get_extension_by_oid() to get > the ASN.1, and then I need to decode it. Its the decoding bit that I'm > uncertain about. Hello, Actually I think it might be much easier to do that inside gnutls by extending get_subject_alt_name() to be able to accept the OID as parameter to parse the 2.5.29.18 extension as well. Then would be easy to submit a gnutls_x509_crt_get_issuer_alt_name that can be added to gnutls. > I had no idea about how to start the Certificate Policies. For that you might want to see dn.c:gnutls_x509_rdn_get function that parses the rdnSequence of PKIX. It is mostly libtasn1 stuff you'd need but indeed the policies extension looks not to be the easier structure to parse. regards, Nikos From nmav at gnutls.org Mon Jul 13 08:39:30 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 13 Jul 2009 09:39:30 +0300 Subject: [Help-gnutls] Problem building from git In-Reply-To: <200907051604.18090.bradh@frogmouth.net> References: <200907051604.18090.bradh@frogmouth.net> Message-ID: <4A5AD6A2.9050108@gnutls.org> Brad Hards wrote: > Hi, > > I'm trying to build gnutls from git (commit > 762950f92f97f8fc71b9acdedce5872ba9c272f0), and having some trouble. [...] > crq.c: In function 'get_subject_alt_name': > crq.c:1652: error: passing argument 5 of > 'gnutls_x509_crq_get_extension_by_oid' from incompatible pointer type > ./../includes/gnutls/x509.h:780: note: expected 'size_t *' but argument is of > type 'unsigned int *' This is quite strange. In my copy x509.h:780 gnutls_x509_crq_get_extension_by_oid has argument 5 as unsigned int and not size_t*. Is it the same in your system? If yes it is some compiler issue in your system (do you have option to install different compiler?). regards, Nikos From bradh at frogmouth.net Mon Jul 13 09:33:20 2009 From: bradh at frogmouth.net (Brad Hards) Date: Mon, 13 Jul 2009 17:33:20 +1000 Subject: [Help-gnutls] Problem building from git In-Reply-To: <4A5AD6A2.9050108@gnutls.org> References: <200907051604.18090.bradh@frogmouth.net> <4A5AD6A2.9050108@gnutls.org> Message-ID: <200907131733.20846.bradh@frogmouth.net> On Monday 13 July 2009 16:39:30 Nikos Mavrogiannopoulos wrote: > This is quite strange. In my copy x509.h:780 > gnutls_x509_crq_get_extension_by_oid has argument 5 as unsigned int and > not size_t*. Is it the same in your system? No, it isn't. I have: int gnutls_x509_crq_get_extension_by_oid (gnutls_x509_crq_t crq, const char *oid, int indx, void *buf, size_t * sizeof_buf, unsigned int *critical); http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/includes/gnutls/x509.h;h=2a87cba7a2d0b035e2e99abb224fac8b4f8a976d;hb=HEAD#l780 shows the same. Uncommitted local changes? working branch? Brad From nmav at gnutls.org Mon Jul 13 09:50:01 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 13 Jul 2009 10:50:01 +0300 Subject: [Help-gnutls] Problem building from git In-Reply-To: <200907131733.20846.bradh@frogmouth.net> References: <200907051604.18090.bradh@frogmouth.net> <4A5AD6A2.9050108@gnutls.org> <200907131733.20846.bradh@frogmouth.net> Message-ID: <4A5AE729.1020907@gnutls.org> Brad Hards wrote: > On Monday 13 July 2009 16:39:30 Nikos Mavrogiannopoulos wrote: >> This is quite strange. In my copy x509.h:780 >> gnutls_x509_crq_get_extension_by_oid has argument 5 as unsigned int and >> not size_t*. Is it the same in your system? > No, it isn't. I have: > int gnutls_x509_crq_get_extension_by_oid (gnutls_x509_crq_t crq, > const char *oid, int indx, > void *buf, size_t * sizeof_buf, > unsigned int *critical); Sorry didn't check correctly. Does the following patch solve the issue for you? regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: crq.patch Type: text/x-patch Size: 3712 bytes Desc: not available URL: From bradh at frogmouth.net Mon Jul 13 10:00:47 2009 From: bradh at frogmouth.net (Brad Hards) Date: Mon, 13 Jul 2009 18:00:47 +1000 Subject: [Help-gnutls] Problem building from git In-Reply-To: <4A5AE729.1020907@gnutls.org> References: <200907051604.18090.bradh@frogmouth.net> <200907131733.20846.bradh@frogmouth.net> <4A5AE729.1020907@gnutls.org> Message-ID: <200907131800.48058.bradh@frogmouth.net> On Monday 13 July 2009 17:50:01 Nikos Mavrogiannopoulos wrote: > Sorry didn't check correctly. Does the following patch solve the issue > for you? > @@ -1664,7 +1666,7 @@ get_subject_alt_name (gnutls_x509_crq_t crq, > } > > result = gnutls_x509_crq_get_extension_by_oid (crq, "2.5.29.17", 0, > - dnsname.data, > &dnsname.size, + > dnsname.data, dns_size, critical); Almost. Needs to be &dns_size here. There are more problems, but not in this file. Brad From bradh at frogmouth.net Mon Jul 13 12:37:28 2009 From: bradh at frogmouth.net (Brad Hards) Date: Mon, 13 Jul 2009 20:37:28 +1000 Subject: [Help-gnutls] Parsing certificate extensions and issuer alt names In-Reply-To: <4A5AD54C.6040108@gnutls.org> References: <200907071949.51751.bradh@frogmouth.net> <4A5AD54C.6040108@gnutls.org> Message-ID: <200907132037.28924.bradh@frogmouth.net> On Monday 13 July 2009 16:33:48 Nikos Mavrogiannopoulos wrote: > Actually I think it might be much easier to do that inside gnutls by > extending get_subject_alt_name() to be able to accept the OID as > parameter to parse the 2.5.29.18 extension as well. Then would be easy > to submit a gnutls_x509_crt_get_issuer_alt_name that can be added to > gnutls. OK. Will that require copyright assignment? Brad From bradh at frogmouth.net Mon Jul 13 13:07:00 2009 From: bradh at frogmouth.net (Brad Hards) Date: Mon, 13 Jul 2009 21:07:00 +1000 Subject: Fwd: Re: [Help-gnutls] Problem building from git Message-ID: <200907132107.01316.bradh@frogmouth.net> On Monday 13 July 2009 17:50:01 Nikos Mavrogiannopoulos wrote: > Brad Hards wrote: > > On Monday 13 July 2009 16:39:30 Nikos Mavrogiannopoulos wrote: > >> This is quite strange. In my copy x509.h:780 > >> gnutls_x509_crq_get_extension_by_oid has argument 5 as unsigned int and > >> not size_t*. Is it the same in your system? > > > > No, it isn't. I have: > > int gnutls_x509_crq_get_extension_by_oid (gnutls_x509_crq_t crq, > > const char *oid, int indx, > > void *buf, size_t * sizeof_buf, > > unsigned int *critical); > > Sorry didn't check correctly. Does the following patch solve the issue > for you? There was one missing & (see previous message), and a lot of other problems. However the problems appear to mostly be one of two types: 1. Cases where we're using %d to print a ssize_t or size_t. That requires %zd instead. I'm confident about my fixes for those. 2. Cases where we are passing an integer to a function that expects a pointer (sometimes with, sometimes without a macro) to gnutls_transport_set_ptr(). This I'm less confident about, because (again) I'm not sure I understand the intent. Perhaps the address-of operator needs to be in the macro? Perhaps the macro needs to be used for the tests and examples as well? There is something confusing (or confused) about tests/mini-eagain.c. It looks a bit like a work-in-progress. Patch attached (zipped to get under the 40K limit on the list). Please provide review - I'm not very confident, and I got 9 out of 39 test failures. Brad ------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-build-2009-07-13.patch.zip Type: application/zip Size: 8461 bytes Desc: not available URL: From nmav at gnutls.org Mon Jul 13 13:16:24 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 13 Jul 2009 14:16:24 +0300 Subject: [Help-gnutls] Parsing certificate extensions and issuer alt names In-Reply-To: <200907132037.28924.bradh@frogmouth.net> References: <200907071949.51751.bradh@frogmouth.net> <4A5AD54C.6040108@gnutls.org> <200907132037.28924.bradh@frogmouth.net> Message-ID: <4A5B1788.4090208@gnutls.org> Brad Hards wrote: > On Monday 13 July 2009 16:33:48 Nikos Mavrogiannopoulos wrote: >> Actually I think it might be much easier to do that inside gnutls by >> extending get_subject_alt_name() to be able to accept the OID as >> parameter to parse the 2.5.29.18 extension as well. Then would be easy >> to submit a gnutls_x509_crt_get_issuer_alt_name that can be added to >> gnutls. > OK. Will that require copyright assignment? Most probably it will. If you want to avoid that, the patch has to be few lines only (less than 15). Otherwise let me know and I will send you the required papers. regards, Nikos From bradh at frogmouth.net Mon Jul 13 14:31:03 2009 From: bradh at frogmouth.net (Brad Hards) Date: Mon, 13 Jul 2009 22:31:03 +1000 Subject: [Help-gnutls] Parsing certificate extensions and issuer alt names In-Reply-To: <4A5B1788.4090208@gnutls.org> References: <200907071949.51751.bradh@frogmouth.net> <200907132037.28924.bradh@frogmouth.net> <4A5B1788.4090208@gnutls.org> Message-ID: <200907132231.04724.bradh@frogmouth.net> On Monday 13 July 2009 21:16:24 Nikos Mavrogiannopoulos wrote: > Brad Hards wrote: > > On Monday 13 July 2009 16:33:48 Nikos Mavrogiannopoulos wrote: > >> Actually I think it might be much easier to do that inside gnutls by > >> extending get_subject_alt_name() to be able to accept the OID as > >> parameter to parse the 2.5.29.18 extension as well. Then would be easy > >> to submit a gnutls_x509_crt_get_issuer_alt_name that can be added to > >> gnutls. > > > > OK. Will that require copyright assignment? > > Most probably it will. If you want to avoid that, the patch has to be > few lines only (less than 15). Otherwise let me know and I will send you > the required papers. Urgh. This hurts every time I try it... Lets at least get the process started, and I'll try to keep the patch trivial in any case. Brad From mydevforums at gmail.com Mon Jul 13 19:21:06 2009 From: mydevforums at gmail.com (Ram G) Date: Mon, 13 Jul 2009 13:21:06 -0400 Subject: [Help-gnutls] Dynamically building the PSK keys Message-ID: <3a8533cc0907131021l2a0fcb20o7b3e01d8f76cacd4@mail.gmail.com> Hi, I'm working on the sample programs provided in the source examples folder and I would like some help from you. I'm trying to do a DH key exchange with PSK authentication. The client sample (ex-client-psk.c) assigns the pre shared key as follows: const gnutls_datum_t key = { (char*) "DEADBEEF", 8 }; The server sample (ex-serv-psk.c) does the key assignment in the callback function pskfunc as follows: key->data = gnutls_malloc (4); key->data[0] = 0xDE; key->data[1] = 0xAD; key->data[2] = 0xBE; key->data[3] = 0xEF; key->size = 4; I would like to assign the pre-shared key dynamically. If I assign the PSK in the server as follows, it does not work. I get the error "Decryption has failed". char * somekey = "DEADBEEF"; key -> data = somekey; My question is : since data in the struct gnutls_datum_t has been defined as unsigned char, why doesn't this assignment work ? Can you please help me how I can make the PSK keys to be dynamic and make the authentication to succeed ? I'll really appreciate your help. Ram G -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Jul 13 19:38:18 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 13 Jul 2009 20:38:18 +0300 Subject: Fwd: Re: [Help-gnutls] Problem building from git In-Reply-To: <200907132107.01316.bradh@frogmouth.net> References: <200907132107.01316.bradh@frogmouth.net> Message-ID: <4A5B710A.4000301@gnutls.org> Brad Hards wrote: > Patch attached (zipped to get under the 40K limit on the list). Please provide > review - I'm not very confident, and I got 9 out > of 39 test failures. Hi, I have solved the warnings except the transport_ptr cast. Most of them a bit different (I don't know how widely used i z for size_t, so I just casted size_t to int for printing). The former warning for cast is not easy to solve and not really needed on current platforms. Anyway I see Simon has added gl_fd_to_handle() that could be used with an inline function to perform this cast gracefully... but I don't really know if it is the proper place. regards, Nikos From nmav at gnutls.org Mon Jul 13 22:10:09 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 13 Jul 2009 23:10:09 +0300 Subject: [Help-gnutls] Dynamically building the PSK keys In-Reply-To: <3a8533cc0907131021l2a0fcb20o7b3e01d8f76cacd4@mail.gmail.com> References: <3a8533cc0907131021l2a0fcb20o7b3e01d8f76cacd4@mail.gmail.com> Message-ID: <4A5B94A1.8050007@gnutls.org> Ram G wrote: > Hi, > > I'm working on the sample programs provided in the source examples folder > and I would like some help from you. I'm trying to do a DH key exchange with > PSK authentication. > > The client sample (ex-client-psk.c) assigns the pre shared key as follows: > > const gnutls_datum_t key = { (char*) "DEADBEEF", 8 }; > > The server sample (ex-serv-psk.c) does the key assignment in the callback > function pskfunc as follows: > > key->data = gnutls_malloc (4); > key->data[0] = 0xDE; > key->data[1] = 0xAD; > key->data[2] = 0xBE; > key->data[3] = 0xEF; > key->size = 4; It is not the same as above. Above you use 8 bytes and here 4. Use instead: key->data[0] = 'D'; key->data[1] = 'E'; key->data[2] = 'A'; key->data[3] = 'D'; key->data[4] = 'B'; key->data[5] = 'E'; key->data[6] = 'E'; key->data[7] = 'F'; key->size = 8; > I would like to assign the pre-shared key dynamically. If I assign the PSK > in the server as follows, it does not work. I get the error "Decryption has > failed". Actually how the keys are going to be generated? You have to think about that seriously and make sure that the key generation is not weakening the cryptosystem. To be on the safe side, and especially if you are not experienced in the field use the tools provided by gnutls for the key generation. regards, Nikos From bradh at frogmouth.net Tue Jul 14 01:37:23 2009 From: bradh at frogmouth.net (Brad Hards) Date: Tue, 14 Jul 2009 09:37:23 +1000 Subject: Fwd: Re: [Help-gnutls] Problem building from git In-Reply-To: <4A5B710A.4000301@gnutls.org> References: <200907132107.01316.bradh@frogmouth.net> <4A5B710A.4000301@gnutls.org> Message-ID: <200907140937.23941.bradh@frogmouth.net> On Tuesday 14 July 2009 03:38:18 Nikos Mavrogiannopoulos wrote: > I have solved the warnings except the transport_ptr cast. Most of them > a bit different (I don't know how widely used i z for size_t, so I just > casted size_t to int for printing). Thanks. I did some checking - looks like 'z' is in glibc, based on the SuSv3. I think that might come from C99 - I don't have a copy to check. Not sure if it is supported in C89. Which compilers / C libraries are supported for gnutls? > The former warning for cast is not > easy to solve and not really needed on current platforms. Anyway I see > Simon has added gl_fd_to_handle() that could be used with an inline > function to perform this cast gracefully... but I don't really know if > it is the proper place. I also saw that it was identified as an issue some time ago. http://www.mail-archive.com/help-gnutls at gnu.org/msg00286.html Do you have any suggestions other than turning off -Werror? Brad From bradh at frogmouth.net Tue Jul 14 11:46:10 2009 From: bradh at frogmouth.net (Brad Hards) Date: Tue, 14 Jul 2009 19:46:10 +1000 Subject: [Help-gnutls] Parsing certificate extensions and issuer alt names In-Reply-To: <4A5AD54C.6040108@gnutls.org> References: <200907071949.51751.bradh@frogmouth.net> <4A5AD54C.6040108@gnutls.org> Message-ID: <200907141946.11694.bradh@frogmouth.net> On Monday 13 July 2009 16:33:48 Nikos Mavrogiannopoulos wrote: > Actually I think it might be much easier to do that inside gnutls by > extending get_subject_alt_name() to be able to accept the OID as > parameter to parse the 2.5.29.18 extension as well. Then would be easy > to submit a gnutls_x509_crt_get_issuer_alt_name that can be added to > gnutls. I had a first cut at this. See attached patch. Thoughts / comments? Brad -------------- next part -------------- commit a46a2b6388b96bb4541ee9e1d0515430f6afe618 Author: Brad Hards Date: Tue Jul 14 14:22:49 2009 +1000 Initial version of issuer altname handling. Heavily based on the existing subject altname handling, this adds some minor refactoring to allow the issuer altname OID to use the same basic code. The changes in the printing code are a bit larger - we don't have issuer altname in the certificate request, so it wasn't practical to share the code. diff --git a/lib/includes/gnutls/x509.h b/lib/includes/gnutls/x509.h index 2a87cba..e61ef25 100644 --- a/lib/includes/gnutls/x509.h +++ b/lib/includes/gnutls/x509.h @@ -198,6 +198,21 @@ extern "C" void *ret, size_t * ret_size); + int gnutls_x509_crt_get_issuer_alt_name (gnutls_x509_crt_t cert, + unsigned int seq, void *ret, + size_t * ret_size, + unsigned int *critical); + int gnutls_x509_crt_get_issuer_alt_name2 (gnutls_x509_crt_t cert, + unsigned int seq, void *ret, + size_t * ret_size, + unsigned int *ret_type, + unsigned int *critical); + + int gnutls_x509_crt_get_issuer_alt_othername_oid (gnutls_x509_crt_t cert, + unsigned int seq, + void *ret, + size_t * ret_size); + int gnutls_x509_crt_get_ca_status (gnutls_x509_crt_t cert, unsigned int *critical); int gnutls_x509_crt_get_basic_constraints (gnutls_x509_crt_t cert, diff --git a/lib/x509/output.c b/lib/x509/output.c index 38200bb..27617d3 100644 --- a/lib/x509/output.c +++ b/lib/x509/output.c @@ -655,6 +655,148 @@ print_san (gnutls_string * str, const char *prefix, int type, } static void +print_ian (gnutls_string * str, const char *prefix, int type, + cert_type_t cert) +{ + unsigned int ian_idx; + char str_ip[64]; + char *p; + + for (ian_idx = 0;; ian_idx++) + { + char *buffer = NULL; + size_t size = 0; + int err; + + if (type == TYPE_CRT) + err = + gnutls_x509_crt_get_issuer_alt_name (cert.crt, ian_idx, buffer, + &size, NULL); + else + return; + + if (err == GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) + break; + if (err != GNUTLS_E_SHORT_MEMORY_BUFFER) + { + addf (str, "error: get_issuer_alt_name: %s\n", + gnutls_strerror (err)); + return; + } + + buffer = gnutls_malloc (size); + if (!buffer) + { + addf (str, "error: malloc: %s\n", + gnutls_strerror (GNUTLS_E_MEMORY_ERROR)); + return; + } + + if (type == TYPE_CRT) + err = + gnutls_x509_crt_get_issuer_alt_name (cert.crt, ian_idx, buffer, + &size, NULL); + + if (err < 0) + { + gnutls_free (buffer); + addf (str, "error: get_issuer_alt_name2: %s\n", + gnutls_strerror (err)); + return; + } + + switch (err) + { + case GNUTLS_SAN_DNSNAME: + addf (str, "%s\t\t\tDNSname: %.*s\n", prefix, (int) size, buffer); + break; + + case GNUTLS_SAN_RFC822NAME: + addf (str, "%s\t\t\tRFC822name: %.*s\n", prefix, (int) size, buffer); + break; + + case GNUTLS_SAN_URI: + addf (str, "%s\t\t\tURI: %.*s\n", prefix, (int) size, buffer); + break; + + case GNUTLS_SAN_IPADDRESS: + p = ip_to_string (buffer, size, str_ip, sizeof (str_ip)); + if (p == NULL) + p = ERROR_STR; + addf (str, "%s\t\t\tIPAddress: %s\n", prefix, p); + break; + + case GNUTLS_SAN_DN: + addf (str, "%s\t\t\tdirectoryName: %.*s\n", prefix, + (int) size, buffer); + break; + + case GNUTLS_SAN_OTHERNAME: + { + char *oid = NULL; + size_t oidsize; + + oidsize = 0; + if (type == TYPE_CRT) + err = gnutls_x509_crt_get_issuer_alt_othername_oid + (cert.crt, ian_idx, oid, &oidsize); + + if (err != GNUTLS_E_SHORT_MEMORY_BUFFER) + { + gnutls_free (buffer); + addf (str, "error: get_issuer_alt_othername_oid: %s\n", + gnutls_strerror (err)); + return; + } + + oid = gnutls_malloc (oidsize); + if (!oid) + { + gnutls_free (buffer); + addf (str, "error: malloc: %s\n", + gnutls_strerror (GNUTLS_E_MEMORY_ERROR)); + return; + } + + if (type == TYPE_CRT) + err = gnutls_x509_crt_get_issuer_alt_othername_oid + (cert.crt, ian_idx, oid, &oidsize); + if (err < 0) + { + gnutls_free (buffer); + gnutls_free (oid); + addf (str, "error: get_issuer_alt_othername_oid2: %s\n", + gnutls_strerror (err)); + return; + } + + if (err == GNUTLS_SAN_OTHERNAME_XMPP) + addf (str, _("%s\t\t\tXMPP Address: %.*s\n"), prefix, + (int) size, buffer); + else + { + addf (str, _("%s\t\t\totherName OID: %.*s\n"), prefix, + (int) oidsize, oid); + addf (str, _("%s\t\t\totherName DER: "), prefix); + hexprint (str, buffer, size); + addf (str, _("\n%s\t\t\totherName ASCII: "), prefix); + asciiprint (str, buffer, size); + addf (str, "\n"); + } + gnutls_free (oid); + } + break; + + default: + addf (str, "error: unknown Issuer AltName\n"); + break; + } + + gnutls_free (buffer); + } +} + +static void print_extensions (gnutls_string * str, const char *prefix, int type, cert_type_t cert) { @@ -666,6 +808,7 @@ print_extensions (gnutls_string * str, const char *prefix, int type, size_t sizeof_oid = sizeof (oid); int critical; size_t san_idx = 0; + size_t ian_idx = 0; size_t proxy_idx = 0; size_t basic_idx = 0; size_t keyusage_idx = 0; @@ -796,6 +939,21 @@ print_extensions (gnutls_string * str, const char *prefix, int type, san_idx++; } + else if (strcmp (oid, "2.5.29.18") == 0) + { + if (ian_idx) + { + addf (str, "error: more than one Issuer AltName extension\n"); + continue; + } + + addf (str, _("%s\t\tIssuer Alternative Name (%s):\n"), prefix, + critical ? _("critical") : _("not critical")); + + print_ian (str, prefix, type, cert); + + ian_idx++; + } else if (strcmp (oid, "2.5.29.31") == 0) { if (crldist_idx) diff --git a/lib/x509/x509.c b/lib/x509/x509.c index 048ff89..ade73e3 100644 --- a/lib/x509/x509.c +++ b/lib/x509/x509.c @@ -1079,10 +1079,10 @@ _gnutls_parse_general_name (ASN1_TYPE src, const char *src_name, } static int -get_subject_alt_name (gnutls_x509_crt_t cert, - unsigned int seq, void *ret, - size_t * ret_size, unsigned int *ret_type, - unsigned int *critical, int othername_oid) +get_alt_name(gnutls_x509_crt_t cert, const char *extension_id, + unsigned int seq, void *ret, + size_t * ret_size, unsigned int *ret_type, + unsigned int *critical, int othername_oid) { int result; gnutls_datum_t dnsname; @@ -1101,7 +1101,7 @@ get_subject_alt_name (gnutls_x509_crt_t cert, *ret_size = 0; if ((result = - _gnutls_x509_crt_get_extension (cert, "2.5.29.17", 0, &dnsname, + _gnutls_x509_crt_get_extension (cert, extension_id, 0, &dnsname, critical)) < 0) { return result; @@ -1113,8 +1113,20 @@ get_subject_alt_name (gnutls_x509_crt_t cert, return GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE; } - result = asn1_create_element - (_gnutls_get_pkix (), "PKIX1.SubjectAltName", &c2); + if (strncmp("2.5.29.18", extension_id, 9) == 0) + { + result = asn1_create_element(_gnutls_get_pkix (), "PKIX1.IssuerAltName", &c2); + } + else if (strncmp("2.5.29.17", extension_id, 9) == 0) + { + result = asn1_create_element(_gnutls_get_pkix (), "PKIX1.SubjectAltName", &c2); + } + else + { + gnutls_assert (); + return GNUTLS_E_INTERNAL_ERROR; + } + if (result != ASN1_SUCCESS) { gnutls_assert (); @@ -1188,7 +1200,49 @@ gnutls_x509_crt_get_subject_alt_name (gnutls_x509_crt_t cert, size_t * ret_size, unsigned int *critical) { - return get_subject_alt_name (cert, seq, ret, ret_size, NULL, critical, 0); + return get_alt_name (cert, "2.5.29.17", seq, ret, ret_size, NULL, critical, 0); +} + +/** + * gnutls_x509_crt_get_issuer_alt_name - Get certificate's issuer alternative name, if any + * @cert: should contain a #gnutls_x509_crt_t structure + * @seq: specifies the sequence number of the alt name (0 for the first one, 1 for the second etc.) + * @ret: is the place where the alternative name will be copied to + * @ret_size: holds the size of ret. + * @critical: will be non zero if the extension is marked as critical (may be null) + * + * This function will return the issuer alternative names, contained in the + * given certificate. + * + * This is specified in X509v3 Certificate Extensions. GNUTLS will + * return the Isssuer Alternative name (2.5.29.18), or a negative error code. + * + * When the SAN type is otherName, it will extract the data in the + * otherName's value field, and %GNUTLS_SAN_OTHERNAME is returned. + * You may use gnutls_x509_crt_get_subject_alt_othername_oid() to get + * the corresponding OID and the "virtual" SAN types (e.g., + * %GNUTLS_SAN_OTHERNAME_XMPP). + * + * If an otherName OID is known, the data will be decoded. Otherwise + * the returned data will be DER encoded, and you will have to decode + * it yourself. Currently, only the RFC 3920 id-on-xmppAddr Issuer AltName + * is recognized. + * + * Returns: the alternative issuer name type on success, one of the + * enumerated #gnutls_x509_subject_alt_name_t. It will return + * %GNUTLS_E_SHORT_MEMORY_BUFFER if @ret_size is not large enough + * to hold the value. In that case @ret_size will be updated with + * the required size. If the certificate does not have an + * Alternative name with the specified sequence number then + * %GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE is returned. + **/ +int +gnutls_x509_crt_get_issuer_alt_name (gnutls_x509_crt_t cert, + unsigned int seq, void *ret, + size_t * ret_size, + unsigned int *critical) +{ + return get_alt_name (cert, "2.5.29.18", seq, ret, ret_size, NULL, critical, 0); } /** @@ -1222,8 +1276,41 @@ gnutls_x509_crt_get_subject_alt_name2 (gnutls_x509_crt_t cert, unsigned int *ret_type, unsigned int *critical) { - return get_subject_alt_name (cert, seq, ret, ret_size, ret_type, critical, - 0); + return get_alt_name (cert, "2.5.29.17", seq, ret, ret_size, ret_type, critical, 0); +} + +/** + * gnutls_x509_crt_get_issuer_alt_name2 - Get certificate issuer's alternative name, if any + * @cert: should contain a #gnutls_x509_crt_t structure + * @seq: specifies the sequence number of the alt name (0 for the first one, 1 for the second etc.) + * @ret: is the place where the alternative name will be copied to + * @ret_size: holds the size of ret. + * @ret_type: holds the type of the alternative name (one of gnutls_x509_subject_alt_name_t). + * @critical: will be non zero if the extension is marked as critical (may be null) + * + * This function will return the alternative names, contained in the + * given certificate. It is the same as + * gnutls_x509_crt_get_issuer_alt_name() except for the fact that it + * will return the type of the alternative name in @ret_type even if + * the function fails for some reason (i.e. the buffer provided is + * not enough). + * + * Returns: the alternative issuer name type on success, one of the + * enumerated #gnutls_x509_subject_alt_name_t. It will return + * %GNUTLS_E_SHORT_MEMORY_BUFFER if @ret_size is not large enough + * to hold the value. In that case @ret_size will be updated with + * the required size. If the certificate does not have an + * Alternative name with the specified sequence number then + * %GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE is returned. + **/ +int +gnutls_x509_crt_get_issuer_alt_name2 (gnutls_x509_crt_t cert, + unsigned int seq, void *ret, + size_t * ret_size, + unsigned int *ret_type, + unsigned int *critical) +{ + return get_alt_name (cert, "2.5.29.18", seq, ret, ret_size, ret_type, critical, 0); } /** @@ -1257,7 +1344,41 @@ gnutls_x509_crt_get_subject_alt_othername_oid (gnutls_x509_crt_t cert, unsigned int seq, void *ret, size_t * ret_size) { - return get_subject_alt_name (cert, seq, ret, ret_size, NULL, NULL, 1); + return get_alt_name (cert, "2.5.29.17", seq, ret, ret_size, NULL, NULL, 1); +} + +/** + * gnutls_x509_crt_get_issuer_alt_othername_oid - Get Issuer AltName otherName OID + * @cert: should contain a #gnutls_x509_crt_t structure + * @seq: specifies the sequence number of the alt name (0 for the first one, 1 for the second etc.) + * @ret: is the place where the otherName OID will be copied to + * @ret_size: holds the size of ret. + * + * This function will extract the type OID of an otherName Subject + * Alternative Name, contained in the given certificate, and return + * the type as an enumerated element. + * + * This function is only useful if + * gnutls_x509_crt_get_issuer_alt_name() returned + * %GNUTLS_SAN_OTHERNAME. + * + * Returns: the alternative issuer name type on success, one of the + * enumerated gnutls_x509_subject_alt_name_t. For supported OIDs, it + * will return one of the virtual (GNUTLS_SAN_OTHERNAME_*) types, + * e.g. %GNUTLS_SAN_OTHERNAME_XMPP, and %GNUTLS_SAN_OTHERNAME for + * unknown OIDs. It will return %GNUTLS_E_SHORT_MEMORY_BUFFER if + * @ret_size is not large enough to hold the value. In that case + * @ret_size will be updated with the required size. If the + * certificate does not have an Alternative name with the specified + * sequence number and with the otherName type then + * %GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE is returned. + **/ +int +gnutls_x509_crt_get_issuer_alt_othername_oid (gnutls_x509_crt_t cert, + unsigned int seq, + void *ret, size_t * ret_size) +{ + return get_alt_name (cert, "2.5.29.18", seq, ret, ret_size, NULL, NULL, 1); } /** From bradh at frogmouth.net Tue Jul 14 11:52:47 2009 From: bradh at frogmouth.net (Brad Hards) Date: Tue, 14 Jul 2009 19:52:47 +1000 Subject: Fwd: Re: [Help-gnutls] Problem building from git In-Reply-To: <4A5B710A.4000301@gnutls.org> References: <200907132107.01316.bradh@frogmouth.net> <4A5B710A.4000301@gnutls.org> Message-ID: <200907141952.48162.bradh@frogmouth.net> On Tuesday 14 July 2009 03:38:18 Nikos Mavrogiannopoulos wrote: > Simon has added gl_fd_to_handle() that could be used with an inline > function to perform this cast gracefully... but I don't really know if > it is the proper place. I have another suggestion, based on that macro. Its pretty trivial. I'm just a bit confused about what gl/tests/test-sockets.c is trying to do. With this, I've got the tests passing. Brad -------------- next part -------------- commit 108d4baeb6a885879d33457e0c59bb2b45f8e538 Author: Brad Hards Date: Tue Jul 14 18:01:16 2009 +1000 Fix up building on 64-bit. diff --git a/gl/sockets.h b/gl/sockets.h index b42e368..581ffdc 100644 --- a/gl/sockets.h +++ b/gl/sockets.h @@ -44,7 +44,7 @@ gl_fd_to_handle (int fd) #else -#define gl_fd_to_handle(x) (x) +#define gl_fd_to_handle(x) (&(x)) #endif /* WINDOWS_SOCKETS */ diff --git a/gl/tests/test-sockets.c b/gl/tests/test-sockets.c index 3c85a43..1fd668f 100644 --- a/gl/tests/test-sockets.c +++ b/gl/tests/test-sockets.c @@ -40,7 +40,7 @@ main (int argc, char *argv[]) return 1; } - (void) gl_fd_to_handle (0); + // (void) gl_fd_to_handle (0); return 0; } From bradh at frogmouth.net Tue Jul 14 12:05:19 2009 From: bradh at frogmouth.net (Brad Hards) Date: Tue, 14 Jul 2009 20:05:19 +1000 Subject: [Help-gnutls] Parsing certificate extensions and issuer alt names In-Reply-To: <200907141946.11694.bradh@frogmouth.net> References: <200907071949.51751.bradh@frogmouth.net> <4A5AD54C.6040108@gnutls.org> <200907141946.11694.bradh@frogmouth.net> Message-ID: <200907142005.20551.bradh@frogmouth.net> On Tuesday 14 July 2009 19:46:10 Brad Hards wrote: > On Monday 13 July 2009 16:33:48 Nikos Mavrogiannopoulos wrote: > > Actually I think it might be much easier to do that inside gnutls by > > extending get_subject_alt_name() to be able to accept the OID as > > parameter to parse the 2.5.29.18 extension as well. Then would be easy > > to submit a gnutls_x509_crt_get_issuer_alt_name that can be added to > > gnutls. > > I had a first cut at this. See attached patch. [I realise this can't be applied yet - I'm just looking for feedback] Here is an example that I was sent a while ago, and what I see running it through certtool. Do you think it is worth adding that as a unit test? $ ./src/certtool --infile ~/devel/kde-src/kdesupport/qca/unittest/certunittest/certs/76.pem -i X.509 Certificate Information: Version: 3 Serial Number (hex): 76 Issuer: C=SE,O=Stockholms universitet,CN=Stockholm University CA Validity: Not Before: Wed Mar 22 09:15:28 UTC 2006 Not After: Thu Mar 22 09:15:28 UTC 2007 Subject: C=SE,O=Stockholms universitet,CN=sip1.su.se Subject Public Key Algorithm: RSA Modulus (bits 1024): ad:4c:d7:4c:3d:fa:64:ae:c2:c1:92:47:fd:f6:94:35 37:1d:6a:a3:3b:27:28:99:b1:fa:ce:ef:4d:dd:ed:c4 ff:6c:9d:f0:2b:14:fc:b6:b3:8e:87:f3:ae:5b:08:06 15:7d:be:af:bc:a4:ba:7d:da:21:45:d4:b8:3d:77:62 57:bf:c8:7a:87:ff:88:3d:bd:65:fb:51:e1:42:06:54 88:d2:d0:31:9e:5a:ad:d1:0a:a5:3e:04:9d:18:b1:dc a0:ee:0f:3f:28:e8:9f:d8:e3:d0:0f:f3:a4:91:99:1e 24:54:0a:8a:28:eb:76:2a:13:d3:18:7e:be:47:05:f9 Exponent (bits 24): 01:00:01 Extensions: Key Usage (not critical): Digital signature. Non repudiation. Key encipherment. Key Purpose (not critical): TLS WWW Server. TLS WWW Client. Subject Key Identifier (not critical): 3a5c5cd1cc2c9edf73f73bd81b59b1eab83035c5 Authority Key Identifier (not critical): 9e2e30ba37d95144c99dbf1821f1bd7eeeb58648 CRL Distribution points (not critical): URI: http://ca.su.se/2005-1/crl-v2.crl Unknown extension 2.5.29.32 (not critical): ASCII: 0p0n..*.p+....0b0...+.........http://ca.su.se/CPS0?..+.......03.1Limited Liability, see http://www.swupki.su.se/CP Hexdump: 3070306e06082a85702b020101013062301f06082b060105050702011613687474703a2f2f63612e73752e73652f435053303f06082b0601050507020230331a314c696d69746564204c696162696c6974792c2073656520687474703a2f2f7777772e737775706b692e73752e73652f4350 Issuer Alternative Name (not critical): RFC822name: ca at su.se URI: http://ca.su.se Subject Alternative Name (not critical): DNSname: incomingproxy.sip.su.se DNSname: incomingproxy1.sip.su.se DNSname: outgoingproxy.sip.su.se DNSname: outgoingproxy1.sip.su.se DNSname: out.sip.su.se DNSname: appserver.sip.su.se DNSname: appserver1.sip.su.se DNSname: sip1.su.se Signature Algorithm: RSA-SHA Signature: 11:15:88:3b:ca:d7:29:87:41:3b:5a:6b:cc:e3:80:0d ff:ca:ab:bb:bb:51:5f:a6:92:15:6a:e3:2f:25:6b:ff 55:a4:e2:9a:c2:2b:8c:b9:26:97:cd:c3:97:61:f5:9f 1f:fe:0c:85:b2:bd:62:16:c6:fa:7d:2d:e7:25:34:dd dd:f5:65:59:17:dc:34:21:88:c7:98:3c:2a:e4:9b:de ee:9f:ed:5c:e7:90:63:9e:89:13:11:11:24:1c:d4:6f 01:7a:1d:33:6d:d6:52:ec:16:0e:da:0f:44:2a:56:c6 49:3e:4f:c1:09:dc:e2:0f:4a:ee:9a:8f:c8:a4:8d:56 4c:db:eb:43:6e:8e:0f:fe:a9:88:de:ec:c0:9c:37:e6 51:9d:40:68:e9:4d:8d:67:4e:bf:40:45:05:9b:eb:94 22:16:7c:20:63:35:80:b7:a1:0b:b4:37:1b:8f:9d:e1 cd:fc:08:32:71:42:74:8f:3a:05:a2:5e:e4:af:86:14 26:28:3b:1b:ac:ac:d1:69:e0:51:87:97:84:25:b4:e4 03:c0:e9:d0:49:9b:d1:4a:e4:45:58:62:c5:e8:3d:ee cb:71:51:c0:13:02:37:46:96:32:7d:30:b9:ee:1d:79 c8:ee:28:46:75:47:e0:e6:af:f5:d3:9b:e9:b1:0a:4e Other Information: MD5 fingerprint: 146193ad068b89c90caee8405bcd8949 SHA-1 fingerprint: f196cc4bf2376499987cc412eccd1ce019c39b38 Public Key Id: 5fccf39f1d88719c0ba62c5df5f45c6d717172a5 -----BEGIN CERTIFICATE----- MIIE6zCCA9OgAwIBAgIBdjANBgkqhkiG9w0BAQUFADBQMQswCQYDVQQGEwJTRTEf MB0GA1UEChMWU3RvY2tob2xtcyB1bml2ZXJzaXRldDEgMB4GA1UEAxMXU3RvY2to b2xtIFVuaXZlcnNpdHkgQ0EwHhcNMDYwMzIyMDkxNTI4WhcNMDcwMzIyMDkxNTI4 WjBDMQswCQYDVQQGEwJTRTEfMB0GA1UEChMWU3RvY2tob2xtcyB1bml2ZXJzaXRl dDETMBEGA1UEAxMKc2lwMS5zdS5zZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEArUzXTD36ZK7CwZJH/faUNTcdaqM7JyiZsfrO703d7cT/bJ3wKxT8trOOh/Ou WwgGFX2+r7ykun3aIUXUuD13Yle/yHqH/4g9vWX7UeFCBlSI0tAxnlqt0QqlPgSd GLHcoO4PPyjon9jj0A/zpJGZHiRUCooo63YqE9MYfr5HBfkCAwEAAaOCAl8wggJb MAsGA1UdDwQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwHQYD VR0OBBYEFDpcXNHMLJ7fc/c72BtZseq4MDXFMH8GA1UdIwR4MHaAFJ4uMLo32VFE yZ2/GCHxvX7utYZIoVukWTBXMQswCQYDVQQGEwJTRTEYMBYGA1UEChMPVW1lYSBV bml2ZXJzaXR5MRMwEQYDVQQLEwpTd1VQS0ktUENBMRkwFwYDVQQDExBTd1VQS0kg UG9saWN5IENBggEQMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9jYS5zdS5zZS8y MDA1LTEvY3JsLXYyLmNybDB5BgNVHSAEcjBwMG4GCCqFcCsCAQEBMGIwHwYIKwYB BQUHAgEWE2h0dHA6Ly9jYS5zdS5zZS9DUFMwPwYIKwYBBQUHAgIwMxoxTGltaXRl ZCBMaWFiaWxpdHksIHNlZSBodHRwOi8vd3d3LnN3dXBraS5zdS5zZS9DUDAkBgNV HRIEHTAbgQhjYUBzdS5zZYYPaHR0cDovL2NhLnN1LnNlMIG3BgNVHREEga8wgayC F2luY29taW5ncHJveHkuc2lwLnN1LnNlghhpbmNvbWluZ3Byb3h5MS5zaXAuc3Uu c2WCF291dGdvaW5ncHJveHkuc2lwLnN1LnNlghhvdXRnb2luZ3Byb3h5MS5zaXAu c3Uuc2WCDW91dC5zaXAuc3Uuc2WCE2FwcHNlcnZlci5zaXAuc3Uuc2WCFGFwcHNl cnZlcjEuc2lwLnN1LnNlggpzaXAxLnN1LnNlMA0GCSqGSIb3DQEBBQUAA4IBAQAR FYg7ytcph0E7WmvM44AN/8qru7tRX6aSFWrjLyVr/1Wk4prCK4y5JpfNw5dh9Z8f /gyFsr1iFsb6fS3nJTTd3fVlWRfcNCGIx5g8KuSb3u6f7VznkGOeiRMRESQc1G8B eh0zbdZS7BYO2g9EKlbGST5PwQnc4g9K7pqPyKSNVkzb60Nujg/+qYje7MCcN+ZR nUBo6U2NZ06/QEUFm+uUIhZ8IGM1gLehC7Q3G4+d4c38CDJxQnSPOgWiXuSvhhQm KDsbrKzRaeBRh5eEJbTkA8Dp0Emb0UrkRVhixeg97stxUcATAjdGljJ9MLnuHXnI 7ihGdUfg5q/105vpsQpO -----END CERTIFICATE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 76.pem Type: application/x-x509-ca-cert Size: 5129 bytes Desc: not available URL: From nmav at gnutls.org Tue Jul 14 23:12:01 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 15 Jul 2009 00:12:01 +0300 Subject: Fwd: Re: [Help-gnutls] Problem building from git In-Reply-To: <200907140937.23941.bradh@frogmouth.net> References: <200907132107.01316.bradh@frogmouth.net> <4A5B710A.4000301@gnutls.org> <200907140937.23941.bradh@frogmouth.net> Message-ID: <4A5CF4A1.503@gnutls.org> Brad Hards wrote: > On Tuesday 14 July 2009 03:38:18 Nikos Mavrogiannopoulos wrote: >> I have solved the warnings except the transport_ptr cast. Most of them >> a bit different (I don't know how widely used i z for size_t, so I just >> casted size_t to int for printing). > Thanks. > I did some checking - looks like 'z' is in glibc, based on the SuSv3. I think > that might come from C99 - I don't have a copy to check. Not sure if it is > supported in C89. Which compilers / C libraries are supported for gnutls? Actually it is C99 which is what gnutls is supposed to support. It could have been z as well. >> The former warning for cast is not >> easy to solve and not really needed on current platforms. Anyway I see >> Simon has added gl_fd_to_handle() that could be used with an inline >> function to perform this cast gracefully... but I don't really know if >> it is the proper place. > I also saw that it was identified as an issue some time ago. > http://www.mail-archive.com/help-gnutls at gnu.org/msg00286.html > > Do you have any suggestions other than turning off -Werror? We would need something like: static inline void* int2ptr(int fd) { void* ret; memcpy(ret, &fd, sizeof(fd)); return ret; } static inline int ptr2int(void* ptr) { int fd; memcpy(&fd, ptr, sizeof(fd)); return fd; } However this interferes with the win32 emulation API, thus it might be better to have some suggestions from simon as well. regards, Nikos > Brad From nmav at gnutls.org Tue Jul 14 23:13:09 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 15 Jul 2009 00:13:09 +0300 Subject: Fwd: Re: [Help-gnutls] Problem building from git In-Reply-To: <200907141952.48162.bradh@frogmouth.net> References: <200907132107.01316.bradh@frogmouth.net> <4A5B710A.4000301@gnutls.org> <200907141952.48162.bradh@frogmouth.net> Message-ID: <4A5CF4E5.8030707@gnutls.org> Brad Hards wrote: > On Tuesday 14 July 2009 03:38:18 Nikos Mavrogiannopoulos wrote: >> Simon has added gl_fd_to_handle() that could be used with an inline >> function to perform this cast gracefully... but I don't really know if >> it is the proper place. > I have another suggestion, based on that macro. Its pretty trivial. I'm just a > bit confused about what gl/tests/test-sockets.c is trying to do. > With this, I've got the tests passing. Actually you don't want to pass the pointer there but the actual integer (the real socket). That's why it gets complicated. From nmav at gnutls.org Tue Jul 14 23:18:19 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 15 Jul 2009 00:18:19 +0300 Subject: [Help-gnutls] Parsing certificate extensions and issuer alt names In-Reply-To: <200907141946.11694.bradh@frogmouth.net> References: <200907071949.51751.bradh@frogmouth.net> <4A5AD54C.6040108@gnutls.org> <200907141946.11694.bradh@frogmouth.net> Message-ID: <4A5CF61B.6070002@gnutls.org> Brad Hards wrote: > On Monday 13 July 2009 16:33:48 Nikos Mavrogiannopoulos wrote: >> Actually I think it might be much easier to do that inside gnutls by >> extending get_subject_alt_name() to be able to accept the OID as >> parameter to parse the 2.5.29.18 extension as well. Then would be easy >> to submit a gnutls_x509_crt_get_issuer_alt_name that can be added to >> gnutls. > I had a first cut at this. See attached patch. > > Thoughts / comments? Looks ok to me. Only some comment: + if (strncmp("2.5.29.18", extension_id, 9) == 0) + { + result = asn1_create_element(_gnutls_get_pkix (), "PKIX1.IssuerAltName", &c2); + } + else if (strncmp("2.5.29.17", extension_id, 9) == 0) Here it should have been strcmp instead of strncmp to avoid having false positives (such as 2.5.29.17 == 2.5.29.17.24) in some future extension. If you could send me an updated version I'll commit it. best regards, Nikos From nmav at gnutls.org Tue Jul 14 23:19:44 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 15 Jul 2009 00:19:44 +0300 Subject: [Help-gnutls] Parsing certificate extensions and issuer alt names In-Reply-To: <200907142005.20551.bradh@frogmouth.net> References: <200907071949.51751.bradh@frogmouth.net> <4A5AD54C.6040108@gnutls.org> <200907141946.11694.bradh@frogmouth.net> <200907142005.20551.bradh@frogmouth.net> Message-ID: <4A5CF670.6000806@gnutls.org> Brad Hards wrote: > On Tuesday 14 July 2009 19:46:10 Brad Hards wrote: >> On Monday 13 July 2009 16:33:48 Nikos Mavrogiannopoulos wrote: >>> Actually I think it might be much easier to do that inside gnutls by >>> extending get_subject_alt_name() to be able to accept the OID as >>> parameter to parse the 2.5.29.18 extension as well. Then would be easy >>> to submit a gnutls_x509_crt_get_issuer_alt_name that can be added to >>> gnutls. >> I had a first cut at this. See attached patch. > [I realise this can't be applied yet - I'm just looking for feedback] > > Here is an example that I was sent a while ago, and what I see running it through > certtool. Do you think it is worth adding that as a unit test? Yes. From mydevforums at gmail.com Tue Jul 14 23:43:39 2009 From: mydevforums at gmail.com (Ram G) Date: Tue, 14 Jul 2009 17:43:39 -0400 Subject: [Help-gnutls] Dynamically building the PSK keys In-Reply-To: <3a8533cc0907131336t6594847cgd39b9c6e5244b962@mail.gmail.com> References: <3a8533cc0907131021l2a0fcb20o7b3e01d8f76cacd4@mail.gmail.com> <4A5B94A1.8050007@gnutls.org> <3a8533cc0907131336t6594847cgd39b9c6e5244b962@mail.gmail.com> Message-ID: <3a8533cc0907141443s3934eda9va7fac0ace7ef9874@mail.gmail.com> I tried out a couple of more ideas but no luck. Setting the key on the server side as follows works: key->data = gnutls_malloc (4); key->data = "\xDE\xAD\xBE\xEF"; key->size = 4; I also tried as follows: char * somekey = "DEADBEEF"; //DEADBEEF is hardcoded for test but will be dynamically generated int i,temp; for (i = 0; somekey[i]; i += 2) { sscanf(&somekey[i], "%02x", &temp); key->data[i / 2] = temp; } This does not work either. I'm scratching my head how to take a string like "DEADBEEF" and convert it to "\xDE\xAD\xBE\xEF" and assign it to key->data. If PSK key value on the client side is given as const gnutls_datum_t key = { (char*) "DEADBEEF", 8 }; why doesn't it work if I assign it the same way on the server side? Why does it expect it as hexadecimal values ? Any ideas highly appreciated. -Ramg On Mon, Jul 13, 2009 at 4:36 PM, Ram G wrote: > Hi Nikos, > > Thanks for your response. > > I tried your suggestion and that does not work either. However the sample > program works fine when assigning two hexadecimal characters each to the 4 > bytes. > > It is a weird requirement but we cannot use certificates or previously > known keys for the PSK authentication. Instead what I'm doing is establish > an anonymous DH handshake between the client and the server. Now both the > client and the server know the master secret. I would like to use this > master secret as pre-shared keys between the client and the server. > > Can you please let me know if this can weaken the cryptosystem ? I'll try > out any alternate suggestion you might have. > > Thanks and Regards > > Ramg > > On Mon, Jul 13, 2009 at 4:10 PM, Nikos Mavrogiannopoulos < > nmav at gnutls.org> wrote: > >> Ram G wrote: >> > Hi, >> > >> > I'm working on the sample programs provided in the source examples >> folder >> > and I would like some help from you. I'm trying to do a DH key exchange >> with >> > PSK authentication. >> > >> > The client sample (ex-client-psk.c) assigns the pre shared key as >> follows: >> > >> > const gnutls_datum_t key = { (char*) "DEADBEEF", 8 }; >> > >> > The server sample (ex-serv-psk.c) does the key assignment in the >> callback >> > function pskfunc as follows: >> > >> > key->data = gnutls_malloc (4); >> > key->data[0] = 0xDE; >> > key->data[1] = 0xAD; >> > key->data[2] = 0xBE; >> > key->data[3] = 0xEF; >> > key->size = 4; >> >> It is not the same as above. Above you use 8 bytes and here 4. Use >> instead: >> key->data[0] = 'D'; >> key->data[1] = 'E'; >> key->data[2] = 'A'; >> key->data[3] = 'D'; >> key->data[4] = 'B'; >> key->data[5] = 'E'; >> key->data[6] = 'E'; >> key->data[7] = 'F'; >> key->size = 8; >> >> > I would like to assign the pre-shared key dynamically. If I assign the >> PSK >> > in the server as follows, it does not work. I get the error "Decryption >> has >> > failed". >> >> Actually how the keys are going to be generated? You have to think about >> that seriously and make sure that the key generation is not weakening >> the cryptosystem. To be on the safe side, and especially if you are not >> experienced in the field use the tools provided by gnutls for the key >> generation. >> >> >> regards, >> Nikos >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From axos88 at gmail.com Wed Jul 15 00:27:59 2009 From: axos88 at gmail.com (Akos Vandra) Date: Wed, 15 Jul 2009 00:27:59 +0200 Subject: [Help-gnutls] TLSv1.2 decoding Message-ID: Hello, I am a student doing some research on the inner workings of TLSv1.2, for implementation on a custom hardware. Currently I am sniffing traffic between gnutls-serv and gnutls-cli, and trying to work out each bytes meaning (yeah I am a little bit crazy, but this helps me understand the protocol top to bottom. :) I am trying to decode the CertificateVerify structure, but have thus far failed. I have access to both client(512bit) and server(1024bit) keys, and have sniffed their communication, what I came up with (along the stream) is this CertificateVerify packet sent from the client to the server: 0x16, 0x03, 0x03, 0x00, 0x46, 0x0f, 0x00, 0x00, 0x42, 0x00, 0x40, 0xe4, 0xe9, 0xcd, 0xcb, 0xef, 0x24, 0x03, 0xb2, 0x9e, 0x67, 0xc4, 0x4b, 0x8d, 0x48, 0x6f, 0x27, 0x34, 0x2d, 0xc3, 0xc6, 0x22, 0x53, 0x86, 0xeb, 0x12, 0xf6, 0x0b, 0xb1, 0xd5, 0xaf, 0xc0, 0xb7, 0x97, 0x48, 0xfa, 0xd8, 0xdc, 0xca, 0xc8, 0x58, 0xe4, 0x49, 0x9c, 0x49, 0x58, 0xaf, 0x95, 0x94, 0xef, 0x30, 0xa2, 0x4b, 0x6f, 0xc4, 0x60, 0x0f, 0x46, 0x8b, 0xd7, 0xc2, 0x39, 0x77, 0xa7, 0xc3, As far as I know, this means the next things: TLSPlainText. ContentType = 0x16 (Handshake) ProtocolVersion = 0x03, 0x03, Length = 0x00, 0x46, Fragment = Handshake TLSPlainText.Handshake. HandshakeType = 0x0f (certificate_verify) Length = 0x00, 0x00, 0x42, Body = CertificateVerify TLSPlainText.Handshake. CertificateVerify Length = 0x00, 0x40, <-- The RFC doesn't say that there should be a length info here, but this certainly is the remaining part's length. Data = 0xe4, 0xe9, 0xcd, 0xcb, 0xef, 0x24, 0x03, 0xb2, 0x9e, 0x67, 0xc4, 0x4b, 0x8d, 0x48, 0x6f, 0x27, 0x34, 0x2d, 0xc3, 0xc6, 0x22, 0x53, 0x86, 0xeb, 0x12, 0xf6, 0x0b, 0xb1, 0xd5, 0xaf, 0xc0, 0xb7, 0x97, 0x48, 0xfa, 0xd8, 0xdc, 0xca, 0xc8, 0x58, 0xe4, 0x49, 0x9c, 0x49, 0x58, 0xaf, 0x95, 0x94, 0xef, 0x30, 0xa2, 0x4b, 0x6f, 0xc4, 0x60, 0x0f, 0x46, 0x8b, 0xd7, 0xc2, 0x39, 0x77, 0xa7, 0xc3 I tried decoding this signed data with openssl (successfully), it yielded: $openssl rsautl -verify -inkey clientkey.pem -in sign.bin -hexdump 0000 - 47 f6 a5 1b a9 cb 4a a6-90 63 2c 65 ec 6f 6d 20 0010 - 10 af a8 f0 f0 80 0d 99-a3 22 cf 2b 07 b0 a4 c8 0020 - c7 ec 1d 33 My question is how to interpret this data? From the rfc I understood that this should be a struct { SignatureAndHashAlgorithm algorithm; opaque signature<0..2^16-1>; } DigitallySigned; But this certainly isn't one (for ex. none of the bytes could make for a length info for the signature field). What am I missing? I am not sure what is the hash that should be calculated, so I am not sending that along, because I don't think it is correct. Thanks in advance for your help, Vandra ?kos From mydevforums at gmail.com Wed Jul 15 04:44:32 2009 From: mydevforums at gmail.com (Ram G) Date: Tue, 14 Jul 2009 22:44:32 -0400 Subject: [Help-gnutls] How are the PSK keys read Message-ID: <3a8533cc0907141944m6ab26d5focea62e0e91ebd305@mail.gmail.com> Hello, Does any body have any experience how the pre-shared keys are read from when doing a DH key exchange with PSK authentication ? Other than hard coding it into the application, what are the other sources it is read from ( database ? file ? ) and how ? I have looked at the sample code provided in the examples directory. The client sample (ex-client-psk.c) assigns the pre shared key as follows: const gnutls_datum_t key = { (char*) "DEADBEEF", 8 }; The server sample (ex-serv-psk.c) does the key assignment in the callback function pskfunc as follows: key->data = gnutls_malloc (4); key->data[0] = 0xDE; key->data[1] = 0xAD; key->data[2] = 0xBE; key->data[3] = 0xEF; key->size = 4; Obviously these are hard coded values. How are the keys read in the real world ? If anyone has any samples to share, I would really appreciate it. I'm working on a prototype and I have to report to my boss whether we can use GnuTLS. I'm trying to assign a dynamic value to the keys but I cannot make the TLS handshake to happen. Thanks and Regards Ramg -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradh at frogmouth.net Wed Jul 15 06:10:06 2009 From: bradh at frogmouth.net (Brad Hards) Date: Wed, 15 Jul 2009 14:10:06 +1000 Subject: [Help-gnutls] How are the PSK keys read In-Reply-To: <3a8533cc0907141944m6ab26d5focea62e0e91ebd305@mail.gmail.com> References: <3a8533cc0907141944m6ab26d5focea62e0e91ebd305@mail.gmail.com> Message-ID: <200907151410.07951.bradh@frogmouth.net> On Wednesday 15 July 2009 12:44:32 Ram G wrote: > Does any body have any experience how the pre-shared keys are read from > when doing a DH key exchange with PSK authentication ? Other than hard > coding it into the application, what are the other sources it is read from > ( database ? file ? ) and how ? Surely this is a bit implementation specific? What does your specific application need to do? I haven't tried this, but the documentation suggests that gnutls has some built-in support for using a password file: http://www.gnu.org/software/gnutls/manual/html_node/Authentication-using- PSK.html#Authentication-using-PSK > Obviously these are hard coded values. How are the keys read in the real > world ? Just provide them however suits your application. > If anyone has any samples to share, I would really appreciate it. There is an example of using gnutls_srp_set_server_credentials_file() in src/serv.c Brad From davefx at gmail.com Wed Jul 15 09:24:32 2009 From: davefx at gmail.com (=?UTF-8?B?RGF2aWQgTWFyw61uIENhcnJlw7Fv?=) Date: Wed, 15 Jul 2009 09:24:32 +0200 Subject: [Help-gnutls] Dynamically building the PSK keys In-Reply-To: <3a8533cc0907141443s3934eda9va7fac0ace7ef9874@mail.gmail.com> References: <3a8533cc0907131021l2a0fcb20o7b3e01d8f76cacd4@mail.gmail.com> <4A5B94A1.8050007@gnutls.org> <3a8533cc0907131336t6594847cgd39b9c6e5244b962@mail.gmail.com> <3a8533cc0907141443s3934eda9va7fac0ace7ef9874@mail.gmail.com> Message-ID: I think you are keeping the same confusion in data formats. A string with characters "ABCD" is saved in memory as characters 'A' (ascii 0x41), 'B' (ascii 0x42), 'C' (ascii 0x43) and 'D' (ascii 0x44) in 4 bytes, not as 2 bytes 0xAB and 0xCD. Greetings -- David Mar?n Carre?o 2009/7/14 Ram G > > I tried out a couple of more ideas but no luck. > > Setting the key on the server side as follows works: > > key->data = gnutls_malloc (4); > key->data = "\xDE\xAD\xBE\xEF"; > key->size = 4; > > I also tried as follows: > > char * somekey = "DEADBEEF"; //DEADBEEF is hardcoded for test but will be > dynamically generated > int i,temp; > > for (i = 0; somekey[i]; i += 2) { > sscanf(&somekey[i], "%02x", &temp); > key->data[i / 2] = temp; > } > This does not work either. I'm scratching my head how to take a string like > "DEADBEEF" and convert it to "\xDE\xAD\xBE\xEF" and assign it to key->data. > > If PSK key value on the client side is given as > const gnutls_datum_t key = { (char*) "DEADBEEF", 8 }; > why doesn't it work if I assign it the same way on the server side? Why > does it expect it as hexadecimal values ? > > Any ideas highly appreciated. > > -Ramg > > > On Mon, Jul 13, 2009 at 4:36 PM, Ram G wrote: > >> Hi Nikos, >> >> Thanks for your response. >> >> I tried your suggestion and that does not work either. However the sample >> program works fine when assigning two hexadecimal characters each to the 4 >> bytes. >> >> It is a weird requirement but we cannot use certificates or previously >> known keys for the PSK authentication. Instead what I'm doing is establish >> an anonymous DH handshake between the client and the server. Now both the >> client and the server know the master secret. I would like to use this >> master secret as pre-shared keys between the client and the server. >> >> Can you please let me know if this can weaken the cryptosystem ? I'll try >> out any alternate suggestion you might have. >> >> Thanks and Regards >> >> Ramg >> >> On Mon, Jul 13, 2009 at 4:10 PM, Nikos Mavrogiannopoulos < >> nmav at gnutls.org> wrote: >> >>> Ram G wrote: >>> > Hi, >>> > >>> > I'm working on the sample programs provided in the source examples >>> folder >>> > and I would like some help from you. I'm trying to do a DH key exchange >>> with >>> > PSK authentication. >>> > >>> > The client sample (ex-client-psk.c) assigns the pre shared key as >>> follows: >>> > >>> > const gnutls_datum_t key = { (char*) "DEADBEEF", 8 }; >>> > >>> > The server sample (ex-serv-psk.c) does the key assignment in the >>> callback >>> > function pskfunc as follows: >>> > >>> > key->data = gnutls_malloc (4); >>> > key->data[0] = 0xDE; >>> > key->data[1] = 0xAD; >>> > key->data[2] = 0xBE; >>> > key->data[3] = 0xEF; >>> > key->size = 4; >>> >>> It is not the same as above. Above you use 8 bytes and here 4. Use >>> instead: >>> key->data[0] = 'D'; >>> key->data[1] = 'E'; >>> key->data[2] = 'A'; >>> key->data[3] = 'D'; >>> key->data[4] = 'B'; >>> key->data[5] = 'E'; >>> key->data[6] = 'E'; >>> key->data[7] = 'F'; >>> key->size = 8; >>> >>> > I would like to assign the pre-shared key dynamically. If I assign the >>> PSK >>> > in the server as follows, it does not work. I get the error "Decryption >>> has >>> > failed". >>> >>> Actually how the keys are going to be generated? You have to think about >>> that seriously and make sure that the key generation is not weakening >>> the cryptosystem. To be on the safe side, and especially if you are not >>> experienced in the field use the tools provided by gnutls for the key >>> generation. >>> >>> >>> regards, >>> Nikos >>> >>> >> > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradh at frogmouth.net Wed Jul 15 13:13:51 2009 From: bradh at frogmouth.net (Brad Hards) Date: Wed, 15 Jul 2009 21:13:51 +1000 Subject: [Help-gnutls] [patch] Fix typo in test case for dn.c Message-ID: <200907152113.51597.bradh@frogmouth.net> This one is trivial. Brad -------------- next part -------------- commit 21dae841545ce7d966f754a6b39577161510ea92 Author: Brad Hards Date: Wed Jul 15 21:11:20 2009 +1000 Typo fix in test output. diff --git a/tests/dn.c b/tests/dn.c index abae077..c47b04c 100644 --- a/tests/dn.c +++ b/tests/dn.c @@ -107,7 +107,7 @@ doit (void) ret = gnutls_x509_crt_get_issuer (cert, &xdn); if (ret < 0) - fail ("get_subject %d\n", ret); + fail ("get_issuer %d\n", ret); printf ("Issuer:\n"); print_dn (xdn); From nmav at gnutls.org Wed Jul 15 23:09:21 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 16 Jul 2009 00:09:21 +0300 Subject: [Help-gnutls] [patch] Fix typo in test case for dn.c In-Reply-To: <200907152113.51597.bradh@frogmouth.net> References: <200907152113.51597.bradh@frogmouth.net> Message-ID: <4A5E4581.7050602@gnutls.org> Brad Hards wrote: > This one is trivial. Thank you. Applied. From carolin.latze at unifr.ch Thu Jul 16 14:13:21 2009 From: carolin.latze at unifr.ch (Carolin Latze) Date: Thu, 16 Jul 2009 14:13:21 +0200 Subject: [Help-gnutls] TLS 1.2 with standard signature? Why hash->size == 36?? Message-ID: <4A5F1961.7060507@unifr.ch> Hi all, according to RFC 5246, TLS 1.2 should use a standard signature, but if I enable TLS 1.2 in GnuTLS and print out the hash size it says 36... that does not sound like a standard signature.. I would expect something like 20 for SHA1. Am I wrong? Carolin From mydevforums at gmail.com Thu Jul 16 16:43:26 2009 From: mydevforums at gmail.com (Ram G) Date: Thu, 16 Jul 2009 10:43:26 -0400 Subject: [Help-gnutls] Dynamically building the PSK keys In-Reply-To: References: <3a8533cc0907131021l2a0fcb20o7b3e01d8f76cacd4@mail.gmail.com> <4A5B94A1.8050007@gnutls.org> <3a8533cc0907131336t6594847cgd39b9c6e5244b962@mail.gmail.com> <3a8533cc0907141443s3934eda9va7fac0ace7ef9874@mail.gmail.com> Message-ID: <3a8533cc0907160743t68484963xd773586bf1d794a8@mail.gmail.com> Finally I could complete the handshake using DHE-PSK. I followed the samples ex-client-psk.c and ex-serv-psk.c but instead of hardcoded keys, I dynamically assigned the keys as follows: char * dynamickeys; //Could be any string with hex characters like DEADBEEF atohx(key->data,dynamickeys); Here is the atohx function I got from the following link: http://cboard.cprogramming.com/c-programming/77086-no-atoh-function-c-ascii-hex-well-lets-create-one.html char * atohx(char * dst, const char * src) { int lsb,msb; char * ret; ret = dst; for(lsb = 0, msb = 0; *src; src += 2) { msb = tolower(*src); lsb = tolower(*(src + 1)); msb -= isdigit(msb) ? 0x30 : 0x57; lsb -= isdigit(lsb) ? 0x30 : 0x57; if((msb < 0x0 || msb > 0xf) || (lsb < 0x0 || lsb > 0xf)) { *ret = 0; return NULL; } *dst++ = (char)(lsb | (msb << 4)); } *dst = 0; return ret; } Thanks to all for all your suggestions. Thanks Ramg On Wed, Jul 15, 2009 at 3:24 AM, David Mar?n Carre?o wrote: > I think you are keeping the same confusion in data formats. > A string with characters "ABCD" is saved in memory as characters 'A' (ascii > 0x41), 'B' (ascii 0x42), 'C' (ascii 0x43) and 'D' (ascii 0x44) in 4 bytes, > not as 2 bytes 0xAB and 0xCD. > > Greetings > -- > David Mar?n Carre?o > > 2009/7/14 Ram G > >> >> I tried out a couple of more ideas but no luck. >> >> Setting the key on the server side as follows works: >> >> key->data = gnutls_malloc (4); >> key->data = "\xDE\xAD\xBE\xEF"; >> key->size = 4; >> >> I also tried as follows: >> >> char * somekey = "DEADBEEF"; //DEADBEEF is hardcoded for test but will be >> dynamically generated >> int i,temp; >> >> for (i = 0; somekey[i]; i += 2) { >> sscanf(&somekey[i], "%02x", &temp); >> key->data[i / 2] = temp; >> } >> This does not work either. I'm scratching my head how to take a string >> like "DEADBEEF" and convert it to "\xDE\xAD\xBE\xEF" and assign it >> to key->data. >> >> If PSK key value on the client side is given as >> const gnutls_datum_t key = { (char*) "DEADBEEF", 8 }; >> why doesn't it work if I assign it the same way on the server side? Why >> does it expect it as hexadecimal values ? >> >> Any ideas highly appreciated. >> >> -Ramg >> >> >> On Mon, Jul 13, 2009 at 4:36 PM, Ram G wrote: >> >>> Hi Nikos, >>> >>> Thanks for your response. >>> >>> I tried your suggestion and that does not work either. However the sample >>> program works fine when assigning two hexadecimal characters each to the 4 >>> bytes. >>> >>> It is a weird requirement but we cannot use certificates or previously >>> known keys for the PSK authentication. Instead what I'm doing is establish >>> an anonymous DH handshake between the client and the server. Now both the >>> client and the server know the master secret. I would like to use this >>> master secret as pre-shared keys between the client and the server. >>> >>> Can you please let me know if this can weaken the cryptosystem ? I'll try >>> out any alternate suggestion you might have. >>> >>> Thanks and Regards >>> >>> Ramg >>> >>> On Mon, Jul 13, 2009 at 4:10 PM, Nikos Mavrogiannopoulos < >>> nmav at gnutls.org> wrote: >>> >>>> Ram G wrote: >>>> > Hi, >>>> > >>>> > I'm working on the sample programs provided in the source examples >>>> folder >>>> > and I would like some help from you. I'm trying to do a DH key >>>> exchange with >>>> > PSK authentication. >>>> > >>>> > The client sample (ex-client-psk.c) assigns the pre shared key as >>>> follows: >>>> > >>>> > const gnutls_datum_t key = { (char*) "DEADBEEF", 8 }; >>>> > >>>> > The server sample (ex-serv-psk.c) does the key assignment in the >>>> callback >>>> > function pskfunc as follows: >>>> > >>>> > key->data = gnutls_malloc (4); >>>> > key->data[0] = 0xDE; >>>> > key->data[1] = 0xAD; >>>> > key->data[2] = 0xBE; >>>> > key->data[3] = 0xEF; >>>> > key->size = 4; >>>> >>>> It is not the same as above. Above you use 8 bytes and here 4. Use >>>> instead: >>>> key->data[0] = 'D'; >>>> key->data[1] = 'E'; >>>> key->data[2] = 'A'; >>>> key->data[3] = 'D'; >>>> key->data[4] = 'B'; >>>> key->data[5] = 'E'; >>>> key->data[6] = 'E'; >>>> key->data[7] = 'F'; >>>> key->size = 8; >>>> >>>> > I would like to assign the pre-shared key dynamically. If I assign the >>>> PSK >>>> > in the server as follows, it does not work. I get the error >>>> "Decryption has >>>> > failed". >>>> >>>> Actually how the keys are going to be generated? You have to think about >>>> that seriously and make sure that the key generation is not weakening >>>> the cryptosystem. To be on the safe side, and especially if you are not >>>> experienced in the field use the tools provided by gnutls for the key >>>> generation. >>>> >>>> >>>> regards, >>>> Nikos >>>> >>>> >>> >> >> _______________________________________________ >> Help-gnutls mailing list >> Help-gnutls at gnu.org >> http://lists.gnu.org/mailman/listinfo/help-gnutls >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Jul 16 21:48:00 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 16 Jul 2009 22:48:00 +0300 Subject: [Help-gnutls] Dynamically building the PSK keys In-Reply-To: <3a8533cc0907160743t68484963xd773586bf1d794a8@mail.gmail.com> References: <3a8533cc0907131021l2a0fcb20o7b3e01d8f76cacd4@mail.gmail.com> <4A5B94A1.8050007@gnutls.org> <3a8533cc0907131336t6594847cgd39b9c6e5244b962@mail.gmail.com> <3a8533cc0907141443s3934eda9va7fac0ace7ef9874@mail.gmail.com> <3a8533cc0907160743t68484963xd773586bf1d794a8@mail.gmail.com> Message-ID: <4A5F83F0.6080603@gnutls.org> Ram G wrote: > Finally I could complete the handshake using DHE-PSK. I followed the samples > ex-client-psk.c and ex-serv-psk.c but instead of hardcoded keys, I > dynamically assigned the keys as follows: > > char * dynamickeys; //Could be any string with hex characters like DEADBEEF > atohx(key->data,dynamickeys); If you want to use passwords for psk please use gnutls_psk_netconf_derive_key(). If you just want to convert hex to binary data you can just use gnutls_hex_encode and decode. PSK works with keys (not passwords) that are usually derived from a device such as /dev/(u)random. regards, Nikos From mydevforums at gmail.com Mon Jul 20 16:05:04 2009 From: mydevforums at gmail.com (Ram G) Date: Mon, 20 Jul 2009 10:05:04 -0400 Subject: [Help-gnutls] GnuTLS with PHP or Python on windows Message-ID: <3a8533cc0907200705s2c4bd85dy5303bb40e20244b8@mail.gmail.com> Hello, I'm trying to make use of GnuTLS for a project and working on a prototype. I have seen from Google searches that there are modules for PHP and Python available for linux platforms. I downloaded python-gnutls but currently running into issues installing the package on Windows - work in progress. Does anybody have any experience with using GnuTLS for web components on windows ? I have read that libcurl uses GnuTLS internally - is libcurl a possible solution ? Regards Ramg -------------- next part -------------- An HTML attachment was scrubbed... URL: From mydevforums at gmail.com Thu Jul 23 21:23:16 2009 From: mydevforums at gmail.com (Ram G) Date: Thu, 23 Jul 2009 15:23:16 -0400 Subject: [Help-gnutls] GnuTLS with PHP or Python on windows In-Reply-To: References: <3a8533cc0907200705s2c4bd85dy5303bb40e20244b8@mail.gmail.com> Message-ID: <3a8533cc0907231223x5f3ff006o52c989f5cb5c3de8@mail.gmail.com> Hi Daniel, Thanks for your response. I have downloaded libcurl and currently researching the various options but I have this question for you. I would like to use GnuTLS for TLS communication without using certificates and use pre-shared keys (DHE-PSK). Is it possible to set options to make GnuTLS to behave in this way when I build libcurl with GnuTLS ? Thanks in advance Ramg On Wed, Jul 22, 2009 at 5:47 PM, Daniel Stenberg wrote: > On Mon, 20 Jul 2009, Ram G wrote: > > Does anybody have any experience with using GnuTLS for web components on >> windows ? I have read that libcurl uses GnuTLS internally - is libcurl a >> possible solution ? >> > > Yes, libcurl can be built to use GnuTLS. > > -- > > / daniel.haxx.se > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at haxx.se Thu Jul 23 21:28:51 2009 From: daniel at haxx.se (Daniel Stenberg) Date: Thu, 23 Jul 2009 21:28:51 +0200 (CEST) Subject: [Help-gnutls] GnuTLS with PHP or Python on windows In-Reply-To: <3a8533cc0907231223x5f3ff006o52c989f5cb5c3de8@mail.gmail.com> References: <3a8533cc0907200705s2c4bd85dy5303bb40e20244b8@mail.gmail.com> <3a8533cc0907231223x5f3ff006o52c989f5cb5c3de8@mail.gmail.com> Message-ID: On Thu, 23 Jul 2009, Ram G wrote: > Thanks for your response. I have downloaded libcurl and currently > researching the various options but I have this question for you. I would > like to use GnuTLS for TLS communication without using certificates and use > pre-shared keys (DHE-PSK). Is it possible to set options to make GnuTLS to > behave in this way when I build libcurl with GnuTLS ? This topic is drifting away from being GnuTLS-specific so this list might not be the most suitable anymore. But no, I don't think libcurl supports that (yet). -- / daniel.haxx.se From simon at josefsson.org Wed Jul 29 22:43:16 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 29 Jul 2009 22:43:16 +0200 Subject: [Help-gnutls] GNU Libtasn1 2.3 Message-ID: <87tz0vmd97.fsf@mocca.josefsson.org> I'm happy to announce the first release of Libtasn1 as an official GNU project. GNU Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding/decoding. Libtasn1 is used by GnuTLS to parse and generate X.509 structures and by Shishi to parse and generate Kerberos V5 structures. * Noteworthy changes in release 2.3 (2009-07-29) [stable] - Libtasn1 is now an official GNU project. - Solve build problem on Tru64 related to TRUE/FALSE. - More careful decoding of OIDs. - Fixed warning in ASN1.y. - Use "Software libraries" info dircategory. - Drop GPL/LGPL copies from the manual (not needed there). - New configure parameters to set packaging specific information. The parameters are --with-packager, --with-packager-version, and --with-packager-bug-reports. See for more details. Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join the help-gnutls mailing list, see: . Homepage: http://www.gnu.org/software/libtasn1/ Here are the compressed sources (1.5MB): ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz Here are GPG detached signatures using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig A ZIP archive containing the Windows binaries (268KB): http://josefsson.org/gnutls4win/libtasn1-2.3.zip http://josefsson.org/gnutls4win/libtasn1-2.3.zip.sig A Debian mingw32 package is also available (240KB): http://josefsson.org/gnutls4win/mingw32-libtasn1_2.3-1_all.deb The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2010-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2010-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: 71607f846e83849f0722ffdd93247028c9c88384 libtasn1-2.3.tar.gz 0dc935133aa110fc17e0c212ca3c9b446f3da37e5e51ea1c8561c3ec libtasn1-2.3.tar.gz 31d1570b30f9a86850d74e535138f52f8f164179 libtasn1-2.3.zip 623864081339c7ef653d0356d6abadc64e0a799031351277e302c3ef libtasn1-2.3.zip 461ed2aa187cc86780ca0155b08be05401f9a403 mingw32-libtasn1_2.3-1_all.deb 425d98c7b456d120bf103a0fef59eff55f3694a9682ee0bd3240289d mingw32-libtasn1_2.3-1_all.deb Happy hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Thu Jul 30 13:33:51 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 30 Jul 2009 13:33:51 +0200 Subject: [Help-gnutls] Re: GNU Libtasn1 2.3 In-Reply-To: <87tz0vmd97.fsf__5819.01253103769$1248929158$gmane$org@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 29 Jul 2009 22:43:16 +0200") References: <87tz0vmd97.fsf__5819.01253103769$1248929158$gmane$org@mocca.josefsson.org> Message-ID: <873a8e8kww.fsf@mocca.josefsson.org> Simon Josefsson writes: > Here are the compressed sources (1.5MB): > ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz > http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz > > Here are GPG detached signatures using key 0xB565716F: > ftp://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig > http://ftp.gnu.org/gnu/gnutls/libtasn1-2.3.tar.gz.sig The correct URLs should be: ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.3.tar.gz http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.3.tar.gz ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.3.tar.gz.sig http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.3.tar.gz.sig Thanks to Arfrever Frehtes Taifersar Arahesis for noticing this. /Simon