[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Digital Signature proposal
Bob,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.
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.
I agree to this.
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
DSS is a set of a core specification and a set of profiles. Maybe this is a structure we can or should adopt.
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?
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.
Best regards
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.
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]