Loading credentials in verify callback just as needed ?

[Tim Ruehsen]

Am Thursday 30 August 2012 schrieb Nikos Mavrogiannopoulos:
> > There are 150 certs at the moment.
> > GnuTLS 3.0.22 uses ~1.8 millions of malloc()s to read these files in.
> > OpenSSL just ~5.000.
> 
> Ouch. It's the libtasn1's operation that uses quite excessively malloc
> to parse the X.509 structures and create a tree, but 1.8 million for 150
> certificates seems too much. Most probably an optimization there would
> eliminate the issue you see.
> 
> > On my rather old AMD 2000+ it takes ~1s to load these.
> > Using valgrind for development (wget1.14), it takes around 30-40s.
> > See some output at the end of my inital post (i meant to write Wget1.14
> > there, not mget1.14).
> 
> Ouch.

Yes, ouch ;-)

I took a look at libtasn1, and yes, the best thing would be a partial rewrite.
Unlikely someone is doing that... a quicker way to speed up would be the use 
of memory pools in libtasn1.
If there is some potential within the GnuTLS sources, I can't say.


> >> GnuTLS doesn't have something similar to that, like loading the CA
> >> file on demand.
> >> You could of course simulate that functionality by using the
> >> certificate's authority key identifier, or the issuer's name.
> > 
> > Here is exactly the point, where you could help me.
> > I would like to do that.
> > But when the verification callback function is called (set by
> > gnutls_certificate_set_verify_function()), information about the key id
> > or issuer seem not to be available.
> 
> You can obtain the peer's certificate. gnutls_certificate_get_peers()
> convert it to a gnutls_x509_crt_t and then read the key id or issuer.

Sorry, Nikos, for being my "rubber duck" ;-)

I found the problem some minutes ago while writing this email.
I used
	gnutls_x509_crt_import(cert, &cert_list[it], GNUTLS_X509_FMT_PEM)
instead of
	gnutls_x509_crt_import(cert, &cert_list[it], GNUTLS_X509_FMT_DER)

Now I am getting issuer and DN etc.

I let you know if and when the 'lazy loading' works and how it performs.
But still: optimizing libtasn1 is an issue...

     Tim Rühsen