Experiments with GnuTLS and Qt

[Nikos Mavrogiannopoulos]

On 01/09/2012 02:35 PM, Richard Moore wrote:

>> - 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.


Thanks. I've removed that. It will be included in the next release.

> 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 *.


When supplying an OID the const char* type is used, while when gnutls
is copying an OID, it copies to a void* pointer. In both cases though
a null terminated string is used/copied. We might change those (void*)
to (char*) in a future version.

>> - 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.


This look pretty simple. I'll add a function for that.

>> 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.


No this what I meant. What I meant is to get a single string and
treat it as being "the full name", rather than getting each field of
DN in separate. But since you have this multiple strings requirement
it doesn't look practical.

>>  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'.


It can be optimized, e.g. using a hash table, but given that we support a 
handful of DN OIDs, it doesn't really make sense. If it proves to be a 
bottleneck we reconsider.

regards,
Nikos