RE: Part 3 CD01 7.2.1 PD1.4 Forbids encryption of signatures

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I have an immediate concern about further hacking of digital-signature
provisions.  I think we SHOULD NOT make the addition proposed in
OFFICE-2656. 

I am frightened to see this increasing complexity by what appears to be
last-minute instant design of provisions that have serious security,
privacy, and authentication implications.  I MUST object. 

Furthermore, this cannot be accomplished simply by stating a conformance
condition.  This is a material change to how digital signature works in ODF
1.2 Packages.

The way we make ODF document privacy, authenticity and security more robust
is to simplify and have a very straightforward systematic approach.  What we
have already is already too complex (and underspecified in important
respects).

 - Dennis

MORE DETAIL

We are better off leaving the treatment of digital signatures alone, as I
already conceded, since the change to 7.2.1 (PD 1.2.4) In Part 3 CD01-rev02
opens the door to signature encryption and that is good enough for now.
Also, OFFICE-2656 just makes the business about the manifest.xml being
signed even more problematic, since the manifest.xml before encryption will
be different than the manifest.xml after encryption and the decryption
procedure must adjust for that so the signed manifest.xml can be verified
with any encrypted signatures that include it as  well as unencrypted
signatures that include it.

ANALYSIS - WHY THIS DOESN'T HOLD UP 

All references to package elements by URIs are, by their nature, to the
unencrypted, *uncompressed* forms of package files.  I'm not aware of
anywhere that we made any exception for the interpretation of URIs within
XML-based package files that refer to other files of the package/document.
(There may be some difficulty about understanding what the
absolute-reference base is, but that is not relevant to this discussion.)

In every case of internal reference by relative URI (and any external
referencing into packages I am aware of, as might be needed for RDF metadata
too), there is no provision to refer to the data units of the Zip
representation.  The references are always to the conceptually extracted and
uncompressed streams that are resolves as URIs and have the MIME types
optionally specified in their <manifest:file-entry>.
 
As far as I can tell, the encryption mechanism is the only exception.  It
does not use URIs though.  It does refer to the data units of the Zip
packaging.  It can do that, as far as I can tell, and as you taught me,
because it is part of the <manifest:file-entry> element that is the bridge
between the package file as it is regarded as a component of a document (or
package structure) and the physical representation of the file data in a
data unit of the Zip package (as identified by the manifest:full-path
attribute of the <manifest:file-entry>).  This is the only case I know of
where we provide for that.  It seems to me that the special provisions for
treating the mimetype Zip data unit as a magic number is purely package
level, although it can be successfully signed, along with any (pre- or
post-encryption?) thumbnail, in the META-INF/documentsignature.xml.  
 
To do a part-wise signing, I think it is inappropriate to assume that the
signature is on anything but extracted, uncompressed streams.  If not, there
is a serious problem with transforms that are available to use and
identified in the XML Digital Signature elements and we raise new problems
about the semantics of the signature.  This will also make it difficult to
extend our reach to additional signature technologies such as XaDES (as if I
knew what that was [;<).

Finally, if we were to do whole-package signing and encryption of the Zip as
the Zip data stream as a BLOB, it seems to me that the appropriate and quite
straightforward mechanism would be to use some sort of wrapper mechanism
(including external signatures and encryptions) by which the entire package
could be signed/encrypted in any combinations as determined by the nesting
of wrappers.  There are already good solutions for that and they are
considered quite robust.  There are even standards for them and they don't
require any knowledge of the Zip structure or its use.  

Whole-package signing/encryption would not replace the in-package signature
mechanism, which is required for attestations about presented and understood
(parts of) content.  

Fortunately, a full-package signature/encryption arrangement can be
developed as a supplementary practice by implementation-defined agreement
among implementers without impacting the current progression of ODF 1.2 and
the specification of ODF 1.2 Packages.


-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
Sent: Friday, April 30, 2010 05:16
To: dennis.hamilton@acm.org
Cc: ODF TC List
Subject: Re: Part 3 CD01 7.2.1 PD1.4 Forbids encryption of signatures

Hi,

Regarding encryption and signatures, I've noticed that we did not 
exactly state when a signature operates on the encrypted data, and when 
it operates on the decrypted data. I've submitted 
http://tools.oasis-open.org/issues/browse/OFFICE-2656

for this.

Michael
[ ... ]