Paul Hoffman wrote:
At 2:15 PM -0700 6/20/05, James M Snell wrote:
The spec already allows enveloped XML signatures for the document.
Question: should we only allow signing of the entire document or are
there valid use cases for allowing each individual entry in the feed
to be individually signed?
There are many valid use cases for both: that's why the spec
explicitly allows both.
From the spec (Section 5)
The root of an Atom document (i.e., atom:feed in an Atom Feed
Document, atom:entry in an Atom Entry Document) MAY have an Enveloped
Signature, as described by XML-Signature and Syntax Processing
[W3C.REC-xmldsig-core-20020212].
...
Other elements in an Atom Document MUST NOT be signed unless their
definitions explicitly specify such a capability.
Given this language, the the spec only explicitly allows digital signing
of the Atom Feed and Entry Documents. It does not explicitly allow for
digitally signing individual entries within a Feed document. In fact,
it explicitly forbids it given that the definition of <entry /> does not
"explicitly specify" the capacity to be signed.
<?xml ...?>
<feed>
<entry />
<Signature /> <!-- is valid atom 1.0 -->
</feed>
<?xml ...?>
<entry>
<Signature /> <!-- is valid atom 1.0 -->
</entry>
<?xml ...?>
<feed>
<entry>
<Signature /> <!-- does *not* appear to be valid atom 1.0
given my interpretation of Section 5 -->
</entry>
</feed>
Is this a bug in the spec or am I reading the spec incorrectly? If the
former, then we need to get it resolved, because as it appears to read
(to me anyway) we are not allowed to put Signatures within a Feeds entry
elements. If the latter, I'll thwack my head on the desk to see if that
helps me to start making better sense of what I'm reading. :-)
I'm quite happy with limiting it to the first as I don't really see
much of a reason to support the second and third examples, but wanted
to see if anyone had any opinions or use cases that could justify the
ability to independently sign individual entries within a feed.
The spec uses MAY for the conformance criteria, so no one has to
support either.
At 9:17 PM -0700 6/20/05, James M Snell wrote:
In other words, if the entry in the first example above were to be
included in an aggregate feed containing entries from multiple
authors, the <author /> element from its containing feed would need
to be added to the entry element's collection of metadata...
(<entry>...</entry> becomes <entry> .. .<author /> ... </entry>)
thereby invalidating any signature calculated over the entry.
Fully disagree. No one is *forced* to add the collection of metadata
to the entry. You give a very good reason why someone would not want to.
The only way someone would not be forced to add author or
source-w/author to the entry would be if digitally signed entry elements
contained within a feed were required to be complete entries capable of
standing alone as entry documents and were required to contain source
elements as Bob has asserted. If the author and/or source elements are
missing from the entry, it would not work in an aggregated feed scenario
without adding in those pieces of metadata. The only solution for this
(as has been noted in other notes in this thread) is a canonicalization
scheme for signed entry elements.
One would also have to contend with the potential problems
introduced by namespace declarations with the feed. The bottom line
of this is that an entry with a signature could not simply be copied
over to a new containing feed element with the signature in tact
making the aggregator scenario unworkable.
Again, fully disagree. It is quite reasonable to pass along signed
entries without changing them.
Only if such entries are canonicalized in order to remove any problems
introduced by namespace declarations.
The entry in the example below...
<feed xmlns:xhtml="http://www.w3.org/1999/xhtml"; xmlns="...">
<entry>
<id>...</id>
<content type="xhtml">
<xhtml:div>...</xhtml:div>
</content>
<Signature xmlns="..."/>
</entry>
</feed>
Could not simply be reliably passed along unmodified to an aggregate
feed that could quite possibly use a different set of namespace
declarations. e.g.
<!-- aggregate feed with previous entry copied unmodified and
obviously wrong -->
<a:feed xmlns:a="..." xmlns="http://www.w3.org/1999/xhtml";>
<entry>
<id>...</id>
<content type="xhtml">
<xhtml:div>...</xhtml:div>
</content>
<Signature xmlns="..."/>
</entry>
</a:feed>
Am I missing something fundamental here?
So... given all this... I think I'm gong to make an assertion and
open that assertion up for debate: The need for an end-to-end trust
model for Atom capable of traversing any number of intermediaries is
largely a myth.
How can we debate that before businesses have had a chance to create
their models?
What is really needed is a simple mechanism for protecting feeds
against spoofed sources (e.g. man-in-the-middle serving up a bogus
feed) and for indicating that content is trustworthy* on the document
level (as opposed to individual feed entry level).
* by which I mean, for example, binary enclosures are trustworthy,
the feed itself does not contain any malicious content, etc
This is a very different model than what we chose for Atom. It is
possibly an interesting idea, but it isn't Atom.
?? I don't understand. What part of my post "isn't Atom"? My comment
deals with potential security issues that are specifically discussed in
the Security Considerations (Section 8) portion of the Atom spec.
Specifically:
8.1 "... Many elements in these languages are considered 'unsafe' in
that they open clients to one or
more types of attack. Implementers of software which processes Atom
should carefully consider
their handling of every type of element when processing incoming
(X)HTML in Atom documents.
See the security sections of [RFC2854] and [HTML] for guidance."
8.4 "...Atom Processors should be aware of the potential for spoofing
attacks where the attacker
publishes an atom:entry with the atom:id value of an entry from
another feed, perhaps with a falsified
atom:source element duplicating the atom:id of the other feed."
--Paul Hoffman, Director
--Internet Mail Consortium
