Dan Sandler wrote:
> This essentially means that intermediate entities which parse and
> re-emit Atom feed data (such as aggregators or caches) must remember
> "semantically meaningless" details, such as the order of elements, in
> order to re-construct the Atom feed XML in a way that preserves
> signature validity.
One other *significant* limitation in Atom's support for signatures
is that there is no way for an intermediary to add to or otherwise modify an
Atom entry without breaking the signature. What this means is that
intermediaries like PubSub, if they modify an entry by adding content,
repairing broken syntax, or normalizing character sets will be forced to
remove the original signature and insert a new signature issued by the
intermediary. Similar issues will arise in any case where someone copies a
signed Atom entry from one feed to another. Unless the copying is done in
such a way that it doesn't disturb the canonicalized form of the entry, the
original signature will be invalidated.
There are numerous other issues relating to signed Atom documents
that we've decided (somewhat unwisely...) to punt until after the core
document is released. The existing signature support is vitally important to
have in the core, however, I feel it really *must* be expanded upon
extensively in future extensions.
bob wyman
