[xacml] RE: Comparing KeyInfos. Forwarded message from john howard.

[Anne Anderson <Anne.Anderson@Sun.com>]

------- start of forwarded message -------
From: "john howard" <john.howard@inmezzo.com>
To: <Anne.Anderson@sun.com>
Subject: RE: Comparing KeyInfos
Date: Thu, 3 Oct 2002 18:39:21 +0100

Anne,

Thanks for the reply.  I think the selected approach is the practical one at this time.  Longer term there is an issue with comparing complex objects such as KeyInfo and it will not always be the case that XPath can resolve the problem.  Sometimes knowledge of the object will be required.  e.g. XPath will not resolve the issue were the policy holds a Certificate in it's KeyInfo and the KeyInfo in the context holds the SHA1 hash of the public key.  This is a valid comparison that cannot be resolved using XPath.

John.

-----Original Message-----
From: Anne Anderson [mailto:Anne.Anderson@Sun.com]
Sent: 03 October 2002 18:18
To: john howard
Cc: Anne Anderson
Subject: Re: Comparing KeyInfos


On 2 October, john howard writes: Comparing KeyInfos
 > In a couple of the conformance tests (IIB016, 11B017) there is
 > a requirement to compare KeyInfos.  The comparison is
 > performed as a string-match even though the data type is
 > KeyInfo.  As KeyInfos can be compared in a number of ways the
 > string-match would appear inadequate.  e.g. In the simple case

 > <ds:KeyInfo>
 > 	<ds:KeyName>jhibbert-key</ds:KeyName>
 > </ds:KeyInfo>
 > 
 > would not match 
 > <ds:KeyInfo>
 > 	<ds:KeyName>jhibbert-key</ds:KeyName>
 > 	<ds:KeyValue>....</ds:KeyValue>
 > </ds:KeyInfo>
 > 
 > Although the KeyInfos are the same.
 > 
 > Is there a need for a keyinfo-match function or is there a
 > more generic object-match that would match based on the data
 > type and therefore be completely extendable.

John, we discussed this in today's meeting.  There are four
approaches:

1) We decided that a keyInfo-match function would be very
   complex, given the structure of a ds:KeyInfo element.  There
   certainly is not time to do this right for XACML 1.0.
2) A second option would be to define a separate
   identifier:subject: attribute for each leaf sub-element in the
   ds:KeyInfo structure.  We do not feel this is important enough
   to justify defining more attributes before we have some
   experience with use of XACML.
3) Various groups of XACML users could go ahead and define
   attribute identifiers as in 2) in some namespace that they
   control.  They could propose their set to XACML for inclusion
   in 1.0+.
4) Use an <AttributeSelector> with an XPATH expression to pull
   out the specific element of the ds:KeyInfo you want, then use
   one of the XACML-defined functions to compare it to the value
   you want.  This is the official solution for 1.0.  We will add
   text about this to Appendix A (Functions) under a new heading
   "Structured Types".

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

------- end of forwarded message -------

-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692