Lisa Dusseault wrote:
>
> 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).
It depends entirely on what you mean by "publish". If you mean have the
server store exactly what the client sent and serve it back up with
perfect fidelity, then you're right. Thing is, that's not what APP was
intended to do.
Because of Atom's must-ignore semantics, all APP servers should be able
to work with digitally signed entries sent by a client on PUT or POST.
What it does with those signatures is completely up the server. Whether
or not those signatures and the content they cover is preserved in a way
that does not invalidate the signature is completely up to the server
implementation. This is not an interoperability problem. It's a client
expectation problem. If the client expects to have the digital
signatures preserved, it better darn well know what the server will do
with 'em before it sends 'em.
>
> 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.
There is no need for such a requirement. RFC4287 already states that
entries and feeds can be digitally signed. It also already states that
unknown extensions MUST be ignored. That's enough. A server can sign
an entry, a client must either know how to deal with the signature or
must know how to ignore it. There's nothing else APP needs to say on
the matter.
>
> 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.
What exactly are you trying to achieve with this?
- James
