Working around wrong algorithm specification in certificates

Mads Kiilerich mads at
Sat Jul 24 03:06:49 CEST 2010

  Nikos Mavrogiannopoulos wrote, On 07/21/2010 09:23 AM:
> Mads Kiilerich wrote:
>>>> You don't want to pollute your code with workarounds or flexibility for
>>>> stupid bugs like this?
>>> I was thinking about your copy of gnutls :) If the fix works and the
>>> problem is general the workaround might be included in the gnutls code
>>> as well. I've seen quite some implementations putting wrong OIDs here
>>> and there, and working around those practices is not that exceptional
>>> any more.
>> This patch works for me and 2.10.0:
>> --- gnutls-2.10.0/lib/   2010-07-20
>> 22:57:35.000000000 +0200
>> +++ gnutls-2.10.0/lib/gnutls_algorithms.c       2010-07-20
>> 22:57:07.000000000 +0200
>> @@ -2125,6 +2125,7 @@
>>     {"GOST R 34.10-2001", PK_GOST_R3410_2001_OID, 0},
>>     {"GOST R 34.10-94", PK_GOST_R3410_94_OID, 0},
>>     {0, 0, 0}
>>   };
>> I can see that you added PK_X509_RSA_OID since 2.10.0. Could this
>> perhaps be added too?
>> There is also anecdotical evidence that SIG_RSA_SHA1_OID needs the same
>> treatment. I haven't seen that, but getting both fixed at once could be
>> great.
> I've added them to the 2.10.x branch. I've not added the SHA1_OID but if
> you have some certificates using it, I'll add it. Clearly this OID
> shouldn't have been there!


The anecdote of the need for SIG_RSA_SHA1_OID could be tracked down to 
the comments on 
. But the BER encoded certificate on 
(which despite the text _not_ is what is displayed) also uses 
Please consider adding support for that too.

If you are going to make a release from gnutls_2_10_x then I hope you 
will include "Correctly deinitialize crypto API handles." as well.

However, according to NEWS you have released 2.11.0 already - but it is 
not on ?


More information about the Gnutls-help mailing list