From daniel at haxx.se Tue Nov 1 09:56:39 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Tue, 1 Nov 2005 09:56:39 +0100 (CET) Subject: [Help-gnutls] 1.2.9 release candidate In-Reply-To: References: Message-ID: On Fri, 28 Oct 2005, Simon Josefsson wrote: > NEWS entries below. Suggestions on the text is also appreciated. A minor mistake appears in the man page doc/manpages/gnutls_certificate_set_verify_flags.3: When describing the 'flags' argument iy says: .IP "unsigned int flags" 12 are the flagsis a structure that holds diffie hellman parameters. Which is just confusing! ;-) (this is of course also visible in the HTML version etc) -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From daniel at haxx.se Tue Nov 1 10:01:08 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Tue, 1 Nov 2005 10:01:08 +0100 (CET) Subject: [Help-gnutls] 1.2.9 release candidate In-Reply-To: References: Message-ID: On Fri, 28 Oct 2005, Simon Josefsson wrote: > GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2, > GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5: New gnutls_certificate_verify_flags values. Any ideas on how we can know at compile-time if these are present or not? Them being enum values make it rather tricky since we can't simply do: #ifdef GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 flags | = GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2; #endif or similar. Of course I can make a configure-check for them, but it would be nice with some simple preprocessor magic... -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From daniel at haxx.se Tue Nov 1 10:38:16 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Tue, 1 Nov 2005 10:38:16 +0100 (CET) Subject: [Help-gnutls] Re: 1.2.9 release candidate In-Reply-To: References: Message-ID: On Tue, 1 Nov 2005, Simon Josefsson wrote: >> Of course I can make a configure-check for them, but it would be nice with >> some simple preprocessor magic... > > I think a configure check is the simplest solution available. If you don't > want to pollute your source code with #ifdef's, you could have configure > define those two symbols to 0 if they aren't defined by gnutls.h. Of course. But my argument was not so much of concern of how the #ifdefs will look in my code (libcurl being massively portable we have #ifdefs all over already), it is how my code figures out what the installed GnuTLS supports or not. (Or in this case, what the headers contain or not.) In OpenSSL land, I've almost always been able to avoid checking for version- specific features in configure by using preprocessor magic such as checking for specific version numbers etc. Like this: #if OPENSSL_VERSION_NUMBER >= 0x0090581fL #define HAVE_SSL_GET1_SESSION 1 #else #undef HAVE_SSL_GET1_SESSION #endif > I usually want to make the core code look good for the latest-and-greatest > features, and work around missing functionality in earlier releases through > some replacement stuff in configure. Well, you could easily just add a simple define in the header file next to the enums that we could #ifdef with to figure this out. Or if you'd have a numerical version define (like OpenSSL and others) we could do a numerical check like above. By ducking for this, you force every single GnuTLS-user out there to add feature-checks to our configure scripts. It might not bother you as author of the lib, but it bothers me and I see this in the big perspective and how this will affect us in the long run and how this will make our configure scripts having to check for more and more features should more of these things occur later on. (And I actually consider that more likely than that _no_ more such things will occur.) Please reconsider. -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From jas at extundo.com Tue Nov 1 10:27:43 2005 From: jas at extundo.com (Simon Josefsson) Date: Tue, 01 Nov 2005 10:27:43 +0100 Subject: [Help-gnutls] Re: 1.2.9 release candidate In-Reply-To: (Daniel Stenberg's message of "Tue, 1 Nov 2005 10:01:08 +0100 (CET)") References: Message-ID: Daniel Stenberg writes: > On Fri, 28 Oct 2005, Simon Josefsson wrote: > >> GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2, >> GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5: New gnutls_certificate_verify_flags values. > > Any ideas on how we can know at compile-time if these are present or > not? Them being enum values make it rather tricky since we can't > simply do: > > #ifdef GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 > flags | = GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2; > #endif > > or similar. Of course I can make a configure-check for them, but it > would be nice with some simple preprocessor magic... I think a configure check is the simplest solution available. If you don't want to pollute your source code with #ifdef's, you could have configure define those two symbols to 0 if they aren't defined by gnutls.h. I usually want to make the core code look good for the latest-and-greatest features, and work around missing functionality in earlier releases through some replacement stuff in configure. Thanks, Simon From jas at extundo.com Tue Nov 1 11:26:08 2005 From: jas at extundo.com (Simon Josefsson) Date: Tue, 01 Nov 2005 11:26:08 +0100 Subject: [Help-gnutls] Re: 1.2.9 release candidate In-Reply-To: (Daniel Stenberg's message of "Tue, 1 Nov 2005 10:38:16 +0100 (CET)") References: Message-ID: Daniel Stenberg writes: > On Tue, 1 Nov 2005, Simon Josefsson wrote: > >>> Of course I can make a configure-check for them, but it would be >>> nice with some simple preprocessor magic... >> >> I think a configure check is the simplest solution available. If >> you don't want to pollute your source code with #ifdef's, you could >> have configure define those two symbols to 0 if they aren't defined >> by gnutls.h. > > Of course. But my argument was not so much of concern of how the > #ifdefs will look in my code (libcurl being massively portable we have > #ifdefs all over already), it is how my code figures out what the > installed GnuTLS supports or not. (Or in this case, what the headers > contain or not.) Ok. > In OpenSSL land, I've almost always been able to avoid checking for > version- > specific features in configure by using preprocessor magic such as > checking for specific version numbers etc. Like this: > > #if OPENSSL_VERSION_NUMBER >= 0x0090581fL > #define HAVE_SSL_GET1_SESSION 1 > #else > #undef HAVE_SSL_GET1_SESSION > #endif My experience has been that it is more reliable to test for features rather than version numbers, even if it takes a few more line of codes to do so. >> I usually want to make the core code look good for the >> latest-and-greatest features, and work around missing functionality >> in earlier releases through some replacement stuff in configure. > > Well, you could easily just add a simple define in the header file > next to the enums that we could #ifdef with to figure this out. I have added: /* Increment this define if you add new enum's. The purpose of this CPP symbol is to let application figure out which flags are supported through CPP checks in the code, and to avoid lengthy autoconf snippets in every application. */ #define GNUTLS_CERTIFICATE_VERIFY_FLAGS_LAST 32 so that your code could do #if defined (GNUTLS_CERTIFICATE_VERIFY_FLAGS_LAST) && GNUTLS_CERTIFICATE_VERIFY_FLAGS_LAST >= 32 flags |= GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 | GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5; #endif Does this solve your concern? Did you have a better solution in mind? > By ducking for this, you force every single GnuTLS-user out there to > add feature-checks to our configure scripts. It might not bother you > as author of the lib, but it bothers me and I see this in the big > perspective and how this will affect us in the long run and how this > will make our configure scripts having to check for more and more > features should more of these things occur later on. (And I actually > consider that more likely than that _no_ more such things will occur.) If you don't want to add specific feature checks, you could always require the earliest version of the GnuTLS library that you know support everything you need, e.g.: AM_PATH_LIBGNUTLS(1.2.9, starttls=yes, starttls=no) or something. Thanks, Simon From jas at extundo.com Tue Nov 1 10:18:46 2005 From: jas at extundo.com (Simon Josefsson) Date: Tue, 01 Nov 2005 10:18:46 +0100 Subject: [Help-gnutls] Re: 1.2.9 release candidate In-Reply-To: (Daniel Stenberg's message of "Tue, 1 Nov 2005 09:56:39 +0100 (CET)") References: Message-ID: Daniel Stenberg writes: > On Fri, 28 Oct 2005, Simon Josefsson wrote: > >> NEWS entries below. Suggestions on the text is also appreciated. > > A minor mistake appears in the man page > doc/manpages/gnutls_certificate_set_verify_flags.3: > > When describing the 'flags' argument iy says: > > .IP "unsigned int flags" 12 > are the flagsis a structure that holds diffie hellman parameters. > > Which is just confusing! ;-) (this is of course also visible in the > HTML version etc) Oops! It should have been only "are the flags". Fixed in CVS. Thanks, Simon From nmav at gnutls.org Tue Nov 1 11:56:32 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 1 Nov 2005 12:56:32 +0200 Subject: [Help-gnutls] 1.2.9 release candidate In-Reply-To: References: Message-ID: <200511011156.33040.nmav@gnutls.org> On Tuesday 01 November 2005 10:01, Daniel Stenberg wrote: > #ifdef GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 > flags | = GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2; > #endif No you don't want to add this line. It is not needed to verify the certificate in question (the one sent some days ago) since it was self signed with MD2, and it is very dangerous to enable MD2 for any algorithm. If you insist into adding it make it configurable by the user. -- Nikos Mavrogiannopoulos From daniel at haxx.se Tue Nov 1 12:07:27 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Tue, 1 Nov 2005 12:07:27 +0100 (CET) Subject: [Help-gnutls] Re: 1.2.9 release candidate In-Reply-To: References: Message-ID: On Tue, 1 Nov 2005, Simon Josefsson wrote: > My experience has been that it is more reliable to test for features rather > than version numbers, even if it takes a few more line of codes to do so. Then we have different views on this. (The preprocessor check also works on _all_ platforms, and thus isn't limited to those which can run configure. Possibly this is a moot point in this case, as possibly GnuTLS doesn't build in such environments?) > #define GNUTLS_CERTIFICATE_VERIFY_FLAGS_LAST 32 > Does this solve your concern? Did you have a better solution in mind? That solves it and is perfect. Thanks! > If you don't want to add specific feature checks, you could always require > the earliest version of the GnuTLS library that you know support everything > you need, e.g.: > > AM_PATH_LIBGNUTLS(1.2.9, starttls=yes, starttls=no) In my experience, the majority of all users will continue using out-dated versions (very often they simply remain with the version that comes with their Linux distro). Setting up strict requirements on "3rd party libraries" will only cause me grief. -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From jas at extundo.com Tue Nov 1 12:17:48 2005 From: jas at extundo.com (Simon Josefsson) Date: Tue, 01 Nov 2005 12:17:48 +0100 Subject: [Help-gnutls] Re: 1.2.9 release candidate In-Reply-To: (Daniel Stenberg's message of "Tue, 1 Nov 2005 12:07:27 +0100 (CET)") References: Message-ID: Daniel Stenberg writes: > (The preprocessor check also works on _all_ platforms, and thus isn't > limited to those which can run configure. Possibly this is a moot > point in this case, as possibly GnuTLS doesn't build in such > environments?) In theory, it should be possible to build autoconf-based programs even if you can't run configure or make. Copy config.h.in to config.h, manually edit system specific matters, and invoke the compiler and linker manually. It is sometimes easier to make autoconf/make work on the system, though... >> #define GNUTLS_CERTIFICATE_VERIFY_FLAGS_LAST 32 > >> Does this solve your concern? Did you have a better solution in mind? > > That solves it and is perfect. Thanks! We discussed this some more, and we'll likely add an OpenSSL-like version number integer. If that works, I'll remove this symbol, since the version number integer is more generic. And it would be less maintenance work for us. >> If you don't want to add specific feature checks, you could always >> require the earliest version of the GnuTLS library that you know >> support everything you need, e.g.: >> >> AM_PATH_LIBGNUTLS(1.2.9, starttls=yes, starttls=no) > > In my experience, the majority of all users will continue using > out-dated versions (very often they simply remain with the version > that comes with their Linux distro). Setting up strict requirements on > "3rd party libraries" will only cause me grief. Right. Thanks, Simon From daniel at haxx.se Tue Nov 1 12:22:55 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Tue, 1 Nov 2005 12:22:55 +0100 (CET) Subject: [Help-gnutls] Re: 1.2.9 release candidate In-Reply-To: References: Message-ID: On Tue, 1 Nov 2005, Simon Josefsson wrote: > We discussed this some more, and we'll likely add an OpenSSL-like version > number integer. If that works, I'll remove this symbol, since the version > number integer is more generic. And it would be less maintenance work for > us. FYI: We've done it for many years in libcurl as well, and many users are successfully using version number checks in source code based on those defines. This is how we do it: http://cool.haxx.se/cvs.cgi/curl/include/curl/curlver.h?rev=HEAD&content-type=text/vnd.viewcvs-markup -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From daniel at haxx.se Tue Nov 1 13:35:27 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Tue, 1 Nov 2005 13:35:27 +0100 (CET) Subject: [Help-gnutls] 1.2.9 release candidate In-Reply-To: <200511011156.33040.nmav@gnutls.org> References: <200511011156.33040.nmav@gnutls.org> Message-ID: On Tue, 1 Nov 2005, Nikos Mavrogiannopoulos wrote: >> #ifdef GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 >> flags | = GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2; >> #endif > > No you don't want to add this line. It is not needed to verify the > certificate in question (the one sent some days ago) since it was self > signed with MD2 Sorry, but then I'm lost. Can you then please enlighten me what I would need to do to verify that certificate with GnuTLS 1.2.9? > If you insist into adding it make it configurable by the user. Perhaps. -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From jas at extundo.com Tue Nov 1 14:39:18 2005 From: jas at extundo.com (Simon Josefsson) Date: Tue, 01 Nov 2005 14:39:18 +0100 Subject: [Help-gnutls] Re: 1.2.9 release candidate In-Reply-To: (Daniel Stenberg's message of "Tue, 1 Nov 2005 13:35:27 +0100 (CET)") References: <200511011156.33040.nmav@gnutls.org> Message-ID: Daniel Stenberg writes: > On Tue, 1 Nov 2005, Nikos Mavrogiannopoulos wrote: > >>> #ifdef GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 >>> flags | = GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2; >>> #endif >> >> No you don't want to add this line. It is not needed to verify the >> certificate in question (the one sent some days ago) since it was >> self signed with MD2 > > Sorry, but then I'm lost. Can you then please enlighten me what I > would need to do to verify that certificate with GnuTLS 1.2.9? Nothing. It work by default. See an earlier reply from me, which included output from gnutls-cli with successful verification. You may want to use the MD5 flag, but I really recommend against it. Trusted MD5 roots will work anyway, since they are trusted directly. /Simon From daniel at haxx.se Tue Nov 1 14:42:17 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Tue, 1 Nov 2005 14:42:17 +0100 (CET) Subject: [Help-gnutls] Re: 1.2.9 release candidate In-Reply-To: References: <200511011156.33040.nmav@gnutls.org> Message-ID: On Tue, 1 Nov 2005, Simon Josefsson wrote: >> Sorry, but then I'm lost. Can you then please enlighten me what I would >> need to do to verify that certificate with GnuTLS 1.2.9? > > Nothing. It work by default. See an earlier reply from me, which included > output from gnutls-cli with successful verification. Oh. Sorry, I thought that was achieved with a similar approach in the code. Clearer now. Thanks! -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From jas at extundo.com Tue Nov 1 21:10:33 2005 From: jas at extundo.com (Simon Josefsson) Date: Tue, 01 Nov 2005 21:10:33 +0100 Subject: [Help-gnutls] Re: 1.2.9 release candidate In-Reply-To: (Daniel Stenberg's message of "Tue, 1 Nov 2005 12:22:55 +0100 (CET)") References: Message-ID: Daniel Stenberg writes: > On Tue, 1 Nov 2005, Simon Josefsson wrote: > >> We discussed this some more, and we'll likely add an OpenSSL-like >> version number integer. If that works, I'll remove this symbol, >> since the version number integer is more generic. And it would be >> less maintenance work for us. > > FYI: > > We've done it for many years in libcurl as well, and many users are > successfully using version number checks in source code based on those > defines. > > This is how we do it: > > http://cool.haxx.se/cvs.cgi/curl/include/curl/curlver.h?rev=HEAD&content-type=text/vnd.viewcvs-markup I just installed something similar, and removed the GNUTLS_CERTIFICATE_VERIFY_FLAGS_LAST hack. The NEWS file contain: - Added numeric version symbols to permit simple CPP-based feature tests, suggested by Daniel Stenberg . ... LIBGNUTLS_VERSION_MAJOR, LIBGNUTLS_VERSION_MINOR, LIBGNUTLS_VERSION_PATCH, LIBGNUTLS_VERSION_NUMBER: New CPP symbols, indicating the GnuTLS version number, can be used for feature existence tests. And gnutls.h would contain: #define LIBGNUTLS_VERSION "1.2.9" #define LIBGNUTLS_VERSION_MAJOR 1 #define LIBGNUTLS_VERSION_MINOR 2 #define LIBGNUTLS_VERSION_PATCH 9 #define LIBGNUTLS_VERSION_NUMBER 0x010209 Thoughts? Thanks, Simon From e_agf at yahoo.es Tue Nov 1 21:24:03 2005 From: e_agf at yahoo.es (Fran) Date: Tue, 01 Nov 2005 21:24:03 +0100 Subject: [Help-gnutls] Why not? Message-ID: <1130876643.3704.6.camel@localhost> In certool: > /* > buffer[3] = serial & 0xff; > buffer[2] = (serial >> 8) & 0xff; > buffer[1] = (serial >> 16) & 0xff; > buffer[0] = 0; > */ Why not? > #ifdef _32bit /* Machine */ > #ifdef _32bit_serial > typedef union Raw_Int > { > unsigned char str[sizeof(unsigned int)]; > unsigned int integer; > }RAW_INT; > #endif > /* long int is same as unsigned int !??? */ > #ifdef _64bit_serial > ... > #endif > #endif > > > > #ifdef _64bit > #ifdef _128bit > /* Only C99 */ > ... > #endif > #endif > And : int gnutls_x509_crt_set_int64_serial (crt, unsigned long long int integer) { RAW_INT a; signed int ret; a.integer = integer; if ((ret = gnutls_x509_crt_set_serial (crt,a.str, sizeof(a.str))), ret < 0) { fprintf (stderr, "serial: %s\n", gnutls_strerror (ret)); /*exit (1);*/ return (gnutls_strerror (ret)); } return ; } I think that can work. Good thing or bad thing ? From jas at extundo.com Tue Nov 1 21:54:36 2005 From: jas at extundo.com (Simon Josefsson) Date: Tue, 01 Nov 2005 21:54:36 +0100 Subject: [Help-gnutls] Re: Certificate verification failed In-Reply-To: (Daniel Stenberg's message of "Thu, 27 Oct 2005 12:46:23 +0200 (CEST)") References: <17247.59321.125197.576087@kappa.ac93.org> <200510262330.54617.nmav@gnutls.org> Message-ID: Daniel Stenberg writes: > On Thu, 27 Oct 2005, Simon Josefsson wrote: > >> However, I am skeptical about supporting MD2, and even MD5, by >> default. I know GnuTLS certtool print a warning about MD5, but the >> library does not, and most GnuTLS library users probably doesn't >> either. > > Perhaps if we got some nice pointers in the docs or something us > library users could also output a warning in similar style. We have added the section below. Specific suggestions and comments are welcome. Thanks, Simon 5.1.3 Digital signatures ------------------------ In this section we will provide some information about digital signatures, how they work, and give the rationale for disabling some of the algorithms used. Digital signatures work by using somebody's secret key to sign some arbitrary data. Then anybody else could use the public key of that person to verify the signature. Since the data may be arbitrary thus not a suitable input to a cryptographic digital signature algorithm and also for performance reasons cryptographic hash algorithms are used to preprocess the input to the signature algorithm. This works as long as it is difficult enough to generate two different messages with the same hash algorithm output. In that case the same signature could be used as a proof for both messages. Nobody wants to sign an innocent message of donating 1 Euro to Greenpeace and find out that he donated 1.000.000 Euro to Bad Inc. The available digital signature algorithms in GnuTLS are listed below: `RSA' RSA is public key cryptosystem designed by Ronald Rivest, Adi Shamir and Leonard Adleman. It can be used with any hash functions. `DSA' DSA is the USA's Digital Signature Standard. It uses only the SHA-1 hash algorithm. The supported cryptographic hash algorithms are: `MD2' MD2 is a cryptographic hash algorithm designed by Ron Rivest. It is optimized for 8-bit processors. Outputs 128 bits of data. There not known weaknesses of this algorithm but since this algorithm is rarely used and not really studied it should not be used today. `MD5' MD5 is a cryptographic hash algorithm designed by Ron Rivest. Outputs 128 bits of data. It is considered to be broken. `SHA-1' SHA is a cryptographic hash algorithm designed by NSA. Outputs 160 bits of data. It is also considered to be broken, though no practical attacks have been found. `RMD160' RIPEMD is a cryptographic hash algorithm developed in the framework of the EU project RIPE. Outputs 160 bits of data. For a hash algorithm to be called cryptographic the following three requirements must hold 1. Preimage resistance. That means the algorithm must be one way and given the output of the hash function H(x), it is impossible to calculate x. 2. 2nd preimage resistance. That means that given a pair x,y with y=H(x) it is impossible to calculate an x' such that y=H(x'). 3. Collision resistance. That means that it is impossible to calculate random x and x' such H(x')=H(x). The last two requirements in the list are the most important in digital signatures. These protect against somebody who would like to generate two messages with the same hash output. When an algorithm is considered broken usually it means that the Collision resistance of the algorithm is less than brute force. Using the birthday paradox the brute force attack takes 2^hash size \over 2operations. Today colliding certificates using the MD5 hash algorithm have been generated as shown in [WEGER] (*Note WEGER: Bibliography.) . 5.1.3.1 Trading security for interoperability ............................................. If you connect to a server and use GnuTLS' functions to verify the certificate chain, and get a *note GNUTLS_CERT_INSECURE_ALGORITHM:: validation error (*note Verifying X.509 certificate paths::), it means that somewhere in the certificate chain there is a certificate signed using `RSA-MD2' or `RSA-MD5'. These two digital signature algorithms are considered broken, so GnuTLS fail when attempting to verify the certificate. In some situations, it may be useful to be able to verify the certificate chain anyway, assuming an attacker did not utilize the fact that these signatures algorithms are broken. This section will give help on how to achieve that. First, it is important to know that you do not have to enable any of the flags discussed here to be able to use trusted root CA certificates signed using `RSA-MD2' or `RSA-MD5'. The only attack today is that it is possible to generate certificates with colliding signatures; you cannot forge signatures. If you are using *note gnutls_certificate_verify_peers2:: to verify the certificate chain, you can call *note gnutls_certificate_set_verify_flags:: with the `GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2' or `GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5' flag, as in: gnutls_certificate_set_verify_flags (x509cred, GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5); This will tell the verifier algorithm to enable `RSA-MD5' when verifying the certificates. If you are using *note gnutls_x509_crt_verify:: or *note gnutls_x509_crt_list_verify::, you can pass the `GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5' parameter directly in the `flags' parameter. If you are using these flags, it may also be a good idea to warn the user when verification failure occur for this reason. The simplest is to not use the flags by default, and only fall back to using them after warning the user. If you wish to inspect the certificate chain yourself, you can use *note gnutls_certificate_get_peers:: to extract the raw server's certificate chain, then use *note gnutls_x509_crt_import:: to parse each of the certificates, and then use *note gnutls_x509_crt_get_signature_algorithm:: to find out the signing algorithm used for each certificate. If any of the intermediary certificates are using `GNUTLS_SIGN_RSA_MD2' or `GNUTLS_SIGN_RSA_MD5', you could present a warning. From daniel at haxx.se Tue Nov 1 22:41:11 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Tue, 1 Nov 2005 22:41:11 +0100 (CET) Subject: [Help-gnutls] Re: Certificate verification failed In-Reply-To: References: <17247.59321.125197.576087@kappa.ac93.org> <200510262330.54617.nmav@gnutls.org> Message-ID: On Tue, 1 Nov 2005, Simon Josefsson wrote: Very good addition indeed. Just a very minor wording nit: > MD2 is a cryptographic hash algorithm designed by Ron Rivest. It is > optimized for 8-bit processors. Outputs 128 bits of data. There > not known weaknesses of this algorithm but since this algorithm is ^^^^^ Should rather be "There are no known"... -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From nmav at gnutls.org Tue Nov 1 23:03:31 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 1 Nov 2005 23:03:31 +0100 Subject: [Help-gnutls] Re: Certificate verification failed In-Reply-To: References: <17247.59321.125197.576087@kappa.ac93.org> Message-ID: <200511012303.31908.nmav@gnutls.org> On Tuesday 01 November 2005 22:41, Daniel Stenberg wrote: > Very good addition indeed. Just a very minor wording nit: > > MD2 is a cryptographic hash algorithm designed by Ron Rivest. It is > > optimized for 8-bit processors. Outputs 128 bits of data. There > > not known weaknesses of this algorithm but since this algorithm is > > ^^^^^ Should rather be "There are no known"... Indeed. I just corrected it. Thank you. -- Nikos Mavrogiannopoulos From e_agf at yahoo.es Sun Nov 6 17:07:55 2005 From: e_agf at yahoo.es (Fran) Date: Sun, 06 Nov 2005 16:07:55 +0000 Subject: [Help-gnutls] Re: Why not? Message-ID: <1131293276.4717.19.camel@localhost> Nobody reply me, well. pkcs12 bag are incorrect generated without any error, while I'm trying to solve the problem I see this in certtool (1.2.8) (line 2510): > if (result < 0) { > fprintf(stderr, "bag_set_data: %s\n", gnutls_strerror(result)); > exit(1); > } > > index = result; > > result = gnutls_pkcs12_bag_set_friendly_name(kbag, index, name); > if (result < 0) { > fprintf(stderr, "bag_set_friendly_name: %s\n", > gnutls_strerror(result)); > exit(1); > } > > size = sizeof(_key_id); > result = gnutls_x509_privkey_get_key_id(key, 0, _key_id, &size); > if (result < 0) { > fprintf(stderr, "key_id: %s\n", gnutls_strerror(result)); > exit(1); > } > > key_id.data = _key_id; > key_id.size = size; > > >>>>>>>>>>>>>>>>>>>>>/* result = gnutls_pkcs12_bag_set_key_id(kbag, result , &key_id);*/<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > result = gnutls_pkcs12_bag_set_key_id(kbag, index , &key_id); > > if (result < 0) { > fprintf(stderr, "bag_ gnutls_x509_privkey_get_key_id gnutls_x509_privkey_get_key_idset_key_id: %s\n", > gnutls_strerror(result)); > exit(1); > } > man gnutls_x509_privkey_get_key_id > RETURN VALUE > In case of failure a negative value will be returned, and 0 on success. > man gnutls_pkcs12_bag_set_key_id > int gnutls_pkcs12_bag_set_key_id(gnutls_pkcs12_bag_t bag, int indx, const gnutls_datum_t * id); man gnutls_pkcs12_bag_set_data > DESCRIPTION > This function will insert the given data of the given type into the bag. > > Returns the index of the added bag on success, or a negative value on error. Incompatible class of object in assignment or bad definition. I think that should be "index" and not "result". From nmav at gnutls.org Sun Nov 6 23:52:41 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 6 Nov 2005 23:52:41 +0100 Subject: [Help-gnutls] Re: Why not? In-Reply-To: <1131293276.4717.19.camel@localhost> References: <1131293276.4717.19.camel@localhost> Message-ID: <200511062352.42133.nmav@gnutls.org> On Sunday 06 November 2005 17:07, Fran wrote: > Nobody reply me, well. Reply on what? > pkcs12 bag are incorrect generated without any error, while I'm trying > to solve the problem I see this in certtool (1.2.8) (line 2510): Yes indeed it looks like a bug. I've already corrected it on the cvs, and the fix will be included in the next release. Thank you for the report. -- Nikos Mavrogiannopoulos From nmav at gnutls.org Sun Nov 6 23:52:41 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 6 Nov 2005 23:52:41 +0100 Subject: [Help-gnutls] Re: Why not? In-Reply-To: <1131293276.4717.19.camel@localhost> References: <1131293276.4717.19.camel@localhost> Message-ID: <200511062352.42133.nmav@gnutls.org> On Sunday 06 November 2005 17:07, Fran wrote: > Nobody reply me, well. Reply on what? > pkcs12 bag are incorrect generated without any error, while I'm trying > to solve the problem I see this in certtool (1.2.8) (line 2510): Yes indeed it looks like a bug. I've already corrected it on the cvs, and the fix will be included in the next release. Thank you for the report. -- Nikos Mavrogiannopoulos From jas at extundo.com Mon Nov 7 22:34:46 2005 From: jas at extundo.com (Simon Josefsson) Date: Mon, 07 Nov 2005 22:34:46 +0100 Subject: [Help-gnutls] GnuTLS 1.2.9 Message-ID: We are pleased to announce the availability of GnuTLS version 1.2.8. GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. This is the last non-bugfix release in the 1.2.x series. We will open the 1.3.x branch after this release. The goal of 1.3.x will be to merge work currently done on CVS branches, for TLS Pre-Shared-Keys and TLS Inner Application. Other planned improvements in 1.3.x are system-independent resume data structures, modularization of the bignum operations, and TLS OpenPGP improvements. This release disable the RSA-MD5 algorithm when verifying untrusted intermediary X.509 CA certificates. This decision was made based on the results in Lenstra, Wang and Weger's "Colliding X.509 Certificates". This is discussed in more detail, including instructions on how to re-enable the algorithm for application's that need backwards compatibility, in: http://josefsson.org/gnutls/manual/html_node/Digital-signatures.html Noteworthy changes since version 1.2.8: - Documentation was updated and improved. - RSA-MD2 is now supported for verifying digital signatures. - Due to cryptographic advances, verifying untrusted X.509 certificates signed with RSA-MD2 or RSA-MD5 will now fail with a GNUTLS_CERT_INSECURE_ALGORITHM verification output. For applications that must remain interoperable, you can use the GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 or GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5 flags when verifying certificates. Naturally, this is not recommended default behaviour for applications. To enable the broken algorithms, call gnutls_certificate_set_verify_flags with the proper flag, to change the verification mode used by gnutls_certificate_verify_peers2. - Make it possible to send empty data through gnutls_record_send, to align with the send(2) API. - Some changes in the certificate receiving part of handshake to prevent some possible errors with non-blocking servers. - Added numeric version symbols to permit simple CPP-based feature tests, suggested by Daniel Stenberg . - The (experimental) low-level crypto alternative to libgcrypt used earlier (Nettle) has been replaced with crypto code from gnulib. This leads to easier re-use of these components in other projects, leading to more review and simpler maintenance. The new configure parameter --with-builtin-crypto replace the old --with-nettle, and must be used if you wish to enable this functionality. See README under "Experimental" for more information. Internally, GnuTLS has been updated to use the new "Generic Crypto" API in gl/gc.h. The API is similar to the old crypto/gc.h, because the gnulib code were based on GnuTLS's gc.h. - Fix compiler warning in the "anonself" self test. - API and ABI modifications: gnutls_x509_crt_list_verify: Added 'const' to prototype in . This doesn't reflect a change in behaviour, so we don't break backwards compatibility. GNUTLS_MAC_MD2: New gnutls_mac_algorithm_t value. GNUTLS_DIG_MD2: New gnutls_digest_algorithm_t value. GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2, GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5: New gnutls_certificate_verify_flags values. Use when calling gnutls_x509_crt_list_verify, gnutls_x509_crt_verify, or gnutls_certificate_set_verify_flags. GNUTLS_CERT_INSECURE_ALGORITHM: New gnutls_certificate_status_t value, used when broken signature algorithms is used (currently RSA-MD2/MD5). LIBGNUTLS_VERSION_MAJOR, LIBGNUTLS_VERSION_MINOR, LIBGNUTLS_VERSION_PATCH, LIBGNUTLS_VERSION_NUMBER: New CPP symbols, indicating the GnuTLS version number, can be used for feature existence tests. Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: . The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ (updated fastest) Here are the compressed sources: http://josefsson.org/gnutls/releases/gnutls-1.2.9.tar.bz2 (2.7MB) ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.2.9.tar.bz2 (2.7MB) Here are GPG detached signatures signed using key 0xB565716F: http://josefsson.org/gnutls/releases/gnutls-1.2.9.tar.bz2.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.2.9.tar.bz2.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: 1280R/B565716F 2002-05-05 [expires: 2006-02-28] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the build reports for various platforms: http://josefsson.org/autobuild-logs/gnutls.html Here are the SHA-1 checksums: 7229d094de83cabd572fcaab806ab3afc6b58959 gnutls-1.2.9.tar.bz2 fae5d7a5d84935406ba3ed6e2804a18cede6fcf1 gnutls-1.2.9.tar.bz2.sig Enjoy, Nikos and Simon From joelkp at ERC.MsState.Edu Fri Nov 11 15:27:19 2005 From: joelkp at ERC.MsState.Edu (Joel J. Konkle-Parker) Date: Fri, 11 Nov 2005 08:27:19 -0600 (CST) Subject: [Help-gnutls] libgnutls-extra.m4 Message-ID: <200511111427.jABERJZY024938@ERC.MsState.Edu> In checking my own package's autotools files, I noticed that libgnutls-extra.m4 is using AC_TRY_RUN in its macros. This is currently deprecated in favor of AC_RUN_IFELSE. Is this the result of a decision to support old autoconf versions, or a bug? -- Joel Konkle-Parker From jas at extundo.com Sat Nov 12 12:33:47 2005 From: jas at extundo.com (Simon Josefsson) Date: Sat, 12 Nov 2005 12:33:47 +0100 Subject: [Help-gnutls] Re: libgnutls-extra.m4 In-Reply-To: <200511111427.jABERJZY024938@ERC.MsState.Edu> (Joel J. Konkle-Parker's message of "Fri, 11 Nov 2005 08:27:19 -0600 (CST)") References: <200511111427.jABERJZY024938@ERC.MsState.Edu> Message-ID: "Joel J. Konkle-Parker" writes: > In checking my own package's autotools files, I noticed that libgnutls-extra.m4 > is using AC_TRY_RUN in its macros. This is currently deprecated in favor of > AC_RUN_IFELSE. > > Is this the result of a decision to support old autoconf versions, or a bug? I believe it is a bug. I added a TODO item: - Update libgnutls-extra.m4 to use modern autoconf constructs. Thanks, Simon From jas at extundo.com Tue Nov 15 17:50:12 2005 From: jas at extundo.com (Simon Josefsson) Date: Tue, 15 Nov 2005 17:50:12 +0100 Subject: [Help-gnutls] GnuTLS 1.3.0 Message-ID: We are pleased to announce the availability of GnuTLS version 1.3.0. This is the first release on the experimental 1.3.x branch that will lead to 1.4.0. GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. The goal of 1.3.x will be to merge work currently done on CVS branches, for TLS Pre-Shared-Keys and TLS Inner Application. Other planned improvements in 1.3.x are system-independent resume data structures, modularization of the bignum operations, and TLS OpenPGP improvements. Noteworthy changes since version 1.2.9: ** Support for TLS Pre-Shared Key (TLS-PSK) ciphersuites have been added. This add several new APIs, see below. Read the updated manual for more information. A new self test "pskself" has been added, that will test this functionality. ** The session resumption data are now system independent. ** The code has been re-indented to conform to the GNU coding style. ** Removed the RIPEMD ciphersuites. ** Added a discussion of the internals of gnutls in manual. ** Fixes for Tru64 UNIX 4.0D that lack MAP_FAILED, from Albert Chin. ** Remove trailing comma in enums, for IBM C v6, from Albert Chin. ** Make sure config.h is included first in a few files, from Albert Chin. ** Don't use C++ comments ("//") as they are invalid, from Albert Chin. ** Don't install SRP programs and man pages if --disable-srp-authentication, from Albert Chin. ** API and ABI modifications: New gnutls_kx_algorithm_t key exchange type: GNUTLS_KX_PSK New gnutls_credentials_type_t credential type: GNUTLS_CRD_PSK New credential types: gnutls_psk_server_credentials_t gnutls_psk_client_credentials_t New functions to allocate PSK credentials: gnutls_psk_allocate_client_credentials gnutls_psk_free_client_credentials gnutls_psk_free_server_credentials gnutls_psk_allocate_server_credentials New enum type for PSK key flags: gnutls_psk_key_flags New function prototypes for credential callback: gnutls_psk_client_credentials_function gnutls_psk_server_credentials_function New function to set PSK username and key: gnutls_psk_set_client_credentials New function to set PSK passwd file: gnutls_psk_set_server_credentials_file New function to extract PSK user in server: gnutls_psk_server_get_username New functions to set PSK callback: gnutls_psk_set_server_credentials_function gnutls_psk_set_client_credentials_function Use size_t instead of int for output size parameter: gnutls_srp_base64_encode gnutls_srp_base64_decode Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: . The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ (updated fastest) Here are the compressed sources: http://josefsson.org/gnutls/releases/gnutls-1.3.0.tar.bz2 (3.0MB) ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.3.0.tar.bz2 (3.0MB) Here are GPG detached signatures signed using key 0xB565716F: http://josefsson.org/gnutls/releases/gnutls-1.3.0.tar.bz2.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.3.0.tar.bz2.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: 1280R/B565716F 2002-05-05 [expires: 2006-02-28] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the build reports for various platforms: http://josefsson.org/autobuild-logs/gnutls.html Here are the SHA-1 checksums: 6cf8ebd216c0be614039790438dbc55f91692327 gnutls-1.3.0.tar.bz2 086da32866fc66ce20731216682832f8c50daea1 gnutls-1.3.0.tar.bz2.sig Enjoy, Nikos and Simon From e_agf at yahoo.es Tue Nov 15 20:52:43 2005 From: e_agf at yahoo.es (Fran) Date: Tue, 15 Nov 2005 19:52:43 +0000 Subject: [Help-gnutls] About Future Plans: Private keys encrypted. Message-ID: <1132084363.3782.10.camel@localhost> Hello, I can see that certtool do not encrypt keys and not support some keys generated with openssl (encrypted). I can see : > int gnutls_x509_privkey_import_pkcs8: > This function will convert the given DER or PEM encoded PKCS8 2.0 encrypted key to the native gnutls_x509_privkey_t format. The output will be stored in key. Currently only RSA keys can be imported, > and flags can only be used to indicate an unencrypted key. I think that this is a very high risk security problem for applications that use a file key. And others: > Internet X.509 Public Key Infrastructure > Certificate and CRL Profile The protection afforded private keys is a critical factor in maintaining security. On a small scale, failure of users to protect their private keys will permit an attacker to masquerade as them, or decrypt their personal information. On a larger scale, compromise of a CA's private signing key may have a catastrophic effect. If an attacker obtains the private key unnoticed, the attacker may issue bogus certificates and CRLs. Existence of bogus certificates and CRLs will undermine confidence in the system. If the compromise is detected, all certificates issued to the CA shall be revoked, preventing services between its users and users of other CAs. Rebuilding after such a compromise will be problematic, so CAs are advised to implement a combination of strong technical measures (e.g., tamper-resistant cryptographic modules) and appropriate Encryption in the first wall. In CVS TODO I can not find something about this feature. Any plans to make this posible in the future? Thanks, in advance. -- Fco. J. From nmav at gnutls.org Tue Nov 15 23:16:44 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 15 Nov 2005 23:16:44 +0100 Subject: [Help-gnutls] About Future Plans: Private keys encrypted. In-Reply-To: <1132084363.3782.10.camel@localhost> References: <1132084363.3782.10.camel@localhost> Message-ID: <200511152316.45534.nmav@gnutls.org> On Tuesday 15 November 2005 20:52, Fran wrote: > Hello, > I can see that certtool do not encrypt keys and not support some keys > generated with openssl (encrypted). > I can see : > > int gnutls_x509_privkey_import_pkcs8: > > This function will convert the given DER or PEM encoded PKCS8 2.0 > > encrypted key to the native gnutls_x509_privkey_t format. The output will > > be stored in key. Currently only RSA keys can be imported, and flags can > > only be used to indicate an unencrypted key. > I think that this is a very high risk security problem for applications > that use a file key. You can both encrypt and decrypt pkcs8 keys in gnutls. The only limitation is that pkcs8 2.0 is supported and not previous versions. -- Nikos Mavrogiannopoulos From e_agf at yahoo.es Wed Nov 16 01:52:26 2005 From: e_agf at yahoo.es (Fran) Date: Wed, 16 Nov 2005 00:52:26 +0000 Subject: [Help-gnutls] About Future Plans: Private keys encrypted. In-Reply-To: <200511152316.45534.nmav@gnutls.org> References: <1132084363.3782.10.camel@localhost> <200511152316.45534.nmav@gnutls.org> Message-ID: <1132102346.3927.16.camel@localhost> * You can both encrypt and decrypt pkcs8 keys in gnutls. The only limitation is * that pkcs8 2.0 is supported and not previous versions. Well, But encryption of key file with password do not work for me, always exports the key as plain. I used 2,4,8,16 types. I can not understand very well the man pages, and why the key do not is saved as encrypted. In the code exposed is the same put GNUTLS_PKCS_PLAIN or GNUTLS_PKCS_USE_PKCS12_RC2_40, etc. I can not understand it. Regards. Import: > This function will convert the given DER or PEM encoded PKCS8 2.0 encrypted key to the native gnutls_x509_privkey_t format. The > output will be stored in key. Currently only RSA keys can be imported, ->>> and flags can only be used to indicate an unencrypted key. Export: > This function will export the private key to a PKCS8 structure. Currently only RSA keys can be exported since there is no docu- > mented standard for other keys. If the flags do not specify the encryption cipher, then the default 3DES (PBES2) will be used. > /* > GNUTLS_PKCS_PLAIN = 1, > GNUTLS_PKCS_USE_PKCS12_3DES = 2, > GNUTLS_PKCS_USE_PKCS12_ARCFOUR = 4, > GNUTLS_PKCS_USE_PKCS12_RC2_40 = 8, > GNUTLS_PKCS_USE_PBES2_3DES = 16 > */ > > size = sizeof (buffer); > if (ret = gnutls_x509_privkey_export_pkcs8 (key, out_cert_format, passwd, /*flags*/GNUTLS_PKCS_USE_PKCS12_RC2_40 > , buffer, &size), ret < 0) > { > fprintf (stderr, "privkey_export_pkcs8: %s\n", gnutls_strerror (ret)); > exit (1); > } > }; > } > > > > { > FILE *file; > file = fopen ("new-user.key", "w"); > fwrite (buffer, 1, size, file); /* Always is plain */ > fclose (file); > }; On Mar, 2005-11-15 at 23:16 +0100, Nikos Mavrogiannopoulos wrote: > On Tuesday 15 November 2005 20:52, Fran wrote: > > Hello, > > I can see that certtool do not encrypt keys and not support some keys > > generated with openssl (encrypted). > > I can see : > > > int gnutls_x509_privkey_import_pkcs8: > > > This function will convert the given DER or PEM encoded PKCS8 2.0 > > > encrypted key to the native gnutls_x509_privkey_t format. The output will > > > be stored in key. Currently only RSA keys can be imported, and flags can > > > only be used to indicate an unencrypted key. > > I think that this is a very high risk security problem for applications > > that use a file key. > > You can both encrypt and decrypt pkcs8 keys in gnutls. The only limitation is > that pkcs8 2.0 is supported and not previous versions. > > -- Fco. J. From nmav at gnutls.org Wed Nov 16 12:33:11 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 16 Nov 2005 12:33:11 +0100 Subject: [Help-gnutls] About Future Plans: Private keys encrypted. In-Reply-To: <1132102346.3927.16.camel@localhost> References: <1132084363.3782.10.camel@localhost> <200511152316.45534.nmav@gnutls.org> <1132102346.3927.16.camel@localhost> Message-ID: <200511161233.11552.nmav@gnutls.org> On Wednesday 16 November 2005 01:52, Fran wrote: > * You can both encrypt and decrypt pkcs8 keys in gnutls. The only > limitation is > * that pkcs8 2.0 is supported and not previous versions. > > Well, But encryption of key file with password do not work for me, > always exports the key as plain. I used 2,4,8,16 types. > I can not understand very well the man pages, and why the key do not is > saved as encrypted. Which manpages were problematic? The whole PKCS #8 stuff is complex though. > In the code exposed is the same put GNUTLS_PKCS_PLAIN or > GNUTLS_PKCS_USE_PKCS12_RC2_40, etc. > I can not understand it. If you use "certtool --generate-privkey -8" you get a pkcs8 encrypted key. The only thing you need to do is call gnutls_x509_privkey_export_pkcs8() with the flag (say) GNUTLS_PKCS_USE_PKCS12_3DES and an ASCII password. -- Nikos Mavrogiannopoulos From e_agf at yahoo.es Thu Nov 17 01:22:28 2005 From: e_agf at yahoo.es (Fran) Date: Thu, 17 Nov 2005 00:22:28 +0000 Subject: [Help-gnutls] About Future Plans: Private keys encrypted. In-Reply-To: <200511161233.11552.nmav@gnutls.org> References: <1132084363.3782.10.camel@localhost> <200511152316.45534.nmav@gnutls.org> <1132102346.3927.16.camel@localhost> <200511161233.11552.nmav@gnutls.org> Message-ID: <1132186953.3536.17.camel@localhost> On M?r, 2005-11-16 at 12:33 +0100, Nikos Mavrogiannopoulos wrote: > Which manpages were problematic? It is strange for me (for me): > unsigned int flags > 0 if encrypted or GNUTLS_PKCS_PLAIN if not encrypted. > Currently only RSA keys can be imported, > and flags can only be used to indicate an unencrypted key. 0 != unencrypted key but some code have something like this: > gnutls_x509_privkey_import_pkcs8(key, &pem, in_cert_format, pass, 0); > If you use "certtool --generate-privkey -8" you get a pkcs8 encrypted key. > The only thing you need to do is call gnutls_x509_privkey_export_pkcs8() > with the flag (say) GNUTLS_PKCS_USE_PKCS12_3DES and an ASCII password. All works fine. Was a problem with (configuration parameters + mistake + other errors) in my test program. Thanks and Regards -- Fco. J. From nmav at gnutls.org Fri Nov 18 16:34:54 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 18 Nov 2005 16:34:54 +0100 Subject: [Help-gnutls] About Future Plans: Private keys encrypted. In-Reply-To: <1132186953.3536.17.camel@localhost> References: <1132084363.3782.10.camel@localhost> <200511161233.11552.nmav@gnutls.org> <1132186953.3536.17.camel@localhost> Message-ID: <200511181634.54951.nmav@gnutls.org> On Thursday 17 November 2005 01:22, Fran wrote: > On M?r, 2005-11-16 at 12:33 +0100, Nikos Mavrogiannopoulos wrote: > > Which manpages were problematic? > > It is strange for me (for me): > > unsigned int flags > > 0 if encrypted or GNUTLS_PKCS_PLAIN if not encrypted. > > Currently only RSA keys can be imported, > > and flags can only be used to indicate an unencrypted key. It is indeed strange. The problem is that if the key is DER encoded that encryption status cannot be auto-detected[0]. In the PEM case it is different since there is a header we can check. That's the purpose of this flag. I've added some clarification on the documentation... [0]. We could try to decode it as encrypted and if that fails try the unencrypted decoding, but this is too high level. If needed it should be done on a higher layer. -- Nikos Mavrogiannopoulos From msubramanian at spikesource.com Thu Nov 24 13:51:16 2005 From: msubramanian at spikesource.com (Muguntharaj Subramanian) Date: Thu, 24 Nov 2005 18:21:16 +0530 Subject: [Help-gnutls] Gnutls 1.2.6 build Error Message-ID: <4385B744.3060900@spikesource.com> Hi All, I face the following error while building gnutls. $ ./configure $ make ............ ............ ........... gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../ -I../minitasn1/ -I../../includes/ -D_REENTRANT -D_THREAD_SAFE -O2 -finline-functions -pipe -I/opt/oss/include -I/opt/oss/include -MT common.lo -MD -MP -MF .deps/common.Tpo -c common.c -fPIC -DPIC -o .libs/common.o common.c:321: error: conflicting types for '_gnutls_x509_sign_to_oid' ./common.h:43: error: previous declaration of '_gnutls_x509_sign_to_oid' was here common.c:321: error: conflicting types for '_gnutls_x509_sign_to_oid' ./common.h:43: error: previous declaration of '_gnutls_x509_sign_to_oid' was here make[3]: *** [common.lo] Error 1 make[3]: Leaving directory `/opt/spikedev/MsubBuilds/comps/gnutls/src/lib/x509' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/spikedev/MsubBuilds/comps/gnutls/src/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/spikedev/MsubBuilds/comps/gnutls/src' make: *** [all] Error 2 [/opt/spikedev/MsubBuilds/comps/gnutls/src] DEV msubramanian at mugunth [1080] Please let me know if i am missing something. Thanks Mugunth