At 11:58 AM -0700 6/30/05, James M Snell wrote:
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
There is no reason to do that with Canonical XML.
b. Ignorance on my part as to what all the interoperability issues
are. Can you elaborate or point me to some relevant discussions?
The description of how to pull things down from the outside info is
well-defined for Canonical XML, and Canonical XML is required for
XMLDigSig, so folks have worked harder on it than Inclusive.
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.
We have no intention of doing HMACs, so I believe that this falls
out. I have added words about that in a different message I just sent.
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.
Consistency will probably lead to more interoperability, particularly
in an area as tricky as canonicalization.
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?
You have to define exactly what is covered by the signature. No
SHOULDs, no MAYs. So you either have to define exactly how to bring
in referenced data (and do you follow links in that data, and links
in links...?), or you say "it's just the bits you see here". As
another example, how would you sign an entry that points to a page
that is known to change all the time because it shows the current
date? Or a hit counter?
There is no "security risk" if you state exactly what is signed. You
should point out that the referenced material can change and is not
covered by the signature.
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.
No, it isn't. The reference is 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"
That works for me. You might also consider adding "and they are
allowed to add their own signatures in the place of stripped
signatures".
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".
Not unless you can define "trust the content". All you can trust is
that it is part of the assertion made by the semantic content of the
signed message. That might be "I saw this program", it might be "I
wrote this program", it might be "this program erased my hard drive",
and so on. I think you were suggesting that signatures over active
content could be automatically parsed to mean something; that's not
OK without a lot of additional words and a different type of
signature.
Suggestion (and only a suggestion): don't go there.
--Paul Hoffman, Director
--Internet Mail Consortium
