[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Two JIRA Issues for discussion
OK. If anyone wants a change to the current text, please enter a JIRA issue with the specifics. We can track the details better that way. Thanks! -Rob Hanssens Bart <Bart.Hanssens@fedict.be> wrote on 03/05/2010 01:46:55 AM: > > my main point is that: currently XAdES support is a "may" in a "note". > > Now, I only know one ODF-office suite code base that actually implements > XML-DSIG, but IIRC even this implementation uses its own ds:Object to > indicate the signing time. So there already is a need for something more > than just plain XML-DSIG... > > XML-DSIG is just fine for signing macro's etc, but when signing documents, > it's going to be hard _not_ to use XAdES if one is serious about it. > > > > 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. > > I'd suggest a "should understand XAdES" if they understand XML-DSIG. > > Note that XAdES has various "forms" (or "levels"): ranging from a simple > XAdES-BES to everything but the kitchen sink XAdES-A for archiving. I'll > leave it up to the implementation to decide what level they'd like to support. > > > > 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". > > Degrading shouldn't be a problem, just ignore ds:Object and its children. > > > > 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. > > IMHO, they should be allowed 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. > > Yes, we need that for foreign element, attributes (and actually alsofor other > ODF features, but that's another story) > > > > Best regards > > Bart
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]