Re: [office] Digital Signature proposal

Hi Michael

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

Bob,

Bob Jolliffe wrote:

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.

It is my understanding that DSS describes signing and verifying protocols. I haven't had the time to have a closer look at the DSS specification, but maybe the DSS spec has some advice for us here. If a signing service in the case that a XAdes signature is requested would just create a XAdes signature, then the signature type probably is not required. If a signing service would store the information that a XAdes signature was requested, then we may want to do so, too, regardless whether this is necessary. It may also helpful to know whether a verifying service would auto-detect a XAdes signature, and how.

When the DSS service is used to request a signature it clearly needs to specify which format of signature is required. Whether there is merit in storing a signature format indication together with the signature is still open to question - I will follow up and report back.

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

I agree to this.

DSS is a set of a core specification and a set of profiles. Maybe this is a structure we can or should adopt.

Agreed. Though a well designed extensible "framework" for digital signatures in ODF might be a more significant amount of work. I will investigate.

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.

How do you define "use"? Is that the load - modify (per user interaction) - save scenario? Or the situation where another signature is added to a document?

The load-modify-save scenario. If I have a set of signatures in a file called META-INF/mysignatures.xml, for example, this file is removed (by openoffice) when I modify the document in any way. I guess the application makes the assumption that modifying the document necessarily invalidates the signatures. This is not a fair assumption to make as it prevents the signatures on parts of a document surviving load-modify-save sessions which only modify unsigned parts of the document.

Kind regards
Bob

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.

Best regards

Michael

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

office message