httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Victor Wagner <vi...@wagner.pp.ru>
Subject Re: SSL client certificate extensions requirements backport
Date Fri, 21 Dec 2007 08:33:55 GMT
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.


Mime
View raw message