OASIS Open Document Format for Office Applications (OpenDocument) TC

Hi,

I would suggest using the http://www.w3.org/TR/xmlenc-core/ specification as a basis.

It specifies the following digest algorithms. 


Message Digest

       1. REQUIRED SHA1
          http://www.w3.org/2000/09/xmldsig#sha1
       2. RECOMMENDED SHA256
          http://www.w3.org/2001/04/xmlenc#sha256
       3. OPTIONAL SHA512
          http://www.w3.org/2001/04/xmlenc#sha512
       4. OPTIONAL RIPEMD-160
          http://www.w3.org/2001/04/xmlenc#ripemd160



~Florian




>>> Patrick Durusau 

That's a good idea, though I note that since this spec was written some
new attacks on SHA1 have appeared. Is it possible to say "use xmlenc
_except_ we change SHA256 from RECOMMENDED to REQUIRED"?

It seems appropriate to "require" at least one hash which, at the time
of writing, "has no known attacks".

Good idea? Bad idea?

Best,
Daniel.

On Tue, 2006-28-11 at 10:32 +0000, Florian Reuter wrote:
> Hi,
> 
> I would suggest using the http://www.w3.org/TR/xmlenc-core/ specification as a basis.
> 
> It specifies the following digest algorithms. 
> 
> 
> Message Digest
> 
>        1. REQUIRED SHA1
>           http://www.w3.org/2000/09/xmldsig#sha1
>        2. RECOMMENDED SHA256
>           http://www.w3.org/2001/04/xmlenc#sha256
>        3. OPTIONAL SHA512
>           http://www.w3.org/2001/04/xmlenc#sha512
>        4. OPTIONAL RIPEMD-160
>           http://www.w3.org/2001/04/xmlenc#ripemd160
> 
> 
> 
> ~Florian
> 
> 
> 
> 
> >>> Patrick Durusau 

On 28/11/06, Daniel Carrera 

On Tue, 2006-28-11 at 10:59 +0000, Dave Pawson wrote:
> > That's a good idea, though I note that since this spec was written some
> > new attacks on SHA1 have appeared. Is it possible to say "use xmlenc
> > _except_ we change SHA256 from RECOMMENDED to REQUIRED"?
[snip]
> How about adding some flexibility for implementors.
> I.e. list  a few acceptable encryption algorithms, then require
> that an implementation record the one used, which then
> means that other implementations can use a number of algorithms
> and we can have interop?

Yes, that would be good. We can say that SHA1, SHA256, SHA512 and
RIPMEND-160 are all ok (list taken from xmlenc), but all implementations
must support at least SHA256 but preferably all.

> The informative clauses can be used to explain the rationale for
> requiring SHA256?

Yes. Developers may not know that SHA1 is becoming week rather quickly.
I just read that RSA expects a successful pre-image attack on SHA1
within 5-10 years.

http://www.heise-security.co.uk/articles/75686/2

That _would_ render SHA1 useless for passwords.

Cheers,
Daniel.
-- 
"I AM in shape. Round IS a shape."

On Tue, 2006-28-11 at 11:11 +0000, Daniel Carrera wrote:
> Yes, that would be good. We can say that SHA1, SHA256, SHA512 and
> RIPMEND-160 are all ok (list taken from xmlenc), but all implementations
> must support at least SHA256 but preferably all.

I know this is moving further away from Florian's list, but I think we
should also include WHIRLPOOL. There are good reasons for this:

1) SHA and RIPMEND are based on the same design principles, the same as
MD4/MD5, and hashes from this family are continuously being broken (MD4,
MD5, SHA-0, SHA-1 and the original RIPMEND). Some worry that there is a
fundamental design problem (see Bruce Schneier) and we need a completely
different algorithm.

WHIRLPOOL is the only popular hash I know of that is of a different
design.

2) WHIRLPOOL is an ISO standard (ISO/IEC 10118-3), is un-patented, is
believed to be secure, and it has been recommended by the NESSIE
project.

