Re: [office] Passwords (Proposal)

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

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].

<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