OASIS eXtensible Access Control Markup Language (XACML) TC

does anyone recall why there is an x500Name-match and an x500Name- 
equal function in the spec? they seem to serve the same purpose  
however the latter is more concisely written and it almost seems as if  
it was meant to supersede the -match function.

thanks

b

All,

These were defined before my time in the TC, but when I read the spec, 
it appears clear to me that "equal" returns true only on exact equality 
and "match" returns true if the first argument matches a terminal 
sequence of the second argument. In an example:

first argument: ou=xacml,o=oasis
second argument: dn=alice,ou=xacml,o=oasis

in this case

x500-equal -> false
x500-match -> true

Or at least this is my interpretation of "terminal sequence".

Best regards,
Erik


bill parducci wrote:
> does anyone recall why there is an x500Name-match and an 
> x500Name-equal function in the spec? they seem to serve the same 
> purpose however the latter is more concisely written and it almost 
> seems as if it was meant to supersede the -match function.
>
> thanks
>
> b
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

ok, i read the x500  thread in comments about 6 times and i think i understand both sides of the discussion. it seems like there is a simple solution to "fix" it:

original:
• urn:oasis:names:tc:xacml:1.0:function:x500Name-match 
This function shall take two arguments of "urn:oasis:names:tc:xacml:2.0:data-type:x500Name" and shall return an "http://www.w3.org/2001/XMLSchema#boolean".  It shall return “True” if and only if the first argument matches some terminal sequence of RDNs from the second argument when compared using x500Name-equal.  

proposed change:
• urn:oasis:names:tc:xacml:1.0:function:x500Name-match 
This function shall take two arguments of "urn:oasis:names:tc:xacml:2.0:data-type:x500Name" and shall return an "http://www.w3.org/2001/XMLSchema#boolean".  It SHALL return “True” if and only if the entire first argument matches the terminal sequence of RDNs from the second argument when compared using x500Name-equal. 

i made the first change to correct the perception that only a portion of the first argument must be matched. using the example in the thread this:

first argument: ou=hello,o=oasis
second argument: dn=alice,ou=xacml,o=oasis

would be false.

i made the second change to be precise, effectively stating that comparison must start at the last RDN on each string and work backwards. therefore this:

first argument: dn=alice,ou=xacml
second argument: dn=alice,ou=xacml,o=oasis

would be false

and this:

first argument: ou=xacml,o=oasis
second argument: dn=alice,ou=xacml,o=oasis

would be true.

despite the plural nature of the text, i think the intent of this function was to allow 1:n RDNs to match. if so, then we should modify this:

sequence of RDNs

to say this:

sequence of one or more RDNs 

making this true:

first argument: o=oasis
second argument: dn=alice,ou=xacml,o=oasis

if not, then we should clarify and say this:

sequence of two or more RDNs 

making this an ERROR:

first argument: o=oasis
second argument: dn=alice,ou=xacml,o=oasis

because you cannot have single RDN for first argument in this definition.

thoughts?

b

Hi Bill

the first problem I have is with the wording terminal sequence. 
Terminal sequence of an X.500 DN, from an X.500 perspective, is the leaf 
end of the DIT. In X.500 DNs are written as strings in little-endien 
order, ie. they typically start with C= and typically end with CN=. LDAP 
then reversed this in its string format of RDNs, to be conformant with 
DNS big-endian name forms. So if you make the statement "terminal 
sequence of RDNs" it is ambiguous, do you mean the X.500 terminal 
sequence or the LDAP terminal sequence? I would therefore propose that 
the text is reworded to specify the semantics of what is intended rather 
than relying on the syntax of the particular strings. Semantically what 
is intended is that the two specified DIT subtrees match. So my 
rewording would be

"it SHALL return “True” if and only if the subtree specified by the 
first argument matches the root of the subtree specified by the second 
argument, when compared using x500Name-equal."

The second problem I have is, what if the first subtree is smaller than 
the second subtree? Do they still match? In all of Bill's examples, the 
first subtree was larger than the second subtree. So what is the result 
of the reverse case e.g.

first argument: dn=alice,ou=xacml, o=oasis
second argument: o=oasis

is this a match or not? If it does match, then the above text is 
sufficient. If it does not, the above text will need supplementing with 
"The first subtree must be larger than or equal to the second subtree".

regards

David


