At 2:54 AM -0400 4/25/05, Bob Wyman wrote:
One other *significant* limitation in Atom's support for signatures is that there is no way for an intermediary to add to or otherwise modify an Atom entry without breaking the signature.
That's a purposeful design property of digital signatures. The exact same issue has long affected secure mail forwarders using S/MIME or OpenPGP.
What this means is that intermediaries like PubSub, if they modify an entry by adding content, repairing broken syntax, or normalizing character sets will be forced to remove the original signature and insert a new signature issued by the intermediary.
Right. The intermediary can, however, add a signed extension that says "this message was earlier signed by Xyzzy, and we verified that signature before we changed things." If the recipient trusts your signature, they also must trust your attestation that you verified the earlier signature.
There are numerous other issues relating to signed Atom documents that we've decided (somewhat unwisely...) to punt until after the core document is released. The existing signature support is vitally important to have in the core, however, I feel it really *must* be expanded upon extensively in future extensions.
Given that this is IETF Last Call, such issues are appropriate, and may delay us from getting a standard if the Security ADs bring them up. Can you list them? If they are Atom-specific, we can consider them; if they are generic to XMLDigSig, we probably have to punt (but will want to report them in the Security Considerations section of the draft).
--Paul Hoffman, Director --Internet Mail Consortium
