Bob Jolliffe <> wrote on 03/02/2010 06:22:37 PM:
> >
> > "Note: Applications may use extensions to the [xmldsig-core]
> > specification, such as those required
> > for implementation of XAdES signatures specified in ETSI TS 101 903
v1.3.2
> > [XAdES]."
> >
> > And [XAdES] is a non-normative reference.
> >
> > Do we really want to say "Applications _should_ use extensions to the
> > [xmldsig-core] specification..." ? That sounds odd to me. Surely the
> > user, not the implementation should decide.
> >
> > Maybe we want something like (in conformance terms) "A Conforming
> > OpenDocument Package Consumer should support XAdES signatures
specified
> > in ETSI TS 101 903 v1.3.2 [XAdES]" ? (Could do the same on producer
> > conformance.)
>
> As one of the drafters of this original wording regarding XAdES
> (together with Jomar Silva) I am happy to enough to see this
> rewording. We both at the time would have liked some stronger wording
> but felt this was the least controversial to get in. The govt of
> Brazil really requires XAdES and it was important to specify that this
> is indeed supported. Not that it was ever precluded. To say that
> consumers (and possibly producers) *should* support XAdES is maybe
> better but let us also be careful not to lose the sense that producers
> *may* also use other extensions so long as they remain within the
> bounds of what is permitted by XMLDsig.
>
Backing up a little. Part 3 defines conformance for three things:
1) packages (the static files)
2) consumers (applications that read packages)
3) producers (applications that write packages)
These are all in the conformance clause, section 7.2.
http://docs.oasis-open.org/office/v1.2/part3/cd01/OpenDocument-v1.2-part3-cd01.pdf
Take a look at (PD1.4) in the that section for the dsig requirements for
conformant packages:
(PD1.4) It may contain files whose relative paths begin with “META-INF/”
and whose names contain the term “signatures”. These file shall meet the
requirements:
(PD1.4.1) The files shall be well-formed XML files in accordance with
[XML1.0].
(PD1.4.2) The XML root element of each file shall be a
<dsig:document-signatures> element 4.2.
(PD1.4.3) The XML root element of the file shall be valid with respect to
the digital signature schema defined in appendix A.2 OpenDocument Digital
Signature Schema.
So the first question is this: If you have a XAdES digital signature,
does it violate the above, or any other requirement of a conforming
package? If not, then we're fine.
On the producer side, all that is really required is that the application
be able to produce a conforming package. So we're fine if the above
package conformance language is fine.
On the consumer side, we have this:
"(PC1.1) It shall be able to parse and interpret OpenDocument packages and
OpenDocument extended packages, but it need not interpret the semantics of
all elements, attributes and attribute values."
So I think this all boils down to this, I think:
A) Do we want to mandate that consumers understand XAdES ? I don't think
so. Remember, as currently writtem a conforming consumer is not required
to understand dsigs at all.
B) Do we want to require that consumers tolerate, i.e., degrade gracefully
in the presence of XAdES extensions if they don't understand them? I
think that is reasonable and covered by "need not interpret the semantics
of all elements, attributes and attribute values".
C) Do we want to ensure that XAdES are allowed in conforming packages? or
only in extended packages? I think the "extended" conformance class was
meant for document types that went beyond the defines MIME content types
for spreadsheets, text, presentations, etc. There was the intent that the
core package conformance class would allow some extensions.
I'm open to suggestions here. One thing that might work is:
1) Add a MAY statement to package conformance stating explicitly that
extensions such as XAdES are permitted in conforming packages.
2) Change PC1.1 to put some meat around how to degrade gracefully. For
example, what should a consumer do if they encounter extensions that they
do not understand? I assume it is better to ignore them than to give an
error and halt. We might want to echo the similar language we have in
Part 1 on foreign elements and attributes.
But I know nothing about XAdES, so someone should check to see if this is
reasonable.
-Rob
