At 12:47 PM -0700 6/29/05, James M Snell wrote:
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.
Good.
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).
This is OK from a security standpoint, but why have it? Why not always have the signature contain all the validating information?
3. When signing complete Atom documents (atom:feed and top level atom:entry), Inclusive Canonicalization with no pre-c14n normalization is required.
There seems to be many more interoperability issues with Inclusive Canonicalization than with Exclusive. What is your reasoning here?
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.
Please explain the "security risk". I probably disagree with this requirement, but want to hear your risk analysis.
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.
Why is this different than #3?
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
Fully disagree. We are signing the bits in the document, not the outside. There is "security risk", those items are simply unsigned.
7. If an entry contains a content element that uses @src, the digital signature MUST cover the referenced resource.
Fully disagree.
8. Aggregators and Intermediaries MUST NOT alter/augment the content of digitally signed entry elements.
Also disagree, but for a different reason. Aggregators and intermediaries should be free to diddle bits if they strip the signatures that they have broken.
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)
How will you assert that?
10. The I-D will not introduce any new elements or attributes
Thank you!
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).
Disagree, for the same reasons as above. We are signing the bits only, not some representation of the universe at the time of signing.
Like I said, I'll be trying to have the draft put together by this weekend.
Hopefully, my comments above cause you to put discussion of your reasoning in there. Please don't read my comments as "don't do this", but rather "if you're going to do this, you have to justify it". That will make the document stronger and more likely to be implemented properly.
--Paul Hoffman, Director --Internet Mail Consortium
