This is very rough but is this at least a step in the right direction? 15.5. Digital Signatures and Encryption
Atom Entry and Feed Documents might contain XML Digital Signatures [REC-xmldsig-core] and might be encrypted using XML Encryption [REC-xmlenc-core] as specified in Section 5 of [RFC4287]. When servers or clients receive digitally signed or encrypted Entry Documents, they are under no obligation to preserve the integrity of the signatures or the encryption. They are allowed to modify member resources in ways that can invalidate signatures. If such modifications are made, it is recommended that any invalid signatures be removed. A server can require that Entry Documents received from a client, either via POST or PUT, be digitally signed with a valid signature or are encrypted, or both. How such requirements are communicated to the client are considered out of scope for this specification. Signatures and encrypted elements are considered to be foreign markup within an Atom document and are required to be handled according to the rules specified in Sections 5 and 6.3 of [RFC4287]. - James Tim Bray wrote: > > The more I think about this, the more the right answer seems obvious. > The notion of a client signing a whole Atom entry is just fundamentally > bogus, because some parts of it are actually owned by the server (id, > update-timestamp). On the other hand, the notion of a client signing > the payload (title/author/categories/summary/content) is interesting and > worth exploring. Fortunately, Atom & APP are flexible enough that > anyone can try a few things out without breaking any implementations. > Unfortunately, nobody has ever implemented anything like this that I > know of, and I don't even know of any applications that need it, so > it''s *way* too early to try to specify The Right Thing To Do. > > So.... I would address Sam's points like so: > > Expand 15.5 to point out all the problems that have emerged in this > discussion and which make client-originated dig-sig a non-starter for > APP. Further point out that server-side dig-sig, per RFC4287 rules, > might make all sorts of sense in certain apps and is perfectly > technically feasible; I now think it's a bug that the spec leaves you > with the impression that something about server-side digsig might not > work. Further point out that signature elements can freely be inserted > in to-be-posted entries by clients and are guaranteed not to break the > server because of our MustIgnore rule, and make it clear that the door > is open to payload signing. > > The idea is that down the road, when there's a body of experience and we > know what the Best Practices are, someone can spec an APP Extension to > capture them. -Tim > >
