RE: [office] Spreadsheet Table Protection Options

[Doug Mahugh <Doug.Mahugh@microsoft.com>]

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