OASIS Open Document Format for Office Applications (OpenDocument) TC

On Friday 16 February 2007 12:08, Michael Brauer wrote:
> A document signature *shall* be considered to be valid only if
> it valid itself, and if it is applied to all files of the package.

This requirement will prevent applications from implementing sectional
signing.
Sectional signing allows signing of only certain elements in a document
and is supported by xml-dsig.
For example in an approval process a document may be written by one
person and signed, then another person needs to approve it after
possibly adding some comments to a "comments" section of the document.
Another example is a collaboration of multiple people on the same
document, each responsible for his own section. Two requirements may
arise in this scenario: section A may need to be edited after section B
is already completed and signed, and person A may not want to appear to
have signed the text of section B for legal or other reasons.

To add to my previous suggestion for visible signatures:
I propose to add a new signature control.
This control can have some default appearance (something like
"x________").
It can have attributes such as the intended signer name/role.
It can be associated with an existing document element (section, table,
etc.) for sectional signing.
It must have a unique ID attribute.
When a user activates this control, the application will produce
document content to represent a new appearance for the signed control
(For example the application may prompt the user or may already have a
pre-configure signature image file for the user and the new appearance
will be built from that image + signer name + date / time).
The document content for the new appearance will not be stored in the
document itself so as not to break already existing signatures, but
instead will be written to a new file within the META-INF folder. The
content of the file will be an element that includes the originating
control's ID and the new appearance markup.
Next, the application will sign the whole document (or the element
specified in the control) and create the appropriate 

Uri,

we had long discussions about section signing in OOo, and in the end
decided to not do it.

One problem are the styles.
It doesn't help to sign a section w/o signing all styles that are
involved, otherwise someone could hide text which is in a signed section.

The other problem is that (current) ODF applications read the complete
XML, and even when only modifying one character, they completely
"export" everything again - content and styles. They don't remember what
XML they did read. For embedded signatures they would have to do so.

So for now we don't plan to implement such thing in SO/OOo.

It probably doesn't make sense to specify anything when nobody plans to
implement it in the near future.
So we better wait until someone really wants to do so - or does anyone
have plans here?

And to your visible signatures:
I would like to have that also, but we have no concrete plans right now.
It's easier to specify such things if someone is really working on such
a feature, otherwise you will miss something, or specify it in a way
it's not usable.
Probably for exactly this reason OASIS requires 3 confirmation that a
spec is actively used before it can become a standard.

So I suggest to specify these two things in a later ODF release, when
nobody plans to do such implementations now.

Malte.

Uri Resnitzky wrote, On 02/21/07 22:31:
> On Friday 16 February 2007 12:08, Michael Brauer wrote:
>   
>> A document signature *shall* be considered to be valid only if
>> it valid itself, and if it is applied to all files of the package.
>>     
>
> This requirement will prevent applications from implementing sectional
> signing.
> Sectional signing allows signing of only certain elements in a document
> and is supported by xml-dsig.
> For example in an approval process a document may be written by one
> person and signed, then another person needs to approve it after
> possibly adding some comments to a "comments" section of the document.
> Another example is a collaboration of multiple people on the same
> document, each responsible for his own section. Two requirements may
> arise in this scenario: section A may need to be edited after section B
> is already completed and signed, and person A may not want to appear to
> have signed the text of section B for legal or other reasons.
>
> To add to my previous suggestion for visible signatures:
> I propose to add a new signature control.
> This control can have some default appearance (something like
> "x________").
> It can have attributes such as the intended signer name/role.
> It can be associated with an existing document element (section, table,
> etc.) for sectional signing.
> It must have a unique ID attribute.
> When a user activates this control, the application will produce
> document content to represent a new appearance for the signed control
> (For example the application may prompt the user or may already have a
> pre-configure signature image file for the user and the new appearance
> will be built from that image + signer name + date / time).
> The document content for the new appearance will not be stored in the
> document itself so as not to break already existing signatures, but
> instead will be written to a new file within the META-INF folder. The
> content of the file will be an element that includes the originating
> control's ID and the new appearance markup.
> Next, the application will sign the whole document (or the element
> specified in the control) and create the appropriate 

Malte,

It would be useful if you can provide a reference to the past long
discussions you are referring to in order to see the rationales and
arguments used.

