Jochen wrote:
Giuseppe Castagno schrieb:
Hi Joachim,
Joachim Lingner - Sun Germany Software Engineer - ham02 - Hamburg wrote:
Hi,
I wrote a page at
http://wiki.services.openoffice.org/wiki/Improving_The_Digital_Signature_Feature
where I put together my view of how the "signature framework" could
work. It is not clear when this is to be implemented and who would
take of it.
I had at last some time to read the page you wrote.
Interesting ideas, but I'm not sure the resource to implement that are
easily available. Not to mention the complexity of the job (I'm
thinking to the different legal issues, different among the countries).
My idea is that OOo does only provide the infrastructure for the
signature component. The signature components itself should be developed
by interested parties. This is something that cannot be done by OOo
unless there are a lot more volunteers (developers, lawyers) and
donators. The latter is important because certification processes will
certainly cost money.
I think that practically all of the job carried out by OOo in sign a
document can already be duplicated (I agree, with a lot of effort on the
part of a developer) in an extension as the OOo API is today, but for
the functionality needed that are present but still unpublished.
The trick would be refactor the code so that it can be used by other
parties, which indeed is a huge task.
See issue 87496 [1] as an example.
This issue is about "Publish storage related services". Did you confuse
the issue with some other?
actually I was thinking along the lines:
- to sign means (almost always) accessing the components of the package,
then:
- perform some digest on every one of them (digest method could differ)
- sign the digest
- add the signature info to the package
Where the package is what is (usually) called storage in OOo API literature.
This is one the low-level part that should be done to sign a ODF
package, at least in one incarnation. That's the reason I was thinking
about Storage: well I didn't explain my thoughts, sorry :-).
So why not focusing on this may be smaller task?
Because the building blocks provided by the existing singature component
may not be sufficient. Also the maintainance effort lays with OOo.
Currently only very few resources are dedicated to the signature
project. In other words, there are simply not enough voulunteers who
drive the project.
Certified solutions may require a code review as well. In this case, a
small change in the OOo signature code, could cause the loss of the
certification. For example, a company builds a signature solution based
on OOo 3.0 and have it certified by the respective authorities. This
effort could be nullified when OOo 3.1 comes out due to changes to OOo's
signature code.
Signatures and security is also a very sensitive area. So I would rather
"outsource" all the critical stuff to companies which are specialized in
that area.
Another aspect is that if other componanies build on OOo's solution then
they will certainly submit issues, enhancements etc., which will be
normal because of different requirements in the countries. Given the
current commitment of the community for the signature project, I do not
see how this could be managed.
Therefore I'd rather invest initially a lot of time for this framework
knowing that the follow-up effort will be little.
I'll try to elaborate my idea in the next days, commenting directly on
your proposal wiki 'Discussion' page.
BeppeC.
--
Kind Regards,
Giuseppe Castagno
[email protected]
[email protected]
Acca Esse http://www.acca-esse.eu
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
