RE: mapping identities RE: Compromise Authentication Proposal

[Christopher Oliva <Chris.Oliva@entrust.com>]

I'm a little concerned with section 9.1 of the document to which you
refer. I think there is room to clarify the situation with respect to
mapping of identities and what is meant by the statement "A server which
supports mappings of names MUST be capable of being configured to
support certificates for which no mapping is required." I assume what
this means is that the "subject name" of the certificate does not need
to be mapped to an entry DN.

Furthermore, certificates may contain the subjectAltName extension
field. This allows the "subject name" to be specified in a variety of
alternate (non distinguished name) formats such as email address, ip
address, OID etc. What I'm suggesting is that no mapping of these names
should be required to a DN or entry within the directory system and that
the ldap access controls allow the configuration of authorization
identities based on the subjectAltName. Also note that a certificate may
contain multiple subjectAltNames and/or subject name and that each of
those unambiguously identify the subject.

Chris.

> ----------
> From: 	Jeff.Hodges@stanford.edu[SMTP:Jeff.Hodges@stanford.edu]
> Sent: 	Thursday, October 08, 1998 4:18 PM
> To: 	ietf-ldapext@netscape.com
> Subject: 	Re: mapping identities RE: Compromise Authentication
> Proposal 
> 
> Just to point out: separating the concepts of "authentication
> identities" from 
> "authorization identities", which is what this subthread is nominally
> about -- 
> ~is~ addressed in draft-ietf-ldapext-authmeth-02.txt (and in SASL
> (RFC2222)). 
> See sections 5 and 11 in authmeth-02, and section 3 (para 6 & 7) in
> RFC2222.
> 
> Note that I am going to be (real soon now) moving
> authmeth-02:section-5 (back) 
> into draft-ietf-ldapext-ldapv3-tls so that the latter may be
> progressed 
> without dependence on authmeth.
> 
> Jeff
> 
> 
> 
>