RE: [office] RE: Directories in Zip packages

[David LeBlanc <dleblanc@exchange.microsoft.com>]

There isn't really a way to sign a directory entry without making up a transform. If you did that, then you'd have to specify the transform in the standard. I can think of several ways to make a transform, but it would be a nuisance to implement and express in normative language.

IMHO, that's really overkill. I think we want to drop back to "What You See Is What You Sign." If an empty directory has no effect on either the content or appearance of the document, and I cannot imagine a scenario in which it would, then we should ignore it for the purpose of signatures. If a file turned up later in that directory, then the presence of a new file would then violate the requirement that all of the files be signed, and you're dealing with either an invalid or partial signature, depending on how an implementer wanted to treat that particular error.

In OOXML signatures, there are provisions for certain parts of the archive not being signed, so there's some tolerance for metadata to get updated without invalidating the signature. This is part of why I wrote the proposal to say that "all files must be signed in order for the signature to be a full document signature" - I wanted to provide for the possibility in the future of signing something less.

Given the time constraints, I'd propose doing the following:

1) Ignore empty directories.
2) Do not make a transform that captures the directory structure of the archive, because it does not affect the appearance or content of the document.
3) In vNext, we should work on defining what must be signed in a more refined manner, paying attention to what affects content and/or appearance and what does not.

-----Original Message-----
From: Bob Jolliffe [mailto:bobjolliffe@gmail.com] 
Sent: Monday, September 27, 2010 3:19 PM
To: dennis.hamilton@acm.org
Cc: Hanssens Bart; Svante Schubert; ODF TC List
Subject: Re: [office] RE: Directories in Zip packages

On 27 September 2010 22:11, Dennis E. Hamilton <dennis.hamilton@acm.org> wrote:
> -1
>
> Unless there is a proposal for how to accomplish the signing of 
> "directories" via XML Digital Signature (and also directory entries 
> for package files, which we don't sign either).
>
> Please include a specific rule for knowing what is a directory entry 
> in the Zip, because there is no help in APPNOTE 6.2.0 that I can find.

Not sure whether this should make me laugh or cry.  Given that it seems you are right that the appnote is not helpful, and given that I know the java ZipEntry class has a method called isDirectory(), I thought I'd quickly look up how the openjdk implements it:

     public boolean isDirectory() {
         return name.endsWith("/");
     }

well there you have it.  Make of that what you will :-)

In practice, besides the trailing '/', it does look empirically like you can spot a directory by the fact that the local file header of the entry is followed immediately by the next local file header ie. there is no file data section.  Note this is unlike the zero length file (which has a file data section of 2 bytes worth of compression infrastructure). So as far as 'directory' entries are concerned there really really doesn't seem to be anything to sign.  So I guess I would go along with Bart's suggestion but minus the "directories".  And if we do find these things in an odf zip package (which we'd rather not) the consumer could and should simply ignore them.

Cheers
Bob

>
>  - Dennis
>
> -----Original Message-----
> From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be]
> Sent: Monday, September 27, 2010 10:42
> To: dennis.hamilton@acm.org; 'Svante Schubert'
> Cc: ODF TC List
> Subject: RE: [office] RE: Directories in Zip packages
>
> Arrgh :-) Folks, this is going back and forth, while I really would 
> like to see some work on XAdES :-)
>
> My suggestion:
>
> - discourage (but not forbid) the use of empty directories and empty 
> files in ODF packages
> - sign everything in the zip (including empty directories and empty 
> files)
> - change the 1.2 draft about document signatures and mention "sign 
> every entry" instead of "sign every file"
>
> This means there's no impact on unsigned ODF docs (because every 
> implementation can still use empty things, although it is discouraged)
>
> There is impact on signed implementations signing/verifying signed 
> docs, but those products probably have to be updated anyway (to 
> support correct prefixes, version attributes etc)
>
>
> Bart
>
>
> ________________________________________
> From: Dennis E. Hamilton [dennis.hamilton@acm.org]
> Sent: Monday, September 27, 2010 7:30 PM
> To: 'Svante Schubert'
> Cc: ODF TC List
> Subject: RE: [office] RE: Directories in Zip packages
>
> Svante, a sub-document doesn't have to be an "actual" directory in any 
> literal sense.  This was clear in ODF 1.0/1.1 and I know of nothing 
> that requires us to change that.
>
> The sub-document <manifest:file-entry> simply has to specify a "path" 
> prefix that some of the package files share and that are treated as a 
> collection with respect to the manifest:media-type.  Otherwise we 
> would be in a world of hurt with manifest:full-path="/".
>
> We don't have nor require that "META-INF/" be declared as a 
> sub-document or have a directory entry in the package, nor do we do so 
> for "Thumbnail/" and so on.
>
> When there is an ODF Package-significant use for declaring empty 
> directories, we should treat it as an extension case.  In the 
> meantime, I think we should give consumers a break here, especially 
> around document security issues.  A speculative future scenario is no 
> help to a consumer who stumbles on one of these now because of some inscrutable producer behavior.
>
>  - Dennis
>
> -----Original Message-----
> From: Svante Schubert [mailto:Svante.Schubert@oracle.com]
> Sent: Monday, September 27, 2010 09:20
> To: office@lists.oasis-open.org
> Subject: Re: [office] RE: Directories in Zip packages
>
> On 27.09.2010 16:57, Bob Jolliffe wrote:
>
>        ...
>
>        So I would say that an odf producer should only produce entries 
> in the
>        zipfile for non-zero-length streams (this would by default also
>        excludes directories).  And that each of these shall be 
> referenced in
>        a full document signature.
>
> May I remind the TC, that from the perspective of the package (ODF 1.2 
> part
> 3 - which can be seen as the base layer of ODF 1.2) an entity called a 
> document is defined by a directory related with a media type (in the 
> manifest.xml).
>
> In general I believe when a generic functionality does not hurt, it 
> should not be forbidden nor dropped as other yet unknown user 
> scenarios might rely on it.
>
> Regards,
> Svante
>
>
> --
>
>
>  <http://www.oracle.com/>
> Svante Schubert | ODF Standardization
> Phone: +49 40 23646 965
> Oracle Office GBU
>
> ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der 
> Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der 
> Ven
>
>  <http://www.oracle.com/commitment>
>
> Oracle is committed to developing practices and products that help 
> protect the environment
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> 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:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> 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:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>

---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php