OASIS Open Document Format for Office Applications (OpenDocument) TC

Right, but the current spec (which I did not change) says that everything should be signed. This would include 0-length files because if they got something in them, this would be a change.

If there are files that do not affect content or appearance, then we may not sign these, and should document them as such.

Sent from my phone, but I might be verbose - I have a keyboard...

-----Original Message-----
From: Dennis E. Hamilton 

Hi David,


I totally agree, and like mentioned before, every *file* (including the 0-length current.xml) has been signed 
in the example :-)
If there's another *file* that should have been signed (but isn't), can you please give an example ? That's
probably something we've missed and then we'll correct it in our application. Thanks.

So that leaves us with zip entries like "Configurations/menubar/", if they are to be signed, then it should
IMHO be reflected in the spec (I wouldn't call this "a file", and the spec only says "shall contain a 

Bart, there is no Zip entry like "Configurations/menubar/".  The only way
for there to be a Zip entry is for there to be a Zip directory entry with
that name, and that means there would have to be a file in the package that
had that name.  

There might be such a META-INF/manifest.xml 

Dennis,


uhm, perhaps I'm missing something here.

I'm not looking at the manifest at all, only at the zip.

There *is* a zip entry called "Configurations/menubar/".

Unzipping the .odt would map it to empty directories, but directories are actually
also files (probably this is what you meant, David  ?), so indeed they should also
be signed.


Best regards,

Bart


________________________________________
From: Dennis E. Hamilton [dennis.hamilton@acm.org]
Sent: Sunday, September 26, 2010 12:08 AM
To: Hanssens Bart; 'David LeBlanc'; office@lists.oasis-open.org
Cc: Cornelis Frank
Subject: RE: [office] RE: XAdES support in ODF

Bart, there is no Zip entry like "Configurations/menubar/".  The only way
for there to be a Zip entry is for there to be a Zip directory entry with
that name, and that means there would have to be a file in the package that
had that name.

There might be such a META-INF/manifest.xml 

I don't believe there is such a Zip entry.  What tool are you using to look
at the Zip file?  (Do not use the built-in Windows shell that simulates
folders, or any Linux equivalent.  They may make a folder where there is
none in the Zip itself if there is a Zipped file that has that path as part
of its name.)

 - Dennis

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
Sent: Saturday, September 25, 2010 16:26
To: dennis.hamilton@acm.org; 'David LeBlanc'; office@lists.oasis-open.org
Cc: Cornelis Frank
Subject: RE: [office] RE: XAdES support in ODF

Dennis,


uhm, perhaps I'm missing something here.

I'm not looking at the manifest at all, only at the zip.

There *is* a zip entry called "Configurations/menubar/".

Unzipping the .odt would map it to empty directories, but directories are
actually
also files (probably this is what you meant, David  ?), so indeed they
should also
be signed.


Best regards,

Bart


________________________________________
From: Dennis E. Hamilton [dennis.hamilton@acm.org]
Sent: Sunday, September 26, 2010 12:08 AM
To: Hanssens Bart; 'David LeBlanc'; office@lists.oasis-open.org
Cc: Cornelis Frank
Subject: RE: [office] RE: XAdES support in ODF

Bart, there is no Zip entry like "Configurations/menubar/".  The only way
for there to be a Zip entry is for there to be a Zip directory entry with
that name, and that means there would have to be a file in the package that
had that name.

There might be such a META-INF/manifest.xml 

Dennis,

I use command line unzip 6.0 (ubuntu) which is based upon info-zip's code.
(unzip -l hello.. just lists the entries in the packages, without unzipping
to the file system)

Or, use hexdump and look at the end of the zip :-)

Which makes sense, because one can also zip (outside ODF context)
empty directories, and they get stored as well (probably with some flag that
says "this might be a directory", then we must check if it is allowed to do so
within ODF, because the ODF packaging is more restrictive about this)

Bart

________________________________________
From: Dennis E. Hamilton [dennis.hamilton@acm.org]
Sent: Sunday, September 26, 2010 4:44 AM
To: Hanssens Bart; 'David LeBlanc'; office@lists.oasis-open.org
Cc: Cornelis Frank
Subject: RE: [office] RE: XAdES support in ODF

