Tim Bray wrote: > [snip] > This turns out to be pretty hard. It is the server's responsibility: > - to ensure that each entry has a globally unique atom:id element > - to ensure that each entry has an accurate atom:updated timestamp > > So to preserve dig-sig, the client would be required to generate a > globally-unique ID and be real careful about time-stamping, and the > server would have to trust it. Practically speaking, I think you'd need > an out-of-band signal saying that the client is trying to achieve this > effect.
Unless the server is storing the exact XML sent to it by the client preserving the integrity of any included digital signatures becomes damn near impossible. For instance, I have several implementations that accept an entry from a client, shred the content out into a relational database, and reconstructs the entry when requested. While the entry that is returned to the client will generally have the same content, title, etc, there will be enough changes that any digital signature included in the original post would be worthless -- elements will be presented in a different order; the atom:id, atom:updated: atom:author information will be different; extension elements may have been added or removed; attributes may be added or removed or shifted around; the server may apply content filters to the text; etc. In effect, a digital signature in an entry being sent from the client to the server is only guaranteed to cover that specific representation -- that is, only the representation is signed, and not the resource. > [snip] > My perception is that of all the APP server implementations I've seen > (and as the author of a testing tool, I've seen lots) exactly none would > have any chance of preserving dig-sigs. Unless there is an explicit promise by the server that dsig's will be preserved there is no reasonable assumption a client can make other than they will not be preserved. > [snip] > I haven't thought this through fully, but it may be the case that APP is > inherently unsuited for publishing activities where client signature > preservation is a requirement. Hmm, now I'm thinking about special > arrangements for preserving signatures on "payload" elements: > title/category/summary/content. > I think it depends entirely on the scenario. It is easy to imagine a case where a dsig in the entry is used by the server to verify the integrity of the PUT/POST operation rather than as some piece of metadata to be preserved. >> 2) Should I strip a digital signature if I'm going to invalidate it? > > I would think so. > Absolutely. >> 3) Should I provide a mechanism for a client to indicate that it would >> prefer a post fail than that digital signatures be broken? (This >> especially seems potentially useful for encryption)? > > I don't think we understand the problem well enough yet to specify a > solution. This is a general problem that applies for more than just dsigs. Should we provide a mechanism for a client to indicate that it would prefer a post fail if a particular extension cannot be supported? Or if a particular content type cannot be supported? We have the APP features draft as a way of allowing the server to signal it's capabilities. Would it not be enough for the server to state whether or not dsigs will be preserved? The client could look at that and make a determination about what to do. > >> 4) It's probably desirable to recommend that servers not break digital >> signatures unless they are modifying content. > > The trouble is that at the moment, *every* server implementation > modifies content. -Tim > This would be an absolutely terrible recommendation. In APP, the server is control. It can change whatever it wants any time it wants. The client needs to be aware of that make and make decisions accordingly. What we need is a way of allowing the server to tell the client what it will do, which is why the features draft exists. - James
