[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]