NESSIE = New European Schemes for Signatures, Integrity and Encryption

http://en.wikipedia.org/wiki/NESSIE

I notice that NESSIE did _not_ recommend SHA-1 at all, but only the
later variants.


In fact, why don't we use the NESSIE list instead of xmlenc? NESSIE's
list is WHIRLPOOL, SHA-256, SHA-384 and SHA-512.

I would feel more comfortable using this list than the other one. And we
could say that applications must support at least WHIRLPOOL and SHA-256.

What do you think?

Cheers,
Daniel.
-- 
"I AM in shape. Round IS a shape."

Hi Daniel, all,

actually, the "password" we are talking about do not belong to a 
security feature like digital signatures or encryption, but are only 
passwords that an office application user interface may request before a 
user may remove the write protection of a text section or table.

The hash values we are talking about are only used to encode the 
password itself.

For this reason, I think it should be sufficient to specify a single 
hash algorithm that shall be used. Since we are using SHA1 already 
inside the packages, and since SHA1 is used in practice by 
OpenOffice.org, I would like to propose that we specify that SHA1 is 
used to calculate the hash value. This seems also to be in alignment 
with the W3C xml-enc requirements that Florian has posted.

If we want to extend this to other algorithms, then we need an 
additional attribute to specify the algorithm that is used to encode 
that hash value. Given the purpose of the password attributes in 
question, I personally don't think we need that. But if we want to 
support additional algorithms, then I agree to Florian's suggestion to 
follow the XML Encryption specification.

There is only exception, and this is the password attribute specified in 
section 8.8.3 Source Service. This password is checked by the external 
components that this section describes itself. The ODF implementation 
therefore has no control how the password is encoded. The attribute 
description therefore seems to be correct.

Best regards

Michael



Daniel Carrera wrote:
> On Tue, 2006-28-11 at 11:11 +0000, Daniel Carrera wrote:
>> Yes, that would be good. We can say that SHA1, SHA256, SHA512 and
>> RIPMEND-160 are all ok (list taken from xmlenc), but all implementations
>> must support at least SHA256 but preferably all.
> 
> I know this is moving further away from Florian's list, but I think we
> should also include WHIRLPOOL. There are good reasons for this:
> 
> 1) SHA and RIPMEND are based on the same design principles, the same as
> MD4/MD5, and hashes from this family are continuously being broken (MD4,
> MD5, SHA-0, SHA-1 and the original RIPMEND). Some worry that there is a
> fundamental design problem (see Bruce Schneier) and we need a completely
> different algorithm.
> 
> WHIRLPOOL is the only popular hash I know of that is of a different
> design.
> 
> 2) WHIRLPOOL is an ISO standard (ISO/IEC 10118-3), is un-patented, is
> believed to be secure, and it has been recommended by the NESSIE
> project.
> 
> NESSIE = New European Schemes for Signatures, Integrity and Encryption
> 
> http://en.wikipedia.org/wiki/NESSIE
> 
> I notice that NESSIE did _not_ recommend SHA-1 at all, but only the
> later variants.
> 
> 
> In fact, why don't we use the NESSIE list instead of xmlenc? NESSIE's
> list is WHIRLPOOL, SHA-256, SHA-384 and SHA-512.
> 
> I would feel more comfortable using this list than the other one. And we
> could say that applications must support at least WHIRLPOOL and SHA-256.
> 
> What do you think?
> 
> Cheers,
> Daniel.


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

On Tue, 2006-28-11 at 16:42 +0100, Michael Brauer - Sun Germany - ham02
- Hamburg wrote:
> actually, the "password" we are talking about do not belong to a 
> security feature like digital signatures or encryption, but are only 
> passwords that an office application user interface may request before a 
> user may remove the write protection of a text section or table.

For this purpose any hash will do fine since an attacker could always
just edit the XML to not require a password, correct?

> The hash values we are talking about are only used to encode the 
> password itself.

Am I right to understand that any user could just edit the XML and
remove the password protection? If that is the case, then any hash will
be only marginally better than plain text.

