22 messages in org.oasis-open.lists.officeRe: [office] Passwords (Proposal)| From | Sent On | Attachments |
|---|---|---|
| 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: | Daniel Carrera (dani...@zmsl.com) | |
| Date: | Dec 8, 2006 3:54:25 am | |
| List: | org.oasis-open.lists.office | |
| Attachments: | pgp00000.pgp - 0.3k | |
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.
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.
-- "I AM in shape. Round IS a shape."