I did some thinking about this since it came up in IESG evaluation
and concluded that for the moment, there's no way for the client to
reliably and interoperably publish client-signed entries. We should
start by stating that in atompub (because I am guessing we're going
to standardize a mechanism right now).
If there is a requirement that clients understand signed entries,
then we can interoperably have the *server* sign entries and that may
be slightly useful. Not only is it slightly useful if the server
signs with its own key, it also allows for some non-standard
backchannel between publishing clients and servers, in which clients
sign with their own keys. Although the signing mechanism would be
non-standard in that case, all existing clients would be required to
understand signatures so this optional authoring feature would not
break general publishing interoperability.
One way to do client signing in the future is for clients to start by
POSTing signed entries. If this is how it is likely to work in the
future, then today we probably want to decide what "older" servers
should do in the future -- reject signed entries, accept them
unchanged and still signed (unlikely), strip the signature or
invalidate the signature.
Another way to do client signing in the future is for clients to POST
unsigned entries, allow the server to assign timestamps and atomIDs
and make other changes, and then sign the result. The server could
allow PUT or some other mechanism to overwrite an unsigned entry with
a signed entry provided that the server-controlled content remains
the same (need to think about updated value, of course). If this is
the way we expect things to work in the future, then there's less
interop requirements to think about today.
Lisa
On Jun 17, 2007, at 12:57 PM, Tim Bray wrote:
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