Daniel.
-- 
"I AM in shape. Round IS a shape."

Daniel,

Daniel Carrera wrote:

>On Tue, 2006-28-11 at 16:42 +0100, Michael Brauer - Sun Germany - ham02
>- Hamburg wrote:
>  
>
>>actually, the "password" we are talking about do not belong to a 
>>security feature like digital signatures or encryption, but are only 
>>passwords that an office application user interface may request before a 
>>user may remove the write protection of a text section or table.
>>    
>>
>
>For this purpose any hash will do fine since an attacker could always
>just edit the XML to not require a password, correct?
>
>  
>
>>The hash values we are talking about are only used to encode the 
>>password itself.
>>    
>>
>
>Am I right to understand that any user could just edit the XML and
>remove the password protection? If that is the case, then any hash will
>be only marginally better than plain text.
>
>  
>
Not exactly.

If the file associations are not editable by the user, limiting opening 
of the file to the use of an ODF compliant application and they are 
denied access to a DOS command window (with edit or something similar) 
it can be made relatively secure.

True, if the file were to be shared outside of such an environment, one 
would have to rely upon encryption of the entire file for protection.

But it is important to not confuse the standard office OS setup, which 
is terribly insecure, with the use of ODF in more security minded 
establishments. If you reboot a computer with one popular OS using 
another certain OS on CD, I have heard tell you can edit the passwords 
into the OS itself. Strictly rumor mind you! Physical security is a 
first step that doesn't get discussed much.

 Hope you are having a great day!

Patrick

>Daniel.
>  
>

-- 
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work! 

On Tue, 2006-28-11 at 14:04 -0500, Patrick Durusau wrote:
> Not exactly.
> 
> If the file associations are not editable by the user, limiting opening 
> of the file to the use of an ODF compliant application and they are 
> denied access to a DOS command window (with edit or something similar) 
> it can be made relatively secure.

Well, it seems unlikely that a user would be in an environment that lets
them read the XML contents but not edit them.

But I can think of another reason to use hash though: To protect the
password itself, in the event that the document owner chooses to use the
same password elsewhere (which is common).

So, we want a hash that is pre-image resistant. SHA1 qualifies for now,
but I do note that RSA expects to see pre-image attacks in the next 5-10
years. Are we satisfied with that or should we ask for something higher?

Maybe we can take a middle position and say that SHA1 is allowed but we
recommend applications to move to something else in the future. The spec
could say something like this:

--------
The hash can be any of: SHA1, SHA-256, SHA-512 and WHIRLPOOL. The
committee notes that SHA1 is included for compatibility with current
applications but recommends moving to one of the other algorithms in the
coming years.
--------

I think that's a reasonable balance. It doesn't cause immediate hassle
for developers.

But what will we do, say, 8 years from now, when SHA1 is no longer
considered acceptable? Do we change the spec to disallow SHA1? If so,
then some old documents will become invalid. This is a general problem
with any hash or encryption algorithm; one day Blowfish might be broken
and we may have to choose a different algorithm.

Best,
Daniel.
-- 
"I AM in shape. Round IS a shape."

Hi all,

based on the discussions we had, I would suggest that we extend the description of of the 
protection-key attributes as follows:

4.4.3:Protected section

[To avoid saving the password directly into the XML file, only a hash value of the 
password is stored.] The hash value is calculated using the algorithm specified by the 
text:protection-key-digest-algorithm attribute. It takes the values described in §5.7 of 
[xmlenc-core]. Applications *shall* support SHA1, which is the default, and *should* 
support SHA256. They *may* support other algorithms described in §5.7 of [xmlenc-core].



The description of other protection-key attributes would be extended in the same way.

Best regards

Michael

