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] Table Protection: Limitation of table:protection-key hash values


By the way, I agree that the discussion of table:protection-key and
table:table:protection-key-digest-algorithm is unrelated to the proposal
about Table Protection that is part of the final five proposals.

I agree with your and Patrick's observation about our limited ability to say
much about the security regime that might be employed around ODF documents.
I also think there also needs to be a declaration with regard to
table:protection-key not being a security measure.

With regard to digital signatures, I think we should keep in mind that a
document in which the signature has been removed or replaced by that of
another can always be repudiated by the person who is alleged to have
produced it.  With the digital signature retained, it is difficult to
repudiate the signature on that which is signed.  

In contrast, any ODF document having only table cell protection, with or
without table:protection-key, can always be repudiated and, in fact, can be
altered and "forged" to use the same table:protection-key attribute value.
That is, table:protection-key is a weak deterrent and not a security or
authenticity measure.  For the degree that table:protection-key is useful,
the quality of the message digest algorithm is irrelevant.  That is so
stark, I believe there is a professional, ethical responsibility to say
something about it, especially when there is currently encouragement of the
idea that stronger cryptographic hashing methods are somehow better and to
be preferred with respect to table:protection-key.

The text that I offer to explain this for the table:protection-value
attribute is near the end of
http://lists.oasis-open.org/archives/office/200901/msg00010.html and
extracted here:

The table-cell protection feature is provided as a safeguard against
accidental alteration of cells that are kept fixed in order to achieve an
intended purpose, such as use of tables as part of a form for data
collection and reporting.

The locking of table-cell protection is provided as a safeguard against
careless over-riding of the table-cell protections.  Cell locking is not a
secure protection against unauthorized and un-noticed alteration of the
protected table cells.  Knowledge of the password is not required in order
for a knowledgeable party to over-ride the locking by manipulation of the
XML document directly.  Knowledge of the password is not required in order
to deleted the table:protection-key attribute nor to use it for the
locking of protected cells of other tables. 

The hash code protects against casual discovery of the password by
inspection of the XML.  Hash codes of short texts such as memorable
passwords are easily attacked regardless of the strength of the hash code.
The consequences of password compromise can be limited by not using a
table-cell protection password for any other purpose.  The compromise of
passwords can be prevented entirely by generating random hash-code values
without choosing any password at all.


-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
Sent: Monday, January 05, 2009 05:29
To: dennis.hamilton@acm.org
Cc: Patrick Durusau; ODF TC List
Subject: Re: [office] Table Protection: Uselessness of table:protection-key

Dennis, all,

On 03.01.09 14:26, Patrick Durusau wrote:
> Dennis,
> While table/cell protection is an expected "feature," I am not sure how 
> far we should go in terms of warnings to users. In part because any 
> warning we give will be of necessity incomplete. Should we point out 
> that digitally signed documents are only meaningfully "secure" as part 
> of an overall security system? Do we specify at least the common 
> components of such systems?
> One of the things we can say in a standard is what we are not 
> standardizing.
> Perhaps we should say that while ODF can be used in "secure" systems and 
> that there are aspects of ODF, such a digital signatures, that may be 
> useful in building such systems, that security is beyond the purview of 
> the standard. That is we provide the hooks for such systems but your 
> actual mileage will vary.

I agree to this, and in particular would like to point out that a 
digital signature for a piece of a document and a protected piece of a 
document in the sense that the editing applications does not allow 
modifications to it are two different things.

A digital signature ensures that modifications to an ODF document can be 
noticed. But it does not prevent that modifications can be made. It is 
entirely up to the application whether it allows modification of a 
signed documents (or document piece) or not, and what happens to the 
signature information if a document is changed.

The "protection" features again simply says that a piece of a document 
should not be editable. Maybe the name "protection" is not the best, 
although "protect" is a very general term. It is not a terms like 
"secure", "signature" or "encryption" which have their predefined 
meaning in the IT world. And "protect" is only the term we use in the 
ODF specification. Applications may call this feature whatever they want 
to if they believe the term  "protect" leads to wrong expectations.

Two more remarks:
- Even if protected content would get signed, it still would be possible 
to remove the signature itself. That means, the existence of signature 
itself does not protect a document from getting edited.
- We have a lot of other features that have similar issues. Take for 
instance a control for a fixed text. An application that has a mode for 
filling out the form data probably will not allow to change that text. 
But a form editor will by intention do so. And in any case, it is 
possible to change the text in the ODF document itself.

Best regards


Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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