I don't believe there is such a Zip entry.  What tool are you using to look
at the Zip file?  (Do not use the built-in Windows shell that simulates
folders, or any Linux equivalent.  They may make a folder where there is
none in the Zip itself if there is a Zipped file that has that path as part
of its name.)

 - Dennis

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be]
Sent: Saturday, September 25, 2010 16:26
To: dennis.hamilton@acm.org; 'David LeBlanc'; office@lists.oasis-open.org
Cc: Cornelis Frank
Subject: RE: [office] RE: XAdES support in ODF

Dennis,


uhm, perhaps I'm missing something here.

I'm not looking at the manifest at all, only at the zip.

There *is* a zip entry called "Configurations/menubar/".

Unzipping the .odt would map it to empty directories, but directories are
actually
also files (probably this is what you meant, David  ?), so indeed they
should also
be signed.


Best regards,

Bart


________________________________________
From: Dennis E. Hamilton [dennis.hamilton@acm.org]
Sent: Sunday, September 26, 2010 12:08 AM
To: Hanssens Bart; 'David LeBlanc'; office@lists.oasis-open.org
Cc: Cornelis Frank
Subject: RE: [office] RE: XAdES support in ODF

Bart, there is no Zip entry like "Configurations/menubar/".  The only way
for there to be a Zip entry is for there to be a Zip directory entry with
that name, and that means there would have to be a file in the package that
had that name.

There might be such a META-INF/manifest.xml 

I knew I had a command-line Zipper somewhere.  Here is what 7zip has to say
about that document:

12:57
7-Zip (A) 4.42  Copyright (c) 1999-2006 Igor Pavlov  2006-05-14
12:07:19.34 C:\MyProjects\java\ODMdev> 7za l helloworld-signed.odt
Listing archive: helloworld-signed.odt

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------
2010-09-24 16:49:42 .....           39           39  mimetype
2010-09-24 16:49:42 .....         3105          813  content.xml
2010-09-24 16:49:42 .....          532          243  manifest.rdf
2010-09-24 16:49:42 .....        10864         1993  styles.xml
2010-09-24 16:49:42 .....         1247         1247  meta.xml
2010-09-24 16:49:42 .....         1018          434
Thumbnails\thumbnail.png
2010-09-24 16:49:42 .....            0            2
Configurations2\accelerator\current.xml
2010-09-24 16:49:42 D....            0            0
Configurations2\progressbar
2010-09-24 16:49:42 D....            0            0  Configurations2\floater
2010-09-24 16:49:42 D....            0            0
Configurations2\popupmenu
2010-09-24 16:49:42 D....            0            0  Configurations2\menubar
2010-09-24 16:49:42 D....            0            0  Configurations2\toolbar
2010-09-24 16:49:42 D....            0            0
Configurations2\images\Bitmaps
2010-09-24 16:49:42 D....            0            0
Configurations2\statusbar
2010-09-24 16:49:42 .....         8773         1365  settings.xml
2010-09-24 16:49:42 .....         1989          344  META-INF\manifest.xml
2010-09-24 18:52:26 .....        30891        13945
META-INF\documentsignatures.xml
------------------- ----- ------------ ------------  ------------
                                 58458        20425  17 files

Hmm, attributes.

So, two things to figure out here.

1. Is it really "\" and I must remember to use that all of the time (which
says something about the resolution of relative IRIs inside the package)?

2. What is this attribute business and whose extension of the APPNOTE is
that or is it really provided in the APPNOTE.

3. Finally, notice that there is *no* such entry for Thumbnails and META-INF
nor for Configurations2 nor Configurations2\accelerator either so one
wonders what the point is that there are Zip entries of any form for those
Configurations2\... goodies (and their having bogus manifest:media-type
values in the manifest.xml markup).

4. Finally still, I have no idea how much of the way these names are
expressed is being done by the utility versus what is in the file (e.g.,
WinZip showed "\" on the ends, 7-zip shows "D" in some sort of attribute
display).  I'm still looking for a decent hex editor.

I think, without fear of contradiction, however, that there is no way to
reflect those D-attribute thingies in the DSig, and we should not want there
to be.  An external signature on the entire package would include whatever
that is, but we're not going there, it seems to me.

And finally, it seems like OIC Appnote time, aye?

 - Dennis

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Sunday, September 26, 2010 11:30
To: 'Hanssens Bart'; 'David LeBlanc'; office@lists.oasis-open.org
Cc: 'Cornelis Frank'
Subject: RE: [office] RE: XAdES support in ODF

So, please capture the output of the unzip -l helloword-signed.odt and send
me the text file, since I can't duplicate that on my equipment.  

Oh wait, I got it.  There are [bogus?] entries in the global directory at
the end of the file that have no files in the Zip package itself.  They all
happen to have names ending in "\" according to WinZip, which I find passing
strange since I thought the separator in Zip is "/" so I am not sure how
much is literally the case or I have been using the wrong character all of
this time.

I've included a PNG of what WinZip says is in the file, in the order in
which the content appears in the file.

If I perform the Winzip integrity test on the file, here is the report I
get:

No errors detected in compressed data of
\\Whs\Users\orcmid\docs\associazione\standards\OASIS\ODF\Development\hellowo
rld-signed.odt.
Testing ...
testing: mimetype                 OK
testing: content.xml              OK
testing: manifest.rdf             OK
testing: styles.xml               OK
testing: meta.xml                 OK
testing: Thumbnails\thumbnail.png   OK
testing: Configurations2\accelerator\current.xml   OK
testing: Configurations2\progressbar\   OK
testing: Configurations2\floater\   OK
testing: Configurations2\popupmenu\   OK
testing: Configurations2\menubar\   OK
testing: Configurations2\toolbar\   OK
testing: Configurations2\images\Bitmaps\   OK
testing: Configurations2\statusbar\   OK
testing: settings.xml             OK
testing: META-INF\manifest.xml    OK
testing: META-INF\documentsignatures.xml   OK

I need to dig up a decent hex editor and see what is really going on in this
file.  I'll follow-up after I have done that.

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
Sent: Sunday, September 26, 2010 02:30
To: dennis.hamilton@acm.org; 'David LeBlanc'; office@lists.oasis-open.org
Cc: Cornelis Frank
Subject: RE: [office] RE: XAdES support in ODF

Dennis,

I use command line unzip 6.0 (ubuntu) which is based upon info-zip's code.
(unzip -l hello.. just lists the entries in the packages, without unzipping
to the file system)

Or, use hexdump and look at the end of the zip :-)

Which makes sense, because one can also zip (outside ODF context)
empty directories, and they get stored as well (probably with some flag that
says "this might be a directory", then we must check if it is allowed to do
so
within ODF, because the ODF packaging is more restrictive about this)

Bart

[ ... ] 

Bart, I think we went off on a tangent in talking about manifest entries for
[pseudo-]sub-documents.  I don't think any of us think there is any way
those show up in a signature other than the signature of manifest.xml (and
lord knows what manifest.rdf does with them if anything -- I'm afraid to
look).  There's no cheese at the end of that maze, and nothing to change in
the specification.

On the more interesting topic of signing every file in the Zip, there is the
difficulty, as you point out, of not knowing whether the files are material
to the document and what is being signed.  And we don't know what
significance there might be in the mere existence of a package file, even
when its content is of length 0.

I believe the only way out of that is with more powerful transforms that
deal with exactly what it is that is perceivable to the signer and that is
being signed.  This is not something we have available at this point, but it
would be good for folks to come up with some.  Also, I wonder if it would
work to have the transform that is so used also be a (signed) part of the
(signed) package.  Hmm ...

Even if we said there was a prefix (e.g., "not-signable/") that began the
name of every package file that is to be excluded from signing, we have no
way of establishing that the presence of something there is not bogus, and
there is no way to prevent it being included in a signature anyhow.

It seems to me that this is not a road we can go down either, at this point.

 - Dennis

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be] 
Sent: Saturday, September 25, 2010 14:32
To: David LeBlanc; dennis.hamilton@acm.org; office@lists.oasis-open.org
Cc: Cornelis Frank
Subject: RE: [office] RE: XAdES support in ODF

Hi David,


I totally agree, and like mentioned before, every *file* (including the
0-length current.xml) has been signed 
in the example :-)
If there's another *file* that should have been signed (but isn't), can you
please give an example ? That's
probably something we've missed and then we'll correct it in our
application. Thanks.

So that leaves us with zip entries like "Configurations/menubar/", if they
are to be signed, then it should
IMHO be reflected in the spec (I wouldn't call this "a file", and the spec
only says "shall contain a