RE: [office] [OASIS Issue Tracker] Commented: (OFFICE-3028) Updatedigital signatures for better XaDeS support

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

Inline - 

From: Michael Brauer [mailto:michael.brauer@oracle.com] 

David LeBlanc wrote:
>> I'll post this back to the web site when I return from travel, but it is a chicken-and-egg problem. You simply cannot sign the signatures file. You have made the decision that all signatures must be in one file, so you then have a number of problems:

>We don't say that all signatures must be in one file. Were is that said?

Because of the construct that only one file is defined for document signatures, and that an element is then defined to contain said signatures. This is a fine approach, and the OOXML approach of having a 'folder' which is designated to contain signatures, each of which must have a Signature as a top-level element is also a good approach. Either way, the consumer needs to know just where one might find signatures. Regardless, it is a problem to attempt to sign the container of the signatures.

>> 3) Upgrading the XAdES information would also break the signature.

>Thay may be right (I'm not sure, since you can apply transformation to the signatures). But the point is that we currently say that the document-signature.xml may be signed. This means, it hasn't to. What is the value in saying in must not be signed?

Item 3 above - it breaks XAdES, and XAdES support is a very good thing to have.

>> OK, then we should discuss this. It is my position that anything that affects the content or display of the content should be signed - What You See Is What You Sign. It is possible to have additional metadata which may only make sense to the file store. If you sign this metadata, then the store could change it and break it. We have provisions for exactly this in OOXML, and it is needed for several functional reasons. I see it as a benefit if we can maintain as much functional equivalence as possible between ODF and OOXML, and think this is a benefit for everyone. Other people may certainly have other opinions, so I'd like to see what those opinions are.

>The idea behind a document-signature was that it signs everything to ensure the integrity of the file. That is, it should also avoid that files are added to the package. That appears to be something useful to me.

I agree, and we've had similar debates in our organization. There's really 3-4 classes of signature:

1) External signature which completely maintains integrity of the signed data. IMHO, this is the best way to accomplish the goal you cite. But we cannot do this until we make a container, which would solve the encryption problem as well.
2) internal signature which attempts to do the same thing. This runs into chicken and egg problems.
3) Signature of all content and display information
4) Signature of some subset

>If we further have a use case where we only sign the content or display, then I have no objection to add a different kind of signature (let's say a "odf-content-signature") that signs what you are proposing. We only should be a little bit more specific, and list the files that are signed (content.xml, styles.xml, files referenced by <draw:image> if they are contained in the same package, etc.)

That's an interesting idea, and I'd like to think about it and see what others say.