Daniel Carrera wrote:
> On Tue, 2006-28-11 at 14:04 -0500, Patrick Durusau wrote:
>> Not exactly.
>>
>> If the file associations are not editable by the user, limiting opening 
>> of the file to the use of an ODF compliant application and they are 
>> denied access to a DOS command window (with edit or something similar) 
>> it can be made relatively secure.
> 
> Well, it seems unlikely that a user would be in an environment that lets
> them read the XML contents but not edit them.
> 
> But I can think of another reason to use hash though: To protect the
> password itself, in the event that the document owner chooses to use the
> same password elsewhere (which is common).
> 
> So, we want a hash that is pre-image resistant. SHA1 qualifies for now,
> but I do note that RSA expects to see pre-image attacks in the next 5-10
> years. Are we satisfied with that or should we ask for something higher?
> 
> Maybe we can take a middle position and say that SHA1 is allowed but we
> recommend applications to move to something else in the future. The spec
> could say something like this:
> 
> --------
> The hash can be any of: SHA1, SHA-256, SHA-512 and WHIRLPOOL. The
> committee notes that SHA1 is included for compatibility with current
> applications but recommends moving to one of the other algorithms in the
> coming years.
> --------
> 
> I think that's a reasonable balance. It doesn't cause immediate hassle
> for developers.
> 
> But what will we do, say, 8 years from now, when SHA1 is no longer
> considered acceptable? Do we change the spec to disallow SHA1? If so,
> then some old documents will become invalid. This is a general problem
> with any hash or encryption algorithm; one day Blowfish might be broken
> and we may have to choose a different algorithm.
> 
> Best,
> Daniel.


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Does everyone feel that there's no need to include an algorithm that is
not from the SHA family? If I'm alone in thinking we should include
WHIRLPOOL in case SHA is broken 10 years from now, I won't put up a
fuss.

Best,
Daniel.

On Fri, 2006-08-12 at 11:50 +0100, Michael Brauer - Sun Germany - ham02
- Hamburg wrote:
> Hi all,
> 
> based on the discussions we had, I would suggest that we extend the description of of the 
> protection-key attributes as follows:
> 
> 4.4.3:Protected section
> 
> [To avoid saving the password directly into the XML file, only a hash value of the 
> password is stored.] The hash value is calculated using the algorithm specified by the 
> text:protection-key-digest-algorithm attribute. It takes the values described in §5.7 of 
> [xmlenc-core]. Applications *shall* support SHA1, which is the default, and *should* 
> support SHA256. They *may* support other algorithms described in §5.7 of [xmlenc-core].
> 
> 
> 
> The description of other protection-key attributes would be extended in the same way.
> 
> Best regards
> 
> Michael
> 
> Daniel Carrera wrote:
> > On Tue, 2006-28-11 at 14:04 -0500, Patrick Durusau wrote:
> >> Not exactly.
> >>
> >> If the file associations are not editable by the user, limiting opening 
> >> of the file to the use of an ODF compliant application and they are 
> >> denied access to a DOS command window (with edit or something similar) 
> >> it can be made relatively secure.
> > 
> > Well, it seems unlikely that a user would be in an environment that lets
> > them read the XML contents but not edit them.
> > 
> > But I can think of another reason to use hash though: To protect the
> > password itself, in the event that the document owner chooses to use the
> > same password elsewhere (which is common).
> > 
> > So, we want a hash that is pre-image resistant. SHA1 qualifies for now,
> > but I do note that RSA expects to see pre-image attacks in the next 5-10
> > years. Are we satisfied with that or should we ask for something higher?
> > 
> > Maybe we can take a middle position and say that SHA1 is allowed but we
> > recommend applications to move to something else in the future. The spec
> > could say something like this:
> > 
> > --------
> > The hash can be any of: SHA1, SHA-256, SHA-512 and WHIRLPOOL. The
> > committee notes that SHA1 is included for compatibility with current
> > applications but recommends moving to one of the other algorithms in the
> > coming years.
> > --------
> > 
> > I think that's a reasonable balance. It doesn't cause immediate hassle
> > for developers.
> > 
> > But what will we do, say, 8 years from now, when SHA1 is no longer
> > considered acceptable? Do we change the spec to disallow SHA1? If so,
> > then some old documents will become invalid. This is a general problem
> > with any hash or encryption algorithm; one day Blowfish might be broken
> > and we may have to choose a different algorithm.
> > 
> > Best,
> > Daniel.
> 
> 
-- 
"I AM in shape. Round IS a shape."

