(More for documentation than anything else right now...) I've verified that the *applications* (at least 'req') do understand these fields. For an DNS-style LDAP-ish DN the openssl.cnf file should have something like this:
[ policy_match ] commonName = supplied organizationalUnitName = optional domainComponent = match [ policy_anything ] commonName = supplied organizationalUnitName = optional domainComponent = optional [ req_distinguished_name ] commonName = Common Name commonName_max = 64 0.organizationalUnitName = Subcategory (e.g., Students) 0.organizationalUnitName_max = 64 1.organizationalUnitName = Category (e.g., Persons, Servers) 1.organizationalUnitName_default = Persons 1.organizationalUnitName_max = 64 # global TLDS (.com, .org, .net, .edu, .mil) only require two components # national TLDs (.us, .au) require three components # additional components may be desired. 0.domainComponent = domain component 0.domainComponent_max = 64 1.domainComponent = domain component 1.domainComponent_min = 1 1.domainComponent_max = 64 2.domainComponent = TLD domain component (e.g., .com, .us) 2.domainComponent_default = com 2.domainComponent_min = 2 2.domainComponent_max = 4 # no longer 3 due to .info This produces a DN that looks like /CN=Bear Giles/OU=Persons/DC=example/DC=com Before someone asks the obvious question :-), I didn't try this first since I'm working on a database binding that stores and manipulates the X509_NAME value in ASN.1 format, and global 'greps' of the .c files showed a table initialized to handle NID_locality and NID_commonName, but not things like NID_domainComponent. So I'm still not sure that these tables can be used to validate the input to these routines. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
