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 <> 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
