広告
広告
https://www.7key.jp/rfc/4287/rfc4287_5.html#source
https://www.7key.jp/rfc/4287/rfc4287_5.html#translation
Because Atom is an XML-based format, existing XML security mechanisms can be used to secure its content.
AtomはXMLが元となる文書形式なので、既存のXMLセキュリティ技術を用いてその内容を安全なものとすることができる。
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 well.
保護されていないコンテンツに署名をいれたり暗号化したりするからには、フィードやエントリの提供者もしくは集約する中継者にはそれなりの理由があるに違いない。例えば、販売業者は商品に対する割引券を含むメッセージに電子署名を施す場合がある。顧客の明細書の送付にAtomを用いる銀行も、顧客の金融情報を守り顧客に信頼性を保証するために、メッセージに署名や暗号化といった技術を用いたいであろう。中継者は、フィードの受信者が興味を持つ話題を第3者に漏らさないため、集約したフィードを暗号化したいと望むかもしれない。もちろん例はこれだけではない。
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 choose.
当章のアルゴリズム要求事項は、Atom処理装置に関するものである。Atom処理装置は少なくとも、特定の暗号化アルゴリズムで暗号化されたメッセージを受信者側が取り扱い可能であることを要求される。この要求は、送信者側が選択可能なアルゴリズムに限定されない。
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 "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.
言い換えると、名前空間URI"http://www.w3.org/2000/09/xmldsig#"を持つ要素とローカル名が"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 "http://www.w3.org/2001/10/xml-exc-c14n#", as specified in Exclusive XML Canonicalization [W3C.REC-xml-exc-c14n-20020718].
[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"http://www.w3.org/2001/10/xml-exc-c14n#"によって示される排他的な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.
集約者のような中継者は、エントリ自身のatom:source
要素を含まないエントリにatom:source
要素を追加する必要があるかもしれない。そのようなエントリが署名されていた場合、要素を追加することによって署名は使い物にならなくなるだろう。従って、個別に署名されたエントリの発行者は、署名する前にエントリに対してatom:source
要素を追加することが強く推奨される。実装者もまた、正規化と関連した"xml:"名前空間のマークアップの利用に関する問題を考慮すべきである。
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)。
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.
[W3C.REC-xmlenc-core-20021210]の5.1章では、TripleDES、AES-128、AES-256のサポートが要求されている。Atom文書を複合化するAtom処理装置は、CBCモードのAES-128で複合化できなければならない(MUST)。
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).
[W3C.REC-xmlenc-core-20021210]に基づいた暗号化は、元の文書の完全性を保証しない。復号化したメッセージの一部あるいは全てが妥当なものであっても複合化エラーとなるように、メッセージ復号権限のない第3者によりビットの書き換えが可能な暗号化攻撃が知られている。従って、Atom文書を複合化するAtom処理装置は、文書内の署名ハッシュがあればそれを検証し、文書内の文書ハッシュがあればそれを検証することによって複合化された文書の完全性を判断すべきである(SHOULD)。
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.
署名され暗号化されているAtom文書においては、まず初めに署名をし、署名された文書を暗号化する方法が一般的に良いとされている。これにより、文書を署名したエンティティの識別情報を含む全ての情報を暗号化することができ、且つ元の文書との完全性が提供されることとなる。MACを認証に用いる場合、署名が先で暗号化が後との手順を順守せねばならず(MUST)、それ以外の手順はないことに注意が必要である。
広告