Hi Bob,
Yes, the legacy algorithm was not named, and naming it would
have required some of the other changes we had put together in the US/CA/SA
agreement you mentioned, which didn’t get addressed in the BRM. There are two
sets of attributes in the IS29500 element for hashing algorithm, and the name
attribute was added in the new set of attributes, which explicitly didn’t support
the legacy algorithm. So the old algorithm could only be named in an attribute
whose presence precluded the use of it. J
In any event, I entirely agree with your comment that “applications, such as openoffice, should be free to
implement the algorithm for reading and writing .xls or .doc files, but I would
strongly discourage its use in odf files.” It’s an issue for interoperability
with existing documents that have used it in the past, but it’s not an
algorithm that should be used going forward, for all the reasons we discussed
during DIS29500.
Regarding how to name the algorithm, since it’s not named in
IS29500 we can do whatever makes sense to everyone here. Perhaps Rob’s
suggestion (ISO/IEC 29500 Legacy Hash), or do what Adobe does if Duane finds
they’ve named it something already.
- Doug
From: Bob Jolliffe
[mailto:bobj@dst.gov.za]
Sent: Monday, July 07, 2008 3:43 PM
To: office
Cc: Kohei Yoshida
Subject: Re: [office] Proper identifier for Excel-style digest algorithm
Hi
It is unfortunate that this problem of not naming the legacy algorithm relates
to one of the resolutions which never got tabled at the Geneva BRM back in
February due to lack of time. The USA, Canada and South Africa arrived at
an agreement over a set of editing instructions which included amongst others:
"Name the legacy algorithm for use in Transitional
Migration, Features (normative) in A.1.6"
As I recall the situation, the legacy
algorithm is assumed if the algorithm is not named. The resolution
including the above wasn't tabled, so as far as I can tell, it is still not
named. I still have a copy of our resolution which I guess we will put
through to SC34 when the mechanism for receiving comments is up and running.
So for the moment we can name it ourselves as Rob suggested, but it would be
nice for everyone to call it the same thing.
One of the other issues which was raised back then relates to writing out
hashes of passwords made using the legacy algorithm. There was a strong
sense that the legacy hash algorithm be used to verify existing passwords, but
that "strict" conforming applications should not generate hashes of
new passwords using this algorithm. Unfortunately all this remains
unresolved and there are no editing instructions approved by the BRM regarding
the issues.
But it does give rise to the question: are we going to support saving passwords
hashed using iso-29500-legacy-hash in odf v1.2? Currently I guess we do
as we leave the choice of algorithm completely open. Its a tricky
one. I would suggest that applications, such as openoffice, should be
free to implement the algorithm for reading and writing .xls or .doc files, but
I would strongly discourage its use in odf files.
Regards
Bob
----- Original Message -----
From: "robert weir" <robert_weir@us.ibm.com>
To: "Kohei Yoshida" <kyoshida@novell.com>
Cc: "office" <office@lists.oasis-open.org>
Sent: Monday, July 7, 2008 9:50:05 PM (GMT+0200) Africa/Harare
Subject: Re: [office] Proper identifier for Excel-style digest algorithm
Kohei Yoshida
<kyoshida@novell.com> wrote on 07/07/2008 03:03:46 PM:
> Hi there,
>
> I've already asked privately to Michael and Rob, and I think it's
> appropriate to ask this list.
>
> I'm working on supporting the password hash algorithm that Excel uses
to
> hash worksheet and document passwords in OOo. Luckily this
doesn't
> require any modification to the ODF schema since ODF already allows
> alternative digest algorithm as described in Section 18.972
> table:protected (as of v1.2 draft7-3). But I'd like to correctly
> associate and document this Excel-style algorithm in the ODF spec.
>
> The algorithm itself is documented in Section 3.3.1.81 of ECMA TC-45
> OOXML specification. The code contained therein, however, is not
> entirely correct, so I posted the correct algorithm in my blog page[1]
> for now. I assume the final version of the OOXML spec will
contain the
> correct algorithm, but so far, the latest (public) version of the spec
> that I have access to still contains the old, incorrect version.
>
> The question I'd like to ask the list members is this: what identifier
> should we use as the value of the
table:protection-key-digest-algorithm
> attribute to refer to the new algorithm? The current definition
for
> this attribute:
>
> <attribute name="table:protection-key-digest-algorithm"
> a:defaultValue="http://www.w3.org/2000/09/xmldsig#sha1">
> <ref name="anyURI"/>
> </attribute>
>
> suggests that the name must be a URI. But I'm not sure what URI
to use
> for this new algorithm.
>
> Any ideas, anyone?
>
How does OOXML, in their
revised text, refer to the legacy algorithm? I thought they also
supported modern algorithms now like SHA256. So they must have some way
of indicating or referring to the legacy algorithm. It might not be a
URI, but they must describe it somehow, right? If all else fails, call it
something like "ISO/IEC 29500 Legacy Hash".
Ideally we would refer to
either ISO/IEC 29500, section 3.3.1.81 or Ecma-376 (second edition)
whenever either one of those documents appears in a publicly viewable form.
I don't think we want to duplicate their algorithm definition if we can
avoid doing so. Better to reference what they already have, when it is
corrected.
-Rob