Abstract
Add sections to the format about Securing Atom Content and Security Considerations.
Status
Active. Please direct discussion to the atom-syntax list:
Rationale
One of the side-effects of being in the IETF is that we are not allowed to hand-wave or under-specify security for our documents. We don't need to decide all of the security properties in our -00 drafts, but it would be useful for us to start thinking about them now.
Proposal
Atom Format
Section: Securing Atom Content
N,nn.Securing Atom Content Because every Atom root element is an XML object, Atom can use existing XML security services. If an Atom root element is signed, it MUST be signed with XMLDSig [ref]. If an Atom root element is encrypted, it MUST be encrypted with XMLEnc [ref]. Publishers MUST NOT sign any Atom content other than a root element. Publishers SHOULD NOT sign or encrypt Atom content unless security services are actually needed. Atom consumers MUST be able to parse XMLDSig content to extract the Atom content, even if they cannot do any signature validation. Atom consumers MUST NOT reject an Atom item simply because it is signed. The consuming program can decide whether to alert the user (and how to alert the user) if the program cannot verify the signature on an Atom root element.
Section: Security Considerations
NN.nn. Security Considerations The security of the Atom format is based on XMLDSig and XMLEnc. Any weaknesses in either of these two protocols will obviously affect the security of Atom.
Impacts
Atom format text.
Notes
It must be possible to sign individual entries. Also, it must be possible for a signed feed to contain individual entries which are signed by different signers. There should be no requirement that the signer of the feed be associated in any way with the signers of entries. These requirements are necessary to permit aggregators (like PubSub.com) to construct aggregate/synthetic feeds that contain signed entries. -- BobWyman