gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#507633: libgnutls26: GnuTLS does not know VeriSign any more


From: Simon Josefsson
Subject: Re: Bug#507633: libgnutls26: GnuTLS does not know VeriSign any more
Date: Thu, 11 Dec 2008 08:25:14 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (gnu/linux)

Nikos Mavrogiannopoulos <address@hidden> writes:

> Simon Josefsson wrote:
>> My approach introduced a problem with the pkcs1-padding self-test that
>> uses certtool --verify-chain, and the self-test assumes that the last
>> certificate is actually verified against its own public key...  so
>> short-cutting the validation of trust anchors changed the semantics of
>> one public interface.  Sigh.  So I have reverted my patch.
>> 
>> Simon Josefsson <address@hidden> writes:
>> 
>>> I believe that is wrong: with your patch it will fail when the CA is
>>> self-signed using RSA-MD2.
>> There aren't many of those around, so I think we can leave it as a
>> documented bug that self-signed RSA-MD2 certificate cannot be used as a
>> trust anchor.  One might see that as a feature, even. ;)
>> I've aligned the self-tests with Nikos' approach.
>
> What I don't understand is why it fails with my approach. Since I remove
> the trusted certificate from the chain it shouldn't be an issue.

Your approach only removes a CA cert if there are more certs in the
chain.  If there is only one cert in the chain, it will not be removed
(or there is a crash) and the code later on will call
_gnutls_verify_certificate2 on the CA cert, and that function will
extract the public key and check the signature in the cert.  This will
break if it is signed using an unsupported algorithm (e.g., RSA-MD2).

My approach does not modify the chain before validation, but changes
_gnutls_verify_certificate2 so that it detects when it has a trusted
self-signed cert and short-cuts further validation tests.

I think we should revisit this code sometime, now the code can reject
trusted CA certs when the chain is length 1, which is slightly wrong
(but doesn't lead to false positives).  We also have other requests to
support intermediary trusted anchors.  The code is also somewhat
difficult to read...

What is good now is that we have self-tests of some common chains in
tests/chainverify.c.  When we run into problems we can add new chains to
that test so we don't run into regressions.  There is also the PKITS
test vectors, but I recall license problems with them.

> For example this issue does not occur any more with
> hbci-pintan-rp.s-hbci.de. On which cases did you notice that?

That chain has a length of 3, so the self-signed root is removed, and
the problem isn't triggered.

/Simon





reply via email to

[Prev in Thread] Current Thread [Next in Thread]