Paul Hoffman wrote:
> [snip]
> 15.5. Digital Signatures and Encryption
>
> Atom Entry and Feed Documents can contain XML Digital Signatures
> [REC-xmldsig-core] and can be encrypted using XML Encryption
> [REC-xmlenc-core] as specified in Section 5 of [RFC4287]. Handling of
> signatures and encrypted elements in Atom documents is discussed in
> sections 5 and 6.3 of [RFC4287].
>
> Neither servers nor clients are under any obligation to support
> encryption and digital signature of entries or feeds, although it is
> certainly possible that in some installations, clients or servers may
> require signing or encrypting of the documents exchanged in the Atom
> protocol.
Fine up to here.
>
> Because servers are allowed (and in some cases required) to modify the
> contents of an Entry Document before publishing it, a client that signs
> a Entry Document should only do so with the intention of the server
> possibly validating the submission; the client cannot assume that the
> signature will be valid when viewed by a third party, or that the server
> will even publish the client's signature.
>
This gets too close to dictating implementation behavior. There may be
many reasons for having a client sign an entry that goes beyond
validating the submission.
> A server is allowed to strip client-applied signatures, to strip
> client-applied signatures and then re-sign with its own public key, and
> to oversign an entry with its own public key. The meaning to a third
> party of a signature applied by a server is the same as a signature from
> anyone, as described in [RFC4287]. The method for a server to indicate
> to a third party whether or not the client signed an Entry Document is
> by including the client's signature in the published entry, even though
> that signature is likely to be invalid.
>
I preferred Aristotle's suggested text (posted 6/18)
- James
