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] Passwords (Proposal)

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">
		<attribute name="text:protection-key-digest-algorithm"
			<ref name="anyURI"/>

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

Best regards


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
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

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