|Subject:||RE: [xacml-comment] X500 Name Match unclarity|
|From:||Florian Huonder (fhuo...@herasaf.org)|
|Date:||May 27, 2009 7:33:26 am|
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).
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:bi...@parducci.net] Sent: Mittwoch, 27. Mai 2009 16:10 To: Florian Huonder Cc: xacm...@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.
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 126.96.36.199 "Issuer".
On May 27, 2009, at 12:44 AM, Florian Huonder wrote:
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?
-- This publicly archived list offers a means to provide input to the OASIS eXtensible Access Control Markup Language (XACML) TC.
In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting.
Subscribe: xacm...@lists.oasis-open.org Unsubscribe: xacm...@lists.oasis-open.org List help: xacm...@lists.oasis-open.org List archive: http://lists.oasis-open.org/archives/xacml-comment/ Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: http://www.oasis-open.org/maillists/guidelines.php Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml