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,

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.

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