Re: X.509 certificate and its subject name field

[Peter Williams <peter@xxxxxxxxxxxx>]

Anil R. Gangolli wrote:

> I can no longer resist adding my own comments:
>
> (A) Peter says that it is common practice in https servers to use
> a hash of the (entire) certificate as a key for mapping to a user,
> but I'm not sure which ones he's referring to.  The ones I know about
> (Netscape's) do not do this.
>
Are you sure the imputation is what I said: :-)

"Folks may want to recall that in practical https systems deployed
today, certificate-based access control is actually keying off the
hash(cert), not any component of the certificate. "

Are you sure that IIS3, and Netscape https-capable web servers fail to
provide
the SSL3 client certificate to servlet  applications (CGI, server-side
components, asp
scripts, java applications) for servlet/system validation and use
(including impersonation) of accounts
or network ids in the pre-established I&A & authorization sub-systems of
the local  host  (or
local network domain) hosting the web server when resolving access to
non-public resources
in that host, potentially in that domain or potentially other domains
accessible to that nework id?

A practical access control system will surely map certs onto OS accounts

and exploit acls provided by, and enforced by, the OS. Relabelling every
resource for each
protocol (https export) is surely not practical, or cost-effective.
Also, if one wishes to assure oneself that
access is operationally mediated by a C2 compliant deployment, then one
must rely on TCB-based
enforcement of the security policy model, and know that the model
correctly enables the discreationary access control policy  of
C2 rated products/systems (and B2/B3 DAC rules also, if it
comes for free, as with NT!)

If the (Netscape) LDAP server relies on the OS security to enforce user
impersonation rights when the web-server access resources, then this is
fair enough,
as I said; redundant, but fair. NCSC Red Book Distributed Network
security access
control  provided by conforming OSs will compete with distributed
Directory-based access controls,
inevitably, should application-layer directories become commonplace
security infrastructure elements.
(Personally, in the NT5 time-frame,  I see distributed directory
security, and distributed network-domain
security mechanisms merging, for mass-market enterprise products.)

I think my really big point was, if one remembers, that cert contents do
not
*have to* matter and therefore rants about "correct" content forms do
not have to be as critical
as some are alluding; certs can merely be an impersonation token
conveyed securely
via SSL, or any other operational protocol, and then mapped to a more
convenntionally
administered account and authorization regime.

This is how NT's IIS basic authentication work nowadays! (I've
personally no longer much
idea about Netscape servers, given the parsity of public information.)
I'm really not inventing anything!
Imagine that the SSL-client auth cert is an password-replacement
technique for http basic authentication and
host login. Surely, the name in the cert has to be no more descriptive
than the name in the
username/password combo. I did not need a new LDAP server to manage ACLs
for my basic
authentication & authorization; nor do I NEED it therefore for
certificate variations of authenticating
login credentials or thereafter constrain what resources that
id(account) can access.

The dynamics of managing the acls, given cert can expire, are the same
as the dynimcs of
managing password which automatically expire. Security admins will not
see much
change of process (just a switch of technology), and this is what is so
practical!


Peter.