OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


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


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