Hi Daniel,

Daniel Carrera wrote:
> Does everyone feel that there's no need to include an algorithm that is
> not from the SHA family? If I'm alone in thinking we should include
> WHIRLPOOL in case SHA is broken 10 years from now, I won't put up a
> fuss.

Thanks for asking. I've just noticed that my proposal restricts the algorithms that may be 
used to those explicitly mentioned in the xmlenc spec. That was not my intention, and the 
xmlenc sec doesn't do so itself by stating: "Furthermore, the mechanism is extensible, and 
alternative algorithms may be used."

The attribute I'm proposing in fact takes an IRI, so arbitrary algorithms can be used, but 
their support is optional. We should make this explicit by adopting the last sentence of 
the description to: "They *may* support other algorithms described in §5.7 of 
[xmlenc-core] or alternative algorithms."

This would allow to use WHIRLPOOL or any other algorithm in the future in case SHA is 
broken, provided of cause WHIRLPOOL is not broken itself. Until when, I suggest that we 
follow the recommendation from the W3C.

Best regards

Michael


> 
> Best,
> Daniel.
> 
> On Fri, 2006-08-12 at 11:50 +0100, Michael Brauer - Sun Germany - ham02
> - Hamburg wrote:
>> Hi all,
>>
>> based on the discussions we had, I would suggest that we extend the description of of the 
>> protection-key attributes as follows:
>>
>> 4.4.3:Protected section
>>
>> [To avoid saving the password directly into the XML file, only a hash value of the 
>> password is stored.] The hash value is calculated using the algorithm specified by the 
>> text:protection-key-digest-algorithm attribute. It takes the values described in §5.7 of 
>> [xmlenc-core]. Applications *shall* support SHA1, which is the default, and *should* 
>> support SHA256. They *may* support other algorithms described in §5.7 of [xmlenc-core].
>>
>> 
>>
>> The description of other protection-key attributes would be extended in the same way.
>>
>> Best regards
>>
>> Michael
>>
>> Daniel Carrera wrote:
>>> On Tue, 2006-28-11 at 14:04 -0500, Patrick Durusau wrote:
>>>> Not exactly.
>>>>
>>>> If the file associations are not editable by the user, limiting opening 
>>>> of the file to the use of an ODF compliant application and they are 
>>>> denied access to a DOS command window (with edit or something similar) 
>>>> it can be made relatively secure.
>>> Well, it seems unlikely that a user would be in an environment that lets
>>> them read the XML contents but not edit them.
>>>
>>> But I can think of another reason to use hash though: To protect the
>>> password itself, in the event that the document owner chooses to use the
>>> same password elsewhere (which is common).
>>>
>>> So, we want a hash that is pre-image resistant. SHA1 qualifies for now,
>>> but I do note that RSA expects to see pre-image attacks in the next 5-10
>>> years. Are we satisfied with that or should we ask for something higher?
>>>
>>> Maybe we can take a middle position and say that SHA1 is allowed but we
>>> recommend applications to move to something else in the future. The spec
>>> could say something like this:
>>>
>>> --------
>>> The hash can be any of: SHA1, SHA-256, SHA-512 and WHIRLPOOL. The
>>> committee notes that SHA1 is included for compatibility with current
>>> applications but recommends moving to one of the other algorithms in the
>>> coming years.
>>> --------
>>>
>>> I think that's a reasonable balance. It doesn't cause immediate hassle
>>> for developers.
>>>
>>> But what will we do, say, 8 years from now, when SHA1 is no longer
>>> considered acceptable? Do we change the spec to disallow SHA1? If so,
>>> then some old documents will become invalid. This is a general problem
>>> with any hash or encryption algorithm; one day Blowfish might be broken
>>> and we may have to choose a different algorithm.
>>>
>>> Best,
>>> Daniel.
>>


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Hi,

