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