[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Passwords (Proposal)
Hi Helen, Zhi Yu Yue wrote: > > 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. You are right. We should also extend the encryption feature. I will prepare a separate proposal for this. Best regards Michael > > 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 > > -- 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]