for convenience, below is the current proposal for protection keys with the minor 
modification I've stated below. This proposal optionally supports arbitrary hash 
algorithms, which means, it supports also the algorithm used by Office Open XML,
although we do not mention an URI for it. Since mentioning this URI would not alter
the proposal itself but would only mean that we add some additional information,
I suggest that we vote for the proposal as it is, and turn the question whether we
can and want to add this URI into a separate action item.

4.4.3:Protected section

[To avoid saving the password directly into the XML file, only a hash
value of the password is stored.] The hash value is calculated using
the algorithm specified by the text:protection-key-digest-algorithm
attribute. It takes the values described in §5.7 of [xmlenc-core].
Applications *shall* support SHA1, which is the default, and *should*
support SHA256. They *may* support other algorithms described in §5.7
of [xmlenc-core] or alternative algorithms.



The description of other protection-key attributes would be extended
in the same way.

Best regards

Michael

Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> Hi Daniel,
> 
> Daniel Carrera wrote:
>> Does everyone feel that there's no need to include an algorithm that is
>> not from the SHA family? If I'm alone in thinking we should include
>> WHIRLPOOL in case SHA is broken 10 years from now, I won't put up a
>> fuss.
> 
> Thanks for asking. I've just noticed that my proposal restricts the 
> algorithms that may be used to those explicitly mentioned in the xmlenc 
> spec. That was not my intention, and the xmlenc sec doesn't do so itself 
> by stating: "Furthermore, the mechanism is extensible, and alternative 
> algorithms may be used."
> 
> The attribute I'm proposing in fact takes an IRI, so arbitrary 
> algorithms can be used, but their support is optional. We should make 
> this explicit by adopting the last sentence of the description to: "They 
> *may* support other algorithms described in §5.7 of [xmlenc-core] or 
> alternative algorithms."
> 
> This would allow to use WHIRLPOOL or any other algorithm in the future 
> in case SHA is broken, provided of cause WHIRLPOOL is not broken itself. 
> Until when, I suggest that we follow the recommendation from the W3C.
> 
> Best regards
> 
> Michael
> 
> 
>>
>> Best,
>> Daniel.
>>
>> On Fri, 2006-08-12 at 11:50 +0100, Michael Brauer - Sun Germany - ham02
>> - Hamburg wrote:
>>> Hi all,
>>>
>>> based on the discussions we had, I would suggest that we extend the 
>>> description of of the protection-key attributes as follows:
>>>
>>> 4.4.3:Protected section
>>>
>>> [To avoid saving the password directly into the XML file, only a hash 
>>> value of the password is stored.] The hash value is calculated using 
>>> the algorithm specified by the text:protection-key-digest-algorithm 
>>> attribute. It takes the values described in §5.7 of [xmlenc-core]. 
>>> Applications *shall* support SHA1, which is the default, and *should* 
>>> support SHA256. They *may* support other algorithms described in §5.7 
>>> of [xmlenc-core].
>>>
>>> 
>>>
>>> The description of other protection-key attributes would be extended 
>>> in the same way.
>>>
>>> Best regards
>>>
>>> Michael
>>>
>>> Daniel Carrera wrote:
>>>> On Tue, 2006-28-11 at 14:04 -0500, Patrick Durusau wrote:
>>>>> Not exactly.
>>>>>
>>>>> If the file associations are not editable by the user, limiting 
>>>>> opening of the file to the use of an ODF compliant application and 
>>>>> they are denied access to a DOS command window (with edit or 
>>>>> something similar) it can be made relatively secure.
>>>> Well, it seems unlikely that a user would be in an environment that 
>>>> lets
>>>> them read the XML contents but not edit them.
>>>>
>>>> But I can think of another reason to use hash though: To protect the
>>>> password itself, in the event that the document owner chooses to use 
>>>> the
>>>> same password elsewhere (which is common).
>>>>
>>>> So, we want a hash that is pre-image resistant. SHA1 qualifies for now,
>>>> but I do note that RSA expects to see pre-image attacks in the next 
>>>> 5-10
>>>> years. Are we satisfied with that or should we ask for something 
>>>> higher?
>>>>
>>>> Maybe we can take a middle position and say that SHA1 is allowed but we
>>>> recommend applications to move to something else in the future. The 
>>>> spec
>>>> could say something like this:
>>>>
>>>> --------
>>>> The hash can be any of: SHA1, SHA-256, SHA-512 and WHIRLPOOL. The
>>>> committee notes that SHA1 is included for compatibility with current
>>>> applications but recommends moving to one of the other algorithms in 
>>>> the
>>>> coming years.
>>>> --------
>>>>
>>>> I think that's a reasonable balance. It doesn't cause immediate hassle
>>>> for developers.
>>>>
>>>> But what will we do, say, 8 years from now, when SHA1 is no longer
>>>> considered acceptable? Do we change the spec to disallow SHA1? If so,
>>>> then some old documents will become invalid. This is a general problem
>>>> with any hash or encryption algorithm; one day Blowfish might be broken
>>>> and we may have to choose a different algorithm.
>>>>
>>>> Best,
>>>> Daniel.
>>>
> 
> 


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

