[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] RE: Comparing KeyInfos. Forwarded message from john howard.
------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC