Add sections to the format about Securing Atom Content and Security Considerations.


Active. Please direct discussion to the atom-syntax list:


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.


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.


Atom format text.


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 to construct aggregate/synthetic feeds that contain signed entries. -- BobWyman