Re: SASL/EXTERNAL (TLS)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 12:04 PM 8/17/00 +0200, Michael Ströder wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> The authentication identity can be in any form.
>
>The identity has to be unique?

It doesn't not have to be globally unique. But, locally,
it should be unique with the realm and mechanism.


>>  I rather the
>> form be as "natural" as possible.  That is, if the authentication
>> identity is derived from an X.509 certificate, the identity
>> should be "natural" (e.g. X.500) form.
>
>I would not even speak of a X.500 form when using a cert DN since
>most CAs issue certs without caring about directory structure at
>all. E.g. look at my freemail cert DN issued by Thawte:
>
>/S=Stroeder/G=Michael/CN=Michael Stroeder/Email=michael@stroeder.com

Which is exactly why we should use this, the natural form, as the
authentication identity.

>Just use the cert DN as unstructured but unique identifier
>regardless of being meant as X.500 name in former days.

Exactly what we are doing.  We're rely on the underlying service,
TLS in this case, to provide a string representing the authentication
identity.  We support any form.  When no separate authorization
identity is provided, we imply an authorizaton identity of:
  u:/S=Stroeder/G=Michael/CN=Michael Stroeder/Email=michael@stroeder.com

Which we'll then try turned into the DN:
  uid=S=Stroeder/G=Michael/CN=Michael Stroeder/Email=michael@stroeder.com

but will fail due to use of characters which need to be escaped.
When I (or someone else) gets a chance, we'll implement escaping,
so it will be:
  uid=S\3DStroeder/G\3DMichael/CN\3DMichael Stroeder/Email\3Dmichael@stroeder.com

And once Mark gets done, it likely will look like:
  uid=S\3DStroeder/G\3DMichael/CN\3DMichael Stroeder/Email\3Dmichael@stroeder.com, cn=EXTERNAL, cn=AUTHZ

when you can then regex into the DN of your choice.

>Note: The
>cert DN has only to be unique within the name-space of a CA. Two
>different CAs can issue different certs with the same DN.

True.  ldap_pvt_tls_get_peer() will likely need to
be extended to support a variety of other certificate types
and/or authentication forms as well as to deal with name-space
issues.  Likely "X509:" should be prefixed to X.509 certificates
and a CA DN appended.  So, we'd end up with a authcId of

  X509:S\3DStroeder/G\3DMichael/CN\3DMichael Stroeder/Email\3Dmichael@stroeder.com//CA:ca-x500-dn

which then would be stuff into the DN as noted above, then
regexed as directed.