Re: [office] Digital Signature proposal

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

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

> 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