Sorry, I wasn't clear. I was asking what the technical objective would be behind your suggestions. When a client POSTs a digitally signed entry to the server, what is the intent? Is the dsig part of the content that the client would like to have preserved? Or is the dsig some form of message level integrity check the server can use to make sure the entry has not been messed with in transit? Or is the dsig something else? So far this discussion seems to be focusing on the idea that the dsig is part of the content. This group has well established that when it comes to the content of an entry, the server is in complete control and can make any change it wants to make, period, which would presumably include invalidating signatures.
Or, are digital signatures in an entry some kind of special entity that MUST be treated differently than other kinds of extensions? Does the presence of a signature in an entry hold some kind of special meaning that the server MUST be capable of understanding and dealing with? Lisa Dusseault wrote: > > On Jun 17, 2007, at 1:51 PM, James M Snell wrote: > >>> >>> 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. If dsig's are treated as Just-Another-Extension, there is already an established processing model that is more than adequate. RFC4287 states that unknown extensions MUST be ignored. A client could choose to digitally sign every entry is produces; a server that receives those entries could simply ignore the signature if it is not capable of doing anything with it. If some other server chooses to do something with those signatures, then cool. "Older" servers would just continue ignoring those signatures leaving the responsibility on the client to decide if that's an acceptable behavior. >>> >>> 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. >>> Again, the current must-ignore model provides a perfectly adequate approach to dealing with all this. None of this becomes an issue unless you want to assign some kind of special meaning to a digital signature in an entry -- that is, making it more than Just-Another-Extension. - James >> >> What exactly are you trying to achieve with this? >> > > Trying to figure out if there are any additional requirements or > decisions or clarifications to make now, that would make design and > interoperability much easier when (if) a group gets around to > standardizing a way to do client signatures. It's not worth much work > now (present value of money/time and all that) but it's worth a bit of > thought. > > Lisa