bill parducci wrote:
> ok, i read the x500  thread in comments about 6 times and i think i 
> understand both sides of the discussion. it seems like there is a simple 
> solution to "fix" it:
> 
> original:
> • urn:oasis:names:tc:xacml:1.0:function:x500Name-match 
> This function shall take two arguments of 
> "urn:oasis:names:tc:xacml:2.0:data-type:x500Name" and shall return an 
> "http://www.w3.org/2001/XMLSchema#boolean".  It shall return “True” if 
> and only if the first argument matches some terminal sequence of RDNs 
> from the second argument when compared using x500Name-equal.  
> 
> proposed change:
> • urn:oasis:names:tc:xacml:1.0:function:x500Name-match 
> This function shall take two arguments of 
> "urn:oasis:names:tc:xacml:2.0:data-type:x500Name" and shall return an 
> "http://www.w3.org/2001/XMLSchema#boolean".  It SHALL return “True” if 
> and only if the entire first argument matches the terminal sequence of 
> RDNs from the second argument when compared using x500Name-equal. 
> 
> i made the first change to correct the perception that only a portion of 
> the first argument must be matched. using the example in the thread this:
> 
> first argument: ou=hello,o=oasis
> second argument: dn=alice,ou=xacml,o=oasis
> 
> would be false.
> 
> i made the second change to be precise, effectively stating that 
> comparison must start at the last RDN on each string and work backwards. 
> therefore this:
> 
> first argument: dn=alice,ou=xacml
> second argument: dn=alice,ou=xacml,o=oasis
> 
> would be false
> 
> and this:
> 
> first argument: ou=xacml,o=oasis
> second argument: dn=alice,ou=xacml,o=oasis
> 
> would be true.
> 
> despite the plural nature of the text, i think the intent of this 
> function was to allow 1:n RDNs to match. if so, then we should modify this:
> 
> sequence of RDNs
> 
> to say this:
> 
> sequence of one or more RDNs 
> 
> making this true:
> 
> first argument: o=oasis
> second argument: dn=alice,ou=xacml,o=oasis
> 
> if not, then we should clarify and say this:
> 
> sequence of two or more RDNs 
> 
> making this an ERROR:
> 
> first argument: o=oasis
> second argument: dn=alice,ou=xacml,o=oasis
> 
> because you cannot have single RDN for first argument in this definition.
> 
> thoughts?
> 
> b

-- 

Aung San Suu Kyi

Thousands of people including British Prime Minister Gordon Brown, 
Archbishop Desmond Tutu, Vaclav Havel, David Beckham, Daniel Craig, 
Stephen Fry and countless others are calling for the release of Aung San 
Suu Kyi.

Show your support and add your message today
Just go to http://www.64ForSuu.org to add a video, text, image or twitter.

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

> the first problem I have is with the wording terminal sequence.  
> Terminal sequence of an X.500 DN, from an X.500 perspective, is the  
> leaf end of the DIT. In X.500 DNs are written as strings in little- 
> endien order, ie. they typically start with C= and typically end  
> with CN=. LDAP then reversed this in its string format of RDNs, to  
> be conformant with DNS big-endian name forms. So if you make the  
> statement "terminal sequence of RDNs" it is ambiguous, do you mean  
> the X.500 terminal sequence or the LDAP terminal sequence? I would  
> therefore propose that the text is reworded to specify the semantics  
> of what is intended rather than relying on the syntax of the  
> particular strings. Semantically what is intended is that the two  
> specified DIT subtrees match. So my rewording would be
>
> "it SHALL return “True” if and only if the subtree specified by the  
> first argument matches the root of the subtree specified by the  
> second argument, when compared using x500Name-equal."

good point. this makes sense.

> The second problem I have is, what if the first subtree is smaller  
> than the second subtree? Do they still match? In all of Bill's  
> examples, the first subtree was larger than the second subtree. So  
> what is the result of the reverse case e.g.
>
> first argument: dn=alice,ou=xacml, o=oasis
> second argument: o=oasis
>
> is this a match or not? If it does match, then the above text is  
> sufficient. If it does not, the above text will need supplementing  
> with "The first subtree must be larger than or equal to the second  
> subtree".

personally, i think that allowing the second subtree to be larger  
doesn't make sense. my understanding of the intended functionality is  
to provide a way to define a base context that would match a set of  
subcontainers/nodes. allowing for a match in the case above would  
effectively create a match that exceeds the scope of the first  
expression. this seems Bad to me.

b