Claus,
There is another
option, which is to forget the fact that the V2 key was produced by the old
hashing algorithm and regard it as an evolved key that must be mapped to the
desired V3 key in a non-standard way, as we do for some of the canonical
tModels in V2.
However, if the BP WG
are happy to have a UUID-based V3 key then I think that is the best
option.
I am by no means a
cryptography expert but I don't think the change in algorithm will affect the
chances of a collision. Because we changed the initial 16-byte sequence
of the total sequence of bytes given to the MD5 hash algorithm we can be sure
that the sequence of bytes that were used to produce the original WS-I V2 key
can never be used with the new algorithm. This means that the only way
that we could get the exact same 128-bit quantity out of the MD5 hash is if
there were a collision, and although it has not been proven that such
collisions are impossible it does not seem to be a practical
concern.
However, it occurred
to me while thinking about this that we could have a problem in general,
nothing to do with the change of algorithm as such, because we force some of
the bits of the output of the MD5 hash, which means that we could potentially
be introducing "false" collisions by making the output of the hash conform to
the format of a UUID.
We force six bits to
constant values which means that there are 64 different MD5 hash values that
would all produce the same UUID value. I doubt that this will be a
problem in practice, and I don't see what else we could do. By
restricting the format to being a particular UUID format we only have 122 bits
of random number, not a full 128.
The migration from V2
to V3 is covered by section 10.1.3. You cannot map from V2 to V3, at
least not if you follow the recommendations in the spec.
-----Original
Message-----
From: Von
Riegen, Claus [mailto:claus.von.riegen@sap.com]
Sent: 17 September 2003 07:59
To: UDDI Spec TC
(uddi-spec@lists.oasis-open.org)
Subject: [uddi-spec] Issue with changed
hashing algorithm for V3-V2 key derivation
As you might know, WS-I has
specified a category system for profile conformance claims in UDDI. The
tModel's key (in UDDI V2) is "uuid:65719168-72c6-3f29-8c20-62defb0961c0" and
was derived from the proposed V3 key
"uddi:ws-i-org:conformsto:2002_12".
Since we are going to correct our
hashing algorithm in the V3 errata V3.0.1, the V2 key would have to be
regenerated. The correct key would be
"uuid:24ef977d-6293-3d7c-8386-b183cdf86149". However, the WS-I Basic Profile
WG (BP WG) does not feel comfortable to change the key at this point in time -
the Basic Profile 1.0 has been published as a Final Specification and would be
changed incompatibly.
I
believe that there are two alternatives:
- either change the
key to conform to the new hashing algorithm and to enable the domain-based V3
key (as specified above),
-
or do not change the key and map it to the UUID-based V3 key
"uddi:65719168-72c6-3f29-8c20-62defb0961c0" later.
The BP WG would like to pursue the
second alternative, but before deciding so, I wanted to make sure that it is
actually a valid alternative. Since the key was generated using the "old"
hashing algorithm, we must ensure that it can not coincidentally be generated
using the "new" hashing algorithm from another key. In other words, how can we
ensure that a given V2 key is not derived from a domain-based V3 key? Besided
the V3-V2 hashing algorithm, is there also a V2-V3 mapping
algorithm?
Thanks,
Claus