I agree with the proposal. However I
think the document encryption is more important than this one. The method
we discuss here is used to secure the protection properties of section,
while the content of the section is still stored in the xml file without
any encryption. That means, I can easily modify the "text:protected"
property to disable it.

Is the current encryption method for
document (defined in 17.3) enough? I am not a security expert, but it looks
weird to me that we have good support on section's properties but only
SHA1 for the document. 

Best Regards,

Helen Yue





From:
Michael Brauer - Sun Germany
- ham02 - Hamburg <Michael.Brauer@Sun.COM>

To:
office@lists.oasis-open.org

Date:
01/15/2007 06:29 PM

Subject:
Re: [office] Passwords (Proposal)




Hi,


for convenience, below is the current proposal for protection keys with
the minor

modification I've stated below. This proposal optionally supports arbitrary
hash

algorithms, which means, it supports also the algorithm used by Office
Open XML,

although we do not mention an URI for it. Since mentioning this URI would
not alter

the proposal itself but would only mean that we add some additional information,

I suggest that we vote for the proposal as it is, and turn the question
whether we

can and want to add this URI into a separate action item.


4.4.3:Protected section


[To avoid saving the password directly into the XML file, only a hash

value of the password is stored.] The hash value is calculated using

the algorithm specified by the text:protection-key-digest-algorithm

attribute. It takes the values described in .7 of [xmlenc-core].

Applications *shall* support SHA1, which is the default, and *should*

support SHA256. They *may* support other algorithms described in .7

of [xmlenc-core] or alternative algorithms.


<define name="sectionAttr" combine="interleave">

...

     <optional>

         <attribute name="text:protection-key-digest-algorithm"

                a:defaultValue="http://www.w3.org/2000/09/xmldsig#sha1">

            <ref name="anyURI"/>

         </attribute>

     </optional>

</define>


The description of other protection-key attributes would be extended

in the same way.


Best regards


Michael


Michael Brauer - Sun Germany - ham02 - Hamburg wrote:

> Hi Daniel,

>

> Daniel Carrera wrote:

>> Does everyone feel that there's no need to include an algorithm
that is

>> not from the SHA family? If I'm alone in thinking we should include

>> WHIRLPOOL in case SHA is broken 10 years from now, I won't put
up a

>> fuss.

>

> Thanks for asking. I've just noticed that my proposal restricts the

> algorithms that may be used to those explicitly mentioned in the xmlenc

> spec. That was not my intention, and the xmlenc sec doesn't do so
itself

> by stating: "Furthermore, the mechanism is extensible, and alternative

> algorithms may be used."

>

> The attribute I'm proposing in fact takes an IRI, so arbitrary

> algorithms can be used, but their support is optional. We should make

> this explicit by adopting the last sentence of the description to:
"They

> *may* support other algorithms described in .7 of [xmlenc-core] or

