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

["Drummond Reed" <drummond.reed@cordance.net>]

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/members/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
.