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] Digital signature proposal


Michael Brauer wrote:
> Uri Resnitzky wrote:
> > In any case, whatever decision is made on this, I think it is
> > that the spec we're developing will not limit the addition of 
> > sectional signing by add-ons or future implementations. Requiring
> > application to consider a signature invalid because it is not
> > to all files of the package will create such a limitation.
> As Malte explained in his reply, the current proposal does 
> not add this limitation. It defines a document signature and 
> a macro signature that both require that the signature is 
> applied to certain streams, but it explicitly allows 
> arbitrary other signatures, that do not have these 
> restriction. So, if we would agree on this proposal, we still 
> could add signed sections later.

OK, lets discuss sectional signatures separately.

> > Regarding visual signatures - this is implemented in many
> > and file formats, and is actually in everyday use today. Just two 
> > examples for file formats which 'natively' support visual signatures

> > are PDF and OOXML.
> A visual signature would be an extension of the current 
> proposal, but would not have an influence on that proposal 
> itself. I therefore think we should discuss this separately.

Supporting visual signature does influence your original proposal in the
way the XML d-sig <Signature> element is built:
When a document needs to be signed by two persons, when the second
signature is added, its visual appearance markup cannot be directly
added to the document content, because that would invalidate the first
The solution for this is to store the markup for the visual appearance
of each signature in an <Object> element of the <Signature> object in
the META-INF/documentsignatures.xml file, instead of putting it in the
document content.xml.
The <SignedInfo> element of each such <Signature> object must include a
<Reference> element to the visual appearance markup <Object> for that
The content.xml will only have a placeholder (the signature control I
suggested), and we can require the application to display this control
using the markup found in the <Object> of the corresponding <Signature>
(if it is signed).


- Uri

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