5. Atom文書のセキュリティ対策

   Because Atom is an XML-based format, existing XML security mechanisms
   can be used to secure its content.


   Producers of feeds and/or entries, and intermediaries who aggregate
   feeds and/or entries, may have sound 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


   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.
   These requirements do not limit the algorithms that the sender can


5.1. 電子署名

   The root of an Atom Document (i.e., atom:feed in an Atom Feed
   Document, atom:entry in an Atom Entry Document) or any atom:entry
   element MAY have an Enveloped Signature, as described by XML-
   Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212].

Atom文書のルート要素(つまり、Atomフィード文書のatom:feedやAtomエントリ文書のatom:entry)やatom:entry要素には、XML Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212]で説明されるようなエンベロープ署名を用いてよい(MAY)。

   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.

Atom処理装置は、署名の検証ができないとの理由でこのような署名を含むAtom文書を無視してはならず(MUST NOT)、必ず処理を実行し(MUST)、ユーザに署名の検証に失敗した旨を通知することができる(MAY)。

   In other words, the presence of an element with the namespace URI
   "" 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.

言い換えると、名前空間URI""を持つ要素とローカル名が"Signature"である文書要素の子要素が存在するとの理由だけで、Atom処理装置は処理失敗であると判断をしてはならない(MUST NOT)。

   Other elements in an Atom Document MUST NOT be signed unless their
   definitions explicitly specify such a capability.

Atom文書の他の要素は、機能を明示的に可能であると定義していない限り署名されてはならない(MUST NOT)。

   Section 6.5.1 of [W3C.REC-xmldsig-core-20020212] requires support for
   Canonical XML [W3C.REC-xml-c14n-20010315].  However, many
   implementers do not use it because signed XML documents enclosed in
   other XML documents have their signatures broken.  Thus, Atom
   Processors that verify signed Atom Documents MUST be able to
   canonicalize with the exclusive XML canonicalization method
   identified by the URI "", as
   specified in Exclusive XML Canonicalization

[W3C.REC-xmldsig-core-20020212]の6.5.1章は、Canonical XML [W3C.REC-xml-c14n-20010315]をサポートすることを要求するが、他のXML文書に内含された署名済みXML文書の署名は使い物にならないため、Canonical XMLを使わない実装も多い。従って、署名済みAtom文書を検証するAtom処理装置は、Exclusive XML Canonicalization [W3C.REC-xml-exc-c14n-20020718]で定義されるURI""によって示される排他的なXML正規化手段を用いて正規化できることが必須である(MUST)。

   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.

[W3C.REC-xmldsig-core-20020212]の4.4.2章にて、DSA署名のサポートが要求されており、且つRSA署名のサポートが推奨されている。ただし、DSAに比べると市場における認知度はRSAの方が高いので、署名されたAtom文書を検証するAtom処理装置はRSA署名を検証できなければならず(MUST)、それとは反対に必ずしもDSA署名を検証できる必要はない。MAC認証のためのキーマテリアルが適切に処理されていないことが原因で起こるセキュリティ問題があるため、Atom文書ではMAC署名を用いるべきではない(SHOULD NOT)。

5.2. 暗号化

   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].

Atom文書のルート(つまり、Atomフィード文書のatom:feed要素とAtomエントリ文書のatom:entry要素)は、XML Encryption Syntax and Processing [W3C.REC-xmlenc-core-20021210]で定義される処理を用いて暗号化することができる(MAY)。

   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).


5.3. 署名と暗号化

   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.



Copyright (C) 2006 七鍵 初版:2006年10月02日 最終更新:2006年10月05日