Experiments with GnuTLS and Qt

[Richard Moore]

On Mon, Jan 9, 2012 at 8:12 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> 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.

Great.

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

Yeah, I managed to avoid the need for casting here, but I think
treating them consistently would be clearer.

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

Great, I think there's an internal function that does most of this
anyway from reading the sources.

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

Yeah, that really wouldn't be sufficient here. The code I have will do
the job, and with the function to convert to human readable names
would work just fine.

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

I think right now there's no real evidence that this is really any
kind of real world impact, so I totally agree that there's no point in
expending effort here right now.

Cheers

Rich.