I think Sam's perception that the WG didn't do much work on this is
correct. Probably for reasons having to do with server/client
asymmetry, see below.
On Jun 17, 2007, at 12:20 PM, Sam Hartman wrote:
Here are some examples of questions I think should be answered:
1) I'm implementing a server; I don't want to break digital
signatures. What should I be careful of? As an example, what
changes that do not change the meaning of the XML can I make; what
must I avoid? If this can be answered by a reference to a
specific section of another document that would be great.
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.
More generally, in APP, the relationship between client and server is
really unequal. Basically, a client hands some data to the server
and requests a best effort to store it in a useful and minimally-
surprising way. This is based on observation of real-world web
publishing systems; server implementors are typically flatly
unwilling to promise too much. 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.
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.
2) Should I strip a digital signature if I'm going to invalidate it?
I would think so.
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.
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
