OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] DSIG proposal - FYI

Hi Dennis

2009/1/5 Dennis E. Hamilton <dennis.hamilton@acm.org>:
> Bob, I want to support this proposal.
Good.  Pleased to hear it.

>I have some questions and
> suggestions:
> 1. Definitive References
>   1.1 Please provide a definitive reference to ETSI TS 101 903 v1.3.2 that
> someone could use to obtain the specification.

How about:
"XML Advanced Electronic Signatures (XAdES)" (ETSI TS 101 903 v1.3.2)
, ETSI, 650 Route des Lucioles
F-06921 Sophia Antipolis Cedex,FRANCE.  Downloadable from:

>   1.2 I suggest that that [xml-dsig] reference a specific version of the
> XML DSIG specification. Unless there is a conflict with ETSI TS 101 903, or
> with canonicalization of ODF XML items, I suggest "Donald Eastlake, Joseph
> Reagle, David Solo, Frederick Hirsch, Thomas Roessler (eds.).  XML Signature
> Syntax and Processing (Second Edition).  W3C Recommendation 10 June 2008.
> Available at <http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>.  (This
> will also work for citation of the SHA-1 Message Digest procedure.)

yes this looks correct.  Out of curiosity, why do you raise the
particular concern about canonicalisation?  I ask because there was a
canonicalisation problem with earlier sun java implementations -
something about the level of nesting of elements in ODF being too
deep.  It has been solved with the latest sun jdk release.

> 2. References to Signed Material
>   2.1 In this specification, detached signatures are found in XML documents
> of the packages META-INF folder.  In the simplified proposal, there is no
> specified name, but one can expect that they are of MIME type
> application/XML and the root element is <ds:Signature
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#";> (or logical equivalent).

Root element is actually:
<document-signatures xmlns="http://openoffice.org/2004/documentsignatures";>

which in turn contains ds:Signature children.  See section 2.4 of part
3 (packaging).  What is not specified is the mimetype of the
signatures file.  I suppose that should be done.

> That seems to be an immediate consequence of not specifying anything
> further.  Is that understanding correct?  One might assert that much in the
> ODF 1.2 specification.

>  2.2 In the <ds:Signature> element, there will be one or more
> <ds:Reference> elements.  Those elements will need to refer to Zip items
> within the ODF package for there to be signing of those items or elements
> within them (in the case that the item is an XML document).
>  2.3 It is probably important to point out that the use of relative paths
> in the <ds:Reference> element URI is subject to the interpretation for ODF
> 1.2 relative paths and that the reference is understood to be [in]to the
> uncompressed form of the Zip package item.

If you go back to the long discussion we had about relative URIs in
ODF you might remember that I was a bit confused because current
implementations of ODF signatures do not actually follow the
convention ie. the base URI in these signature references is in fact
always the root of the package rather than relative to the file which
contains the reference.  This is historical and not much we can do
about it.  I don't want to mandate a behaviour which makes the only
existing implementations non-conformant.  What I would rather see is a
new interoperable signature format which uses XAdES basic signature
and "proper" relative URI's, at which point we can start to deprecate
the existing signatures.  So for the moment I'm silent on this one.

>  2.4 Although one <ds:Reference> can have no URI and have
> application-determined significance, there is no such agreement for ODF.  If
> you want to reserve that for an ODF-specific usage, we need to say so.
> [xml-dsig]

I haven't seen a use case for this yet.

>  2.5 There needs to be some profile information about whether or not data
> objects being signed are limited to octet streams or whether they may be
> (XPATH) node sets. [xml-dsig].  I suggest the octet stream case.  If
> individual XML-item elements are permitted to be referenced, I suggest that
> be by fragment identifier and xml:id be used for identification of the
> fragment.  If you want to somehow skirt this consideration, I think there
> needs to be some limiting statement (octet streams only, say) so that richer
> cases remain available in future extensions.  The octet-stream-only case
> seems to be the only simple rule that reserves dealing with fragment
> identifiers and/or XPATH (that is, XPOINTER fragment ID) expressions to
> future extensions.

The recommended way to deal with such fragments is not in the URI, but
rather by the application of a transform (of type XPATH for example)
to the octet stream.  Since we have no known applications dealing with
fragments as yet, I would be reluctant to restrict the scenarios to
xml:id only.  I'd quite like to be able to select by attribute
table-protected for example.  I don't think there is any compelling
need to add to what the XML DSIG standard says at this point.

>  2.6 It doesn't have to be mentioned, but it is of course possible to have
> <ds:Signature> elements that sign other <ds:Signature> elements and such
> counter-signing activity is not unusual.

You are right.  It is interesting that what the standard currently does say is:
"If the <dsig:document-signatures> element contains multiple
<Signature> elements, then there should be a relation between the
digital signatures they define, for instance, they may all apply to
the same set of files."
Counter-signing would also constitute a relationship in this sense.
Again the use of metadata might provide a rich way of describing such
relationships but its not something to push for 1.2.


>  - Dennis
> -----Original Message-----
> From: Bob Jolliffe [mailto:bobjolliffe@gmail.com]
> http://lists.oasis-open.org/archives/office/200812/msg00103.html
> Sent: Friday, December 12, 2008 01:09
> To: office TC
> Subject: [office] DSIG proposal - FYI
> Greetings
> For those who are busy examining proposals I'd like to point out that, in
> the interest of progress on 1.2, I have drastically simplified the digital
> signature proposal made earlier this year by Jomar and myself.
> http://wiki.oasis-open.org/office/DSigProposal
> As it currently stands, there are no longer any schema changes being
> proposed - just a short (two sentence) addition to the text indicating that:
> "These digital signatures shall conform to the W3C XML Digital Signature
> specification (http://www.w3.org/TR/xmldsig-core/). Applications may use
> extensions to the XML DSIG core specification, such as those required for
> implementation of XAdES signatures specified in ETSI TS 101 903 v1.3.2."
> Regards
> Bob

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]