wrote:
> Duane Nickull <> wrote on 07/30/2008 01:49:45 PM:
>
>> It sounds like this TC has not documented dSig requirements from users.
> As
>> a big fan of ODF, I would like to suggest we consider collecting some as
> I
>> would hate to see implementations of ODF get pushed aside based on not
>> meeting the basic requirements for dSig. I can help reach out to the
>> Canadian Government, maybe UK, Austria, Germany and US too.
>>
>> Thoughts?
>>
>
> Document security, both on the encryption and digital signature side is a
> critical issue to get right. I know that I'm not an expert in the area,
> but my gut feeling is that we need to bring in some expertise. This is
> similar to what we did when we brought it accessibility experts to
> evaluate our gaps and options with ODF 1.0.
To bring in the expertise from security experts seems to be reasonable.
My feeling is that the whole topic of digital signatures is not specific
to ODF. It effects other formats, too. ODF uses W3C XML DSig
specification. This specification has a lot of extension mechanism and
we are not restricting these. XAdes is one specification that extends
XML DSig, and it is my understanding that a XAdes signature is a valid
XML DSig signature. This means that a file format that allows to store a
XML DSig signature (like ODF) automatically also allows to store a XAdes
signature. There may be other specifications or maybe just algorithms
that extend XML DSig or that can be used with XML DSig that ensure that
local requirements can be met.
I therefore expect that it is for XML based formats either considered to
be sufficient to store an XML DSig signature (with possible extensions
like XAdes), or that there is some common practice what other
specifications have to be supported that we can adopt. By support I here
don't mean that applications must support these, but only that the file
format is capable of storing all information that are required to use a
certain kind of signature.
>
> The concerns I have are:
>
> 1) XAdES appears to satisfy the requirements of Brazil and possible
> Europe. But what about the US (FIPS)? What about Japan? What about
> China? Most of the ODF vendors today are selling their products
> internationally. The open source implementations are certainly
> distributing internationally. So I think we need a more comprehensive
> view of what the digital signature requirements are globally. Although
> XAdES may be part of this, I think it may be worth getting the
> requirements up front and to work this out comprehensively. Maybe it
> means we need W3C XML DigSig and 3 other standards, including XAdES. I
> don't know. But I don't want to wait for ODF 2.0 for this. I want us to
> get this done for ODF 1.2.
I agree. When talking about requirements I think it is important that we
differ between the file format itself and applications. ODF should be
able to store signatures that meet the Brazilian requirements, but as
well should be able to store signatures that meet the requirements of
let's say the US or China. But an application that is used let's say in
Brazil has not to be capable of creating a signature that meets the
Japanese requirements, nor does it has to be capable of verifying the
signature of a document that has been signed in Japan.
In particular, from the few experience I have with the topic, I assume
that there is not a signature that meets all local requirements that do
exist in the world. We therefore need a lot of flexibility within the
file format. The question is whether the flexibility that XML DSig
provides is sufficient.
>
> 2) Are we doing the right thing for encryption? I read one blog post by a
> security expert suggesting that what we have specified today may not be
> adequate:
> http://blogs.msdn.com/david_leblanc/archive/2008/07/03/office-crypto-follies.aspx
Encryption is a different topic. We may want to know the opinion of
experts here, too, but we should not mix this with the digital signature
topic.
>
> 3) Are we doing what we need now, to be flexible for what we may add
> tomorrow? For example, we may not allow field level encryption today, or
> slide-level signatures today, or multiple author signatures on overlapping
> parts of a document, but let's make sure that we don't specify these
> things in a way which would preclude us from adding more advanced features
For signatures, we actually support all this already. An ODF document
may for instance contain a signature that signs only fields. But we do
not specify a feature called "field level signature" where we explicitly
state what parts of a document have to be signed.
> later. I'd like to be able to wave my arms and describe how these
> features could be done, by extending what we have specified, without
> looking too foolish.
>
> Again, this is not my area of expertise, but I can certainly tap into
> security expertise within IBM. I wonder whether it would be worth putting
> together a few experts from TC members and member companies to review what
> we have today, and Jomar's/Bob's proposal, and suggest additional
> requirements that should be met for ODF 1.2, and serve as a reviewer of
> the security areas of the eventual draft text. This could be done as a
> "security subcommittee" like we did with accessibility. Or we could do it
> with a few conference calls, outside of the normal TC call schedule.
My suggestion is that we first try to get the opinion of some experts,
and that we then decide whether we need additional calls or even a SC.
Best regards
Michael
>
> In the end we need these features in ODF to be world class, because that
> is our audience.
>
> -Rob
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
--
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH Nagelsweg 55
D-20097 Hamburg, Germany
http://sun.com/staroffice +49 40 23646 500
http://blogs.sun.com/GullFOSS
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering
