From simon at josefsson.org  Mon Jan  5 14:39:29 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 05 Jan 2009 14:39:29 +0100
Subject: Valid hash algorithms for X.509 certificates
In-Reply-To: <f43cca2f0812301713o789a5410va5ede420a2590827@mail.gmail.com>
	("David =?iso-8859-1?Q?Mar=EDn_Carre=F1o=22's?= message of "Wed, 31 Dec
	2008 02:13:10 +0100")
References: <f43cca2f0812301713o789a5410va5ede420a2590827@mail.gmail.com>
Message-ID: <87tz8dj2i6.fsf@mocca.josefsson.org>

"David Mar??n Carre??o" <davefx at gmail.com> writes:

> Related with the MD5 issue, if I am not wrong, currently the only
> interoperable hash algorithm for use with X.509 algorithms is SHA-1.

Right.

> However, in the document [0] it is said that SHA-1 will probably
> follow the same fate in a not very long time.
>
> SHA-2 is currently allowed in standard X.509 certificates according to
> RFC 4055, but only if RSASSA-PSS is used (at least, I understand it
> that way).

No, I believe RFC 4055 also defines SHA-2 for PKCSv1.5 (e.g., pre-PSS),
see section 5 of the document.

> Also, a new document "Internet X.509 Public Key Infrastructure:
> Additional Algorithms and Identifiers for DSA and ECDSA"[1] is under
> development, that includes SHA-2 hashing only when the certificate
> uses DSA or ECDSA...

Right.  That is DSA2.

> Does anyone know if the IETF is preparing a revision or update to RFC
> 3279 for deprecating (officially) MD2 and MD5 and including SHA-2 (or
> other algorithms) as a proposed "standard" for all kinds of public
> keys?
>
> [0] http://www.win.tue.nl/hashclash/rogue-ca/
> [1] http://tools.ietf.org/html/draft-ietf-pkix-sha2-dsa-ecdsa-05

I believe SHA-2 is already taken care of with RFC 4055.  MD2 and MD5 are
discouraged by RFC 3279 already, and I'm not sure any stronger words
will make much practical difference.

GnuTLS should support RSA SHA-2 since v2.0.  There is a self-test
tests/sha2/ that create a RSA X.509 certificate chain signed using some
SHA-2 algorithms:

Certificate[0]: CN=End-user
	Issued by: CN=SHA 256 sub-sub-CA
	Verifying against certificate[1].
	Verification output: Verified.

Certificate[1]: CN=SHA 256 sub-sub-CA
	Issued by: CN=SHA 384 sub-CA
	Verifying against certificate[2].
	Verification output: Verified.

Certificate[2]: CN=SHA 384 sub-CA
	Issued by: CN=SHA 512 CA
	Verifying against certificate[3].
	Verification output: Verified.

Certificate[3]: CN=SHA 512 CA
	Issued by: CN=SHA 512 CA
	Verification output: Verified.

Test OK

/Simon




From simon at josefsson.org  Mon Jan  5 14:42:46 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 05 Jan 2009 14:42:46 +0100
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <495AAB48.3020300@fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Tue, 30 Dec 2008 18:14:16 -0500")
References: <495AAB48.3020300@fifthhorseman.net>
Message-ID: <87mye5j2cp.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> Hi folks--
>
> In light of the recent demonstration of an attack against
> X.509 PKI  using weaknesses in MD5 [0], i'm quite happy to
> see that you must explicitly enable the use of MD5 for
> certificate validation in gnutls for over 3 years
> (from the 2005-11-07 NEWS entry):
>
> - 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.

Hurray.  Some people were against that move at the time, but I think it
was the right choice.

> However, gnutls-cli seems to blithely accept certificates that *are*
> signed with an md5 hash.  You can see this from a debian system with:
>
> echo | gnutls-cli --print-cert --x509cafile /etc/ssl/certs/Equifax_Secure_Global_eBusiness_CA.pem support.mayfirst.org | certtool -i
>
> This seems to be the case with both 2.4.2-4 and 2.6.3-1, afaict, 
> but i haven't tested with 2.7.x. 
>
> Are there plans to change this?

I suspect that is a consequence of the now sub-optimal chain validation
algorithm the library is using that pre-empts some of the more advanced
tests on chains of length 1.  The patch I proposed to really solve the
GNUTLS-SA-2008-3 problem should fix the MD5 bug, but it had other
consequences.  Maybe this is worth revisiting, and fixing the
side-effects, we really should reject ALL chains with RSA-MD5 signatures
in them.

/Simon




From tmraz at redhat.com  Mon Jan  5 19:48:45 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Mon, 05 Jan 2009 19:48:45 +0100
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <87mye5j2cp.fsf@mocca.josefsson.org>
References: <495AAB48.3020300@fifthhorseman.net>
	<87mye5j2cp.fsf@mocca.josefsson.org>
Message-ID: <1231181325.5218.168.camel@vespa.frost.loc>

On Mon, 2009-01-05 at 14:42 +0100, Simon Josefsson wrote:
> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
> 
> > Hi folks--
> >
> > In light of the recent demonstration of an attack against
> > X.509 PKI  using weaknesses in MD5 [0], i'm quite happy to
> > see that you must explicitly enable the use of MD5 for
> > certificate validation in gnutls for over 3 years
> > (from the 2005-11-07 NEWS entry):
> >
> > - 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.
> 
> Hurray.  Some people were against that move at the time, but I think it
> was the right choice.
> 
> > However, gnutls-cli seems to blithely accept certificates that *are*
> > signed with an md5 hash.  You can see this from a debian system with:
> >
> > echo | gnutls-cli --print-cert --x509cafile /etc/ssl/certs/Equifax_Secure_Global_eBusiness_CA.pem support.mayfirst.org | certtool -i
> >
> > This seems to be the case with both 2.4.2-4 and 2.6.3-1, afaict, 
> > but i haven't tested with 2.7.x. 
> >
> > Are there plans to change this?
> 
> I suspect that is a consequence of the now sub-optimal chain validation
> algorithm the library is using that pre-empts some of the more advanced
> tests on chains of length 1.  The patch I proposed to really solve the
> GNUTLS-SA-2008-3 problem should fix the MD5 bug, but it had other
> consequences.  Maybe this is worth revisiting, and fixing the
> side-effects, we really should reject ALL chains with RSA-MD5 signatures
> in them.

If the only MD5 used in signatures is in the _trusted_ CA cert (and not
in the leaf and intermediate certificates) it is OK. But it is not the
case of the support.mayfirst.org site. But I don't see how the removal
of the last selfsigned certificate from the chain could break the
algorithm. There must be some different bug in play.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb





From tmraz at redhat.com  Mon Jan  5 20:11:25 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Mon, 05 Jan 2009 20:11:25 +0100
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <1231181325.5218.168.camel@vespa.frost.loc>
References: <495AAB48.3020300@fifthhorseman.net>
	<87mye5j2cp.fsf@mocca.josefsson.org>
	<1231181325.5218.168.camel@vespa.frost.loc>
Message-ID: <1231182685.5218.172.camel@vespa.frost.loc>

On Mon, 2009-01-05 at 19:48 +0100, Tomas Mraz wrote:
> On Mon, 2009-01-05 at 14:42 +0100, Simon Josefsson wrote:
> > Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
> > 
> > > Hi folks--
> > >
> > > In light of the recent demonstration of an attack against
> > > X.509 PKI  using weaknesses in MD5 [0], i'm quite happy to
> > > see that you must explicitly enable the use of MD5 for
> > > certificate validation in gnutls for over 3 years
> > > (from the 2005-11-07 NEWS entry):
> > >
> > > - 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.
> > 
> > Hurray.  Some people were against that move at the time, but I think it
> > was the right choice.
> > 
> > > However, gnutls-cli seems to blithely accept certificates that *are*
> > > signed with an md5 hash.  You can see this from a debian system with:
> > >
> > > echo | gnutls-cli --print-cert --x509cafile /etc/ssl/certs/Equifax_Secure_Global_eBusiness_CA.pem support.mayfirst.org | certtool -i
> > >
> > > This seems to be the case with both 2.4.2-4 and 2.6.3-1, afaict, 
> > > but i haven't tested with 2.7.x. 
> > >
> > > Are there plans to change this?
> > 
> > I suspect that is a consequence of the now sub-optimal chain validation
> > algorithm the library is using that pre-empts some of the more advanced
> > tests on chains of length 1.  The patch I proposed to really solve the
> > GNUTLS-SA-2008-3 problem should fix the MD5 bug, but it had other
> > consequences.  Maybe this is worth revisiting, and fixing the
> > side-effects, we really should reject ALL chains with RSA-MD5 signatures
> > in them.
> 
> If the only MD5 used in signatures is in the _trusted_ CA cert (and not
> in the leaf and intermediate certificates) it is OK. But it is not the
> case of the support.mayfirst.org site. But I don't see how the removal
> of the last selfsigned certificate from the chain could break the
> algorithm. There must be some different bug in play.

And the bug is that ret is not set to 0 in _gnutls_verify_certificate2()
in case the unsecure algorithm in signature is detected. The same holds
for crl signature verification in _gnutls_verify_crl2().

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb





From dkg at fifthhorseman.net  Mon Jan  5 20:31:12 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 05 Jan 2009 14:31:12 -0500
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <1231181325.5218.168.camel@vespa.frost.loc>
References: <495AAB48.3020300@fifthhorseman.net>	
	<87mye5j2cp.fsf@mocca.josefsson.org>
	<1231181325.5218.168.camel@vespa.frost.loc>
Message-ID: <49626000.3050308@fifthhorseman.net>

On 01/05/2009 01:48 PM, Tomas Mraz wrote:
> If the only MD5 used in signatures is in the _trusted_ CA cert (and not
> in the leaf and intermediate certificates) it is OK. But it is not the
> case of the support.mayfirst.org site. But I don't see how the removal
> of the last selfsigned certificate from the chain could break the
> algorithm. There must be some different bug in play.

I agree with this assessment.  It would be really useful in debugging if
certtool was able to use the same internal algorithm that the other
tools use.  I'm sorry that i haven't had the time to debug this further yet.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090105/c02da6bb/attachment.pgp>

From dkg at fifthhorseman.net  Tue Jan  6 06:20:15 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 06 Jan 2009 00:20:15 -0500
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <49626000.3050308@fifthhorseman.net>
References: <495AAB48.3020300@fifthhorseman.net>		<87mye5j2cp.fsf@mocca.josefsson.org>	<1231181325.5218.168.camel@vespa.frost.loc>
	<49626000.3050308@fifthhorseman.net>
Message-ID: <4962EA0F.4080504@fifthhorseman.net>

On 01/05/2009 02:31 PM, Daniel Kahn Gillmor wrote:
>  I'm sorry that i haven't had the time to debug this further yet.

Ok, i got to look into it tonight with gdb against the gnutls 2.6.3
libraries (i'm using the versions from debian experimental).  here's
what i found:

gnutls_certificate_verify_peers2() ultimately calls
_gnutls_verify_certificate2(), which (at lib/x509/verify.c:321) properly
sets the flags in the output variable, but does not set ret to 0.

gnutls_x509_crt_list_verify(), the immediate caller of
_gnutls_verify_certificate2(), does not check the data in *output unless
the return code is actually zero.

So i suspect that the following is the correct patch (against the git
head), but i have not tested it yet (and i need to sleep before it gets
any later):

diff --git a/lib/x509/verify.c b/lib/x509/verify.c
index 02964ba..c00b4bf 100644
--- a/lib/x509/verify.c
+++ b/lib/x509/verify.c
@@ -320,6 +320,7 @@ _gnutls_verify_certificate2 (gnutls_x509_crt_t cert,
 	{
 	  if (output)
 	    *output |= GNUTLS_CERT_INSECURE_ALGORITHM | GNUTLS_CERT_INVALID;
+	  ret = 0;
 	}
     }

@@ -1036,6 +1037,7 @@ _gnutls_verify_crl2 (gnutls_x509_crl_t crl,
       {
 	if (output)
 	  *output |= GNUTLS_CERT_INSECURE_ALGORITHM | GNUTLS_CERT_INVALID;
+	ret = 0;
       }
   }

Any thoughts about this proposal?  This would affect the built-in X.509
verification routines, not just gnutls-cli and gnutls-serv.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090106/5f8e882e/attachment.pgp>

From dkg at fifthhorseman.net  Tue Jan  6 06:57:35 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 06 Jan 2009 00:57:35 -0500
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <4962EA0F.4080504@fifthhorseman.net>
References: <495AAB48.3020300@fifthhorseman.net>		<87mye5j2cp.fsf@mocca.josefsson.org>	<1231181325.5218.168.camel@vespa.frost.loc>	<49626000.3050308@fifthhorseman.net>
	<4962EA0F.4080504@fifthhorseman.net>
Message-ID: <4962F2CF.6060005@fifthhorseman.net>

On 01/06/2009 12:20 AM, Daniel Kahn Gillmor wrote:
> So i suspect that the following is the correct patch (against the git
> head), but i have not tested it yet (and i need to sleep before it gets
> any later):
> 
> diff --git a/lib/x509/verify.c b/lib/x509/verify.c
> index 02964ba..c00b4bf 100644
> --- a/lib/x509/verify.c
> +++ b/lib/x509/verify.c
> @@ -320,6 +320,7 @@ _gnutls_verify_certificate2 (gnutls_x509_crt_t cert,
>  	{
>  	  if (output)
>  	    *output |= GNUTLS_CERT_INSECURE_ALGORITHM | GNUTLS_CERT_INVALID;
> +	  ret = 0;
>  	}
>      }
> 
> @@ -1036,6 +1037,7 @@ _gnutls_verify_crl2 (gnutls_x509_crl_t crl,
>        {
>  	if (output)
>  	  *output |= GNUTLS_CERT_INSECURE_ALGORITHM | GNUTLS_CERT_INVALID;
> +	ret = 0;
>        }
>    }

OK, i've tested this patch now against 2.6.3, and it seems to have the
documented behavior: connections certified with SHA1 signatures work
fine, but connections certified with MD5 produce output like:

 [...]
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: DHE-RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
*** Verifying server certificate failed...
1 dkg at pip:~$

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090106/dbeaf0bb/attachment.pgp>

From nmav at gnutls.org  Tue Jan  6 09:40:51 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 06 Jan 2009 10:40:51 +0200
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <4962EA0F.4080504@fifthhorseman.net>
References: <495AAB48.3020300@fifthhorseman.net>		<87mye5j2cp.fsf@mocca.josefsson.org>	<1231181325.5218.168.camel@vespa.frost.loc>	<49626000.3050308@fifthhorseman.net>
	<4962EA0F.4080504@fifthhorseman.net>
Message-ID: <49631913.9010203@gnutls.org>

Daniel Kahn Gillmor wrote:
> On 01/05/2009 02:31 PM, Daniel Kahn Gillmor wrote:
>>  I'm sorry that i haven't had the time to debug this further yet.
> 
> Ok, i got to look into it tonight with gdb against the gnutls 2.6.3
> libraries (i'm using the versions from debian experimental).  here's
> what i found:
> 
> gnutls_certificate_verify_peers2() ultimately calls
> _gnutls_verify_certificate2(), which (at lib/x509/verify.c:321) properly
> sets the flags in the output variable, but does not set ret to 0.
> 
> gnutls_x509_crt_list_verify(), the immediate caller of
> _gnutls_verify_certificate2(), does not check the data in *output unless
> the return code is actually zero.
> 
> So i suspect that the following is the correct patch (against the git
> head), but i have not tested it yet (and i need to sleep before it gets
> any later):
> 
> diff --git a/lib/x509/verify.c b/lib/x509/verify.c
> index 02964ba..c00b4bf 100644
> --- a/lib/x509/verify.c
> +++ b/lib/x509/verify.c
> @@ -320,6 +320,7 @@ _gnutls_verify_certificate2 (gnutls_x509_crt_t cert,
>  	{
>  	  if (output)
>  	    *output |= GNUTLS_CERT_INSECURE_ALGORITHM | GNUTLS_CERT_INVALID;
> +	  ret = 0;
>  	}
>      }
> 
> @@ -1036,6 +1037,7 @@ _gnutls_verify_crl2 (gnutls_x509_crl_t crl,
>        {
>  	if (output)
>  	  *output |= GNUTLS_CERT_INSECURE_ALGORITHM | GNUTLS_CERT_INVALID;
> +	ret = 0;
>        }
>    }
> 
> Any thoughts about this proposal?  This would affect the built-in X.509
> verification routines, not just gnutls-cli and gnutls-serv.

Looks like the correct thing to do. Apply it!

regards,
Nikos




From dkg at fifthhorseman.net  Tue Jan  6 17:04:00 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 06 Jan 2009 11:04:00 -0500
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <49631913.9010203@gnutls.org>
References: <495AAB48.3020300@fifthhorseman.net>		<87mye5j2cp.fsf@mocca.josefsson.org>	<1231181325.5218.168.camel@vespa.frost.loc>	<49626000.3050308@fifthhorseman.net>
	<4962EA0F.4080504@fifthhorseman.net> <49631913.9010203@gnutls.org>
Message-ID: <496380F0.9050807@fifthhorseman.net>

On 01/06/2009 03:40 AM, Nikos Mavrogiannopoulos wrote:
> Looks like the correct thing to do. Apply it!

OK, it's applied to the git head.  Is this something that should be
backported to the 2.6 branch?  Currently our documentation doesn't match
our implementation there.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090106/f3ec7da1/attachment.pgp>

From nmav at gnutls.org  Tue Jan  6 17:33:27 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 06 Jan 2009 18:33:27 +0200
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <496380F0.9050807@fifthhorseman.net>
References: <495AAB48.3020300@fifthhorseman.net>		<87mye5j2cp.fsf@mocca.josefsson.org>	<1231181325.5218.168.camel@vespa.frost.loc>	<49626000.3050308@fifthhorseman.net>	<4962EA0F.4080504@fifthhorseman.net>
	<49631913.9010203@gnutls.org> <496380F0.9050807@fifthhorseman.net>
Message-ID: <496387D7.8030705@gnutls.org>

Daniel Kahn Gillmor wrote:
> On 01/06/2009 03:40 AM, Nikos Mavrogiannopoulos wrote:
>> Looks like the correct thing to do. Apply it!

> OK, it's applied to the git head.  Is this something that should be
> backported to the 2.6 branch? 

Since it is a bugfix i think it qualifies for backporting, but Simon
should have the last word on that.

> Currently our documentation doesn't match
> our implementation there.

In what sense?

regards,
Nikos




From dkg at fifthhorseman.net  Tue Jan  6 17:47:33 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 06 Jan 2009 11:47:33 -0500
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <496387D7.8030705@gnutls.org>
References: <495AAB48.3020300@fifthhorseman.net>		<87mye5j2cp.fsf@mocca.josefsson.org>	<1231181325.5218.168.camel@vespa.frost.loc>	<49626000.3050308@fifthhorseman.net>	<4962EA0F.4080504@fifthhorseman.net>	<49631913.9010203@gnutls.org>
	<496380F0.9050807@fifthhorseman.net> <496387D7.8030705@gnutls.org>
Message-ID: <49638B25.5050308@fifthhorseman.net>

On 01/06/2009 11:33 AM, Nikos Mavrogiannopoulos wrote:
>> Currently our documentation doesn't match
>> our implementation there.
> 
> In what sense?

I just meant that our documentation (NEWS) claims that certificate
validations that rely on MD2 and MD5 will fail unless a given flag is
set, but they currently don't do this.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090106/33ad10fc/attachment.pgp>

From simon at josefsson.org  Tue Jan  6 22:50:56 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 06 Jan 2009 22:50:56 +0100
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <496387D7.8030705@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Tue, 06 Jan 2009 18:33:27 +0200")
References: <495AAB48.3020300@fifthhorseman.net>
	<87mye5j2cp.fsf@mocca.josefsson.org>
	<1231181325.5218.168.camel@vespa.frost.loc>
	<49626000.3050308@fifthhorseman.net>
	<4962EA0F.4080504@fifthhorseman.net> <49631913.9010203@gnutls.org>
	<496380F0.9050807@fifthhorseman.net> <496387D7.8030705@gnutls.org>
Message-ID: <87wsd8gl33.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Daniel Kahn Gillmor wrote:
>> On 01/06/2009 03:40 AM, Nikos Mavrogiannopoulos wrote:
>>> Looks like the correct thing to do. Apply it!
>
>> OK, it's applied to the git head.  Is this something that should be
>> backported to the 2.6 branch? 
>
> Since it is a bugfix i think it qualifies for backporting, but Simon
> should have the last word on that.

I agree, Daniel please backport it.  Please also add NEWS items for the
change.

To avoid regressions, I'm adding the chain to the self-tests.  It would
be useful if we had a more comprehensive self-test suite for X.509
chaining, given the three latest problems it seems this is an
under-tested area.  There is the PKITS stuff, but its license is
unclear...

/Simon




From simon at josefsson.org  Tue Jan  6 23:00:30 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 06 Jan 2009 23:00:30 +0100
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <1231182685.5218.172.camel@vespa.frost.loc> (Tomas Mraz's message
	of "Mon, 05 Jan 2009 20:11:25 +0100")
References: <495AAB48.3020300@fifthhorseman.net>
	<87mye5j2cp.fsf@mocca.josefsson.org>
	<1231181325.5218.168.camel@vespa.frost.loc>
	<1231182685.5218.172.camel@vespa.frost.loc>
Message-ID: <87sknwgkn5.fsf@mocca.josefsson.org>

Tomas Mraz <tmraz at redhat.com> writes:

> And the bug is that ret is not set to 0 in _gnutls_verify_certificate2()
> in case the unsecure algorithm in signature is detected. The same holds
> for crl signature verification in _gnutls_verify_crl2().

Thanks for debugging it.  I appreciate it.

/Simon




From simon at josefsson.org  Tue Jan  6 23:17:33 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 06 Jan 2009 23:17:33 +0100
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <49626000.3050308@fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Mon, 05 Jan 2009 14:31:12 -0500")
References: <495AAB48.3020300@fifthhorseman.net>
	<87mye5j2cp.fsf@mocca.josefsson.org>
	<1231181325.5218.168.camel@vespa.frost.loc>
	<49626000.3050308@fifthhorseman.net>
Message-ID: <87ocykgjuq.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> On 01/05/2009 01:48 PM, Tomas Mraz wrote:
>> If the only MD5 used in signatures is in the _trusted_ CA cert (and not
>> in the leaf and intermediate certificates) it is OK. But it is not the
>> case of the support.mayfirst.org site. But I don't see how the removal
>> of the last selfsigned certificate from the chain could break the
>> algorithm. There must be some different bug in play.
>
> I agree with this assessment.  It would be really useful in debugging if
> certtool was able to use the same internal algorithm that the other
> tools use.

Indeed, and I've now made that happen.  Look at the final line at:

jas at mocca:~/src/gnutls/src master$ (echo | gnutls-cli --print-cert --x509cafile /etc/ssl/certs/Equifax_Secure_Global_eBusiness_CA.pem support.mayfirst.org; cat /etc/ssl/certs/Equifax_Secure_Global_eBusiness_CA.pem) | ./certtool -e
Certificate[0]: C=US,O=support.mayfirst.org,OU=GT69079880,OU=See www.rapidssl.com/resources/cps (c)07,OU=Domain Control Validated - RapidSSL(R),CN=support.mayfirst.org
	Issued by: C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1
	Verifying against certificate[1].
	Verification output: Not verified, Insecure algorithm.

Certificate[1]: C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1
	Issued by: C=US,O=Equifax Secure Inc.,CN=Equifax Secure Global eBusiness CA-1
	Verification output: Verified.

Chain verification output: Not verified, Insecure algorithm.
jas at mocca:~/src/gnutls/src master$ 

The last line contains the result from validating the chain using the
library algorithm.  The flags are always 0 which can vary from how
libgnutls is used by applications, though, but at least this is a step
in the right direction.

/Simon




From dkg at fifthhorseman.net  Wed Jan  7 02:08:44 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 06 Jan 2009 20:08:44 -0500
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <87wsd8gl33.fsf@mocca.josefsson.org>
References: <495AAB48.3020300@fifthhorseman.net>	<87mye5j2cp.fsf@mocca.josefsson.org>	<1231181325.5218.168.camel@vespa.frost.loc>	<49626000.3050308@fifthhorseman.net>	<4962EA0F.4080504@fifthhorseman.net>
	<49631913.9010203@gnutls.org>	<496380F0.9050807@fifthhorseman.net>
	<496387D7.8030705@gnutls.org> <87wsd8gl33.fsf@mocca.josefsson.org>
Message-ID: <4964009C.3030908@fifthhorseman.net>

On 01/06/2009 04:50 PM, Simon Josefsson wrote:
> I agree, Daniel please backport it.  Please also add NEWS items for the
> change.

OK, this is now done.  i've backported for 2.6, but not for any earlier
branch.  this is such a trivial change that it would be no problem for
me to backport it to other branches if folks think that's the right
thing to do.  What branches are we targetting for this level of support?

> To avoid regressions, I'm adding the chain to the self-tests.  It would
> be useful if we had a more comprehensive self-test suite for X.509
> chaining, given the three latest problems it seems this is an
> under-tested area.  There is the PKITS stuff, but its license is
> unclear...

Thanks for adding that test, simon.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090106/72c36f84/attachment.pgp>

From simon at josefsson.org  Wed Jan  7 11:39:53 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 07 Jan 2009 11:39:53 +0100
Subject: deprecating MD5 in signature verification for gnutls-{cli, serv}
In-Reply-To: <4964009C.3030908@fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Tue, 06 Jan 2009 20:08:44 -0500")
References: <495AAB48.3020300@fifthhorseman.net>
	<87mye5j2cp.fsf@mocca.josefsson.org>
	<1231181325.5218.168.camel@vespa.frost.loc>
	<49626000.3050308@fifthhorseman.net>
	<4962EA0F.4080504@fifthhorseman.net> <49631913.9010203@gnutls.org>
	<496380F0.9050807@fifthhorseman.net> <496387D7.8030705@gnutls.org>
	<87wsd8gl33.fsf@mocca.josefsson.org>
	<4964009C.3030908@fifthhorseman.net>
Message-ID: <87fxjv8kna.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> On 01/06/2009 04:50 PM, Simon Josefsson wrote:
>> I agree, Daniel please backport it.  Please also add NEWS items for the
>> change.
>
> OK, this is now done.  i've backported for 2.6, but not for any earlier
> branch.

Thanks.  When possible, it is a good idea to add links to the discussion
and give credit to the reporter, so I changed the NEWS entry to:

** gnutls: deprecate X.509 validation chains using MD5 and MD2 signatures.
This is a bugfix -- the previous attempt to do this from internal x509
certificate verification procedures did not return the correct value
for certificates using a weak hash.  Reported by Daniel Kahn Gillmor
<dkg at fifthhorseman.net> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3332>,
debugged and patch by Tomas Mraz <tmraz at redhat.com> and Daniel Kahn
Gillmor <dkg at fifthhorseman.net>.

> this is such a trivial change that it would be no problem for me to
> backport it to other branches if folks think that's the right thing to
> do.  What branches are we targetting for this level of support?

I don't have resources to make releases from anything but the latest
stable branch (v2.6.x) and the latest development branch (v2.7), but
feel free to back-port quick fixes like this to older branches too if
you think someone is looking at them (or want a canonical place to point
people to the patch).

Daily snapshot's are still being built for v2.4.x, see
http://daily.josefsson.org/gnutls-2.4/ -- however as soon as it stop
building for some reason, I'm going to remove that script since it just
takes too much of my time to keep maintaining old versions forever.
This happened for v2.0 and v2.2 only relatively recently (I think there
were some autoconf problem).

If you or others wants to offer support for older branches, e.g. to make
another release of v2.4.x, that would be fine (although I'd prefer if
you would help make v2.6/2.7 better instead :)).

/Simon




From simon at josefsson.org  Wed Jan  7 12:59:55 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 07 Jan 2009 12:59:55 +0100
Subject: GnuTLS 2.7.4
Message-ID: <87tz8b72dg.fsf@mocca.josefsson.org>

The GnuTLS 2.7.x branch is NOT what you want for your stable system.  It
is intended for developers and experienced users.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.7.4.tar.bz2 (5.8MB)
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.7.4.tar.bz2

Here is the OpenPGP signature:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.7.4.tar.bz2.sig
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.7.4.tar.bz2.sig

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 AB, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

/Simon

* Version 2.7.4 (released 2009-01-07)

** gnutls: deprecate X.509 validation chains using MD5 and MD2 signatures.
This is a bugfix -- the previous attempt to do this from internal x509
certificate verification procedures did not return the correct value
for certificates using a weak hash.  Reported by Daniel Kahn Gillmor
<dkg at fifthhorseman.net> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3332>,
debugged and patch by Tomas Mraz <tmraz at redhat.com> and Daniel Kahn
Gillmor <dkg at fifthhorseman.net>.

** gnutls: New interface to get key id for certificate requests.
Patch from David Mar?n Carre?o <davefx at gmail.com> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3321>.

** gnutls: gnutls_x509_crq_print will now also print public key id.

** certtool: --verify-chain now prints results of using library verification.
Earlier, certtool --verify-chain used its own validation algorithm
which wasn't guaranteed to give the same result as the libgnutls
internal validation algorithm.  Now this command print a new final
line with header 'Chain verification output:' that contains the result
From using the internal verification algorithm on the same chain.

** tests: Add crq_key_id self-test of gnutls_x509_crq_get_key_id.

** API and ABI modifications:
gnutls_x509_crq_get_key_id: ADDED.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20090107/2f4bd593/attachment.pgp>

From deengert at anl.gov  Thu Jan  8 01:14:57 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Wed, 07 Jan 2009 18:14:57 -0600
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
Message-ID: <49654581.3020505@anl.gov>

This is also being submitted to https://bugs.launchpad.net/bugs

Using the Ubuntu version of libgnutls13_2.0.4-1ubuntu2.3 on Hardy 8.04.1,
ldaps: has stopped working. This looks like it is related to
the December changes that are also in gnutls-2.6.3. See attached
patch that should work in both.

ldapsearch -d 1  -H ldaps://...

TLS: peer cert untrusted or revoked (0x82)
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)


The OpenLDAP ldap server certificate issued by Verisign is signed by:

Verisign_Intermediate-Secure_Site_Managed_PKI_for_SSL_Standard_Certificates.pem

which is signed by:
Verisign_Class_3_Public_Primary_Certification_Authority.pem

Both of these are in /etc/ssl/certs as 7651b327.0 and f0a38a80.0

Verisign_Class_3_Public_Primary_Certification_Authority.pem
is a self signed version 1 cert issued in 1996, with no extensions.

In lib/x509/verify.c  gnutls_x509_crt_get_ca_status is called
but returns GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE as there is no
Basic Constraint.

The attached patch (to gnutls13_2.0.4-1ubuntu2.3) checks for
this return and if it is a self signed cert, will treat it as a CA.
The patch looks like it can be applied to 2.6.3 as well.

Clients on Solaris 9 and 10, and OpenLDAP using OpenSSL on any
platform have no problems with this old cert.




-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnutls.verify.patch.txt
URL: </pipermail/attachments/20090107/9b64b494/attachment.txt>

From simon at josefsson.org  Thu Jan  8 09:15:00 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 08 Jan 2009 09:15:00 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <49654581.3020505@anl.gov> (Douglas E. Engert's message of "Wed, 
	07 Jan 2009 18:14:57 -0600")
References: <49654581.3020505@anl.gov>
Message-ID: <87sknu2ozf.fsf@mocca.josefsson.org>

"Douglas E. Engert" <deengert at anl.gov> writes:

> This is also being submitted to https://bugs.launchpad.net/bugs
>
> Using the Ubuntu version of libgnutls13_2.0.4-1ubuntu2.3 on Hardy 8.04.1,
> ldaps: has stopped working. This looks like it is related to
> the December changes that are also in gnutls-2.6.3. See attached
> patch that should work in both.
>
> ldapsearch -d 1  -H ldaps://...
>
> TLS: peer cert untrusted or revoked (0x82)
> ldap_err2string
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>
>
> The OpenLDAP ldap server certificate issued by Verisign is signed by:
>
> Verisign_Intermediate-Secure_Site_Managed_PKI_for_SSL_Standard_Certificates.pem
>
> which is signed by:
> Verisign_Class_3_Public_Primary_Certification_Authority.pem
>
> Both of these are in /etc/ssl/certs as 7651b327.0 and f0a38a80.0
>
> Verisign_Class_3_Public_Primary_Certification_Authority.pem
> is a self signed version 1 cert issued in 1996, with no extensions.

Do you have a complete chain that triggers this?  It will help our
regression test suite.

I don't have f0a38a80.0 on my debian lenny system.  Does it also lack a
basicConstraint?  Does it use RSA-MDx?  If yes, that would explain the
problem.

> In lib/x509/verify.c  gnutls_x509_crt_get_ca_status is called
> but returns GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE as there is no
> Basic Constraint.
>
> The attached patch (to gnutls13_2.0.4-1ubuntu2.3) checks for
> this return and if it is a self signed cert, will treat it as a CA.
> The patch looks like it can be applied to 2.6.3 as well.

The patch seems too permissive to me: the intention is that V1 certs
should be rejected by GnuTLS unless GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
and/or GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT are passed as flags.

Internally, GnuTLS by default enables the
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT flag when called via
gnutls_certificate_verify_peers2.  So I think GnuTLS should typically
accept this chain.

Indeed, looking at the code that invokes the function you patched:

  if (!(flags & GNUTLS_VERIFY_DISABLE_CA_SIGN) &&
      !((flags & GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) && issuer_version == 1))
    {
      if (check_if_ca (cert, issuer, flags) == 0)
	{
	  gnutls_assert ();
	  if (output)
	    *output |= GNUTLS_CERT_SIGNER_NOT_CA | GNUTLS_CERT_INVALID;
	  return 0;
	}
    }

It seems that the code you patched should not have been invoked at all
if (flags & GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) && issuer_version == 1
is true (if I understand the logic correctly..).  Could you debug why
this isn't the case?  Maybe issuer_version is wrong?

A complete chain to reproduce this will let me debug it too.

/Simon

> Clients on Solaris 9 and 10, and OpenLDAP using OpenSSL on any
> platform have no problems with this old cert.
>
>
>
>
> -- 
>
>  Douglas E. Engert  <DEEngert at anl.gov>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444
> --- ,verify.c	2009-01-06 14:02:41.000000000 -0600
> +++ verify.c	2009-01-07 17:07:27.000000000 -0600
> @@ -130,11 +130,20 @@
>  	  }
>        }
>  
> -  if (gnutls_x509_crt_get_ca_status (issuer, NULL) == 1)
> +  result = gnutls_x509_crt_get_ca_status (issuer, NULL);
> +  if (result == 1)
>      {
>        result = 1;
>        goto cleanup;
>      }
> +     /* Old self signed CA certs may not have basic constrant */
> +  else if ((result == GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) &&
> +           (gnutls_x509_crt_check_issuer(issuer, issuer) == 1))
> +    {
> +      gnutls_assert ();
> +      result = 1;
> +      goto cleanup;
> +    }
>    else
>      gnutls_assert ();
>  
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel




