[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Summary of group discussion
Michael Ströder wrote:
Howard Chu wrote:
The other alternative is to fix the LDAP definition of the
NameAndOptionalUID syntax, so that it's actually usable in LDAP.
Given the bass-ackward RDN ordering that was chosen for the string
representation of DNs in LDAP, the only unambiguous thing to do with
these is to put the x500uniqueIdentifier *first* in the string. So
revise RFC4517's definition 3.3.21
NameAndOptionalUID = [BitString] distinguishedName
The SHARP character in the current definition is extraneous since the
BitString definition is already fully delimited.
If we fix this syntax then I would drop all objections relating to its use.
1. I don't any deployment which uses the optional BitString part. The
deployments I know just use the distinguishedName.
Right. I doubt that anyone will ever notice a change here.
2. The implementations I know which might make use of the optional UID part
did not use a BitString there. They messed it up with attribute 'uid' (which
is of DirectoryString).
Then they're broken regardless of what we decide.
3. Changing declaration in RFC 4517 would potentially break things.
For a very very small number of deployments. I suspect the number is zero.
=> My suggestion would be to add an applicability note to section 3.3.21 which
states that either distinguishedName MUST NOT contain SHARP. Or maybe it would
be possible to mandate that SHARP MUST be escaped like described in RFC 4514.
No, changing the escaping rules for DNs would definitely break things.
Also, on the topic of X.500 compatibility, as Jochen pointed out:
>> UserClasses ::= SEQUENCE {
>> allUsers [0] NULL OPTIONAL,
>> thisEntry [1] NULL OPTIONAL,
>> name [2] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL,
>> userGroup [3] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL,
>> -- dn component shall be the name of an
>> -- entry of GroupOfUniqueNames
>> subtree [4] SET SIZE (1..MAX) OF SubtreeSpecification OPTIONAL }
ACIs specifying users are also not just simple DNs. The obvious implication is
that when a user with an associated x500UniqueIdentifier authenticates to a
DSA, this UID must also be included in the authzID that the DSA associates to
the session. RFC4511 doesn't mention anything about this. Additionally, X.501
16.4.2.4 (g) Note 3
NOTE 3 – When authentication is based on supplied SecurityParameters,
the unique identifier associated with the user may be taken from the
subjectUniqueIdentifier field of the sender’s Certificate in the optional
CertificationPath
I would take this to mean that if an LDAP session was authenticated with
SASL/EXTERNAL using an X.509 client cert, the LDAP DSA SHOULD look for the
cert's subjectUniqueIdentifier. But I guess that's a digression for another
thread...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext