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] RE: XAdES support in ODF

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 
<ds:Reference> element for each *file*" - 1.2cd05 part 1, but perhaps I'm
misinterpreting "file" in this

Regarding files not affecting content or appearance, I think it's not
possible to be sure that a file does not
ever change content or appearance (might be implementation-specific), and
signing applications may not
even have the slightest idea how ODF could be rendered (like our eID
component: it parses some XML
and adds signatures, that's it)

Best regards,


From: David LeBlanc [dleblanc@exchange.microsoft.com]
Sent: Saturday, September 25, 2010 10:29 PM
To: dennis.hamilton@acm.org; Hanssens Bart; office@lists.oasis-open.org
Cc: Cornelis Frank
Subject: RE: [office] RE: XAdES support in ODF

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 <dennis.hamilton@acm.org>
Sent: Friday, September 24, 2010 10:07 PM
To: David LeBlanc <dleblanc@exchange.microsoft.com>; 'Hanssens Bart'
<Bart.Hanssens@fedict.be>; office@lists.oasis-open.org
Cc: 'Cornelis Frank' <Frank.Cornelis@fedict.be>
Subject: RE: [office] RE: XAdES support in ODF

You're right, the Configurations2\accelerator\current.xml should have been
signed, and it was.  Oddly, they used the default transformation, but I
guess that is tolerable considering it is a 0-length file.

So I don't think they missed any that they weren't supposed to.  They even
signed the mimetype, Thumbnails/thumbnail.png, manifest.rdf and
META-INF/manifest.xml.  It looks like everything was signed that could be.

 - Dennis

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]