[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Announcing mod_ssl_user

From: Martin v. L÷wis <martin_at_v.loewis.de>
Date: 2003-06-21 12:58:30 CEST

Colin Watson <cjwatson@flatline.org.uk> writes:

> I usually prefer to see usernames in commit messages because, when I'm
> working in technical contexts, I think of people by their usernames.
> Plus, as above, it's clearly a far more correct choice of primary key.
> Annotating with the real name would be fine if it's manageable.

Certainly. If Debian would start to use SSL client authentication for
Subversion, some sort of solution would have to be found. There would
need to be a decision whether Debian would use its own CA, or whether
it would accept "foreign" certificates (e.g. from Verisign).

If Debian would use its own CA, the user DNs could be constructed
up-front to include the user-id (0.9.2342.19200300.100.1.1) in the CN,
and then use

SSLUserName SSL_CLIENT_S_DN_userID

If Debian would accept arbitrary certificates (from a set of trusted
CAs), there would be no choice but to use FakeBasicAuth, which would
then set the username to the full DN - I'm certain that the two users
with the same common name would still have different DNs. At that
point, enhancing the FakeBasicAuth mechanism to include a mapping to
local user names might be appropriate.

In neither case, additional attributes in the certificate would be
used. In the first case, it would not be needed, since constructing
the DNs so that they really identify the user uniquely seems
desirable. In the second case, it could not be used, since the foreign
CA just would not provide certificates that include Debian user names.

Regards,
Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 21 12:59:28 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.