> bear> NID_domainComponent. So I'm still not sure that these tables > bear> can be used to validate the input to these routines. > > Do I get it right, you're after having the string length limits and > possibly the allowed string types for DC and more in that table?
What I'm ultimately trying to support is database functions to convert between tables and X.509 subjects. I expect this will be a set of functions like: x509name_set_field_string (x509name *name, text *field, text *value, int *pos); I can expect the database user to know "field" means things like "O", "CN" or "DC" (especially if they're all listed in another table :-), but not to know size limits, types, etc. So I want to provide error checking as soon as possible - it's much nicer to have db => update t set name = x509_name_field_string (name,...)... ERROR: domainComponent (DC) must be less than 64 bytes long. than a much more opaque OpenSSL error stack. Hence the attempt to find a table that allows me to check values before I call the actual routines. As for domainComponent in particular, the RFC clearly limits it to 64 octets, and the DNS system has component limits of either 64 or 128 octets. So in this particular case a limit is appropriate. More generally, if the RFC limits the size of any NID, the code should probably enforce it. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
