[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Spreadsheet Table Protection Options
The final IS29500 text will have the corrected algorithm. The necessary changes were identified before the BRM and it's my understanding that they've been made and the final text is accurate. So we can do option 1 as Rob outlined below, and that's probably best to avoid any duplication of the description. - Doug -----Original Message----- From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] Sent: Monday, August 25, 2008 5:19 PM To: office@lists.oasis-open.org Subject: Re: [office] Spreadsheet Table Protection Options > > I'd like to inform the list that my below is now ready. > > http://wiki.oasis-open.org/office/Spreadsheet_Table_Protection_Options > > But there is still one thing to be decided, which is the URI for the > legacy Excel password hash algorithm that we discussed earlier on > another thread. I remember Rob mentioned something like 'ISO/IEC 29500 > Legacy Hash' could be used, but Michael mentioned that it has to be an > URI. But other than that, I don't remember we ever have reached an > agreed-upon URI that we could use for this. The hash algorithm itself > is specified in the OOXML spec (albeit incorrectly), but it remains > unnamed if I understand Doug's statement correctly. > > If we can use any URI, I can make one up. But does anyone have any good > suggestion on what to use? > > Also, I've incorporated the requirement of double-hashing the legacy > hash values into my proposal as we discussed during the call. > This is a difficult one, and not because of the URI. We could just make up a URI if we wanted to. The problem is that we do not have a good normative description of the encryption algorithm that we can cite. What we do have is: 1) An incorrect algorithm in the Ecma-376 standard 2) A version in the ISO/IEC 29500 standard which we cannot even look at right now, so I'm not sure whether it is correct or not. 3) A blog entry that claims to have the correct algorithm I can see a couple ways out. 1) We could wait for the ISO/IEC 29500 text to be published. This could be a matter of a few weeks to months. But it should not be very long. If it expresses the correct algorithm, then we simply reference it by part and clause. Or do we suspect that the algorithm will still be incorrect in the published version of OOXML? If the defect was found and reported to Ecma before the BRM, there is a good chance that it was fixed. Doug would know for sure. or 2) We include the correct algorithm in the ODF specification. Someone would need to formally contribute it to the TC first, my sending it in an email or posting it to the file library. My recommendation would be to see if we can do #1. But agree that if we get to the end of our ODF 1.2 work and ISO/IEC 29500 is still not published, or we find the error still exists in their specification, then we can substitute solution #2. What do others think? -Rob --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]