Bob Wyman wrote:
I can't remember if this has been discussed before. I'm tempted to write a
Pace which would specify that any atom:entry can be signed - whether it is
found in an Atom Feed Document or an Atom Entry Document. Before doing so, I
would appreciate if someone could explain if the constraint in the current
specification is intentional. Why would a signature not be permitted on an
atom:entry found in an Atom Feed Document?
I don't know if the constraint was intentional. At the time, I just wrote down what Mark P. and Paul told me to (PaceDigitalSignatures), but I wrote a little command line program with Apache XMLSec today, and it wasn't very difficult (I'll publish the source soon).
I looked around a bit today, so the following are the findings of a non-expert. MustIgnore should let you put a DSig element anywhere you want, but I don't think we can reasonably require an XPath Filter. Xpath is not a MUST[0], and not all implementations allow it[1]. Also, the DSig people have come up with a new XPath filter that allows greatly increased performance[2], and very few implementations support that[3]. That leaves us with the possibility of specifying how to sign an entry that allows unsigned mangling, but not requiring it. I think there's also the question of whether a feed signature includes the DSig elements that appear within it.
We can probably strike the following:
"Other elements in an Atom document MUST NOT be signed unless their definitions explicitly specify such a capability."
if we gain mustIgnore text (I think this should be uncontroversial).
Robert Sayre
[0] http://www.w3.org/TR/xmldsig-core/#sec-TransformAlg [1] http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html [2] http://www.w3.org/TR/xmldsig-filter2/ [3] http://www.w3.org/Signature/2002/05/xmldsig-filter2-interop.html
