[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OID syntax and NAMEs



Howard Chu wrote:
> Michael Ströder wrote:
>> Howard Chu wrote:
>>> Michael Ströder wrote:
>>>> Eventual I'd like to have a constraint like this:
>>>>
>>>> # check whether appropriate password policy is assigned
>>>> constraint_attribute structuralObjectClass,pwdPolicySubentry
>>>>   set "this/structuralObjectClass & this/pwdPolicySubentry/aeApplicableSOC"
>>>
>>> Not possible without custom code.
>>
>> Hmm, are this/structuralObjectClass and this/pwdPolicySubentry generally
>> unusable in set-constraints?
>>
>> Or does it not work because of the different matching rules?
> 
> Yes, because of the matching rule issue.
> 
> This seems to be a deficiency in either ASN.1 or the LDAP spec, I'm not sure 
> which. The problem is that numeric OIDs are obviously unique, but there's no 
> guarantee that string names are. Moreover, the same name might apply to the
> OID of an attribute, or an objectclass, or a syntax, or some other entity,
> and there's no way to tell the objectIdentifierMatch rule which context is
> relevant. So, we can only match on numeric OIDs.

Hmm, in theory one could normalize the value of this/structuralObjectClass based
on the context to the unique OID as its canonical representation before doing
the comparison with the OID in this/pwdPolicySubentry/aeApplicableSOC.

My naive understanding was that it's done like this to correctly match NAME
aliases used in assertion values during normal search.

Not sure whether that's feasible in OpenLDAP code for sets though.

Ciao, Michael.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature