[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Digital Signature proposal
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]