RE: [uddi-spec] Issue with changed hashing algorithm for V3-V2 key derivation

Title: Message

Thanks, John.

 

I 
believe that we are on the safe side with the UUID-based V3 key and will use 
your feedback for the remaining discussions within WS-I.

 

Claus

  

  
-----Original Message-----
From: John Colgrave 
  [mailto:] 
Sent: Mittwoch, 17. September 
  2003 11:38
To: 'UDDI Spec TC'
Subject: RE: [uddi-spec] 
  Issue with changed hashing algorithm for V3-V2 key 
  derivation

  

  
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.

  
 

  

  
John 
Colgrave

  
IBM

  
 

  

  
-----Original 
  Message-----
From: Von 
  Riegen, Claus [mailto:] 
Sent: 17 September 2003 07:59
To: UDDI Spec TC 
  ()
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