[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Two JIRA Issues for discussion
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]