Re: [office] Digital Signature proposal

Hello Michael

2008/8/8 Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@sun.com>

Jomar,

Jomar Silva wrote:

I just would like to remember that an application that support XAdES will also support XMLDsig (XAdES is an extension of it).

I also believe that an application that support only XMLDsig, will be (or may be) able to validate just the XMLDsig portion of the XAdES signature.

Both is my understanding as well.

When looking at your proposal: Is the <dsig:signature-type> element really required, or could an application guess that a signature is a XAdes signature by analyzing the content of the signature's <object> element?

I don't believe the <dsig:signature-type> element is absolutely required. An application should be able to infer the signature from the contents of the <object> element.

The idea is to provide some sort of hint to the application, but one could debate as to whether this is necessary or desirable.

Looking at the OASIS Digital Signature Services (DSS) profile for Advanced Digirtal Signatures (http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-AdES-spec-v1.0-os.html) it is interesting to note that they have an optional <SignatureType> element which is used for a different purpose:

"3.3.1.1.2.1 Optional Input <SignatureType>

This element is OPTIONAL. If present, <SignatureType> SHALL be either:

urn:ietf:rfc:3275

for requesting XML-based signatures, or

urn:ietf:rfc:3369

for requesting CMS-based signatures ..."

The same DSS spec does make use an element called <SignatureForm> to differentiate between different forms of XAdES signature in a signing request. Section 7.1 of the document lists unique urn identifiers for the different forms of AdES signatures. If we were to include such an element in ODF it might make sense for consistency

(1) to use the name signature-form rather than signature-type

(2) to use the same identifiers as listed in the DSS spec

If the <dsig:signature-type> element is not required, is it them required to list XAdes in the specification? Or can we simply say ODF supports XML DSig. XAdes signatures are an extension of XML DSig. ODF therefore automatically supports XAdes signatures.

Would it still be necessary to list the XAdES namespace declaration in order to validate XAdES signatures? Otherwise we could only validate that it is a valid XML DSIG signature.

Similarly we can already say that ODF supports the use of XML DSIG to sign fragments of an XML stream so there technically is nothing to add. What I would like to see, as a requirement for conformance, is that applications don't clobber those signatures if they don't use them. This seems to be the current behaviour of openoffice for example. This is why we suggested naming a particular file, fragment-signatures.xml, though this is not strictly necessary if applications agree not to remove files <xxx>-signatures.xml if they are referred in the manifest.

Regards
Bob

Michael

There are diagrams here (http://www.w3.org/TR/XAdES/) that demonstrate the differences between XMLDsig and XAdES.

Best,

Jomar

Dave Pawson escreveu:

2008/7/31 Ming Fei Jia <jiamingf@cn.ibm.com>:

Thanks explanation although that can not convince me completely. You said
"...if the application developer choose to only support XMLDsig, it will
still being compliant with ODF 1.2...". Is that true? XMLDsig and XAdES are
as different options in the proposal. If the application only implements
XMLDsig, could the application claim to be compliant with ODF standard? I
think at most it can claim partial compliant. This is the conformance issue.

Another is the interoperability issue. Assume one application only
implements XMLDsig, another application only implements XAdES. How does the
first application validate the signed document with XAdES format generated
by the second application? Seems no way,even both the two applications claim
to be compliant with the same ODF standard.

A conformance issue for ODF?
Seems the TC has to choose one or the other if interoperability is
to work for signed documents.

regards

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

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

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

office message