Regarding styles - a possible solution is to limit sectional signing so
that after the first section is signed styles cannot change. Thus it
will be possible to always sign all the styles information in addition
to the section being signed. Such a limitation will probably not reduce
much the usability of the sectional signing feature.

Regarding complete XML export - if the document is edited using the same
application can't we expect the exported version to be identical to the
imported one if no changes were made? Again I feel this limitation will
probably not reduce much the usability of the sectional signing feature.

Regarding implementation - since OOo is developed by an open community,
would it be helpful if we volunteer to contribute an implementation of
sectional signing in OOo to the community?

The fact is that today we have real customers actually using sectional
signing in proprietary binary format documents. This demonstrates that
this feature is important to users and not just a nice to have idea to
be added to the spec.

In any case, whatever decision is made on this, I think it is critical
that the spec we're developing will not limit the addition of sectional
signing by add-ons or future implementations. Requiring the application
to consider a signature invalid because it is not applied to all files
of the package will create such a limitation.

Regarding visual signatures - this is implemented in many applications
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. I can provide references to many signature products that
add visual signatures as an add-on feature for popular proprietary
binary format based applications. Again, we may be willing to volunteer
to contribute an implementation of visual signatures to OOo.

The motivation here is to enable users to move from paper based
processes to electronic documents covering the complete document
lifecycle including signatures, approvals, etc. Otherwise you find many
cases where the electronic document is printed just so it can be
manually signed, then faxed, mailed and archived or in some cases
scanned back into an electronic archive.

Thanks,

- Uri 



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Malte.Timmermann@Sun.COM [mailto:Malte.Timmermann@Sun.COM] 
Sent: Thursday, February 22, 2007 4:14 PM
To: Uri Resnitzky
Cc: office@lists.oasis-open.org
Subject: Re: [office] Digital signature proposal

Uri,

we had long discussions about section signing in OOo, and in the end
decided to not do it.

One problem are the styles.
It doesn't help to sign a section w/o signing all styles that are
involved, otherwise someone could hide text which is in a signed
section.

The other problem is that (current) ODF applications read the complete
XML, and even when only modifying one character, they completely
"export" everything again - content and styles. They don't remember what
XML they did read. For embedded signatures they would have to do so.

So for now we don't plan to implement such thing in SO/OOo.

It probably doesn't make sense to specify anything when nobody plans to
implement it in the near future.
So we better wait until someone really wants to do so - or does anyone
have plans here?

And to your visible signatures:
I would like to have that also, but we have no concrete plans right now.
It's easier to specify such things if someone is really working on such
a feature, otherwise you will miss something, or specify it in a way
it's not usable.
Probably for exactly this reason OASIS requires 3 confirmation that a
spec is actively used before it can become a standard.

So I suggest to specify these two things in a later ODF release, when
nobody plans to do such implementations now.

Malte.

Uri Resnitzky wrote, On 02/21/07 22:31:
> On Friday 16 February 2007 12:08, Michael Brauer wrote:
>   
>> A document signature *shall* be considered to be valid only if it 
>> valid itself, and if it is applied to all files of the package.
>>     
>
> This requirement will prevent applications from implementing sectional

> signing.
> Sectional signing allows signing of only certain elements in a 
> document and is supported by xml-dsig.
> For example in an approval process a document may be written by one 
> person and signed, then another person needs to approve it after 
> possibly adding some comments to a "comments" section of the document.
> Another example is a collaboration of multiple people on the same 
> document, each responsible for his own section. Two requirements may 
> arise in this scenario: section A may need to be edited after section 
> B is already completed and signed, and person A may not want to appear

> to have signed the text of section B for legal or other reasons.
>
> To add to my previous suggestion for visible signatures:
> I propose to add a new signature control.
> This control can have some default appearance (something like 
> "x________").
> It can have attributes such as the intended signer name/role.
> It can be associated with an existing document element (section, 
> table,
> etc.) for sectional signing.
> It must have a unique ID attribute.
> When a user activates this control, the application will produce 
> document content to represent a new appearance for the signed control 
> (For example the application may prompt the user or may already have a

> pre-configure signature image file for the user and the new appearance

> will be built from that image + signer name + date / time).
> The document content for the new appearance will not be stored in the 
> document itself so as not to break already existing signatures, but 
> instead will be written to a new file within the META-INF folder. The 
> content of the file will be an element that includes the originating 
> control's ID and the new appearance markup.
> Next, the application will sign the whole document (or the element 
> specified in the control) and create the appropriate 

Uri,

Uri Resnitzky wrote, On 02/22/07 17:21:
> Malte,
>
> It would be useful if you can provide a reference to the past long
> discussions you are referring to in order to see the rationales and
> arguments used.
>   
Not so easy - lot's of discussions with colleagues, not written down :(
> Regarding styles - a possible solution is to limit sectional signing so
> that after the first section is signed styles cannot change. Thus it
> will be possible to always sign all the styles information in addition
> to the section being signed. Such a limitation will probably not reduce
> much the usability of the sectional signing feature.
>   
Worth considering...
> Regarding complete XML export - if the document is edited using the same
> application can't we expect the exported version to be identical to the
> imported one if no changes were made? Again I feel this limitation will
> probably not reduce much the usability of the sectional signing feature.
>   
Yes, at least when talking from one application, same version.
But the application would still have to remember the XML of the
signature, to dump it out on export.
Not a big issue.
But wouldn't people expect this feature to work even when using
different applications and/or versions?
OK, right now there are not to many apps doing ODF signatures...
> Regarding implementation - since OOo is developed by an open community,
> would it be helpful if we volunteer to contribute an implementation of
> sectional signing in OOo to the community?
>   
Yes!
Not an easy task, IMHO, considering all the different modules involved,
but possible.
Right now OOo even doesn't support embedded signatures, only detached.
> The fact is that today we have real customers actually using sectional
> signing in proprietary binary format documents. This demonstrates that
> this feature is important to users and not just a nice to have idea to
> be added to the spec.
>
> In any case, whatever decision is made on this, I think it is critical
> that the spec we're developing will not limit the addition of sectional
> signing by add-ons or future implementations. Requiring the application
> to consider a signature invalid because it is not applied to all files
> of the package will create such a limitation.
>   
Yes and no. An overall document signature can require this.
Others don't have to do so.
For example, if you sign macros, only the stuff in the macro/dialogs
folders is signed.

Right now, even our current Document signatures implementation doesn't
require that everything is signed.
Problem is that people don't understand that they can add stuff to the
zip file, without breaking the signatures.
User perception is important here. They simply try such things, and say
that the signature stuff doesn't work.
> Regarding visual signatures - this is implemented in many applications
> 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. I can provide references to many signature products that
> add visual signatures as an add-on feature for popular proprietary
> binary format based applications. Again, we may be willing to volunteer
> to contribute an implementation of visual signatures to OOo.
>   
Also very welcome.
As I said, when there is work done in that area, specification makes sense.
And I would be interested in the list of add-ons and  products...

Malte.



