Re: I-D ACTION:draft-hendrikx-wallis-urn-nzl-00.txt

On Fri, 2005-02-25 at 22:27 -0500, wrote:
> Thus, like the DNS names in http URIs, this common form of UUID does 
> indeed trace to a central registry.

True, but...

>   The structure of such a UUID is not 
> in fact particularly opaque, but the information conveyed says much more 
> about the entity doing the generation and the time at which the generation 
> is done, than it does anything about the resource identified.   For that 
> reason, users rightfully tend to think of UUIDs as more opaque than http 
> URIs.  Indeed, one of the great complications in using UUIDs in certain 
> applications is the lack of convenient ability to generate them uniquely 
> on systems that lack network capability (and thus MAC addresses).

And when you *do* have a MAC address, blathering it in every
email message is a no-no.

"Mail in Mac OS X 10.3.7, when generating a Message-ID header, generates
a GUUID that includes information that identifies the Ethernet hardware
being used, which allows remote attackers to link mail messages to a
particular machine."

see also: About Security Update 2005-001 for Mac OS X

>   They 
> are not pseudo-random 128 bit numbers.

Actually, large random numbers to fit into UUIDs, in a couple ways
discussed in...

One is a trick for wedging them where MAC IDs go...

   A better solution is to obtain a 47-bit cryptographic quality random
   number, and use it as the low 47 bits of the node ID, with the least
   significant bit of the first octet of the node ID set to one.  This
   bit is the unicast/multicast bit, which will never be set in IEEE 802
   addresses obtained from network cards; hence, there can never be a
   conflict between UUIDs generated by machines with and without network

but UUIDs have 4 bits of "version" info... more like scheme info...
using MAC addresses is just one of the schemes for allocating
the rest of the bits. Another is to use a true-random number.

 4.4   Algorithms for creating a UUID from truly random or
           pseudo-random numbers

Dan Connolly, W3C
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Saturday, 26 February 2005 04:06:17 UTC