> alternative algorithms."

>

> This would allow to use WHIRLPOOL or any other algorithm in the future

> in case SHA is broken, provided of cause WHIRLPOOL is not broken itself.

> Until when, I suggest that we follow the recommendation from the W3C.

>

> Best regards

>

> Michael

>

>

>>

>> Best,

>> Daniel.

>>

>> On Fri, 2006-08-12 at 11:50 +0100, Michael Brauer - Sun Germany
- ham02

>> - Hamburg wrote:

>>> Hi all,

>>>

>>> based on the discussions we had, I would suggest that we extend
the

>>> description of of the protection-key attributes as follows:

>>>

>>> 4.4.3:Protected section

>>>

>>> [To avoid saving the password directly into the XML file,
only a hash

>>> value of the password is stored.] The hash value is calculated
using

>>> the algorithm specified by the text:protection-key-digest-algorithm

>>> attribute. It takes the values described in .7 of [xmlenc-core].

>>> Applications *shall* support SHA1, which is the default, and
*should*

>>> support SHA256. They *may* support other algorithms described
in .7

>>> of [xmlenc-core].

>>>

>>> <define name="sectionAttr" combine="interleave">

>>> ...

>>>     <optional>

>>>         <attribute name="text:protection-key-digest-algorithm"

>>>                a:defaultValue="http://www.w3.org/2000/09/xmldsig#sha1">

>>>             <ref name="anyURI"/>

>>>         </attribute>

>>>     </optional>

>>> </define>

>>>

>>> The description of other protection-key attributes would be
extended

>>> in the same way.

>>>

>>> Best regards

>>>

>>> Michael

>>>

>>> Daniel Carrera wrote:

>>>> On Tue, 2006-28-11 at 14:04 -0500, Patrick Durusau wrote:

>>>>> Not exactly.

>>>>>

>>>>> If the file associations are not editable by the user,
limiting

>>>>> opening of the file to the use of an ODF compliant
application and

>>>>> they are denied access to a DOS command window (with
edit or

>>>>> something similar) it can be made relatively secure.

>>>> Well, it seems unlikely that a user would be in an environment
that

>>>> lets

>>>> them read the XML contents but not edit them.

>>>>

>>>> But I can think of another reason to use hash though:
To protect the

>>>> password itself, in the event that the document owner
chooses to use

>>>> the

>>>> same password elsewhere (which is common).

>>>>

>>>> So, we want a hash that is pre-image resistant. SHA1 qualifies
for now,

>>>> but I do note that RSA expects to see pre-image attacks
in the next

>>>> 5-10

>>>> years. Are we satisfied with that or should we ask for
something

>>>> higher?

>>>>

>>>> Maybe we can take a middle position and say that SHA1
is allowed but we

>>>> recommend applications to move to something else in the
future. The

>>>> spec

>>>> could say something like this:

>>>>

>>>> --------

>>>> The hash can be any of: SHA1, SHA-256, SHA-512 and WHIRLPOOL.
The

>>>> committee notes that SHA1 is included for compatibility
with current

>>>> applications but recommends moving to one of the other
algorithms in

>>>> the

>>>> coming years.

>>>> --------

>>>>

>>>> I think that's a reasonable balance. It doesn't cause
immediate hassle

>>>> for developers.

>>>>

>>>> But what will we do, say, 8 years from now, when SHA1
is no longer

>>>> considered acceptable? Do we change the spec to disallow
SHA1? If so,

>>>> then some old documents will become invalid. This is a
general problem

>>>> with any hash or encryption algorithm; one day Blowfish
might be broken

>>>> and we may have to choose a different algorithm.

>>>>

>>>> Best,

>>>> Daniel.

>>>

>

>



--

Michael Brauer, Technical Architect Software Engineering

StarOffice/OpenOffice.org

Sun Microsystems GmbH             Nagelsweg
55

D-20097 Hamburg, Germany          michael.brauer@sun.com

http://sun.com/staroffice         +49 40 23646 500

http://blogs.sun.com/GullFOSS