On 2007.12.20 at 16:55:43 +0000, Dr Stephen Henson wrote: > Well it depends what you want to do. A (usually) readable representation > of an X509 DN would have needed X509_NAME_oneline() back then. > > A portable way of using DNs for access control could use either the DN
What do you mean under "portable"? I see no appearant reason why any of the meanings of this word should be applied to authentication and access control. Unless we use LDAP or simular directory service. But LDAP libraries would have its own ASN.1 parsing library anyway. I'm rather thinking of "managable" way. How to make it easy for system administrator to find out neccessary record in access control file (in order to disable or change), or even add new record without having user certificate handy. And, of course, how to tell from the quick glance on the file which users have which permissions. > > And most of OpenSSL applications have same problem. I've already spend > > considerable time convincing authors of various applications, that > > OPENSSL_config (which is already here from 0.9.7) ought to be called. > > > > And mod_ssl is one such application. I've submitted a patch that does > this properly in Bug #43931. I think that mod_ssl (as well as stunnel and openvpn) have good reasons to be considered an exception from the rule "Every OpenSSL application should read site-wide openssl.cnf". Reason 1. It has its own sophisticated configuration, so nothing prevent it from configuring everything from its own configuration file. And configuration would be kept in one place. Reason 2. It is an application, concerning primarily with cryptography and security. If we talk about some client application such as openssl-based web browser or mail client, users pay very small attention to cryptography related settings in their configs unless things are broken really badly. System administrator of HTTPS server would pay attention to such things, otherwise why he got into trouble installing mod_ssl at all. Reason 3. It is server application. So, there are two main use cases: 1. We have a machine destinated to serve web pages. In this case site-wide openssl.cnf can be tuned to the needs of mod_ssl. But it just means splitting server configuration into two files with different syntax. 2. We have a multipurpose machine, say multiuser host with interactive users which also serves as small intranet server. In this case openssl.cnf would probably be tuned to the needs of interactive users, because they run many different ssl-enabled client programs. And openssl.cnf is only place where common configuration for this programs can be kept. Apache, quite probably would have different requirements for OpenSSL configuration. So, server administrator would have to write separate openssl.cnf for web server. And we fall back to the case 1 - have two files with different syntax where one would suffice. > Unfortunately the X509_NAME_oneline() format is ambiguous meaning that > some DNs cannot be converted to a correct new form. Use of multi valued This is not a problem for CA which have base of certificates handy. Really there are few applications which do such things. I've tested dozen or so widespread OpenSource SSL applications for GOST support and find only one which uses list of printable CN representations for access control - netkit-telnetd. Main reason, I think, is that people do not trust common commercial CAs enogh to grant access just because VeriSign or something alike signed certificate that given public key belongs to user John Doe. If take trouble to run own CA, it is easier to use certificate fingerprint, although it is not readable.
