RE: [uddi-spec] Comments on the recommended V3 key hashing algorithm

Luc,

I don’t see this as being related to the case-folding CR. The case-folding CR means that the algorithm should only be given lower-case keys to hash but that does not change the algorithm itself.
[LC] They are related in so far that we need to update 2 dozen v2 hashed keys in the spec because of the case-folding CR; as such they need to change - the question is whether they are recomputed with the corrected algorithm or not.

I agree with your description of the decisions.

Can you allocate a CR number as we will need a CR whichever decisions we make.
[LC] CR-036

John Colgrave

IBM

-----Original Message-----
From: Luc Clement [mailto:lclement@windows.microsoft.com]
Sent: 15 June 2003 18:22
To: John Colgrave; Bob Atkinson
Cc: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Comments on the recommended V3 key hashing algorithm

Inline <lc>

_____________________________________________
From: John Colgrave [mailto:colgrave@hursley.ibm.com]
Sent:   Monday, June 02, 2003 06:45
To:     Bob Atkinson
Cc:     uddi-spec@lists.oasis-open.org
Subject:        RE: [uddi-spec] Comments on the recommended V3 key hashing algorithm

Bob,

It looks like we need a Change Request either way. I am quite bullish about these things, at least until an implementation is released, so I would prefer to do the right thing, even though it means regenerating a couple of dozen or so keys.

<lc> TC: As you may remember (and what John is suggesting below), we need to change the v3 hashing of the keys in the spec as a result of the casefolding CR we accepted; changing the keys is not at issue here as much as the need to update the algorithm to reflect the need to concatenate the big-endian version of the 16-byte sequence at 1.a. I know of at least 3 server implementations and 2 utils that currently follow the little-endian ordering specified. That said, these aren't released to my knowledge. I wonder if there are more implementations out there?

Please also note that WS-I has been assigned some keys based on the little-endian form of the namespace ID; Claus would need to let us know of the impact of changing these keys at this time.

So we have a choice of making the correction or not. Bob's suggestion (at first blush) is to leave the order as-is. That's the first decision before us.

The second decision is to accept either Option 1 or 2 below. I would prefer to be explicit and not leave the generation to interpretation and thus would like to see the algorithm specified inline in the spec - thus Option 1. (see below note on Option 1)</lc>

The biggest issue I see is that I think we would have to release an updated spec. if we did this, but then I think we are almost at the point where we need to do that anyway, based on the Change Requests that have already been raised.

Option 1

If we continue with the current approach of presenting the details of the algorithm, then I think we should make it clear that it is only the string form that is used (which is "big-endian" regardless of whether the UUID was generated as big-endian or little-endian).

Shouldn't the final five octets be reversed in the little-endian case? All the other multi-octet "fields" are, but the final five are the same in both little-endian and big-endian cases.

<lc> I was wondering about that also. Bob: is John correct? </lc>

Option 2

This is my preferred option whereby we remove most of the details of the algorithm and just say that it is an implementation of the standard name-based algorithm, with a single name space ID (UUID) which we define.

John Colgrave
IBM

-----Original Message-----
From: Bob Atkinson [mailto:bobatk@Exchange.Microsoft.com]
Sent: 30 May 2003 18:55
To: John Colgrave
Cc: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Comments on the recommended V3 key hashing algorithm

I agree: the sequence from 10.1.1 to which you refer does indeed seem, damn it, to be a little-endian version-4 UUID, not a big-endian one. If we truly wish to fix this, yes, we'd have to regen the keys. 'Not clear to me though whether on balance it's worth doing that vs. just living with things as-is. Probably the latter, at first blush...

BTW: The link

http://uddi.org/Pubs/draft-leach-uuids-guids-01.txt

in 10.1.1 is now broken; it should be instead

http://www.uddi.org/pubs/draft-leach-uuids-guids-01.txt

The description of both little endian and big endian forms is intended, I think, to the give appropriate algorithm depending on whether one runs on a big or little endian machine.

I'm sure the prose could be clearer...

Bob

-----Original Message-----
From: John Colgrave [mailto:colgrave@hursley.ibm.com]
Sent: Friday, May 30, 2003 4:34 AM
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] 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

You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_wor

kgroup.php

You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgro

up.php

You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php

uddi-spec message