Eric Scheid wrote:
On 22/6/05 1:39 AM, "Paul Hoffman" <[EMAIL PROTECTED]> wrote:
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.
I think the problem is with clashing xmlns prefixes. Consider these two
separate feeds containing signed entries:
----------------------------------------------------------------
<feed xml:ns1="http://example.com/"; ...>
[...]
<entry>
[...]
<Signature ... />
<ns1:example-element>foo!</ns1:example-element>
</entry>
</feed>
<feed xml:ns1="http://foo.com/"; ...>
[...]
<entry>
[...]
<Signature ... />
<ns1:foo-element>foo!</ns1:foo-element>
</entry>
</feed>
----------------------------------------------------------------
The problem is the xmlns prefix "ns1" is used for two different namespaces.
Question: is the <entry> element itself included in the signature?
Yes
If not, then we can declare the xmlns:ns1 on the <entry> element ... but
we'd also need to disallow any extension or foreign attributes on the
<entry> (and <feed>) elements.
I am becoming increasingly convinced that a c14n algorithm is the *only*
way to accomplish the goal here. The algorithm would recast the entry
being signed as a standalone entity with all appropriate namespace
declarations, etc. Validation of a signed entry would require first
that the entry is extracted from the feed in accordance with the
canonicalization. This will make it possible for us to evaluate the
entry without the messy interference that the containing feed element
introduces. The only trick now is in coming up with the right algorithm.
e.
