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] [OASIS Issue Tracker] Commented: (OFFICE-3028) Updatedigital signatures for better XaDeS support


David LeBlanc wrote:
> 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.

But ODF allows multiple signature files as well. They are not stored in 
a separate folder but in META-INF, but they are identified by having the 
  term "signatures" in their name.

>>> 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.

Why does a "may" break XAdes support? May means that something is 
optional. If in the XAdes case the signature file cannot be signed, then 
it hasn't to be signed. Where does this break XAdes?
>>> 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.

Great. Thanks.

Michael Brauer | Oracle Office Development
Phone: +49 40 23646 500
Oracle Office GBU

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]