On Mon, Jan 9, 2012 at 8:12 PM, Nikos Mavrogiannopoulos <[email protected]> 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. _______________________________________________ Help-gnutls mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-gnutls
