Title: Message
Thanks, Tony.
Sounds
that we can proceed with the alternative approach, i.e. not to change the V2 key
and to use the corresponding UUID-based V3 key (rather than a domain-based
one).
Claus
-----Original Message-----
From: Rogers, Tony
[mailto:]
Sent: Mittwoch, 17. September 2003
10:25
To: Von Riegen, Claus;
Subject: RE: [uddi-spec] Issue with
changed hashing algorithm for V3-V2 key derivation
The central part of the V3 to V2 algorithm is the use of the MD5 message
digest algorithm. This is a cryptographic digest, SPECIFICALLY DESIGNED to
make if difficult to create a message that will produce a desired digest (you
can see why that was a design objective...). OK, it's not as popular as it
once was (SHA-1 seems to be the more popular alternative), because there have
been some weaknesses detected, but it was considered more than good enough in
its day.
So, no, there's no algorithm to get a V3 key that will produce a given V2
key when run through the hash.
The algorithm to get a V3 key from a V2 key is to take the V2 key and put
an appropriate prefix in front of it. :-)
How likely is it that we'll see some other V3 key hash to this one?
Rather unlikely - the message digest algorithms are supposed to distribute the
hashes fairly uniformly across the target domain.
Tony.
-----Original Message-----
From: Von Riegen,
Claus [mailto:]
Sent: Wed 17/09/2003
16:58
To: UDDI Spec TC ()
Cc:
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
