|Patrick Durusau||Nov 27, 2006 4:51 pm|
|David Faure||Nov 28, 2006 1:07 am|
|Daniel Carrera||Nov 28, 2006 1:40 am||.pgp|
|Florian Reuter||Nov 28, 2006 2:32 am|
|Daniel Carrera||Nov 28, 2006 2:51 am||.pgp|
|Dave Pawson||Nov 28, 2006 2:58 am|
|Daniel Carrera||Nov 28, 2006 3:12 am||.pgp|
|Patrick Durusau||Nov 28, 2006 3:30 am|
|Daniel Carrera||Nov 28, 2006 6:29 am||.pgp|
|Patrick Durusau||Nov 28, 2006 6:47 am|
|Daniel Carrera||Nov 28, 2006 6:59 am||.pgp|
|robe...@us.ibm.com||Nov 28, 2006 7:37 am|
|Michael Brauer - Sun Germany - ham02 - Hamburg||Nov 28, 2006 7:42 am|
|Daniel Carrera||Nov 28, 2006 8:16 am||.pgp|
|Patrick Durusau||Nov 28, 2006 11:07 am|
|Daniel Carrera||Nov 29, 2006 1:07 am||.pgp|
|Michael Brauer - Sun Germany - ham02 - Hamburg||Dec 8, 2006 2:50 am|
|Daniel Carrera||Dec 8, 2006 3:54 am||.pgp|
|Michael Brauer - Sun Germany - ham02 - Hamburg||Dec 8, 2006 4:18 am|
|Michael Brauer - Sun Germany - ham02 - Hamburg||Jan 15, 2007 2:24 am|
|Zhi Yu Yue||Jan 15, 2007 6:19 am|
|Michael Brauer - Sun Germany - ham02 - Hamburg||Jan 15, 2007 6:36 am|
|Subject:||Re: [office] Passwords (Proposal)|
|From:||Michael Brauer - Sun Germany - ham02 - Hamburg (Mich...@Sun.COM)|
|Date:||Dec 8, 2006 2:50:31 am|
based on the discussions we had, I would suggest that we extend the description of of the protection-key attributes as follows:
[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.
Daniel Carrera wrote:
On Tue, 2006-28-11 at 14:04 -0500, Patrick Durusau wrote:
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.