Home >> FAQs/Tutorials >> RSS Tutorials >> Index

RSS FAQs - Atom Syndiation Format RFC4287 Reference Document

By: M. Nottingham, Ed. & R. Sayre, Ed.

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15   16  17  18  19  20  21  22  23 

(Continued from previous part...)

   canonicalize with the exclusive XML canonicalization method
   identified by the URI "http://www.w3.org/2001/10/xml-exc-c14n#", as
   specified in Exclusive XML Canonicalization
   [W3C.REC-xml-exc-c14n-20020718].

   Intermediaries such as aggregators may need to add an atom:source
   element to an entry that does not contain its own atom:source
   element.  If such an entry is signed, the addition will break the
   signature.  Thus, a publisher of individually-signed entries should
   strongly consider adding an atom:source element to those entries
   before signing them.  Implementers should also be aware of the issues
   concerning the use of markup in the "xml:" namespace as it interacts
   with canonicalization.

   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 message authentication code (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].

   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 Cipher Block
   Chaining (CBC) mode.

   Encryption based on [W3C.REC-xmlenc-core-20021210] does not ensure
   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).

[Page 27]

5.3.  Signing and Encrypting

   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 document is signed and
   then encrypted, and not the other way around.

6.  Extending Atom

6.1.  Extensions from Non-Atom Vocabularies

   This specification describes Atom's XML markup vocabulary.  Markup
   from other vocabularies ("foreign markup") can be used in an Atom
   Document.  Note that the atom:content element is designed to support
   the inclusion of arbitrary foreign markup.

6.2.  Extensions to the Atom Vocabulary

   The Atom namespace is reserved for future forward-compatible
   revisions of Atom.  Future versions of this specification could add
   new elements and attributes to the Atom markup vocabulary.  Software
   written to conform to this version of the specification will not be
   able to process such markup correctly and, in fact, will not be able
   to distinguish it from markup error.  For the purposes of this
   discussion, unrecognized markup from the Atom vocabulary will be
   considered "foreign markup".

6.3.  Processing Foreign Markup

   Atom Processors that encounter foreign markup in a location that is
   legal according to this specification MUST NOT stop processing or
   signal an error.  It might be the case that the Atom Processor is
   able to process the foreign markup correctly and does so.  Otherwise,
   such markup is termed "unknown foreign markup".

   When unknown foreign markup is encountered as a child of atom:entry,
   atom:feed, or a Person construct, Atom Processors MAY bypass the
   markup and any textual content and MUST NOT change their behavior as
   a result of the markup's presence.

   When unknown foreign markup is encountered in a Text Construct or
   atom:content element, software SHOULD ignore the markup and process
   any text content of foreign elements as though the surrounding markup
   were not present.

[Page 28]

(Continued on next part...)

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15   16  17  18  19  20  21  22  23