Re: [office] Two JIRA Issues for discussion

[robert_weir@us.ibm.com]

Bob Jolliffe <bobjolliffe@gmail.com> 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