RE: [xacml-comment] X500 Name Match unclarity

[Florian Huonder <fhuonder@herasaf.org>]

Hi Bill,

I am from the HERAS-AF project and we provide an OpenSource XACML
Implementation. Therefore we have to implement the X500Name-match and
X500Name-equal functions.
We currently implemented "Possibility 1", but we are not sure if
"Possibility 2" would be right.

It may be, I cannot assess this, that either the equals or the match
function could be omitted because they may have the same intent.
For us as implementers this would be an important hint so we could update
the implementation and refer to this thread (or to any other).

Regards,
Flo

PS. I just saw your comment on the [xacml] mailing list. I am looking
forward to clarify this issue.

-----Original Message-----
From: bill parducci [mailto:bill@parducci.net] 
Sent: Mittwoch, 27. Mai 2009 16:10
To: Florian Huonder
Cc: xacml-comment@lists.oasis-open.org
Subject: Re: [xacml-comment] X500 Name Match unclarity

Will x500Name-equal meet your needs? This has a more precise  
description and to be honest, I think it was meant to supersede the - 
match but I could be mistaken.

b



+++



urn:oasis:names:tc:xacml:1.0:function:x500Name-equal

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 each Relative Distinguished Name  
(RDN) in the two arguments matches.  Otherwise, it SHALL return  
"False".  Two RDNs shall be said to match if and only if the result of  
the following operations is "True" .

1.     Normalize the two arguments according to IETF RFC 2253  
"Lightweight Directory Access Protocol (v3): UTF-8 String  
Representation of Distinguished Names".

2.     If any RDN contains multiple attributeTypeAndValue pairs, re- 
order the Attribute ValuePairs in that RDN in ascending order when  
compared as octet strings (described in ITU-T Rec. X.690 (1997 E)  
Section 11.6 "Set-of components").

3.     Compare RDNs using the rules in IETF RFC 3280 "Internet X.509  
Public Key Infrastructure Certificate and Certificate Revocation List  
(CRL) Profile", Section 4.1.2.4 "Issuer".






On May 27, 2009, at 12:44 AM, Florian Huonder wrote:

> Hi all,
>
> I am talking about the X500 name match function
urn:oasis:names:tc:xacml:1.0:function:x500Name-match 
>  (XACML 2.0 Spec).
> There in the description the term "terminal sequence" is used but  
> this does not exist in any X500 specifications.
> Therefore it is undefined and therefore it leaves room for  
> interpretation.
>
> Possibility 1:
> True is returned in case when all elements of the X500Name in the  
> request are contained in the X500Name in the Policy, in any order.  
> The number of elements must not match but the number of elements in  
> the request must be at least as much as in the Policy.
>
> Possibility 2:
> The term "terminal sequence" can be interpreted as "the last element  
> of the X500 names must match and not all elements.
>
> Could anybody tell me how this x500Name-match function must be  
> implemented?
>
> Regards,
> Florian