> The motivation here is to enable users to move from paper based
> processes to electronic documents covering the complete document
> lifecycle including signatures, approvals, etc. Otherwise you find many
> cases where the electronic document is printed just so it can be
> manually signed, then faxed, mailed and archived or in some cases
> scanned back into an electronic archive.
>
> Thanks,
>
> - Uri 
>
> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Malte.Timmermann@Sun.COM [mailto:Malte.Timmermann@Sun.COM] 
> Sent: Thursday, February 22, 2007 4:14 PM
> To: Uri Resnitzky
> Cc: office@lists.oasis-open.org
> Subject: Re: [office] Digital signature proposal
>
> Uri,
>
> we had long discussions about section signing in OOo, and in the end
> decided to not do it.
>
> One problem are the styles.
> It doesn't help to sign a section w/o signing all styles that are
> involved, otherwise someone could hide text which is in a signed
> section.
>
> The other problem is that (current) ODF applications read the complete
> XML, and even when only modifying one character, they completely
> "export" everything again - content and styles. They don't remember what
> XML they did read. For embedded signatures they would have to do so.
>
> So for now we don't plan to implement such thing in SO/OOo.
>
> It probably doesn't make sense to specify anything when nobody plans to
> implement it in the near future.
> So we better wait until someone really wants to do so - or does anyone
> have plans here?
>
> And to your visible signatures:
> I would like to have that also, but we have no concrete plans right now.
> It's easier to specify such things if someone is really working on such
> a feature, otherwise you will miss something, or specify it in a way
> it's not usable.
> Probably for exactly this reason OASIS requires 3 confirmation that a
> spec is actively used before it can become a standard.
>
> So I suggest to specify these two things in a later ODF release, when
> nobody plans to do such implementations now.
>
> Malte.
>
> Uri Resnitzky wrote, On 02/21/07 22:31:
>   
>> On Friday 16 February 2007 12:08, Michael Brauer wrote:
>>   
>>     
>>> A document signature *shall* be considered to be valid only if it 
>>> valid itself, and if it is applied to all files of the package.
>>>     
>>>       
>> This requirement will prevent applications from implementing sectional
>>     
>
>   
>> signing.
>> Sectional signing allows signing of only certain elements in a 
>> document and is supported by xml-dsig.
>> For example in an approval process a document may be written by one 
>> person and signed, then another person needs to approve it after 
>> possibly adding some comments to a "comments" section of the document.
>> Another example is a collaboration of multiple people on the same 
>> document, each responsible for his own section. Two requirements may 
>> arise in this scenario: section A may need to be edited after section 
>> B is already completed and signed, and person A may not want to appear
>>     
>
>   
>> to have signed the text of section B for legal or other reasons.
>>
>> To add to my previous suggestion for visible signatures:
>> I propose to add a new signature control.
>> This control can have some default appearance (something like 
>> "x________").
>> It can have attributes such as the intended signer name/role.
>> It can be associated with an existing document element (section, 
>> table,
>> etc.) for sectional signing.
>> It must have a unique ID attribute.
>> When a user activates this control, the application will produce 
>> document content to represent a new appearance for the signed control 
>> (For example the application may prompt the user or may already have a
>>     
>
>   
>> pre-configure signature image file for the user and the new appearance
>>     
>
>   
>> will be built from that image + signer name + date / time).
>> The document content for the new appearance will not be stored in the 
>> document itself so as not to break already existing signatures, but 
>> instead will be written to a new file within the META-INF folder. The 
>> content of the file will be an element that includes the originating 
>> control's ID and the new appearance markup.
>> Next, the application will sign the whole document (or the element 
>> specified in the control) and create the appropriate 

Hi all,

I'm not sure if anyone is aware of this but at the recent XML 2006 Conference there was an interesting presentation, "Applying XML Signatures to XForms-based Documents
".  Many of the concerns Uri has were addressed in that presentation.

The abstract for the presentation states; "The first architectural framework for fully combining XForms and XML Signatures is presented, including the ability to perform partial document signing, handle multiple signer scenarios and have the signature capture the presentation context of the signed data."

I'm not sure how far along the XForms group is with this work, but maybe we should consider an inquiry?  Perhaps even a invite to the conference presenter, 
John Boyer, Senior Product Architect, IBM?

~ge~


On 2/22/07, Malte Timmermann <Malte.Timmermann@sun.com">Malte.Timmermann@sun.com
> wrote:
Uri,

Uri Resnitzky wrote, On 02/22/07 17:21:
> Malte,

>
> It would be useful if you can provide a reference to the past long
> discussions you are referring to in order to see the rationales and
> arguments used.
>
Not so easy - lot's of discussions with colleagues, not written down :(
> Regarding styles - a possible solution is to limit sectional signing so
> that after the first section is signed styles cannot change. Thus it
> will be possible to always sign all the styles information in addition
> to the section being signed. Such a limitation will probably not reduce
> much the usability of the sectional signing feature.
>
Worth considering...
> Regarding complete XML export - if the document is edited using the same
> application can't we expect the exported version to be identical to the
> imported one if no changes were made? Again I feel this limitation will
> probably not reduce much the usability of the sectional signing feature.
>
Yes, at least when talking from one application, same version.
But the application would still have to remember the XML of the
signature, to dump it out on export.
Not a big issue.
But wouldn't people expect this feature to work even when using
different applications and/or versions?
OK, right now there are not to many apps doing ODF signatures...
> Regarding implementation - since OOo is developed by an open community,
> would it be helpful if we volunteer to contribute an implementation of
> sectional signing in OOo to the community?
>
Yes!
Not an easy task, IMHO, considering all the different modules involved,
but possible.
Right now OOo even doesn't support embedded signatures, only detached.
> The fact is that today we have real customers actually using sectional
> signing in proprietary binary format documents. This demonstrates that
> this feature is important to users and not just a nice to have idea to
> be added to the spec.
>
> In any case, whatever decision is made on this, I think it is critical
> that the spec we're developing will not limit the addition of sectional
> signing by add-ons or future implementations. Requiring the application
> to consider a signature invalid because it is not applied to all files
> of the package will create such a limitation.
>
Yes and no. An overall document signature can require this.
Others don't have to do so.
For example, if you sign macros, only the stuff in the macro/dialogs
folders is signed.

