[sldev] UUID variant/version bits?

[John Hurliman]

UUID sharing across domains is a bad idea, since trust and authority 
don't always extend across domains. Some clever attacks can be 
constructed by looking at what exists on domain A, carefully 
constructing things on domain B that will cause a collision, and 
bringing an object from domain A to domain B where only parts of the 
object actually transfer because there were UUID collisions with other 
parts. A single 128-bit integer may or may not be a unique identifier 
but it is not an authoritative identifier like a URI can be.

John

Zha Ewry wrote:
> Well, in theory.. UUIDs are supposed to be Universal, not domain 
> specific. The bit space is supposed to be big enough... If it isn't, 
> then we'll need to migrate to a bigger one. Zero made the argument on 
> Tuesday, that it *is* big enough. If the bits which are supposed to be 
> used to mark UUID type are enough to push the UUID space too small, 
> then.. we need a bigger bit space.
>
> - Zha
>
>
> On Nov 29, 2007 1:25 AM, Lawson English <lenglish5 at cox.net 
> <mailto:lenglish5 at cox.net>> wrote:
>
>     Argent Stonecutter wrote:
>     > On 28-Nov-2007, at 16:41, Lawson English wrote:
>     >> Argent Stonecutter wrote:
>     >>> On 28-Nov-2007, at 13:59, Lawson English wrote:
>     >>>> The issue MAY be an issue once the meta-grid goes operational.
>     >>>> You'll have to make sure everyone is using your version of
>     UUIDs or
>     >>>> asset-collisions might arise when moving from grid to grid.
>     >>>
>     >
>     >>> Unless someone has changed things recently, I believe that the
>     >>> intent is for externally-visible assets to be presented as
>     URIs, not
>     >>> UUIDs.
>     >
>     >> Unless I misunderstand, the CAP for a given asset will be
>     roughly of
>     >> the form: server_URL:port/cap/asset/UUID.
>     >>
>     >> Where UUID is the current asset UUID
>     >
>     > (note, I'm using 'domain' in the generic sense of a set of
>     systems and
>     > resources with a single responsible control)
>     >
>     > The mapping from the internal UUID to an external URL will have
>     to be
>     > handled on a per-domain basis. Asset references between domains will
>     > need to be handled by passing a URL out of the domain, and mapping
>     > that URL if needed into a domain's internal ID model. There can
>     not be
>     > any assumptions about the meaning of the URL received from another
>     > domain... it's got to be treated as an opaque token.
>     >
>     > If you're accessing http://asset_server:port/cap/asset/UUID and the
>     > asset doesn't belong to that server, it's gotta return something
>     like
>     >
>     > 302 Remote asset
>     >
>     > Location: http://otherguy:theirport/some/opaque/path/and/id
>     >
>     > And the asset server AND you can't make any assumptions about what
>     > "/some/opaque/path/and/id" means.
>     >
>
>     But....
>
>     What if there is a collission between the UUIDs of two different
>     domains? Unless you have the entire cap as the new asset ID, there
>     will
>     be collisions. I guess, at some point before the meta-grid goes live,
>     asset-wise, LL will need to replace all LL-specific UUIDs with
>     llDomain_URL caps. Guess that would actually work out fine, come to
>     think of it, and should be trivial to implement.
>
>     Lawson
>
>     _______________________________________________
>     Click here to unsubscribe or manage your list subscription:
>     /index.html
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>