Experiments with GnuTLS and Qt

[Richard Moore]

On Mon, Jan 9, 2012 at 12:50 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On Sun, Jan 8, 2012 at 11:00 PM, Richard Moore <rich at kde.org> wrote:
>> I've been evaluating using GnuTLS with Qt this weekend. There's a
>> basic tool that prints out cert info and converts from some Qt data
>> types like QDateTime etc. at
>> http://xmelegance.org/devel/cert-prototype.tar.bz2 I'm just posting it
>> here in case it happens to be useful to anyone. Issues I've
>> encountered are documented in the NOTES file.
>
> Hello,
>  Interesting comments.
>
> - The docs say to report bugs to one place, but they also seem to use the bug
>  reporting tool from savanah. No indication of which is the one to use. It
>  seems the bug report email actually goes to the development list.
>
> Actually both end up in the development list and are treated equally.

That makes sense.

>
> - Getting at the subject/issuer details seems a bit tricky. There seem to be
>  errors in the docs here which doesn't help. Also seems to be using a mixture
>  of void * and char * to hold oids which means we'll need some casts.
>
> Would you like to elaborate on that? Is there is something we should
> fix (in the
> documentation or code)?

Sure, there's certainly a doc error, but I haven't had a chance to
check if it's due to a problem in the doc comments yet or a bug in the
generation tool. If you go here:
http://www.gnu.org/software/gnutls/manual/html_node/X509-certificate-API.html#X509-certificate-API

and search for gnutls_x509_crt_get_dn you'll see that the docs refer
to raw_flag which is only present in the
gnutls_x509_crt_get_dn_by_oid() function.

You can also see that gnutls_x509_crt_get_dn_oid uses void * for the
oid wheras gnutls_x509_crt_get_dn_by_oid() uses a const char *.

>
> - There appears to be no method to map oids to human readable names, there's
>  some internal functions for it but nothing public.
>
> Are you referring to the DN oids? If this is the case and it is an interesting
> feature we could consider exporting the known OIDs. However this cannot
> be a general OID -> string convertion.

Yeah, I wasn't expecting a fully generic conversion. The way this
works in openssl is that if it's a known OID then it converts it to a
human readable name, and if not it returns the oid as a string.
Normally openssl uses internal id numbers for the oid in order to
improve performance.


>
> - Both subject/issuer (distinguished name) and extensions APIs seem to involve
>  querying the oids and passing them around. This is likely to be slow since
>  we're talking string comparisions (and even worse the part of the string
>  that varies is at the end though this might be worked around internally
>  since we provide a length).
>
> To which functions do you refer to? In general I try to promote the
> gnutls_x509_crt_get_dn() that provides an RFC2253 compliant single
> string to describe the DN.

I need to be able to return the DN components in a structured way to
implement this API:

http://doc.qt.nokia.com/5.0-snapshot/qsslcertificate.html#subjectInfo

Getting the DN as a string and then parsing it to get the information
is likely to be slow, and risks mishandling strange DNs that are
deliberately crafted to be mishandled. For example many tools get
repeated elements like multiple CNs wrong, to say nothing of
deliberately strange ones.


>
>  It appears there's another way to get this info
>  gnutls_x509_crt_get_subject() no idea if this is a better mechanism at this
>  time.
>
> If less string comparisons is your goal this looks like an alternative. However,
> unless you expect millions of DN queries I wouldn't worry about string
> comparisons.
> Its impact would be minimal to the cost of DER decoding overhead.

Yeah, I haven't benchmarked anything, so this is most likely correct.
It just seems a bit daft to convert the oid to a string, then do a
string comparison just in order to map something like the country oid
back to 'C'.

>
> - No support for OCSP in the released version, OCSP code appears to be under
>  active development in a branch of the git repo.
>
> It is expected to be merged soon.

Great.

Thanks for taking the time to read through this.

Cheers

rich.

>
> regards,
> Nikos