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



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