Paul Hoffman wrote:
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?
You know, if you had asked me this when I wrote this requirement down in
my notes three days ago I would have been able to give you the answer.
The fact that I'm staring at my screen trying to recall what that answer
is indicates that it's not a very good one ;-) ... You're right, there
really is no need to separate the keyinfo from the signature in this
situation.
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?
Two reasons:
a. No need to re-envelope things at the document level
b. Ignorance on my part as to what all the interoperability issues are.
Can you elaborate or point me to some relevant discussions?
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.
This is mostly tied to #2 above and comes from a lesson learned from
WS-Security. Specifically section 13.2.4 of
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
"Implementers should be aware of the possibility of a token
substitution attack. In any
situation where a digital signature is verified by reference to a
token provided in the
message, which specifies the key, it may be possible for an
unscrupulous producer
to later claim that a different token, containing the same key, but
different information
was intended."
If we don't verify-by-reference to a key contained elsewhere in the feed
(or other location), this no longer becomes an issue.
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?
These entries are subject to re-enveloping in a way that document level
elements are not. It is possible to use ex-c14n throughout so that the
behavior is consistent. The KeyInfo statement relates to #2 and thus
becomes irrelevant.
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.
I tend to consider enclosures to be part of the document, even if they
are included by reference. As a potential consumer of an enclosure I
want to know whether or not the referenced enclosure can be trusted. Is
it accepted to change the SHOULD to a MAY with a caveat outlining the
security risk?
7. If an entry contains a content element that uses @src, the digital
signature MUST cover the referenced resource.
Fully disagree.
Same as above. Even though it is included-by-reference, the referenced
content is still a part of the message.
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.
Ok, my fault. I wasn't clear. Reword to "Aggregators and Intermediaries
MUST NOT alter/augment the content of digitally signed entry elements
unless they strip the Signature from the entry"
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?
Not so much a normative assertion. More of a "if you know who produced
this feed/entry and you decide that you can trust their signature, you
can make finer grained decisions about whether or not to trust the
content".
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.
Absolutely. I am by far not an expert in digital signatures and very
much appreciate the feedback. comments like these are precisely why I
kicked off this thread in the first place. I would especially like to
hear more thoughts on the inc-c14n vs. ex-c14n issue.
--Paul Hoffman, Director
--Internet Mail Consortium
- James