From deengert at anl.gov  Thu Jan  8 18:35:00 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Thu, 08 Jan 2009 11:35:00 -0600
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <87sknu2ozf.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
Message-ID: <49663944.6030708@anl.gov>

Attached are the server cert (auth2.it.anl.gov), the intermediate cert (f0a38a80.0)
and the CA self signed cert (7651b327.0) a debug version of verify.c
and partial output of an ldapsearch using the debug.c

My patch has been #if 0'ed out at line 151.

  Lets refer to the cert chain as A, B and C. The OpenLDAP server (using OpenSSL)
sends server cert A, intermediate cert B, and CA cert C.

The TLS_CACERT file has B and C.


The clist_size is then 3, and the code in  _gnutls_x509_verify_certificate
around lines 443 drop it to 2, leaving the chain as A, B.

The tcase_size is 2.

_gnutls_verify_certificate2 at line 452 is called with cert B and
tcas with B and C and flags 0.

At line 265, find_issuer is called with B. It returns C.
check_is_ca is called at line 297, which fails
because there is no BasicConstraint. The if at 293 looks correct too.


*BUT* if one trusts both B and C, do we need to verify C?
Why does the code arount line 265 not stop after finding that B is in the tcas,
rather then looking for C, and then verifying it?


If I try it again with the TLS_CACERT file with only B,
it also fails because it can not find the issuer of B.
If the code around line 265 was modified if B was found in the tcas,
this shopuld also work.