Right now, even our current Document signatures implementation doesn't
require that everything is signed.
Problem is that people don't understand that they can add stuff to the
zip file, without breaking the signatures.
User perception is important here. They simply try such things, and say
that the signature stuff doesn't work.
> Regarding visual signatures - this is implemented in many applications
> 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. I can provide references to many signature products that
> add visual signatures as an add-on feature for popular proprietary
> binary format based applications. Again, we may be willing to volunteer
> to contribute an implementation of visual signatures to OOo.
>
Also very welcome.
As I said, when there is work done in that area, specification makes sense.
And I would be interested in the list of add-ons and  products...

Malte.



> The motivation here is to enable users to move from paper based
> processes to electronic documents covering the complete document
> lifecycle including signatures, approvals, etc. Otherwise you find many
> cases where the electronic document is printed just so it can be
> manually signed, then faxed, mailed and archived or in some cases
> scanned back into an electronic archive.
>
> Thanks,
>
> - Uri
>
> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: 
Malte.Timmermann@Sun.COM [mailto:Malte.Timmermann@Sun.COM]
> Sent: Thursday, February 22, 2007 4:14 PM
> To: Uri Resnitzky
> Cc: office@lists.oasis-open.org
> Subject: Re: [office] Digital signature proposal
>
> Uri,
>
> we had long discussions about section signing in OOo, and in the end
> decided to not do it.
>
> One problem are the styles.
> It doesn't help to sign a section w/o signing all styles that are
> involved, otherwise someone could hide text which is in a signed
> section.
>
> The other problem is that (current) ODF applications read the complete
> XML, and even when only modifying one character, they completely
> "export" everything again - content and styles. They don't remember what
> XML they did read. For embedded signatures they would have to do so.
>
> So for now we don't plan to implement such thing in SO/OOo.
>
> It probably doesn't make sense to specify anything when nobody plans to
> implement it in the near future.
> So we better wait until someone really wants to do so - or does anyone
> have plans here?
>
> And to your visible signatures:
> I would like to have that also, but we have no concrete plans right now.
> It's easier to specify such things if someone is really working on such
> a feature, otherwise you will miss something, or specify it in a way
> it's not usable.
> Probably for exactly this reason OASIS requires 3 confirmation that a
> spec is actively used before it can become a standard.
>
> So I suggest to specify these two things in a later ODF release, when
> nobody plans to do such implementations now.
>
> Malte.
>
> Uri Resnitzky wrote, On 02/21/07 22:31:
>
>> On Friday 16 February 2007 12:08, Michael Brauer wrote:
>>
>>
>>> A document signature *shall* be considered to be valid only if it
>>> valid itself, and if it is applied to all files of the package.
>>>
>>>
>> This requirement will prevent applications from implementing sectional
>>
>
>
>> signing.
>> Sectional signing allows signing of only certain elements in a
>> document and is supported by xml-dsig.
>> For example in an approval process a document may be written by one
>> person and signed, then another person needs to approve it after
>> possibly adding some comments to a "comments" section of the document.
>> Another example is a collaboration of multiple people on the same
>> document, each responsible for his own section. Two requirements may
>> arise in this scenario: section A may need to be edited after section
>> B is already completed and signed, and person A may not want to appear
>>
>
>
>> to have signed the text of section B for legal or other reasons.
>>
>> To add to my previous suggestion for visible signatures:
>> I propose to add a new signature control.
>> This control can have some default appearance (something like
>> "x________").
>> It can have attributes such as the intended signer name/role.
>> It can be associated with an existing document element (section,
>> table,
>> etc.) for sectional signing.
>> It must have a unique ID attribute.
>> When a user activates this control, the application will produce
>> document content to represent a new appearance for the signed control
>> (For example the application may prompt the user or may already have a
>>
>
>
>> pre-configure signature image file for the user and the new appearance
>>
>
>
>> will be built from that image + signer name + date / time).
>> The document content for the new appearance will not be stored in the
>> document itself so as not to break already existing signatures, but
>> instead will be written to a new file within the META-INF folder. The
>> content of the file will be an element that includes the originating
>> control's ID and the new appearance markup.
>> Next, the application will sign the whole document (or the element
>> specified in the control) and create the appropriate <Signature>
>> element in the documentsignatures.xml file. The file with the new
>> signature appearance must always be included in the signature
>>
> calculation as well.
>
>> The application is expected to display signed controls using the
>> content from their respective appearance files rather than the default
>>
>
>
>> appearance.
>> When a signed control is activated, the application can validate the
>> signature, display information about the signed area, about the signer
>>
>
>
>> and certificate, etc.
>> To prevent users from thinking a document is properly signed when in
>> fact the signature validation fails (as Thomas suggested),
>> applications should display a validation mark on top of the appearance
>>
>
>
>> in any signed signature control.
>> This validation mark will indicate if the signature has been validated
>>
>
>
>> yet or not and if the validation failed or succeeded.
>>
>> I'm new to ODF (but have a lot of experience in digital signatures and
>>
>
>
>> signed documents of various formats) so I apologize in advance if I'm
>> not using the correct terminology.
>>
>> - Uri
>>
>> Uri Resnitzky
>> Chief Scientist
>> ARX
>> http://www.arx.com
>>
>>



