RE: [xri] RE: [xri-editors] URI authority resolution

["Wachob, Gabe" <gwachob@visa.com>]

That would definitely be a step in the right direction! 

As I think Dave pointed out, I don't think a XRID-policing policy can be trusted for ensuring that the registering party (person who created the XRID) can be trusted. I think "trusted" resolution can only provide trust in the fact that the data provided by a directory is in fact the unaltered XRID data actually being published by the authority (on behalf of the registering party who initially created the XRID). 

	-Gabe
 
__________________________________________________ 
gwachob@visa.com
Chief Systems Architect
Technology Strategies and Standards
Visa International 
Phone: +1.650.432.3696   Fax: +1.650.554.6817


> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Tuesday, November 30, 2004 11:38 PM
> To: 'Drummond Reed'; Wachob, Gabe; 'Davis, Peter'; 'Dave McAlpin'
> Cc: xri@lists.oasis-open.org
> Subject: RE: [xri] RE: [xri-editors] URI authority resolution
> 
> 
> Gabe,
> 
> Dave called me to explain that in your scenario, the trusted 
> resolution
> signatures should be interpreted as applying only to the 
> authenticity of the
> XRID, and not as assertions that the "OtherXRIs" in the body 
> of the XRID are
> valid.
> 
> He feels a SAML assertion should be enclosed in the XRID if 
> the authority is
> actually vouching for these "OtherXRIs".
> 
> This makes sense to me. But it reinforces that we should be 
> sure to make it
> clear what is and is not "trusted" in the trusted resolution spec. 
> 
> =Drummond 
> 
> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> Sent: Tuesday, November 30, 2004 4:29 PM
> To: 'Wachob, Gabe'; 'Davis, Peter'; 'Dave McAlpin'
> Cc: xri@lists.oasis-open.org
> Subject: [xri] RE: [xri-editors] URI authority resolution
> 
> Gabe, the trust chain in your scenario doesn't make sense to 
> me. The XRID
> you describe as being resolved from "@community*evilmember" 
> asserts that it
> is equivalent to "@!1!2!3". And you're saying it is 
> "@microsoft" that is
> really equivalent to "@!1!2!3".
> 
> That's cool - so there are 3 delegation chains represented 
> here - two i-name
> chains and one i-number chain.
> 
> 1) "@" delegates to "*community" delegates to "*evilmember".
> 2) "@" delegates to "*microsoft" (we should avoid real names in these
> examples).
> 3) "@" delegates to "!1" delegates to "!2" delegates to "!3".
> 
> In your scenario, "@community" is the authority that would 
> return the XRID
> for "*evilmember". And if that XRID contains a digitally 
> assigned assertion
> that "@community*evilmember" is equivalent to "@!1!2!3", then its the
> "@community" registry that can't be trusted, not "*evilmember". 
> 
> Presumably any registry that is going to issue assertions of 
> equivalence
> between XRIs is going to require authentication from the 
> registrants of
> those XRIs. So before "@community" enters into its registry and starts
> signing assertions that "*evilmember" is equivalent to "@!1!2!3",
> "@community" should be asking the "@!1!2" registry for 
> authentication that
> the registrant of "*evilmember" is also the registrant of "@!1!2!3".
> 
> On the other hand, if the XRID from the "@" registry asserts that
> "@microsoft" is equivalent to "@!1!2!3", the it's the @ 
> registry (or its
> registrars) that should authenticate that the registrant of 
> "@microsoft" is
> also the registrant of "@!1!2!3".
> 
> Either way, it's still up to the resolver to decide what 
> registry it trusts.
> But the whole idea of trusted resolution is predicated on 
> following a chain
> of trust down the delegation chain, right?
> 
> I'm very familiar with this scenario as we're building the 
> foundation for it
> in the XDI.ORG Global Services Specifications right now.
> 
> Or have I missed a larger point in your scenario?
> 
> =Drummond 
> 
> 
> -----Original Message-----
> From: Wachob, Gabe [mailto:gwachob@visa.com] 
> Sent: Monday, November 29, 2004 3:00 PM
> To: Davis, Peter; Drummond Reed
> Cc: xri-editors@lists.oasis-open.org
> Subject: RE: [xri-editors] URI authority resolution
> 
> I'd argue that even your trusted rez example can't be 
> trusted. Consider the
> following, where everything is signed by a single trusted 
> root (ie the @
> trust root):
> 
> @microsoft "maps" to @!1!2!3
> 
> @community*evilmember "maps" to @!1!2!3
> 
> Both are digitally signed by their owners (@microsoft and
> @community*evilmember respectively). Even if @ polices its 
> namespace, it
> doesn't follow that it can police the XRI Descriptors which 
> are in delegated
> namespaces below @ such as @community.
> 
> If we allow the "maps" assertion to be two way (ie 
> "equivalence"), then some
> resolvers could be tricked into thinking that @!1!2!3 can be mapped to
> @community*evilmember (since equivalence can be stated as a 
> bidirectional
> mapping). Whats wrong with this? Consider this attack:
> 
> 1) A resolver resolves @community*evilmember into an XRI 
> Descriptor has
> statements about local access services that point to the 
> evilmember. The
> resolver caches the XRI Descriptor and notes the equivalence 
> statement for
> future use.
> 2) A resolver resolves @microsoft into @!1!2!3 via a "equivalence" 
> 3) Because @!1!2!3 is asserted to be the same as 
> @commmunity*evilmember, the
> resolver uses the cached XRI Descriptor for 
> @community*evilmember instead of
> freshly resolving @!1!2!3 (ie transitive equivalence)
> 4) The resolver is tricked into using the local access services of
> @community*evilmember rather than the ones actually run by 
> microsoft...
> 
> The problem lies in step 3 where a strong form of 
> bidirectional & transitive
> equivalence is assumed. Thats a problem, even if everyone is digitally
> signed a la trusted resolution. 
> 
> Assertions should only be made "outwards" from what is 
> resolved and not
> "inwards" to what is resolved (if that makes sense).
> 
> 	-Gabe
>  
> __________________________________________________ 
> gwachob@visa.com
> Chief Systems Architect
> Technology Strategies and Standards
> Visa International 
> Phone: +1.650.432.3696   Fax: +1.650.554.6817
> 
> 
> > -----Original Message-----
> > From: Davis, Peter [mailto:peter.davis@neustar.biz]
> > Sent: Monday, November 29, 2004 2:42 PM
> > To: Drummond Reed
> > Cc: xri-editors@lists.oasis-open.org
> > Subject: RE: [xri-editors] URI authority resolution
> > 
> > 
> > so, i agree with Gabe, in that equiv. statements are at the 
> addressing
> > layer, and we should use a term such as 'mapping' when 
> > discussing other
> > xri's which point to the same representation.
> > 
> > trustable mapping is performed via trusted resolution, which 
> > returns an
> > assertion of equivalence... that is, an assertion that
> > @Microsoft/(+website) is another name for the resource 
> > representation of
> > http://www.microsoft.com/ or @!1!2!3/(+website)
> > 
> > 'synonym' is as good a term as any i suppose, tho linguistically,
> > synonyms tend to imply a more lax equivalence.
> > 
> > --- peterd
> > 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the
> OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/xri-editors/membe
rs/leave_workg
roup.php.




To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php
.