Simon Josefsson wrote:
> "Douglas E. Engert" <deengert at anl.gov> writes:
> 
>> This is also being submitted to https://bugs.launchpad.net/bugs
>>
>> Using the Ubuntu version of libgnutls13_2.0.4-1ubuntu2.3 on Hardy 8.04.1,
>> ldaps: has stopped working. This looks like it is related to
>> the December changes that are also in gnutls-2.6.3. See attached
>> patch that should work in both.
>>
>> ldapsearch -d 1  -H ldaps://...
>>
>> TLS: peer cert untrusted or revoked (0x82)
>> ldap_err2string
>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>>
>>
>> The OpenLDAP ldap server certificate issued by Verisign is signed by:
>>
>> Verisign_Intermediate-Secure_Site_Managed_PKI_for_SSL_Standard_Certificates.pem
>>
>> which is signed by:
>> Verisign_Class_3_Public_Primary_Certification_Authority.pem
>>
>> Both of these are in /etc/ssl/certs as 7651b327.0 and f0a38a80.0
>>
>> Verisign_Class_3_Public_Primary_Certification_Authority.pem
>> is a self signed version 1 cert issued in 1996, with no extensions.
> 
> Do you have a complete chain that triggers this?  It will help our
> regression test suite.
> 
> I don't have f0a38a80.0 on my debian lenny system.  Does it also lack a
> basicConstraint?  Does it use RSA-MDx?  If yes, that would explain the
> problem.
> 
>> In lib/x509/verify.c  gnutls_x509_crt_get_ca_status is called
>> but returns GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE as there is no
>> Basic Constraint.
>>
>> The attached patch (to gnutls13_2.0.4-1ubuntu2.3) checks for
>> this return and if it is a self signed cert, will treat it as a CA.
>> The patch looks like it can be applied to 2.6.3 as well.
> 
> The patch seems too permissive to me: the intention is that V1 certs
> should be rejected by GnuTLS unless GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
> and/or GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT are passed as flags.
> 
> Internally, GnuTLS by default enables the
> GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT flag when called via
> gnutls_certificate_verify_peers2.  So I think GnuTLS should typically
> accept this chain.
> 
> Indeed, looking at the code that invokes the function you patched:
> 
>   if (!(flags & GNUTLS_VERIFY_DISABLE_CA_SIGN) &&
>       !((flags & GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) && issuer_version == 1))
>     {
>       if (check_if_ca (cert, issuer, flags) == 0)
> 	{
> 	  gnutls_assert ();
> 	  if (output)
> 	    *output |= GNUTLS_CERT_SIGNER_NOT_CA | GNUTLS_CERT_INVALID;
> 	  return 0;
> 	}
>     }
> 
> It seems that the code you patched should not have been invoked at all
> if (flags & GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) && issuer_version == 1
> is true (if I understand the logic correctly..).  Could you debug why
> this isn't the case?  Maybe issuer_version is wrong?
> 
> A complete chain to reproduce this will let me debug it too.
> 
> /Simon
> 
>> Clients on Solaris 9 and 10, and OpenLDAP using OpenSSL on any
>> platform have no problems with this old cert.
>>
>>
>>
>>
>> -- 
>>
>>  Douglas E. Engert  <DEEngert at anl.gov>
>>  Argonne National Laboratory
>>  9700 South Cass Avenue
>>  Argonne, Illinois  60439
>>  (630) 252-5444
>> --- ,verify.c	2009-01-06 14:02:41.000000000 -0600
>> +++ verify.c	2009-01-07 17:07:27.000000000 -0600
>> @@ -130,11 +130,20 @@
>>  	  }
>>        }
>>  
>> -  if (gnutls_x509_crt_get_ca_status (issuer, NULL) == 1)
>> +  result = gnutls_x509_crt_get_ca_status (issuer, NULL);
>> +  if (result == 1)
>>      {
>>        result = 1;
>>        goto cleanup;
>>      }
>> +     /* Old self signed CA certs may not have basic constrant */
>> +  else if ((result == GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) &&
>> +           (gnutls_x509_crt_check_issuer(issuer, issuer) == 1))
>> +    {
>> +      gnutls_assert ();
>> +      result = 1;
>> +      goto cleanup;
>> +    }
>>    else
>>      gnutls_assert ();
>>  
>> _______________________________________________
>> Gnutls-devel mailing list
>> Gnutls-devel at gnu.org
>> http://lists.gnu.org/mailman/listinfo/gnutls-devel
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: f0a38a80.0
URL: </pipermail/attachments/20090108/1960bfcb/attachment.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: auth2.it.anl.gov.cert.pem
URL: </pipermail/attachments/20090108/1960bfcb/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 7651b327.0
URL: </pipermail/attachments/20090108/1960bfcb/attachment-0001.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: verify.trace.txt
URL: </pipermail/attachments/20090108/1960bfcb/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: verify.c
URL: </pipermail/attachments/20090108/1960bfcb/attachment-0002.asc>

