OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml-comment] The x500Name-match function is not clearly defined


Hi Steven,

Yes, an example would be simple to add.

Best regards,
Erik

On 2011-03-29 07:28, Steven Legg wrote:
>
> Hi Erik,
>
> On 28/03/2011 10:47 PM, Erik Rissanen wrote:
>> Steven,
>>
>> Thank you for your attention. XACML specifies (in section A.2) that 
>> the x500Name data type must use the LDAP
>> form of encoding, so there should not be any ambiguity.
>
> Except that the data-type is called x500Name, which raises an element 
> of doubt
> to a reader who is familiar with X.500 as well as LDAP. A single example
> would be enough to dispel the doubt.
>
> Regards,
> Steven
>
> > It refers to a suffix, which is why the word
>> "terminal" is used.
>>
>> Best regards,
>> Erik
>>
>> On 2011-01-24 07:03, Steven Legg wrote:
>>>
>>> The description of the x500Name-match function in Appendix A.3.14 of 
>>> the
>>> XACML 3.0 core specification is ambiguous. The function operates on 
>>> values of
>>> the x500Name data-type, which despite its name uses the LDAP DN 
>>> format for
>>> its concrete syntax. The source of ambiguity in the function 
>>> definition comes
>>> from the fact that LDAP orders the RDNs in a distinguished name in 
>>> the opposite
>>> order to X.500.
>>>
>>> In my experience, the most common use case for matching of DNs after 
>>> straight
>>> equality matching is testing whether one entry (the descendant) is 
>>> in the
>>> subtree of another entry (the ancestor), including the possibility 
>>> that they
>>> are the same entry. In X.500 terms this means testing whether the DN 
>>> of the
>>> ancestor is the same as, or a prefix of, the DN of the descendant. 
>>> In LDAP
>>> terms this means testing whether the DN of the ancestor is the same 
>>> as, or a
>>> suffix of, the DN of the descendant. It is plausible that this is 
>>> what the
>>> x500Name-match is meant to do so this is how I have implemented it. 
>>> However, it
>>> would better if the standard made this clear. I note also from the mail
>>> archives that the precise meaning of "some terminal sequence of 
>>> RDNs" is open
>>> to interpretation.
>>>
>>> Here is my suggestion for an improved description of the x500Name-match
>>> function:
>>>
>>> This function shall take two arguments of
>>> "urn:oasis:names:tc:xacml:1.0:data-type:x500Name" and shall return an
>>> "http://www.w3.org/2001/XMLSchema#boolean";. It shall return "True" 
>>> if and
>>> only if there is a contiguous sequence of RDNs in the second 
>>> argument that
>>> includes the final (rightmost) RDN and is equal to the first argument
>>> according to the x500Name-equal function.
>>>
>>> For example, the following expression SHALL return "True":
>>>
>>> <Apply 
>>> FunctionId="urn:oasis:names:tc:xacml:1.0:function:x500Name-match">
>>> <AttributeValue 
>>> DataType="urn:oasis:names:tc:xacml:1.0:data-type:x500Name"
>>> >ou=Finance,o=Acme</AttributeValue>
>>> <AttributeValue 
>>> DataType="urn:oasis:names:tc:xacml:1.0:data-type:x500Name"
>>> >cn=John Smith,ou=Finance,o=Acme</AttributeValue>
>>> </Apply>
>>>
>>> Note that LDAP encodes the RDNs in the reverse order to X.500. XACML 
>>> uses
>>> the LDAP encoding for the x500Name data-type and this function is 
>>> defined
>>> in terms of the LDAP ordering.
>>>
>>> Regards,
>>> Steven
>>>
>>
>>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]