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: RE: [uddi-spec] Issue with changed hashing algorithm for V3-V2 key derivation


Title: 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:claus.von.riegen@sap.com]
Sent: Wed 17/09/2003 16:58
To: UDDI Spec TC (uddi-spec@lists.oasis-open.org)
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



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