From simon at josefsson.org  Fri Jan  9 10:56:40 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 09 Jan 2009 10:56:40 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <49663944.6030708@anl.gov> (Douglas E. Engert's message of "Thu, 
	08 Jan 2009 11:35:00 -0600")
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov>
Message-ID: <87k594g5uv.fsf@mocca.josefsson.org>

"Douglas E. Engert" <deengert at anl.gov> writes:

> Attached are the server cert (auth2.it.anl.gov), the intermediate cert (f0a38a80.0)
> and the CA self signed cert (7651b327.0)

Thanks, I can reproduce the problem.  Should be fixed with this patch:

 http://git.savannah.gnu.org/cgit/gnutls.git/commit/

> *BUT* if one trusts both B and C, do we need to verify C?
> Why does the code arount line 265 not stop after finding that B is in the tcas,
> rather then looking for C, and then verifying it?

GnuTLS does not support stopping at intermediate CAs right now, see
doc/TODO:

- Chain verifications.
  - Short-cut the certificate verification algorithm before the
    root if a middle-CA is trusted.

Fixing this would be useful.

Thanks,
/Simon




From simon at josefsson.org  Fri Jan  9 11:16:43 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 09 Jan 2009 11:16:43 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <87k594g5uv.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 09 Jan 2009 10:56:40 +0100")
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
Message-ID: <87bpugg4xg.fsf@mocca.josefsson.org>

Simon Josefsson <simon at josefsson.org> writes:

> "Douglas E. Engert" <deengert at anl.gov> writes:
>
>> Attached are the server cert (auth2.it.anl.gov), the intermediate cert (f0a38a80.0)
>> and the CA self signed cert (7651b327.0)
>
> Thanks, I can reproduce the problem.  Should be fixed with this patch:
>
>  http://git.savannah.gnu.org/cgit/gnutls.git/commit/

Sorry, that link was wrong.  For the 2.6.x branch the proper link is:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=423fc8b82f2b9aa3ea820cd5cf75d5813dffbbf0

Please test the patch and confirm whether or not it works for you.  I
think we should do a new 2.6.x release to deal with this.

The latest daily build contains all fixes, so everyone, please test this
as if it were a new 2.6.x release:

http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20090109.tar.gz

It is a good time to raise other problems with 2.6.x now.

Thanks,
/Simon




From tmraz at redhat.com  Fri Jan  9 11:54:28 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Fri, 09 Jan 2009 11:54:28 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <87bpugg4xg.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org>
Message-ID: <1231498468.3391.9.camel@vespa.frost.loc>

On Fri, 2009-01-09 at 11:16 +0100, Simon Josefsson wrote:
> Simon Josefsson <simon at josefsson.org> writes:
> 
> > "Douglas E. Engert" <deengert at anl.gov> writes:
> >
> >> Attached are the server cert (auth2.it.anl.gov), the intermediate cert (f0a38a80.0)
> >> and the CA self signed cert (7651b327.0)
> >
> > Thanks, I can reproduce the problem.  Should be fixed with this patch:
> >
> >  http://git.savannah.gnu.org/cgit/gnutls.git/commit/
> 
> Sorry, that link was wrong.  For the 2.6.x branch the proper link is:
> 
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=423fc8b82f2b9aa3ea820cd5cf75d5813dffbbf0
> 
> Please test the patch and confirm whether or not it works for you.  I
> think we should do a new 2.6.x release to deal with this.

I suppose there is an extraneous gnutls_assert () call in the case the
cert is V1 and the appropriate flags are set.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb





From simon at josefsson.org  Fri Jan  9 12:09:39 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 09 Jan 2009 12:09:39 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <1231498468.3391.9.camel@vespa.frost.loc> (Tomas Mraz's message
	of "Fri, 09 Jan 2009 11:54:28 +0100")
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org>
	<1231498468.3391.9.camel@vespa.frost.loc>
Message-ID: <87fxjska6k.fsf@mocca.josefsson.org>

Tomas Mraz <tmraz at redhat.com> writes:

> On Fri, 2009-01-09 at 11:16 +0100, Simon Josefsson wrote:
>> Simon Josefsson <simon at josefsson.org> writes:
>> 
>> > "Douglas E. Engert" <deengert at anl.gov> writes:
>> >
>> >> Attached are the server cert (auth2.it.anl.gov), the intermediate cert (f0a38a80.0)
>> >> and the CA self signed cert (7651b327.0)
>> >
>> > Thanks, I can reproduce the problem.  Should be fixed with this patch:
>> >
>> >  http://git.savannah.gnu.org/cgit/gnutls.git/commit/
>> 
>> Sorry, that link was wrong.  For the 2.6.x branch the proper link is:
>> 
>> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=423fc8b82f2b9aa3ea820cd5cf75d5813dffbbf0
>> 
>> Please test the patch and confirm whether or not it works for you.  I
>> think we should do a new 2.6.x release to deal with this.
>
> I suppose there is an extraneous gnutls_assert () call in the case the
> cert is V1 and the appropriate flags are set.

The gnutls_assert() is there for logging, and can be useful when
understanding which path an execution took.  If debug logging is not
used (the default) it is essentially a no-op.

I guess we can remove the call if it is triggered very often, but
logging about V1 CA's might make someone notice it and do something
about it.  I'd consider a V1 CA something of an exception and worth
worrying about, hence the assert call.

/Simon




From tmraz at redhat.com  Fri Jan  9 13:44:09 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Fri, 09 Jan 2009 13:44:09 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <87fxjska6k.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org>
	<1231498468.3391.9.camel@vespa.frost.loc>
	<87fxjska6k.fsf@mocca.josefsson.org>
Message-ID: <1231505049.3391.13.camel@vespa.frost.loc>

On Fri, 2009-01-09 at 12:09 +0100, Simon Josefsson wrote:
> Tomas Mraz <tmraz at redhat.com> writes:
> 
> > On Fri, 2009-01-09 at 11:16 +0100, Simon Josefsson wrote:
> >> Simon Josefsson <simon at josefsson.org> writes:
> >> 
> >> > "Douglas E. Engert" <deengert at anl.gov> writes:
> >> >
> >> >> Attached are the server cert (auth2.it.anl.gov), the intermediate cert (f0a38a80.0)
> >> >> and the CA self signed cert (7651b327.0)
> >> >
> >> > Thanks, I can reproduce the problem.  Should be fixed with this patch:
> >> >
> >> >  http://git.savannah.gnu.org/cgit/gnutls.git/commit/
> >> 
> >> Sorry, that link was wrong.  For the 2.6.x branch the proper link is:
> >> 
> >> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=423fc8b82f2b9aa3ea820cd5cf75d5813dffbbf0
> >> 
> >> Please test the patch and confirm whether or not it works for you.  I
> >> think we should do a new 2.6.x release to deal with this.
> >
> > I suppose there is an extraneous gnutls_assert () call in the case the
> > cert is V1 and the appropriate flags are set.
> 
> The gnutls_assert() is there for logging, and can be useful when
> understanding which path an execution took.  If debug logging is not
> used (the default) it is essentially a no-op.
> 
> I guess we can remove the call if it is triggered very often, but
> logging about V1 CA's might make someone notice it and do something
> about it.  I'd consider a V1 CA something of an exception and worth
> worrying about, hence the assert call.

Ah, OK. That makes good sense.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb





From deengert at anl.gov  Fri Jan  9 17:40:53 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Fri, 09 Jan 2009 10:40:53 -0600
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <87bpugg4xg.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov>
	<87sknu2ozf.fsf@mocca.josefsson.org>	<49663944.6030708@anl.gov>
	<87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org>
Message-ID: <49677E15.6030702@anl.gov>



Simon Josefsson wrote:
> Simon Josefsson <simon at josefsson.org> writes:
> 
>> "Douglas E. Engert" <deengert at anl.gov> writes:
>>
>>> Attached are the server cert (auth2.it.anl.gov), the intermediate cert (f0a38a80.0)
>>> and the CA self signed cert (7651b327.0)
>> Thanks, I can reproduce the problem.  Should be fixed with this patch:
>>
>>  http://git.savannah.gnu.org/cgit/gnutls.git/commit/
> 
> Sorry, that link was wrong.  For the 2.6.x branch the proper link is:
> 
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=423fc8b82f2b9aa3ea820cd5cf75d5813dffbbf0
> 
> Please test the patch and confirm whether or not it works for you.  I
> think we should do a new 2.6.x release to deal with this.

I tried the patch against the Ubuntu version, but it still fails. Looking
at 2.6.3 and the Ubuntu version I don't see any differences in this area.


When using ldasearch, gnutls_x509_crl_verify is called with flags=0.

I don't see where GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT or
GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT are set.


I do see that the src/cli.c in the init_global_tls_stuff but cli.c is
a test program(?) and  not part of the lib.

I do see that in 2.6.3 lib/x509/verify.c will XOR?
it at line 444 (2.6.3 version) flags ^= GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT;
But that is too late,
as _gnutls_verify_certificate2 is called at line 402 with flags=0.

Also should line 444 be |= rather the ^= ?


> 
> The latest daily build contains all fixes, so everyone, please test this
> as if it were a new 2.6.x release:
> 
> http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20090109.tar.gz
> 
> It is a good time to raise other problems with 2.6.x now.
> 
> Thanks,
> /Simon
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444




From simon at josefsson.org  Fri Jan  9 17:54:10 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 09 Jan 2009 17:54:10 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <49677E15.6030702@anl.gov> (Douglas E. Engert's message of "Fri, 
	09 Jan 2009 10:40:53 -0600")
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org> <49677E15.6030702@anl.gov>
Message-ID: <87wsd4774d.fsf@mocca.josefsson.org>

"Douglas E. Engert" <deengert at anl.gov> writes:

> Simon Josefsson wrote:
>> Simon Josefsson <simon at josefsson.org> writes:
>>
>>> "Douglas E. Engert" <deengert at anl.gov> writes:
>>>
>>>> Attached are the server cert (auth2.it.anl.gov), the intermediate cert (f0a38a80.0)
>>>> and the CA self signed cert (7651b327.0)
>>> Thanks, I can reproduce the problem.  Should be fixed with this patch:
>>>
>>>  http://git.savannah.gnu.org/cgit/gnutls.git/commit/
>>
>> Sorry, that link was wrong.  For the 2.6.x branch the proper link is:
>>
>> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=423fc8b82f2b9aa3ea820cd5cf75d5813dffbbf0
>>
>> Please test the patch and confirm whether or not it works for you.  I
>> think we should do a new 2.6.x release to deal with this.
>
> I tried the patch against the Ubuntu version, but it still fails. Looking
> at 2.6.3 and the Ubuntu version I don't see any differences in this area.
>
>
> When using ldasearch, gnutls_x509_crl_verify is called with flags=0.
>
> I don't see where GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT or
> GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT are set.

The default is to reject V1 CA's, so the application need to supply
either flag if they want a particular behaviour.

By default, gnutls_x509_crt_list_verify rejects V1 CAs, but it takes a
flags parameter.  If you call the verification through
gnutls_session_verify_peers, you can use the
gnutls_certificate_set_verify_flags function to set the flags to use
(like cli.c does).

> I do see that the src/cli.c in the init_global_tls_stuff but cli.c is
> a test program(?) and  not part of the lib.
>
> I do see that in 2.6.3 lib/x509/verify.c will XOR?
> it at line 444 (2.6.3 version) flags ^= GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT;
> But that is too late,
> as _gnutls_verify_certificate2 is called at line 402 with flags=0.
>
> Also should line 444 be |= rather the ^= ?

That code is meant to _remove_ the GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
flag from the flags parameter, unless
GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT is set.

/Simon

>
>>
>> The latest daily build contains all fixes, so everyone, please test this
>> as if it were a new 2.6.x release:
>>
>> http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20090109.tar.gz
>>
>> It is a good time to raise other problems with 2.6.x now.
>>
>> Thanks,
>> /Simon
>>
>>
>
> -- 
>
>  Douglas E. Engert  <DEEngert at anl.gov>
>  Argonne National Laboratory
>  9700 South Cass Avenue
>  Argonne, Illinois  60439
>  (630) 252-5444




From dkg at fifthhorseman.net  Fri Jan  9 18:06:00 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 09 Jan 2009 12:06:00 -0500
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <87wsd4774d.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov>
	<87sknu2ozf.fsf@mocca.josefsson.org>	<49663944.6030708@anl.gov>
	<87k594g5uv.fsf@mocca.josefsson.org>	<87bpugg4xg.fsf@mocca.josefsson.org>
	<49677E15.6030702@anl.gov> <87wsd4774d.fsf@mocca.josefsson.org>
Message-ID: <496783F8.6050601@fifthhorseman.net>

On 01/09/2009 11:54 AM, Simon Josefsson wrote:
> "Douglas E. Engert" <deengert at anl.gov> writes:
>> Also should line 444 be |= rather the ^= ?
> 
> That code is meant to _remove_ the GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
> flag from the flags parameter, unless
> GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT is set.

But ^= is bitwise xor, which *flips* the relevant bit, rather than
removing it.  I think we want something like this, no?

diff --git a/lib/x509/verify.c b/lib/x509/verify.c
index c00b4bf..6ad4495 100644
--- a/lib/x509/verify.c
+++ b/lib/x509/verify.c
@@ -442,7 +442,7 @@ _gnutls_x509_verify_certificate (const
gnutls_x509_crt_t * certificate_list,
        * certificates can exist in a supplied chain.
        */
       if (!(flags & GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT))
-	flags ^= GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT;
+	flags &= ~GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT;
       if ((ret =
 	   _gnutls_verify_certificate2 (certificate_list[i - 1],
 					&certificate_list[i], 1, flags,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090109/06fbcf9d/attachment.pgp>

From deengert at anl.gov  Fri Jan  9 18:59:47 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Fri, 09 Jan 2009 11:59:47 -0600
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <87wsd4774d.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov>
	<87sknu2ozf.fsf@mocca.josefsson.org>	<49663944.6030708@anl.gov>
	<87k594g5uv.fsf@mocca.josefsson.org>	<87bpugg4xg.fsf@mocca.josefsson.org>
	<49677E15.6030702@anl.gov> <87wsd4774d.fsf@mocca.josefsson.org>
Message-ID: <49679093.3070509@anl.gov>


Simon Josefsson wrote:

> 
> The default is to reject V1 CA's, so the application need to supply
> either flag if they want a particular behaviour.
> 
> By default, gnutls_x509_crt_list_verify rejects V1 CAs, but it takes a
> flags parameter.  If you call the verification through
> gnutls_session_verify_peers, you can use the
> gnutls_certificate_set_verify_flags function to set the flags to use
> (like cli.c does).

That will be a problem, as the application is ldap used by nss-ldap.
I have not looked at how they call gnutls, but we don't want to have to
changes these too.

One could argue the application already provides the list of CA certs
it is willing to trust, so why does it need to provide an additional flag?

If the code change on you TODO list to stop when an intermediate CA cert
is found on the trusted CA list, then this would solve my problem,
as the intermediate cert is V3 and has CA:TRUE, and is trusted.


-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444




From simon at josefsson.org  Sat Jan 10 13:05:05 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 10 Jan 2009 13:05:05 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <49679093.3070509@anl.gov> (Douglas E. Engert's message of "Fri, 
	09 Jan 2009 11:59:47 -0600")
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org> <49677E15.6030702@anl.gov>
	<87wsd4774d.fsf@mocca.josefsson.org> <49679093.3070509@anl.gov>
Message-ID: <87tz87gydq.fsf@mocca.josefsson.org>

"Douglas E. Engert" <deengert at anl.gov> writes:

> Simon Josefsson wrote:
>
>>
>> The default is to reject V1 CA's, so the application need to supply
>> either flag if they want a particular behaviour.
>>
>> By default, gnutls_x509_crt_list_verify rejects V1 CAs, but it takes a
>> flags parameter.  If you call the verification through
>> gnutls_session_verify_peers, you can use the
>> gnutls_certificate_set_verify_flags function to set the flags to use
>> (like cli.c does).
>
> That will be a problem, as the application is ldap used by nss-ldap.
> I have not looked at how they call gnutls, but we don't want to have to
> changes these too.
>
> One could argue the application already provides the list of CA certs
> it is willing to trust, so why does it need to provide an additional flag?

I believe it would break ABI/API compatibility to change this now --
applications assume that V1 CA are rejected since that has been the
documented behaviour for several years.

It seems like a bug in the ldap/nss-ldap code that it doesn't pass the
V1 flag if it really wants GnuTLS to permit V1 CA's.

Nikos, what do you think?  You wrote the code here, and introduced the
work-around flags to deal with V1 certs.

For things that aren't documented, I think we can be pragmatic and come
up with quick fixes and apply them to the v2.6.x branch as needed.  But
anything that changes documented and intended behaviour is not
appropriate for our stable branch IMHO.

> If the code change on you TODO list to stop when an intermediate CA cert
> is found on the trusted CA list, then this would solve my problem,
> as the intermediate cert is V3 and has CA:TRUE, and is trusted.

Yup.  Fixing that would be neat, and could go onto the v2.7.x branch
which we could release as the next stable branch relatively quickly.

/Simon




From simon at josefsson.org  Sat Jan 10 13:11:10 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 10 Jan 2009 13:11:10 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <496783F8.6050601@fifthhorseman.net> (Daniel Kahn Gillmor's
	message of "Fri, 09 Jan 2009 12:06:00 -0500")
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org> <49677E15.6030702@anl.gov>
	<87wsd4774d.fsf@mocca.josefsson.org>
	<496783F8.6050601@fifthhorseman.net>
Message-ID: <87mydzgy3l.fsf@mocca.josefsson.org>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> On 01/09/2009 11:54 AM, Simon Josefsson wrote:
>> "Douglas E. Engert" <deengert at anl.gov> writes:
>>> Also should line 444 be |= rather the ^= ?
>> 
>> That code is meant to _remove_ the GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
>> flag from the flags parameter, unless
>> GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT is set.
>
> But ^= is bitwise xor, which *flips* the relevant bit, rather than
> removing it.  I think we want something like this, no?

Indeed.  It would be nice if we could come up with a X.509 chain and
necessary flags that arguable trigger incorrect behaviour with the
current code before changing this though.  That could go into the
chainverify.c self-test.

Hm.  I'm not sure the code results in incorrect behaviour though -- the
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT flag only matters for root certs, but
those aren't touched by this code anyway, are they?  They are removed
earlier in the same function.  However, maybe the function searches for
the root cert and finds it through some other mechanism...

Anyway, coming up with an example that triggers incorrect behaviour
would be the best here, and would give more confidence in the patch.
Could you try and create such an example?

/Simon

> diff --git a/lib/x509/verify.c b/lib/x509/verify.c
> index c00b4bf..6ad4495 100644
> --- a/lib/x509/verify.c
> +++ b/lib/x509/verify.c
> @@ -442,7 +442,7 @@ _gnutls_x509_verify_certificate (const
> gnutls_x509_crt_t * certificate_list,
>         * certificates can exist in a supplied chain.
>         */
>        if (!(flags & GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT))
> -	flags ^= GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT;
> +	flags &= ~GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT;
>        if ((ret =
>  	   _gnutls_verify_certificate2 (certificate_list[i - 1],
>  					&certificate_list[i], 1, flags,
>
> 	--dkg
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/gnutls-devel




From n.mavrogiannopoulos at gmail.com  Sat Jan 10 14:56:32 2009
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sat, 10 Jan 2009 15:56:32 +0200
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <87tz87gydq.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org> <49677E15.6030702@anl.gov>
	<87wsd4774d.fsf@mocca.josefsson.org> <49679093.3070509@anl.gov>
	<87tz87gydq.fsf@mocca.josefsson.org>
Message-ID: <20090110155632.10ba0626@nmav-eee>

On Sat, 10 Jan 2009 13:05:05 +0100

> Nikos, what do you think?  You wrote the code here, and introduced the
> work-around flags to deal with V1 certs.

X.509 v1 certificates are quite dangerous to use and should be avoided
because of the inherited issues with them (a V1 CA certificate cannot be
distinguished from a V1 server certificate or a V1 person certificate,
thus if one has a V1 server certificate in his trusted certificate list
wouldn't want to trust it as a CA as well).

For these reasons V1, certificates are not trusted to be signers by
default unless the following two flags are set:

1. GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT

This one allows a v1 certificate from the trusted list to be valid as
a CA (here one must know that he should not add V1 server certificates
in his trusted list).

2. GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT

This one is quite dangerous. It allows any intermediate V1 certificate
to be used as a signer. This means that if I manage to get a CA to give
me a V1 personal certificate, I can act as a CA if this flag is set.


> For things that aren't documented, I think we can be pragmatic and
> come up with quick fixes and apply them to the v2.6.x branch as
> needed.  But anything that changes documented and intended behaviour
> is not appropriate for our stable branch IMHO.

I didn't follow the issue closely, but I'd be against any change of the
V1 certificate handling unless there is a good reason to do so. V1
certificates should not be used any more.

> > If the code change on you TODO list to stop when an intermediate CA
> > cert is found on the trusted CA list, then this would solve my
> > problem, as the intermediate cert is V3 and has CA:TRUE, and is
> > trusted.
> Yup.  Fixing that would be neat, and could go onto the v2.7.x branch
> which we could release as the next stable branch relatively quickly.

About releasing 2.7, I think we should wait for the TLS 1.2 support to be completed or
remove it from the supported list.

regards,
Nikos




From simon at josefsson.org  Sun Jan 11 15:03:12 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 11 Jan 2009 15:03:12 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <20090110155632.10ba0626@nmav-eee> (Nikos Mavrogiannopoulos's
	message of "Sat, 10 Jan 2009 15:56:32 +0200")
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org> <49677E15.6030702@anl.gov>
	<87wsd4774d.fsf@mocca.josefsson.org> <49679093.3070509@anl.gov>
	<87tz87gydq.fsf@mocca.josefsson.org>
	<20090110155632.10ba0626@nmav-eee>
Message-ID: <87fxjqj5y7.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> writes:

> On Sat, 10 Jan 2009 13:05:05 +0100
>
>> Nikos, what do you think?  You wrote the code here, and introduced the
>> work-around flags to deal with V1 certs.
>
> X.509 v1 certificates are quite dangerous to use and should be avoided
> because of the inherited issues with them (a V1 CA certificate cannot be
> distinguished from a V1 server certificate or a V1 person certificate,
> thus if one has a V1 server certificate in his trusted certificate list
> wouldn't want to trust it as a CA as well).
>
> For these reasons V1, certificates are not trusted to be signers by
> default unless the following two flags are set:
>
> 1. GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
>
> This one allows a v1 certificate from the trusted list to be valid as
> a CA (here one must know that he should not add V1 server certificates
> in his trusted list).
>
> 2. GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT
>
> This one is quite dangerous. It allows any intermediate V1 certificate
> to be used as a signer. This means that if I manage to get a CA to give
> me a V1 personal certificate, I can act as a CA if this flag is set.

Good points.

>> For things that aren't documented, I think we can be pragmatic and
>> come up with quick fixes and apply them to the v2.6.x branch as
>> needed.  But anything that changes documented and intended behaviour
>> is not appropriate for our stable branch IMHO.
>
> I didn't follow the issue closely, but I'd be against any change of the
> V1 certificate handling unless there is a good reason to do so. V1
> certificates should not be used any more.

I agree fully.

I believe the proper fix in this situation is to patch GnuTLS as
suggested, and fix the applications to use the
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT parameter when verifying chains using
GnuTLS.  Douglas, if you can confirm that this solves your problem, we
can release a new stable 2.6.x with the fix relatively quickly.

>> > If the code change on you TODO list to stop when an intermediate CA
>> > cert is found on the trusted CA list, then this would solve my
>> > problem, as the intermediate cert is V3 and has CA:TRUE, and is
>> > trusted.
>> Yup.  Fixing that would be neat, and could go onto the v2.7.x branch
>> which we could release as the next stable branch relatively quickly.
>
> About releasing 2.7, I think we should wait for the TLS 1.2 support to
> be completed or remove it from the supported list.

I agree.

/Simon




From deengert at anl.gov  Mon Jan 12 16:37:10 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 12 Jan 2009 09:37:10 -0600
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <87tz87gydq.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov>
	<87sknu2ozf.fsf@mocca.josefsson.org>	<49663944.6030708@anl.gov>
	<87k594g5uv.fsf@mocca.josefsson.org>	<87bpugg4xg.fsf@mocca.josefsson.org>
	<49677E15.6030702@anl.gov>	<87wsd4774d.fsf@mocca.josefsson.org>
	<49679093.3070509@anl.gov> <87tz87gydq.fsf@mocca.josefsson.org>
Message-ID: <496B63A6.4090804@anl.gov>



Simon Josefsson wrote:
> "Douglas E. Engert" <deengert at anl.gov> writes:
> 
>> Simon Josefsson wrote:
>>
>>> The default is to reject V1 CA's, so the application need to supply
>>> either flag if they want a particular behaviour.
>>>
>>> By default, gnutls_x509_crt_list_verify rejects V1 CAs, but it takes a
>>> flags parameter.  If you call the verification through
>>> gnutls_session_verify_peers, you can use the
>>> gnutls_certificate_set_verify_flags function to set the flags to use
>>> (like cli.c does).
>> That will be a problem, as the application is ldap used by nss-ldap.
>> I have not looked at how they call gnutls, but we don't want to have to
>> changes these too.
>>
>> One could argue the application already provides the list of CA certs
>> it is willing to trust, so why does it need to provide an additional flag?
> 
> I believe it would break ABI/API compatibility to change this now --
> applications assume that V1 CA are rejected since that has been the
> documented behaviour for several years.
> 
> It seems like a bug in the ldap/nss-ldap code that it doesn't pass the
> V1 flag if it really wants GnuTLS to permit V1 CA's.

Its not the application that wants it. As far as I can tell previous versions
of ldap using OpenLDAP do not have the problem, and only after Ubuntu
back ported the December fixes did this problem start occuring.

I understand that you don't want to change your code.

> 
> Nikos, what do you think?  You wrote the code here, and introduced the
> work-around flags to deal with V1 certs.
> 

Also, as Daniel Kahn Gillmor pointed out, to clear the bit
needs this change:

    > -	flags ^= GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT;
    > +	flags &= ~GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT;

But this would not solve the problem either.


> For things that aren't documented, I think we can be pragmatic and come
> up with quick fixes and apply them to the v2.6.x branch as needed.  But
> anything that changes documented and intended behaviour is not
> appropriate for our stable branch IMHO.
> 
>> If the code change on you TODO list to stop when an intermediate CA cert
>> is found on the trusted CA list, then this would solve my problem,
>> as the intermediate cert is V3 and has CA:TRUE, and is trusted.
> 
> Yup.  Fixing that would be neat, and could go onto the v2.7.x branch
> which we could release as the next stable branch relatively quickly.

Actually I wrote a mod on this Friday, to do this. I need to clean it
up today and send it in for your review.

The CA in question is a Verisign cert used to sign an intermediate cert:
http://www.verisign.com/support/verisign-intermediate-ca/secure-site-intermediate/index.html
So trusting this intermediate V3 cert would work for us.

> 
> /Simon
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444




From simon at josefsson.org  Mon Jan 12 16:50:09 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 12 Jan 2009 16:50:09 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <496B63A6.4090804@anl.gov> (Douglas E. Engert's message of "Mon, 
	12 Jan 2009 09:37:10 -0600")
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org> <49677E15.6030702@anl.gov>
	<87wsd4774d.fsf@mocca.josefsson.org> <49679093.3070509@anl.gov>
	<87tz87gydq.fsf@mocca.josefsson.org> <496B63A6.4090804@anl.gov>
Message-ID: <871vv8mslq.fsf@mocca.josefsson.org>

"Douglas E. Engert" <deengert at anl.gov> writes:

> Simon Josefsson wrote:
>> "Douglas E. Engert" <deengert at anl.gov> writes:
>>
>>> Simon Josefsson wrote:
>>>
>>>> The default is to reject V1 CA's, so the application need to supply
>>>> either flag if they want a particular behaviour.
>>>>
>>>> By default, gnutls_x509_crt_list_verify rejects V1 CAs, but it takes a
>>>> flags parameter.  If you call the verification through
>>>> gnutls_session_verify_peers, you can use the
>>>> gnutls_certificate_set_verify_flags function to set the flags to use
>>>> (like cli.c does).
>>> That will be a problem, as the application is ldap used by nss-ldap.
>>> I have not looked at how they call gnutls, but we don't want to have to
>>> changes these too.
>>>
>>> One could argue the application already provides the list of CA certs
>>> it is willing to trust, so why does it need to provide an additional flag?
>>
>> I believe it would break ABI/API compatibility to change this now --
>> applications assume that V1 CA are rejected since that has been the
>> documented behaviour for several years.
>>
>> It seems like a bug in the ldap/nss-ldap code that it doesn't pass the
>> V1 flag if it really wants GnuTLS to permit V1 CA's.
>
> Its not the application that wants it. As far as I can tell previous
> versions of ldap using OpenLDAP do not have the problem, and only
> after Ubuntu back ported the December fixes did this problem start
> occuring.

The December fixes solved a security problem where some CA certificates
were simply ignored by the validation code, so maybe it only worked by
accident before.

> I understand that you don't want to change your code.

I don't see anything wrong with the code -- with the patch installed on
gnutls 2.6.x, it should behave as per the documentation.

>> For things that aren't documented, I think we can be pragmatic and come
>> up with quick fixes and apply them to the v2.6.x branch as needed.  But
>> anything that changes documented and intended behaviour is not
>> appropriate for our stable branch IMHO.
>>
>>> If the code change on you TODO list to stop when an intermediate CA cert
>>> is found on the trusted CA list, then this would solve my problem,
>>> as the intermediate cert is V3 and has CA:TRUE, and is trusted.
>>
>> Yup.  Fixing that would be neat, and could go onto the v2.7.x branch
>> which we could release as the next stable branch relatively quickly.
>
> Actually I wrote a mod on this Friday, to do this. I need to clean it
> up today and send it in for your review.
>
> The CA in question is a Verisign cert used to sign an intermediate cert:
> http://www.verisign.com/support/verisign-intermediate-ca/secure-site-intermediate/index.html
> So trusting this intermediate V3 cert would work for us.

Thanks!  Several people have asked about this feature, solving it would
be useful.

If the patch is over 10 lines long we will need a copyright assignment
before we can apply it though.  If you want to speed up the process, you
could fill out the form below now.

/Simon

Please email the following information to assign at gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]


[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your postal address here.]





[Which files have you changed so far, and which new files have you written
so far?]




From deengert at anl.gov  Mon Jan 12 17:00:08 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 12 Jan 2009 10:00:08 -0600
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <87fxjqj5y7.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov>
	<87sknu2ozf.fsf@mocca.josefsson.org>	<49663944.6030708@anl.gov>
	<87k594g5uv.fsf@mocca.josefsson.org>	<87bpugg4xg.fsf@mocca.josefsson.org>
	<49677E15.6030702@anl.gov>	<87wsd4774d.fsf@mocca.josefsson.org>
	<49679093.3070509@anl.gov>	<87tz87gydq.fsf@mocca.josefsson.org>	<20090110155632.10ba0626@nmav-eee>
	<87fxjqj5y7.fsf@mocca.josefsson.org>
Message-ID: <496B6908.9090103@anl.gov>

For all the reasons sighted, I agree that V1 certs should not be trusted,
and in our case its a Verisign cert used to sign intermediate certs.
The current code also needs to be fixed, but
stopping at the first trusted cert in the chain might be the best solution
(for us at least) and then get Ubuntu to backport that change, rather
then having to get them to modify OpenLDAP and potentially opening up the
V1 hole you are trying to close.

A goal is to use the vendor's (Ubuntu) code if at all possible as we run
this on many production machines.

Simon Josefsson wrote:
> Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> writes:
> 
>> On Sat, 10 Jan 2009 13:05:05 +0100
>>
>>> Nikos, what do you think?  You wrote the code here, and introduced the
>>> work-around flags to deal with V1 certs.
>> X.509 v1 certificates are quite dangerous to use and should be avoided
>> because of the inherited issues with them (a V1 CA certificate cannot be
>> distinguished from a V1 server certificate or a V1 person certificate,
>> thus if one has a V1 server certificate in his trusted certificate list
>> wouldn't want to trust it as a CA as well).
>>
>> For these reasons V1, certificates are not trusted to be signers by
>> default unless the following two flags are set:
>>
>> 1. GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
>>
>> This one allows a v1 certificate from the trusted list to be valid as
>> a CA (here one must know that he should not add V1 server certificates
>> in his trusted list).
>>
>> 2. GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT
>>
>> This one is quite dangerous. It allows any intermediate V1 certificate
>> to be used as a signer. This means that if I manage to get a CA to give
>> me a V1 personal certificate, I can act as a CA if this flag is set.
> 
> Good points.
> 
>>> For things that aren't documented, I think we can be pragmatic and
>>> come up with quick fixes and apply them to the v2.6.x branch as
>>> needed.  But anything that changes documented and intended behaviour
>>> is not appropriate for our stable branch IMHO.
>> I didn't follow the issue closely, but I'd be against any change of the
>> V1 certificate handling unless there is a good reason to do so. V1
>> certificates should not be used any more.
> 
> I agree fully.
> 
> I believe the proper fix in this situation is to patch GnuTLS as
> suggested, and fix the applications to use the
> GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT parameter when verifying chains using
> GnuTLS.  Douglas, if you can confirm that this solves your problem, we
> can release a new stable 2.6.x with the fix relatively quickly.
> 
>>>> If the code change on you TODO list to stop when an intermediate CA
>>>> cert is found on the trusted CA list, then this would solve my
>>>> problem, as the intermediate cert is V3 and has CA:TRUE, and is
>>>> trusted.
>>> Yup.  Fixing that would be neat, and could go onto the v2.7.x branch
>>> which we could release as the next stable branch relatively quickly.
>> About releasing 2.7, I think we should wait for the TLS 1.2 support to
>> be completed or remove it from the supported list.
> 
> I agree.
> 
> /Simon
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444




From deengert at anl.gov  Mon Jan 12 17:09:41 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 12 Jan 2009 10:09:41 -0600
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <871vv8mslq.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov>
	<87sknu2ozf.fsf@mocca.josefsson.org>	<49663944.6030708@anl.gov>
	<87k594g5uv.fsf@mocca.josefsson.org>	<87bpugg4xg.fsf@mocca.josefsson.org>
	<49677E15.6030702@anl.gov>	<87wsd4774d.fsf@mocca.josefsson.org>
	<49679093.3070509@anl.gov>	<87tz87gydq.fsf@mocca.josefsson.org>
	<496B63A6.4090804@anl.gov> <871vv8mslq.fsf@mocca.josefsson.org>
Message-ID: <496B6B45.6000505@anl.gov>

OK, see form below.


Simon Josefsson wrote:
> "Douglas E. Engert" <deengert at anl.gov> writes:
> 
>> Simon Josefsson wrote:
>>> "Douglas E. Engert" <deengert at anl.gov> writes:
>>>
>>>> Simon Josefsson wrote:
>>>>
>>>>> The default is to reject V1 CA's, so the application need to supply
>>>>> either flag if they want a particular behaviour.
>>>>>
>>>>> By default, gnutls_x509_crt_list_verify rejects V1 CAs, but it takes a
>>>>> flags parameter.  If you call the verification through
>>>>> gnutls_session_verify_peers, you can use the
>>>>> gnutls_certificate_set_verify_flags function to set the flags to use
>>>>> (like cli.c does).
>>>> That will be a problem, as the application is ldap used by nss-ldap.
>>>> I have not looked at how they call gnutls, but we don't want to have to
>>>> changes these too.
>>>>
>>>> One could argue the application already provides the list of CA certs
>>>> it is willing to trust, so why does it need to provide an additional flag?
>>> I believe it would break ABI/API compatibility to change this now --
>>> applications assume that V1 CA are rejected since that has been the
>>> documented behaviour for several years.
>>>
>>> It seems like a bug in the ldap/nss-ldap code that it doesn't pass the
>>> V1 flag if it really wants GnuTLS to permit V1 CA's.
>> Its not the application that wants it. As far as I can tell previous
>> versions of ldap using OpenLDAP do not have the problem, and only
>> after Ubuntu back ported the December fixes did this problem start
>> occuring.
> 
> The December fixes solved a security problem where some CA certificates
> were simply ignored by the validation code, so maybe it only worked by
> accident before.
> 
>> I understand that you don't want to change your code.
> 
> I don't see anything wrong with the code -- with the patch installed on
> gnutls 2.6.x, it should behave as per the documentation.
> 
>>> For things that aren't documented, I think we can be pragmatic and come
>>> up with quick fixes and apply them to the v2.6.x branch as needed.  But
>>> anything that changes documented and intended behaviour is not
>>> appropriate for our stable branch IMHO.
>>>
>>>> If the code change on you TODO list to stop when an intermediate CA cert
>>>> is found on the trusted CA list, then this would solve my problem,
>>>> as the intermediate cert is V3 and has CA:TRUE, and is trusted.
>>> Yup.  Fixing that would be neat, and could go onto the v2.7.x branch
>>> which we could release as the next stable branch relatively quickly.
>> Actually I wrote a mod on this Friday, to do this. I need to clean it
>> up today and send it in for your review.
>>
>> The CA in question is a Verisign cert used to sign an intermediate cert:
>> http://www.verisign.com/support/verisign-intermediate-ca/secure-site-intermediate/index.html
>> So trusting this intermediate V3 cert would work for us.
> 
> Thanks!  Several people have asked about this feature, solving it would
> be useful.
> 
> If the patch is over 10 lines long we will need a copyright assignment
> before we can apply it though.  If you want to speed up the process, you
> could fill out the form below now.
> 
> /Simon
> 
> Please email the following information to assign at gnu.org, and we
> will send you the assignment form for your past and future changes.
> 
> Please use your full legal name (in ASCII characters) as the subject
> line of the message.
> ----------------------------------------------------------------------
> REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES
> 
> [What is the name of the program or package you're contributing to?]

GnuTLS
> 
> 
> [Did you copy any files or text written by someone else in these changes?
> Even if that material is free software, we need to know about it.]

No.

> 
> 
> [Do you have an employer who might have a basis to claim to own
> your changes?  Do you attend a school which might make such a claim?]

No. No.

> 
> 
> [For the copyright registration, what country are you a citizen of?]

U.S.

> 
> 
> [What year were you born?]

1946
> 
> 
> [Please write your email address here.]

deengert at anl.gov
> 
> 
> [Please write your postal address here.]

  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
> 
> 
> 
> 
> 
> [Which files have you changed so far, and which new files have you written
> so far?]

Changed: src/lib/x509/verify.c


> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444




From simon at josefsson.org  Mon Jan 12 17:11:39 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 12 Jan 2009 17:11:39 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <496B6B45.6000505@anl.gov> (Douglas E. Engert's message of "Mon, 
	12 Jan 2009 10:09:41 -0600")
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org> <49677E15.6030702@anl.gov>
	<87wsd4774d.fsf@mocca.josefsson.org> <49679093.3070509@anl.gov>
	<87tz87gydq.fsf@mocca.josefsson.org> <496B63A6.4090804@anl.gov>
	<871vv8mslq.fsf@mocca.josefsson.org> <496B6B45.6000505@anl.gov>
Message-ID: <87tz84sdvo.fsf@mocca.josefsson.org>

"Douglas E. Engert" <deengert at anl.gov> writes:

> OK, see form below.

You need to send it to assign at gnu.org, I could forward it but I think
they want it directly from the submitter.

Sorry for the hassle, and thanks again,
/Simon




From deengert at anl.gov  Mon Jan 12 21:09:49 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 12 Jan 2009 14:09:49 -0600
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <87tz84sdvo.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov>
	<87sknu2ozf.fsf@mocca.josefsson.org>	<49663944.6030708@anl.gov>
	<87k594g5uv.fsf@mocca.josefsson.org>	<87bpugg4xg.fsf@mocca.josefsson.org>
	<49677E15.6030702@anl.gov>	<87wsd4774d.fsf@mocca.josefsson.org>
	<49679093.3070509@anl.gov>	<87tz87gydq.fsf@mocca.josefsson.org>
	<496B63A6.4090804@anl.gov>	<871vv8mslq.fsf@mocca.josefsson.org>
	<496B6B45.6000505@anl.gov> <87tz84sdvo.fsf@mocca.josefsson.org>
Message-ID: <496BA38D.90104@anl.gov>



Simon Josefsson wrote:
> "Douglas E. Engert" <deengert at anl.gov> writes:
> 
>> OK, see form below.
> 
> You need to send it to assign at gnu.org, I could forward it but I think
> they want it directly from the submitter.

OK, sent the form, first time was wrong address.

If you were to create a check_if_same_cert routine the actual code
to shorten the cert chain is only 7 lines, not counting
comments, "{" or "}" lines.

Here is a verify.c patch (Against Ubuntu version) that does the following:

added routine check_if_same_cert() to test if two certs are identical,
using the method used in check_if_ca.
(Note: check_if_ca could call check_if_same_cert too, but it made
the patch file hard to read.)

Adds this code:

+    /* We want to shorten the chain by removing the cert that matches
+     * one of the certs we trust and all the certs after that
+     * i.e. if cert chain is A, B, C, and we trust B, remove B and C
+     * we must leave the first cert on chain. */
+    if (clist_size > 1)
+    {
+      for (i = 1; i < clist_size; i++)
+      {
+        int j;
+	    for (j = 0; j < tcas_size; j++)
+        {
+          if (check_if_same_cert ( certificate_list[i], trusted_cas[j], flags) == 1)
+          {
+              clist_size = i;
+              break;
+          }
+        }
+        /* clist_size may have been changed which gets out of loop */
+      }
+    }
+


Add the recent patches to get the if corrected, and added the patch
for  flags &= ~GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT;

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: verify.c.patch2.txt
URL: </pipermail/attachments/20090112/a69913a1/attachment.txt>

From stefan.janssen at uni-bielefeld.de  Tue Jan 13 16:04:06 2009
From: stefan.janssen at uni-bielefeld.de (Stefan Janssen)
Date: Tue, 13 Jan 2009 16:04:06 +0100
Subject: bug in src/shared.c
Message-ID: <496CAD66.6060600@uni-bielefeld.de>

Hi,

I tried to compile gnuTLS on my Solaris SunOS 5.10 i386 machine. Make 
crashed, because in the file src/shared.c in line 727 the symbol 
HUGE_VAL is used twice. After I added Parentesis behind HUGE_VAL 
everything compiled fine. Maybe you could change this line in your 
source from

            if (double_val == +HUGE_VAL || double_val == -HUGE_VAL)

to

            if (double_val == +HUGE_VAL() || double_val == -HUGE_VAL())


Best regards,
Stefan




From simon at josefsson.org  Tue Jan 13 17:40:40 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 13 Jan 2009 17:40:40 +0100
Subject: bug in src/shared.c
In-Reply-To: <496CAD66.6060600@uni-bielefeld.de> (Stefan Janssen's message of
	"Tue, 13 Jan 2009 16:04:06 +0100")
References: <496CAD66.6060600@uni-bielefeld.de>
Message-ID: <87zlhvma5z.fsf@mocca.josefsson.org>

Stefan Janssen <stefan.janssen at uni-bielefeld.de> writes:

> Hi,
>
> I tried to compile gnuTLS on my Solaris SunOS 5.10 i386 machine. Make
> crashed, because in the file src/shared.c in line 727 the symbol
> HUGE_VAL is used twice. After I added Parentesis behind HUGE_VAL
> everything compiled fine. Maybe you could change this line in your
> source from
>
>            if (double_val == +HUGE_VAL || double_val == -HUGE_VAL)
>
> to
>
>            if (double_val == +HUGE_VAL() || double_val == -HUGE_VAL())

Hi.  Thanks for the report.  Which gcc version do you use?  We've seen
this before, and then it was a gcc bug:

http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2495/focus=2933
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933

Changing the code the way you proposed will break on many platforms, so
it is not an option:

cfg/shared.c:727: error: called object ?+Inf? is not a function

Does either of the suggested fix in the thread above solve the problem
for you?

/Simon




From simon at josefsson.org  Tue Jan 13 18:04:09 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 13 Jan 2009 18:04:09 +0100
Subject: bug in src/shared.c
In-Reply-To: <496CC894.3010701@uni-bielefeld.de> (Stefan Janssen's message of
	"Tue, 13 Jan 2009 18:00:04 +0100")
References: <496CAD66.6060600@uni-bielefeld.de>
	<87zlhvma5z.fsf@mocca.josefsson.org>
	<496CC894.3010701@uni-bielefeld.de>
Message-ID: <87vdsjm92u.fsf@mocca.josefsson.org>

Stefan Janssen <stefan.janssen at uni-bielefeld.de> writes:

> Simon Josefsson wrote:
>> Stefan Janssen <stefan.janssen at uni-bielefeld.de> writes:
>>
>>   
>>> Hi,
>>>
>>> I tried to compile gnuTLS on my Solaris SunOS 5.10 i386 machine. Make
>>> crashed, because in the file src/shared.c in line 727 the symbol
>>> HUGE_VAL is used twice. After I added Parentesis behind HUGE_VAL
>>> everything compiled fine. Maybe you could change this line in your
>>> source from
>>>
>>>            if (double_val == +HUGE_VAL || double_val == -HUGE_VAL)
>>>
>>> to
>>>
>>>            if (double_val == +HUGE_VAL() || double_val == -HUGE_VAL())
>>>     
>>
>> Hi.  Thanks for the report.  Which gcc version do you use?  We've seen
>> this before, and then it was a gcc bug:
>>   
> $> gcc --version
> gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
> Copyright (C) 2004 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.

Then you'll need the patch in:

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02123.html

Or just upgrade to a more recent gcc.

>> http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2495/focus=2933
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
>>
>> Changing the code the way you proposed will break on many platforms, so
>> it is not an option:
>>
>> cfg/shared.c:727: error: called object ?+Inf? is not a function
>>
>> Does either of the suggested fix in the thread above solve the problem
>> for you?
>>   
> The trick with with the redefinition #define HUGE_VAL
> (__builtin_huge_val()) seems to work, but it produces the following
> warnings:
>
> $> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes
> -I../includes -I../lgl -I../lgl -I../gl -I../gl -I./cfg
> -I/vol/pi/include -I/opt/csw/include -I/usr/sfw/include
> -I/usr/X11/include -I/vol/pi/include -g -O2 -MT shared.o -MD -MP -MF
> .deps/shared.Tpo -c -o 
> shared.o `test -f 'cfg/shared.c' || echo './'`cfg/shared.c
>
> cfg/shared.c:61:1: warning: "HUGE_VAL" redefined
> In file included from
> /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/include/math.h:27,
>                 from cfg/shared.c:43:
> /usr/include/iso/math_c99.h:27:1: warning: this is the location of the
> previous definition
>
>
> If I remove the -std=gnu99 flag, but don't change the code, everything
> seems to work fine: (I don't get any respond on STDERR or STDOUT)
>
> $> gcc -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes -I../lgl
> -I../lgl -I../gl -I../gl -I./cfg -I/vol/pi/include -I/opt/csw/include
> -I/usr/sfw/include -I/usr/X11/include -I/vol/pi/include -g -O2 -MT
> shared.o -MD -MP -MF .deps/shared.Tpo -c -o shared.o `test -f 
> 'cfg/shared.c' || echo './'`cfg/shared.c

Thanks for testing, hopefully having this in the mailing list archive
will help others running into the same problem.

/Simon




From deengert at anl.gov  Wed Jan 14 18:04:02 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Wed, 14 Jan 2009 11:04:02 -0600
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <871vv8mslq.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov>
	<87sknu2ozf.fsf@mocca.josefsson.org>	<49663944.6030708@anl.gov>
	<87k594g5uv.fsf@mocca.josefsson.org>	<87bpugg4xg.fsf@mocca.josefsson.org>
	<49677E15.6030702@anl.gov>	<87wsd4774d.fsf@mocca.josefsson.org>
	<49679093.3070509@anl.gov>	<87tz87gydq.fsf@mocca.josefsson.org>
	<496B63A6.4090804@anl.gov> <871vv8mslq.fsf@mocca.josefsson.org>
Message-ID: <496E1B02.7010507@anl.gov>



Simon Josefsson wrote:
> 
> If the patch is over 10 lines long we will need a copyright assignment
> before we can apply it though.  If you want to speed up the process, you
> could fill out the form below now.
> 

I sent in the form to assign at gnu.org. They are sending a paper copy
which must be signed and mailed back. This may be a problem, as I will
have to get it OK'ed, which might take weeks.

So here is the short version of a "shorten the cert chain" patch that
is only 10 lines long. Do with it what you want. As this fixes
our problem, I consider it a bug fix.

But you will need to add a check_if_same_cert routine, which can be
taken from the first half of the check_if_ca routine. The line numbers
may be off, but in the 2.6.3 version, it would be inserted at line 394.

This will also solve our problem, as V1 cert will not get used at all
ans the intermediate cert is trusted and is V3.

Thanks.

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: shorten.chain.small.patch.txt
URL: </pipermail/attachments/20090114/2f79c9da/attachment.txt>

From dam at opencsw.org  Thu Jan 15 17:04:23 2009
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 15 Jan 2009 17:04:23 +0100
Subject: Tiny patch for missing stdint.h
Message-ID: <DC1F046B-97B4-4322-924A-FCCE8C7016D2@opencsw.org>

Hi,

I am compiling libtasn1 1.7 for Solaris 8 and found that a tiny
patch is needed to prevent including the missing (and correctly
my configure detected) stdint.h:

diff -Naur libtasn1-1.7.orig/lib/int.h libtasn1-1.7.patched/lib/int.h
--- libtasn1-1.7.orig/lib/int.h 2008-11-17 11:06:37.000000000 +0100
+++ libtasn1-1.7.patched/lib/int.h      2009-01-15 16:58:59.147771102  
+0100
@@ -31,7 +31,9 @@
  #include <stdlib.h>
  #include <stdio.h>
  #include <ctype.h>
+#ifdef HAVE_STDINT_H
  #include <stdint.h>
+#endif

  #ifdef HAVE_SYS_TYPES_H
  # include <sys/types.h>


Please include the patch at your convenience.


Best regards

   -- Dago




From simon at josefsson.org  Thu Jan 15 18:28:30 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 15 Jan 2009 18:28:30 +0100
Subject: Tiny patch for missing stdint.h
In-Reply-To: <DC1F046B-97B4-4322-924A-FCCE8C7016D2@opencsw.org> (Dagobert
	Michelsen's message of "Thu, 15 Jan 2009 17:04:23 +0100")
References: <DC1F046B-97B4-4322-924A-FCCE8C7016D2@opencsw.org>
Message-ID: <878wpcfphd.fsf@mocca.josefsson.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi,
>
> I am compiling libtasn1 1.7 for Solaris 8 and found that a tiny
> patch is needed to prevent including the missing (and correctly
> my configure detected) stdint.h:

Configure should make sure a stdint.h is generated in gl/.  Isn't this
the case for you?

/Simon

> diff -Naur libtasn1-1.7.orig/lib/int.h libtasn1-1.7.patched/lib/int.h
> --- libtasn1-1.7.orig/lib/int.h 2008-11-17 11:06:37.000000000 +0100
> +++ libtasn1-1.7.patched/lib/int.h      2009-01-15 16:58:59.147771102
> +0100
> @@ -31,7 +31,9 @@
>  #include <stdlib.h>
>  #include <stdio.h>
>  #include <ctype.h>
> +#ifdef HAVE_STDINT_H
>  #include <stdint.h>
> +#endif
>
>  #ifdef HAVE_SYS_TYPES_H
>  # include <sys/types.h>
>
>
> Please include the patch at your convenience.
>
>
> Best regards
>
>   -- Dago




From simon at josefsson.org  Fri Jan 16 12:42:53 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 16 Jan 2009 12:42:53 +0100
Subject: Tiny patch for missing stdint.h
In-Reply-To: <00F8C314-666F-4EE9-BAC3-0D25CE5D0D0B@opencsw.org> (Dagobert
	Michelsen's message of "Fri, 16 Jan 2009 11:37:44 +0100")
References: <DC1F046B-97B4-4322-924A-FCCE8C7016D2@opencsw.org>
	<878wpcfphd.fsf@mocca.josefsson.org>
	<00F8C314-666F-4EE9-BAC3-0D25CE5D0D0B@opencsw.org>
Message-ID: <87zlhrbhoi.fsf@mocca.josefsson.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi Simon,
>
> Am 15.01.2009 um 18:28 schrieb Simon Josefsson:
>> Dagobert Michelsen <dam at opencsw.org> writes:
>>> I am compiling libtasn1 1.7 for Solaris 8 and found that a tiny
>>> patch is needed to prevent including the missing (and correctly
>>> my configure detected) stdint.h:
>>
>> Configure should make sure a stdint.h is generated in gl/.  Isn't this
>> the case for you?
>
> It is generated, but it is not added to the include path:

Ah, thank you.

Please test an updated daily build that should contain a fix:

http://daily.josefsson.org/libtasn1-1/libtasn1-1-20090116.tar.gz

Let me know if it works or not and I'll release it as v1.8.

/Simon




From dam at opencsw.org  Fri Jan 16 13:55:58 2009
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 16 Jan 2009 13:55:58 +0100
Subject: Tiny patch for missing stdint.h
In-Reply-To: <87zlhrbhoi.fsf@mocca.josefsson.org>
References: <DC1F046B-97B4-4322-924A-FCCE8C7016D2@opencsw.org>
	<878wpcfphd.fsf@mocca.josefsson.org>
	<00F8C314-666F-4EE9-BAC3-0D25CE5D0D0B@opencsw.org>
	<87zlhrbhoi.fsf@mocca.josefsson.org>
Message-ID: <E238CFE3-F682-4A60-8DED-F9F61226B26E@opencsw.org>

Hi Simon,

Am 16.01.2009 um 12:42 schrieb Simon Josefsson:
> Dagobert Michelsen <dam at opencsw.org> writes:
>> Am 15.01.2009 um 18:28 schrieb Simon Josefsson:
>>> Dagobert Michelsen <dam at opencsw.org> writes:
>>>> I am compiling libtasn1 1.7 for Solaris 8 and found that a tiny
>>>> patch is needed to prevent including the missing (and correctly
>>>> my configure detected) stdint.h:
>>>
>>> Configure should make sure a stdint.h is generated in gl/.  Isn't  
>>> this
>>> the case for you?
>>
>> It is generated, but it is not added to the include path:
>
> Ah, thank you.
>
> Please test an updated daily build that should contain a fix:
>
> http://daily.josefsson.org/libtasn1-1/libtasn1-1-20090116.tar.gz
>
> Let me know if it works or not and I'll release it as v1.8.

Yes, that does work. However, gl/ is now included twice:

>         /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I..  - 
> I../lib -I../gl -I../gl -I/opt/csw/include  -xO3 -xarch=v8 -I/opt/ 
> csw/include -c Test_encoding.c

This may be an artefact, harmless, but I wanted to let you know.


Best regards

   -- Dago




From simon at josefsson.org  Fri Jan 16 15:12:57 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 16 Jan 2009 15:12:57 +0100
Subject: Tiny patch for missing stdint.h
In-Reply-To: <E238CFE3-F682-4A60-8DED-F9F61226B26E@opencsw.org> (Dagobert
	Michelsen's message of "Fri, 16 Jan 2009 13:55:58 +0100")
References: <DC1F046B-97B4-4322-924A-FCCE8C7016D2@opencsw.org>
	<878wpcfphd.fsf@mocca.josefsson.org>
	<00F8C314-666F-4EE9-BAC3-0D25CE5D0D0B@opencsw.org>
	<87zlhrbhoi.fsf@mocca.josefsson.org>
	<E238CFE3-F682-4A60-8DED-F9F61226B26E@opencsw.org>
Message-ID: <87zlhr9w5y.fsf@mocca.josefsson.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi Simon,
>
> Am 16.01.2009 um 12:42 schrieb Simon Josefsson:
>> Dagobert Michelsen <dam at opencsw.org> writes:
>>> Am 15.01.2009 um 18:28 schrieb Simon Josefsson:
>>>> Dagobert Michelsen <dam at opencsw.org> writes:
>>>>> I am compiling libtasn1 1.7 for Solaris 8 and found that a tiny
>>>>> patch is needed to prevent including the missing (and correctly
>>>>> my configure detected) stdint.h:
>>>>
>>>> Configure should make sure a stdint.h is generated in gl/.  Isn't
>>>> this
>>>> the case for you?
>>>
>>> It is generated, but it is not added to the include path:
>>
>> Ah, thank you.
>>
>> Please test an updated daily build that should contain a fix:
>>
>> http://daily.josefsson.org/libtasn1-1/libtasn1-1-20090116.tar.gz
>>
>> Let me know if it works or not and I'll release it as v1.8.
>
> Yes, that does work.

Thanks for confirming.

> However, gl/ is now included twice:
>
>>         /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I..
>> -
>> I../lib -I../gl -I../gl -I/opt/csw/include  -xO3 -xarch=v8 -I/opt/
>> csw/include -c Test_encoding.c
>
> This may be an artefact, harmless, but I wanted to let you know.

That's intentional, see tests/Makefile.am:

AM_CPPFLAGS = -I$(top_srcdir)/lib -I$(top_srcdir)/gl -I../gl

In other words, the two directories may be different if you are building
with srcdir != builddir, so both -I's are needed.  I don't know how to
avoid duplicating the -I's for the case where the directories are the
same, but it shouldn't hurt anything anyway.

/Simon




From simon at josefsson.org  Fri Jan 16 15:18:39 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 16 Jan 2009 15:18:39 +0100
Subject: Libtasn1 1.8
Message-ID: <87vdsf9vwg.fsf@mocca.josefsson.org>

Libtasn1 is a standalone library written in C for manipulating ASN.1
objects including DER/BER encoding and DER/BER decoding.  Libtasn1 is
used by GnuTLS to manipulate X.509 objects and by Shishi to handle
Kerberos V5 packets.

Version 1.8 (released 2009-01-16)
- Fix crlf self-test under Mingw+Wine.
- Fix build problems on platforms that lack stdint.h.
  Reported by Dagobert Michelsen <dam at opencsw.org> in
  <http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3377>.

Commercial support contracts for Libtasn1 are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, 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:
<http://lists.gnu.org/mailman/listinfo/help-gnutls>.

Homepage:
  http://josefsson.org/libtasn1/

Here are the compressed sources (1.6MB):
  ftp://ftp.gnu.org/gnu/gnutls/libtasn1-1.8.tar.gz
  http://ftp.gnu.org/gnu/gnutls/libtasn1-1.8.tar.gz

Here are GPG detached signatures using key 0xB565716F:
  ftp://ftp.gnu.org/gnu/gnutls/libtasn1-1.8.tar.gz.sig
  http://ftp.gnu.org/gnu/gnutls/libtasn1-1.8.tar.gz.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2009-04-21]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2009-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:

12b8a872eb4aa24f12bd09a24ab6199b8058e5b3  libtasn1-1.8.tar.gz

e6f24e582a61ff19312709e08cbba98193a87b256fc5d21b15931525  libtasn1-1.8.tar.gz

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: </pipermail/attachments/20090116/060886ae/attachment.pgp>

From simon at josefsson.org  Mon Jan 19 12:18:12 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 Jan 2009 12:18:12 +0100
Subject: Google Summer of Code: Interested?
Message-ID: <87k58rtuh7.fsf@mocca.josefsson.org>

If someone is interested to participate as a student in this year's
Google Summer of Code, there is a chance we can apply via GNU.  I guess
almost anything related to GnuTLS is allowed in applications, but the
more realistic and the more useful the idea is, the more likely the
application is to get approved.

Look at the doc/TODO file for inspiration, but feel free to propose
larger ideas too.  (the items in the TODO file are often rather small
tasks.)

/Simon




From at at pre-secure.de  Mon Jan 19 21:38:11 2009
From: at at pre-secure.de (Axel Theilmann)
Date: Mon, 19 Jan 2009 21:38:11 +0100
Subject: CVE-2008-4989 patch causes segfault with certain certificates and
 gnutls 2.4.x
Message-ID: <4974E4B3.4080408@pre-secure.de>


moin,

i was debugging a segfault in an application that uses libprelude which in
turn uses gnutls. the system is opensuse 11.1 with gnutls-2.4.1.

the client application segfaulted upon connection to a server.

after some fiddling, i found out that this segfault was caused by the
CVE-2008-4989 patch
http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3217
that was added by opensuse to gnutls-2.4.1
using a plain gnutls-2.4.1 worked fine. gnutls-2.6.3 worked fine as well.

the segfault also happens just using gnutls-cli to connect so its not a
problem of libprelude.

i can provide a certificate and a server to reproduce this segfault, if
anyone is interested.


the segfault just seems to happen with certain server- and ca-certificates.
connecting to a regular https-server worked fine.

i dont know enough of gnutls-internals to really figure out what the problem
is, but it would be neat if this segfault could be fixed in 2.4.x. since
2.6.3 does not segfault, there seems to be a way to fix the vulnerability
without this segfault...


tty, axel


-- 
Dipl.-Inform. Axel Theilmann                   at at pre-secure.de
Senior Researcher               Phone (+49) 040 / 8080 77 - 880
                                Fax   (+49) 040 / 8080 77 - 877

PRESECURE Consulting GmbH, Muenster        AG M?nster, HRB 6581
Gesch?ftsf?hrer/Managing Director   Dr. Klaus-Peter Kossakowski

                            CarmentiS - Early Warning Expertise
                                      https://www.carmentis.org


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090119/45fc197c/attachment.pgp>

From simon at josefsson.org  Tue Jan 20 19:03:21 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 20 Jan 2009 19:03:21 +0100
Subject: CVE-2008-4989 patch causes segfault with certain certificates
	and gnutls 2.4.x
In-Reply-To: <4974E4B3.4080408@pre-secure.de> (Axel Theilmann's message of
	"Mon, 19 Jan 2009 21:38:11 +0100")
References: <4974E4B3.4080408@pre-secure.de>
Message-ID: <87mydlc0t2.fsf@mocca.josefsson.org>

Axel Theilmann <at at pre-secure.de> writes:

> moin,
>
> i was debugging a segfault in an application that uses libprelude which in
> turn uses gnutls. the system is opensuse 11.1 with gnutls-2.4.1.
>
> the client application segfaulted upon connection to a server.
>
> after some fiddling, i found out that this segfault was caused by the
> CVE-2008-4989 patch
> http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3217
> that was added by opensuse to gnutls-2.4.1
> using a plain gnutls-2.4.1 worked fine. gnutls-2.6.3 worked fine as well.
>
> the segfault also happens just using gnutls-cli to connect so its not a
> problem of libprelude.
>
> i can provide a certificate and a server to reproduce this segfault, if
> anyone is interested.
>
>
> the segfault just seems to happen with certain server- and ca-certificates.
> connecting to a regular https-server worked fine.
>
> i dont know enough of gnutls-internals to really figure out what the problem
> is, but it would be neat if this segfault could be fixed in 2.4.x. since
> 2.6.3 does not segfault, there seems to be a way to fix the vulnerability
> without this segfault...

The code in 2.6.3 should work equally well to 2.4.x as well, and I
believe it will solve the problem with crashes.  So I suggest you ask
the OpenSUSE team to compare 2.6.0 with 2.6.3 and apply the relevant
patch.  Btw, 2.4.2 also contains a fix for another crash that may be
useful to apply.

/Simon




From at at pre-secure.de  Wed Jan 21 12:23:48 2009
From: at at pre-secure.de (Axel Theilmann)
Date: Wed, 21 Jan 2009 12:23:48 +0100
Subject: CVE-2008-4989 patch causes segfault with certain certificates
 and gnutls 2.4.x
In-Reply-To: <87mydlc0t2.fsf@mocca.josefsson.org>
References: <4974E4B3.4080408@pre-secure.de>
	<87mydlc0t2.fsf@mocca.josefsson.org>
Message-ID: <497705C4.3050102@pre-secure.de>

Simon Josefsson wrote:

moin,

> The code in 2.6.3 should work equally well to 2.4.x as well, and I
> believe it will solve the problem with crashes.  So I suggest you ask
> the OpenSUSE team to compare 2.6.0 with 2.6.3 and apply the relevant
> patch.  Btw, 2.4.2 also contains a fix for another crash that may be
> useful to apply.

ok, thanks. i'll open a bug with opensuse.


tty, axel


-- 
Dipl.-Inform. Axel Theilmann                   at at pre-secure.de
Senior Researcher               Phone (+49) 040 / 8080 77 - 880
                                Fax   (+49) 040 / 8080 77 - 877

PRESECURE Consulting GmbH, Muenster        AG M?nster, HRB 6581
Gesch?ftsf?hrer/Managing Director   Dr. Klaus-Peter Kossakowski

                            CarmentiS - Early Warning Expertise
                                      https://www.carmentis.org


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090121/111faf16/attachment.pgp>

From simon at josefsson.org  Wed Jan 21 13:57:56 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 21 Jan 2009 13:57:56 +0100
Subject: CVE-2008-4989 patch causes segfault with certain certificates
	and gnutls 2.4.x
In-Reply-To: <497705C4.3050102@pre-secure.de> (Axel Theilmann's message of
	"Wed, 21 Jan 2009 12:23:48 +0100")
References: <4974E4B3.4080408@pre-secure.de>
	<87mydlc0t2.fsf@mocca.josefsson.org> <497705C4.3050102@pre-secure.de>
Message-ID: <87ljt4aka3.fsf@mocca.josefsson.org>

Axel Theilmann <at at pre-secure.de> writes:

> Simon Josefsson wrote:
>
> moin,
>
>> The code in 2.6.3 should work equally well to 2.4.x as well, and I
>> believe it will solve the problem with crashes.  So I suggest you ask
>> the OpenSUSE team to compare 2.6.0 with 2.6.3 and apply the relevant
>> patch.  Btw, 2.4.2 also contains a fix for another crash that may be
>> useful to apply.
>
> ok, thanks. i'll open a bug with opensuse.

Possibly we should do another release of the 2.4.x branch too, it seems
many haven't upgraded to 2.6.x yet...

/Simon




From dam at opencsw.org  Wed Jan 21 20:47:27 2009
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 21 Jan 2009 20:47:27 +0100
Subject: Some compile issues of gnutls 2.6.3 on Solaris
Message-ID: <C31B13FF-0A76-4A38-A475-D9C817954F43@opencsw.org>

Hi,

I am having some compile issues with the current version gnutls 2.6.3
on Solaris with Sun Studio 11 compiler:

- Some void functions try to return values which is fixed with this  
patch:

diff -Naur gnutls-2.6.3.orig/lib/mac-libgcrypt.c gnutls-2.6.3.patched/ 
lib/mac-libgcrypt.c
--- gnutls-2.6.3.orig/lib/mac-libgcrypt.c       2008-12-12  
19:45:34.000000000 +0100
+++ gnutls-2.6.3.patched/lib/mac-libgcrypt.c    2009-01-21  
20:36:56.850155449 +0100
@@ -93,7 +93,7 @@
  static void
  wrap_gcry_md_close (void *hd)
  {
-  return gcry_md_close (hd);
+  gcry_md_close (hd);
  }

  static int
diff -Naur gnutls-2.6.3.orig/lib/mpi-libgcrypt.c gnutls-2.6.3.patched/ 
lib/mpi-libgcrypt.c
--- gnutls-2.6.3.orig/lib/mpi-libgcrypt.c       2008-12-12  
19:45:34.000000000 +0100
+++ gnutls-2.6.3.patched/lib/mpi-libgcrypt.c    2009-01-21  
20:22:33.521197971 +0100
@@ -120,7 +120,7 @@
  static void
  wrap_gcry_mpi_release (bigint_t a)
  {
-  return gcry_mpi_release (a);
+  gcry_mpi_release (a);
  }

  #undef _gnutls_mpi_alloc_like


- The generated includes from lgl/ are not used during compilation:

...
gmake[6]: Entering directory `/home/dam/mgar/pkg/gnutls/trunk/work/ 
build-isa-sparcv8/gnutls-2.6.3/libextra/gl'
source='hmac-md5.c' object='hmac-md5.lo' libtool=yes \
         DEPDIR=.deps depmode=none /bin/bash ../../build-aux/depcomp \
         /bin/bash ../../libtool --tag=CC   --mode=compile /opt/studio/ 
SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I../..   -I/opt/csw/include  
-I/opt/csw/include -xO3 -xarch=v8 -I/opt/csw/include -c -o hmac-md5.lo  
hmac-md5.c
libtool: compile:  /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H - 
I. -I../.. -I/opt/csw/include -I/opt/csw/include -xO3 -xarch=v8 -I/opt/ 
csw/include -c hmac-md5.c  -KPIC -DPIC -o .libs/hmac-md5.o
"md5.h", line 25: cannot find include file: <stdint.h>
...
build8s% find . -name stdint.h
./work/build-isa-sparcv8/gnutls-2.6.3/lgl/stdint.h


Best regards

   -- Dagobert Michelsen




From simon at josefsson.org  Wed Jan 21 22:26:42 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 21 Jan 2009 22:26:42 +0100
Subject: Some compile issues of gnutls 2.6.3 on Solaris
In-Reply-To: <C31B13FF-0A76-4A38-A475-D9C817954F43@opencsw.org> (Dagobert
	Michelsen's message of "Wed, 21 Jan 2009 20:47:27 +0100")
References: <C31B13FF-0A76-4A38-A475-D9C817954F43@opencsw.org>
Message-ID: <878wp45p0t.fsf@mocca.josefsson.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi,
>
> I am having some compile issues with the current version gnutls 2.6.3
> on Solaris with Sun Studio 11 compiler:
>
> - Some void functions try to return values which is fixed with this
> patch:

Hi!  Thanks for the report.  Both of these had been fixed already on the
gnutls_2_6_x branch.

> - The generated includes from lgl/ are not used during compilation:
>
> ...
> gmake[6]: Entering directory `/home/dam/mgar/pkg/gnutls/trunk/work/
> build-isa-sparcv8/gnutls-2.6.3/libextra/gl'
> source='hmac-md5.c' object='hmac-md5.lo' libtool=yes \
>         DEPDIR=.deps depmode=none /bin/bash ../../build-aux/depcomp \
>         /bin/bash ../../libtool --tag=CC   --mode=compile /opt/studio/
> SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I../..   -I/opt/csw/include
> -I/opt/csw/include -xO3 -xarch=v8 -I/opt/csw/include -c -o hmac-md5.lo
> hmac-md5.c
> libtool: compile:  /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -
> I. -I../.. -I/opt/csw/include -I/opt/csw/include -xO3 -xarch=v8
> -I/opt/
> csw/include -c hmac-md5.c  -KPIC -DPIC -o .libs/hmac-md5.o
> "md5.h", line 25: cannot find include file: <stdint.h>
> ...
> build8s% find . -name stdint.h
> ./work/build-isa-sparcv8/gnutls-2.6.3/lgl/stdint.h

This was new, thank you.  Should be fixed on trunk.  Please test updated
daily build of the 2.6.x trunk (soon to be released):

http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20090121.tar.gz

/Simon




From dam at opencsw.org  Thu Jan 22 17:48:57 2009
From: dam at opencsw.org (Dagobert Michelsen)
Date: Thu, 22 Jan 2009 17:48:57 +0100
Subject: Some compile issues of gnutls 2.6.3 on Solaris
In-Reply-To: <878wp45p0t.fsf@mocca.josefsson.org>
References: <C31B13FF-0A76-4A38-A475-D9C817954F43@opencsw.org>
	<878wp45p0t.fsf@mocca.josefsson.org>
Message-ID: <0860A8D9-BFA3-40A0-9BD6-2F44E0F1D855@opencsw.org>

Hi Simon,

Am 21.01.2009 um 22:26 schrieb Simon Josefsson:
> This was new, thank you.  Should be fixed on trunk.  Please test  
> updated
> daily build of the 2.6.x trunk (soon to be released):
>
> http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20090121.tar.gz

Compilation and testing works fine now. However, on installation I get

libtool: install: warning: relinking `libgnutlsxx.la'
libtool: install: (cd /home/dam/mgar/pkg/gnutls/trunk/work/build-isa- 
sparcv8/gnutls-2.6.4/lib; /bin/bash /home/dam/mgar/pkg/gnutls/trunk/ 
work/build-isa-sparcv8/gnutls-2.6.4/libtool  --tag CXX --mode=relink / 
opt/studio/SOS11/SUNWspro/bin/CC -I../includes/ -xO3 -xarch=v8 -I/opt/ 
csw/include -no-undefined -version-info 37:5:11 -xarch=v8 -L/opt/csw/ 
lib -R/opt/csw/lib/\\\$ISALIST -R/opt/csw/lib -o libgnutlsxx.la - 
rpath /opt/csw/lib libgnutlsxx_la-gnutlsxx.lo libgnutls.la -lnsl - 
lsocket -inst-prefix-dir /home/dam/mgar/pkg/gnutls/trunk/work/install- 
isa-sparcv8)
libtool: relink: /opt/studio/SOS11/SUNWspro/bin/CC -G -zdefs - 
hlibgnutlsxx.so.26 -o .libs/libgnutlsxx.so.26.11.5   .libs/ 
libgnutlsxx_la-gnutlsxx.o   -R/opt/csw/lib -R/opt/csw/lib/\$ISALIST -L/ 
opt/csw/lib -L/home/dam/mgar/pkg/gnutls/trunk/work/install-isa-sparcv8/ 
opt/csw/lib -lgnutls -ltasn1 -lz -lgcrypt -lgpg-error -lintl -lnsl - 
lsocket -library=Cstd -library=Crun -lc   -xarch=v8 -xarch=v8
Undefined                       first referenced
  symbol                             in file
gnutls_priority_set                 .libs/libgnutlsxx_la-gnutlsxx.o
gnutls_priority_set_direct          .libs/libgnutlsxx_la-gnutlsxx.o
gnutls_openpgp_send_cert            .libs/libgnutlsxx_la-gnutlsxx.o
ld: fatal: Symbol referencing errors. No output written to .libs/ 
libgnutlsxx.so.26.11.5
libtool: install: error: relink `libgnutlsxx.la' with the above  
command before installing it
gmake[5]: *** [install-libLTLIBRARIES] Error 1

Please be advised that I don't install .la-files for shared libraries  
(like libassuan etc.)


Best regards

   -- Dago




From nmav at gnutls.org  Sun Jan 25 16:30:16 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 25 Jan 2009 17:30:16 +0200
Subject: [Help-gnutls] client certificate authentication
In-Reply-To: <1232883443.19927.20.camel@nimitz.example.org>
References: <1231356138.7163.7.camel@nimitz.example.org>	
	<4974DD81.4020400@gnutls.org>
	<1232484433.7434.31.camel@nimitz.example.org>
	<1232883443.19927.20.camel@nimitz.example.org>
Message-ID: <497C8588.3000904@gnutls.org>

Tristan Hill wrote:
> I have done some more investigation with ssldump:
[...]
> I'm unsure if this is valid behaviour from openssl however.

Thank you. I'm also not sure if this is a valid behavior from us. I
attach a patch, and I'd appreciate if you check and see that it solves
you issue.

The attached patch tries stay on the safe side and don't try to upgrade
the TLS version on a rehandshake. I'm not sure whether this is the right
thing to do, although performing a rehandshake to upgrade the TLS
version seems quite unlikely.

regards,
Nikos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: handshake.patch
Type: text/x-patch
Size: 1295 bytes
Desc: not available
URL: </pipermail/attachments/20090125/d586d10b/attachment.bin>

From special at dereferenced.net  Mon Jan 26 01:29:51 2009
From: special at dereferenced.net (John Brooks)
Date: Sun, 25 Jan 2009 17:29:51 -0700
Subject: gnutls_hex_encode inconsistency
Message-ID: <e646fda30901251629m41b15ab0rb6455a7e7839c891@mail.gmail.com>

Just a quick little bug here - gnutls_hex_encode, according to the
documentation (and convention), will copy the output size to size_t
*result_size, but does not actually do so. This leaves no way (other than
manually doing the math) to get the exact output size of this function.
Threw me off a little when I had a couple hundred bytes of garbage
afterwards :P

Thanks,
  - John Brooks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20090125/390abca4/attachment.htm>

From stan at saticed.me.uk  Sun Jan 25 23:00:29 2009
From: stan at saticed.me.uk (Tristan Hill)
Date: Sun, 25 Jan 2009 22:00:29 +0000
Subject: [Help-gnutls] client certificate authentication
In-Reply-To: <497C8588.3000904@gnutls.org>
References: <1231356138.7163.7.camel@nimitz.example.org>
	<4974DD81.4020400@gnutls.org>
	<1232484433.7434.31.camel@nimitz.example.org>
	<1232883443.19927.20.camel@nimitz.example.org>
	<497C8588.3000904@gnutls.org>
Message-ID: <1232920829.7343.5.camel@nimitz.example.org>

On Sun, 2009-01-25 at 17:30 +0200, Nikos Mavrogiannopoulos wrote:
> I attach a patch, and I'd appreciate if you check and see that it solves
> you issue.
> 


works for me


Thanks
Tristan





From nmav at gnutls.org  Tue Jan 27 21:58:51 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 27 Jan 2009 22:58:51 +0200
Subject: [Help-gnutls] client certificate authentication
In-Reply-To: <1232920829.7343.5.camel@nimitz.example.org>
References: <1231356138.7163.7.camel@nimitz.example.org>	
	<4974DD81.4020400@gnutls.org>
	<1232484433.7434.31.camel@nimitz.example.org>	
	<1232883443.19927.20.camel@nimitz.example.org>	
	<497C8588.3000904@gnutls.org>
	<1232920829.7343.5.camel@nimitz.example.org>
Message-ID: <497F758B.4020500@gnutls.org>

Tristan Hill wrote:
> On Sun, 2009-01-25 at 17:30 +0200, Nikos Mavrogiannopoulos wrote:
>> I attach a patch, and I'd appreciate if you check and see that it solves
>> you issue.
>>
> works for me

Applied, thank you.




From nmav at gnutls.org  Tue Jan 27 22:00:18 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 27 Jan 2009 23:00:18 +0200
Subject: gnutls_hex_encode inconsistency
In-Reply-To: <e646fda30901251629m41b15ab0rb6455a7e7839c891@mail.gmail.com>
References: <e646fda30901251629m41b15ab0rb6455a7e7839c891@mail.gmail.com>
Message-ID: <497F75E2.5050201@gnutls.org>

John Brooks wrote:
> Just a quick little bug here - gnutls_hex_encode, according to the
> documentation (and convention), will copy the output size to size_t
> *result_size, but does not actually do so. This leaves no way (other than
> manually doing the math) to get the exact output size of this function.
> Threw me off a little when I had a couple hundred bytes of garbage
> afterwards :P

Corrected in git repository at:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=6930e0ea6c242cab6e525b797387a7cba3628cf6

Thank you for the report.

regards,
Nikos




From sven.mueller at enfos.de  Tue Jan 27 20:53:06 2009
From: sven.mueller at enfos.de (Sven =?ISO-8859-1?Q?M=FCller?=)
Date: Tue, 27 Jan 2009 20:53:06 +0100
Subject: Gaim is now Pidgin
Message-ID: <1233085986.9353.8.camel@T60>

Dear gnutls staff,

in the program list appears Gaim, which was renamed - due to brand
violation charges by aol - to Pidgin.


Kind Regards

Sven





From bratschpower at gmail.com  Thu Jan 29 20:04:13 2009
From: bratschpower at gmail.com (Mac Wendelboe)
Date: Thu, 29 Jan 2009 20:04:13 +0100
Subject: gnutls-2.6.3 make check FAIL: rsa-md5-collision
Message-ID: <4981FDAD.5070500@gmail.com>

After making gnutls-2.6.3, make check fails with the following message:

make[3]: Entering directory 
`/usr/local/src/gnutls-2.6.3/tests/rsa-md5-collision'
/usr/local/src/gnutls-2.6.3/src/.libs/lt-certtool: global_init: The 
gcrypt library version is too old.
FAIL: rsa-md5-collision

I also tried the older gnutls-2.6.2, which gives the exact same result.

I tried with libgcrypt-1.4.4 and libgcrypt-1.4.3.
libgcrypt is compiled against libgpg-error-1.7.
My system is Fedora Core 5 with Linux 2.6.20-1.2320.fc5, x86_64.




From nmav at gnutls.org  Sat Jan 31 19:38:05 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 31 Jan 2009 20:38:05 +0200
Subject: gnutls-2.6.3 make check FAIL: rsa-md5-collision
In-Reply-To: <4981FDAD.5070500@gmail.com>
References: <4981FDAD.5070500@gmail.com>
Message-ID: <20090131203805.4d2e3913@nmav-eee>

On Thu, 29 Jan 2009 20:04:13 +0100
Mac Wendelboe <bratschpower at gmail.com> wrote:

> After making gnutls-2.6.3, make check fails with the following
> message:
> 
> make[3]: Entering directory 
> `/usr/local/src/gnutls-2.6.3/tests/rsa-md5-collision'
> /usr/local/src/gnutls-2.6.3/src/.libs/lt-certtool: global_init: The 
> gcrypt library version is too old.
> FAIL: rsa-md5-collision

Are you sure you don't have an old version of the library around?

regards,
Nikos