Ok, I've been going back through all of the discussion on this thread
and use scenarios, etc and should have an I-D ready for this by this
weekend. Here's the summary (in no particular order)
1. After going through a bunch of potential XML encryption use cases, it
really doesn't seem to make any sense at all to use XML Encryption below
the document element level. The I-D will not cover anything about
encryption of Atom documents as there are really no special
considerations that are specific to Atom.
2. The I-D will allow a KeyInfo element to included as a child of the
atom:feed, atom:entry and atom:source elements. These will be used to
identify the signing key. (e.g. the KeyInfo in the Signature can
reference another KeyInfo contained elsewhere in the Feed).
3. When signing complete Atom documents (atom:feed and top level
atom:entry), Inclusive Canonicalization with no pre-c14n normalization
is required.
4. The signature should cover the signing key. (e.g. if a x509 cert
stored externally from the feed is used, the Signature should reference
and cover that x509 cert). Failing to do so opens up a security risk.
5. When signing individual atom:entry elements within a feed, Exclusive
Canonicalization MUST be used. If a separate KeyInfo is used to
identify the signing key, it MUST be contained as either a child of the
entry or source elements. A source element SHOULD be included in the
entry.
6. If an entry contains any "enclosure" links, the digital signature
SHOULD cover the referenced resources. Enclosure links that are not
covered are considered untrusted and pose a potential security risk
7. If an entry contains a content element that uses @src, the digital
signature MUST cover the referenced resource.
8. Aggregators and Intermediaries MUST NOT alter/augment the content of
digitally signed entry elements.
9. In addition to serving as a message authenticator, the Signature may
be used by implementations to assert that potentially untrustworthy
content within a feed can be trusted (e.g. binary enclosures, scripts, etc)
10. The I-D will not introduce any new elements or attributes
11. Certain types of [X]HTML content will be forbidden in unsigned
feeds. e.g. <frameset>, <frame>, <script>, <link>, <style>, <object>,
<embed>, <meta>, etc. Even in feeds signed with trusted keys,
aggregators should handle these with care. (ref:
http://diveintomark.org/archives/2003/06/12/how_to_consume_rss_safely).
Like I said, I'll be trying to have the draft put together by this
weekend.
- James
