OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Comments on the recommended V3 key hashing algorithm


Having had occasion to look at section 10.1.1 again recently, I was reminded
of some issues that I had with it that have not been addressed.  If
necessary I will write a CR but, like Claus, I thought I would float the
issues in an e-mail first.

1) The spec. does not say so but the algorithm presented is clearly meant to
be an instance of the algorithm presented in section "3.3 Algorithm for
creating a name-based UUID" in draft-leach-guids-01.txt.  It may be better
for us to remove the duplication of the algorithm so that if people already
have access to code to generate a name-based UUID they can use that, subject
to a couple of extra constraints, rather than being led to believe that they
have to implement a specific UDDI algorithm.

2) Unfortunately, there is a bug in the 16-byte sequence given in step 1a
which means that the algorithm is not a valid instance of the standard
name-based algorithm.  In the terms of the standard name-based UUID
algorithm, we need a UUID to use as a "name space ID" for all UUIDs
generated from names in that name space.  The algorithm in section 10.1.1
requires the use of a single name space and the 16-byte sequence is meant to
be the UUID to use for that name space.  However, the "official" algorithm
says that the name space ID should be put in network byte order before being
concatenated with the name (in our case the V3 key) and hashed using the MD5
algorithm.  The bug is that the 16-byte sequence given in 10.1.1 is not in
network byte order.  It appears to be a little-endian random UUID.

3) I don't understand why we present the option of using either big-endian
or little-endian, and I think the method of constructing the little-endian
version contains a mistake.  The endian-ness should not affect the string
representation of the UUID, which is what we care about.

My recommendation is that we remove the explicit description of the
algorithm in section 10.1.1 and just say that the recommended algorithm is
that from section 3.3 of draft-leach-guids-01.txt with the extra constraints
that: 1) a single name space ID (UUID) must be used, and we give a correct
16-byte sequence in network byte order to be used; 2) the string
representation of the resulting UUID is to be used, as that should be
independent of the byte order used.

Unfortunately, this would mean that we would have to derive all the V1/V2
keys again.

John Colgrave
IBM





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]