--
Gary Edwards
The OpenDocument Foundation, Inc.
Redwood City, CA USA 94063
(650) 365-0899
(650) 888-2268 c.
gary.edwards@OpenDocument.us">gary.edwards@OpenDocument.us

http://OpendocumentFoundation.us
http://OpenStack.blogspot.com

Founding member of the OASIS OpenDocument TC


Founding member of  the OpenDocument Foundation, Inc. - a USA 501c(3) non profit chartered in the public interest to support, develop and promote the OASIS OpenDocument XML file format.

OpenDocument is the world's first "universal file format".  But it's also central to the future of the Open Internet.  So the Foundation charter includes another most important objective.  The Foundation seeks to increase the participation of open source communities and individuals in the formal "Open Standards" process.  By joining OSS with vendors and traditional organizations in the work of perfecting truly Open Standards, the Foundation believes that the Open Internet we enjoy today will remain open for future generations to come.

Uri, all,

thank you very much for your feedback and suggestions.

Uri Resnitzky wrote:
> Malte,
> 

> 
> In any case, whatever decision is made on this, I think it is critical
> that the spec we're developing will not limit the addition of sectional
> signing by add-ons or future implementations. Requiring the application
> to consider a signature invalid because it is not applied 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.

> Regarding visual signatures - this is implemented in many applications
> 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. I can provide references to many signature products that
> add visual signatures as an add-on feature for popular proprietary
> binary format based applications. Again, we may be willing to volunteer
> to contribute an implementation of visual signatures to OOo.

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.

Best regards

Michael

Michael,

Michael Brauer wrote:
> Uri Resnitzky wrote:
> > In any case, whatever decision is made on this, I think it is
critical 
> > that the spec we're developing will not limit the addition of 
> > sectional signing by add-ons or future implementations. Requiring
the 
> > application to consider a signature invalid because it is not
applied 
> > 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
applications 
> > 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 

Uri,

I have read through your suggestion, and it seem to me that if one would 
specify a visual signature as described by you, it still would be an 
extension of the current proposal. Do you agree?

Michael



Uri Resnitzky wrote:
> Michael,
> 
> Michael Brauer wrote:

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

Michael Brauer wrote:
> I have read through your suggestion, and it seem to me that 
> if one would specify a visual signature as described by you, 
> it still would be an extension of the current proposal. Do you agree?
I agree in the sense that your document signatures are a special case of
the visual signatures that I propose. Therefore I see no reason not to
adopt the visual signatures and that will cover your suggestion as well.

- Uri

Uri,

I think there is some mis-understanding. My question was not whether we 
should or should not have visual signatures. My question was whether we 
could agree on the current digital signature proposal, and still could 
add visual signatures later. My understanding is that this is the case.

Best regards

Michael

Uri Resnitzky wrote:
> Michael Brauer wrote:
>> I have read through your suggestion, and it seem to me that 
>> if one would specify a visual signature as described by you, 
>> it still would be an extension of the current proposal. Do you agree?
> I agree in the sense that your document signatures are a special case of
> the visual signatures that I propose. Therefore I see no reason not to
> adopt the visual signatures and that will cover your suggestion as well.
> 
> - Uri


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS