Greetings again. The "clearing a discuss" thread has been productive, but the proposed wording has changed a few times. Here is what I suggest is good final wording that covers the issues brought up. Comments are welcome.
5. Securing Atom Documents Because Atom is an XML-based format, existing XML security mechanisms can be used to secure its content. [[ NEW ]] Producers of feeds and/or entries, and intermediaries who aggregate feeds and/or entries, may have sound business reasons for signing and/or encrypting otherwise-unprotected content. For example, a merchant might digitally sign a message that contains a discount coupon for its products. A bank that uses Atom to deliver customer statements is very likely to want to sign and encrypt those messages to protect their customers' financial information and to assure the customer of their authenticity. Intermediaries may want to encrypt aggregated feeds so that a passive observer cannot tell what topics the recipient is interested in. Of course, many other examples exist as well. [[ NEW ]] The algorithm requirements in this section pertain to the Atom Processor. They require that a recipient, at a minimum, be able to handle messages that use the specified cryptographic algorithms. This does not limit the algorithms that the sender can choose: it only says that the sender can only assume the recipient can use the named algorithms unless they have other out-of-band knowledge. 5.1 Digital Signatures The root of an Atom document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry Document) MAY have an Enveloped Signature, as described by XML-Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212]. Atom Processors MUST NOT reject an Atom Document containing such a signature because they are not capable of verifying it; they MUST continue processing and MAY inform the user of their failure to validate the signature. In other words, the presence of an element with the namespace URI "http://www.w3.org/2000/09/xmldsig#"; and a local name of "Signature" as a child of the document element MUST NOT cause an Atom Processor to fail merely because of its presence. Other elements in an Atom Document MUST NOT be signed unless their definitions explicitly specify such a capability. [[ NEW ]] Section 6.5.1 of [W3C.REC-xmldsig-core-20020212] requires support for Canonical XML. Atom Processors that verify signed Atom Documents MUST be able to canonicalize with Canonical XML. [[ NEW ]] Section 4.4.2 of [W3C.REC-xmldsig-core-20020212] requires support for DSA signatures and recommends support for RSA signatures. However, because of the much greater popularity in the market of RSA versus DSA, Atom Processors that verify signed Atom Documents MUST be able to verify RSA signatures, but do not need be able to verify DSA signatures. Due to security issues that can arise if the keying material for MAC authentication is not handled properly, Atom documents SHOULD NOT use MACs for signatures. 5.2 Encryption The root of an Atom Document (i.e., atom:feed in an Atom Feed Document, atom:entry in an Atom Entry Document) MAY be encrypted, using the mechanisms described by XML Encryption Syntax and Processing [W3C.REC-xmlenc-core-20021210]. [[ NEW ]] Section 5.1 of [W3C.REC-xmlenc-core-20021210] requires support of TripleDES, AES-128, and AES-256. Atom Processors that decrypt Atom Documents MUST be able to decrypt with AES-128 in CBC mode. [[ NEW ]] Encryption based on [W3C.REC-xmlenc-core-20021210] does not assure integrity of the original document. There are known cryptographic attacks where someone who cannot decrypt a message can still change bits in a way where part or all the decrypted message makes sense but has a different meaning. Thus, Atom Processors that decrypt Atom Documents SHOULD check the integrity of the decrypted document by verifying the hash in the signature (if any) in the document, or by verifying a hash of the document within the document (if any). [[ NEW ]] 5.3 Signing and Encrypting [[ NEW ]] When an Atom Document is to be both signed and encrypted, it is generally a good idea to first sign the document, then encrypt the signed document. This provides integrity to the base document while encrypting all the information, including the identity of the entity that signed the document. Note that, if MACs are used for authentication, the order MUST be that the signed document is encrypted, and not the other way around. --Paul Hoffman, Director --Internet Mail Consortium
