[要約] RFC 2803は、DOM (DOMHASH)のためのダイジェスト値に関する仕様であり、XML文書の整合性を確認するために使用されます。このRFCの目的は、DOMベースのアプリケーションでデータの整合性を保証するための標準的な手法を提供することです。
Network Working Group H. Maruyama
Request for Comments: 2803 K. Tamura
Category: Informational N. Uramoto
IBM
April 2000
Digest Values for DOM (DOMHASH)
DOM（domhash）のダイジェスト値
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML. This definition can be used for XML digital signature as well efficient replication of XML objects.
このメモは、XMLの表面文字列変化に関係なく、XMLオブジェクトのダイジェスト（ハッシュ）値の明確で明確な定義を定義します。この定義は、XMLデジタル署名にもXMLオブジェクトの効率的な複製に使用できます。
Table of Contents
目次
1. Introduction............................................2
2. Digest Calculation......................................3
2.1. Overview..............................................3
2.2. Namespace Considerations..............................4
2.3. Definition with Code Fragments........................5
2.3.1. Text Nodes..........................................5
2.3.2. Processing Instruction Nodes........................6
2.3.3. Attr Nodes..........................................6
2.3.4. Element Nodes.......................................7
2.3.5. Document Nodes......................................9
3. Discussion..............................................9
4. Security Considerations.................................9
References................................................10
Authors' Addresses........................................10
Full Copyright Statement..................................11
The purpose of this document is to give a clear and unambiguous definition of digest (hash) values of the XML objects [XML]. Two subtrees are considered identical if their hash values are the same, and different if their hash values are different.
このドキュメントの目的は、XMLオブジェクト[XML]のダイジェスト（ハッシュ）値の明確で明確な定義を提供することです。ハッシュ値が同じ場合、2つのサブツリーは同一であると見なされ、ハッシュ値が異なる場合は異なります。
There are at least two usage scenarios of DOMHASH. One is as a basis for digital signatures for XML. Digital signature algorithms normally require hashing a signed content before signing. DOMHASH provides a concrete definition of the hash value calculation.
Domhashには少なくとも2つの使用シナリオがあります。1つは、XMLのデジタル署名の基礎としてです。デジタル署名アルゴリズムは通常、署名する前に署名されたコンテンツをハッシュする必要があります。Domhashは、ハッシュ値計算の具体的な定義を提供します。
The other is to use DOMHASH when synchronizing two DOM structures [DOM]. Suppose that a server program generates a DOM structure which is to be rendered by clients. If the server makes frequent small changes on a large DOM tree, it is desirable that only the modified parts are sent over to the client. A client can initiate a request by sending the root hash value of the structure in the cache memory. If it matches with the root hash value of the current server structure, nothing needs be sent. If not, then the server compares the client hash with the older versions in the server's cache. If it finds one that matches the client's version of the structure, then it locates differences with the current version by recursively comparing the hash values of each node. This way, the client can receive only an updated portion of a large structure without requesting the whole thing.
もう1つは、2つのDOM構造[DOM]を同期するときにDomhashを使用することです。サーバープログラムがクライアントによってレンダリングされるDOM構造を生成すると仮定します。サーバーが大きなDOMツリーで頻繁に小さな変更を加える場合、修正された部品のみがクライアントに送信されることが望ましいです。クライアントは、キャッシュメモリ内の構造のルートハッシュ値を送信して、要求を開始できます。現在のサーバー構造のルートハッシュ値と一致する場合、送信する必要はありません。そうでない場合、サーバーはクライアントハッシュをサーバーのキャッシュ内の古いバージョンと比較します。クライアントの構造のバージョンに一致するものが見つかった場合、各ノードのハッシュ値を再帰的に比較することにより、現在のバージョンとの違いを見つけます。このようにして、クライアントは、全体を要求することなく、大きな構造の更新された部分のみを受信できます。
One way of defining digest values is to take a surface string as the input for a digest algorithm. However, this approach has several drawbacks. The same internal DOM structure may be represented in may different ways as surface strings even if they strictly conform to the XML specification. Treatment of white spaces, selection of character encodings, entity references (i.e., use of ampersands), and so on have impact on the generation of a surface string. If the implementations of surface string generation are different, the hash values would be different, resulting in unvalidatable digital signatures and unsuccessful detection of identical DOM structures. Therefore, it is desirable that digest of DOM is defined in the DOM terms -- that is, as an unambiguous algorithm operating on a DOM tree. This is the approach we take in this specification.
ダイジェスト値を定義する1つの方法は、Digestアルゴリズムの入力としてSurface Stringを使用することです。ただし、このアプローチにはいくつかの欠点があります。同じ内部DOM構造は、XML仕様に厳密に準拠していても、表面弦とは異なる方法で表される可能性があります。白い空間の処理、文字エンコーディングの選択、エンティティ参照（つまり、アンパサンドの使用）、その他は表面弦の生成に影響を与えます。Surface Stringの生成の実装が異なる場合、ハッシュ値は異なります。その結果、Validatable Digital Signaturesと同一のDOM構造の検出に失敗します。したがって、DOMのダイジェストはDOM用語で定義されること、つまり、DOMツリーで動作する明確なアルゴリズムとして定義されることが望ましいです。これは、この仕様で取るアプローチです。
Introduction of namespace is another source of variation of surface string because different namespace prefixes can be used for representing the same namespace URI [URI]. In the following example, the namespace prefix "edi" is bound to the URI "http://ecommerce.org/schema" but this prefix can be arbitrary chosen without changing the logical contents as shown in the second example.
名前空間の導入は、同じ名前空間URI [URI]を表すために異なる名前空間プレフィックスを使用できるため、表面弦の別のバリエーションのソースです。次の例では、名前空間のプレフィックス「EDI」はURI "http://ecommerce.org/schema"にバインドされていますが、このプレフィックスは、2番目の例に示すように論理コンテンツを変更せずに任意に選択できます。
<?xml version="1.0"?>
<root xmlns:edi='http://ecommerce.org/schema'>
<edi:order>
:
</edi:order>
</root>
<?xml version="1.0"?>
<root xmlns:ec='http://ecommerce.org/schema'>
<ec:order>
:
</ec:order>
</root>
The DOMHASH defined in this document is designed so that the choice of the namespace prefix does not affect the digest value. In the above example, both the "root" elements will get the same digest value.
このドキュメントで定義されているドンハッシュは、名前空間プレフィックスの選択がダイジェスト値に影響しないように設計されています。上記の例では、両方の「ルート」要素が同じダイジェスト値を取得します。
Hash values are defined on the DOM type Node. We consider the following five node types that are used for representing a DOM document structure:
ハッシュ値は、DOMタイプノードで定義されています。DOMドキュメント構造を表すために使用される次の5つのノードタイプを検討します。
- Text - ProcessingInstruction - Attr - Element - Document
- テキスト-ProcessinStruction -attr-要素 - ドキュメント
Comment nodes and Document Type Definitions (DTDs) do not participate in the digest value calculation. This is because DOM does not require a conformant processor to create data structures for these. DOMHASH is designed so that it can be computed with any XML processor conformant to the DOM or SAX [SAX] specification.
コメントノードとドキュメントタイプ定義（DTD）は、ダイジェスト値の計算に参加しません。これは、DOMがこれらのデータ構造を作成するためにコンフォーマントプロセッサを必要としないためです。Domhashは、DOMまたはSAX [SAX]仕様に適合したXMLプロセッサで計算できるように設計されています。
Nodes with the node type EntityReference must be expanded prior to digest calculation.
ノードタイプのエンティティリファレンスを備えたノードは、消化計算の前に拡張する必要があります。
The digest values are defined recursively on each level of the DOM tree so that only a relevant part needs to be recalculated when a small portion of the tree is changed.
ダイジェスト値は、DOMツリーの各レベルで再帰的に定義されるため、ツリーのごく一部を変更すると、関連する部分のみを再計算する必要があります。
Below, we give the precise definitions of digest for these types. We describe the format of the data to be supplied to a hash algorithm using a figure and a simple description, followed by a Java code fragment using the DOM API and the JDK 1.1 Platform Core API only. Therefore, the semantics should be unambiguous.
以下に、これらのタイプのダイジェストの正確な定義を示します。図と簡単な説明を使用して、ハッシュアルゴリズムに提供されるデータの形式を説明し、その後、Dom APIとJDK 1.1プラットフォームコアAPIのみを使用してJavaコードフラグメントを使用します。したがって、セマンティクスは明確でなければなりません。
As the rule of thumb, all strings are to be in UTF-16BE [UTF16]. If there is a sequence of text nodes without any element nodes in between, these text nodes are merged into one by concatenating them. A zero-length text node is always ignored.
経験則として、すべての弦はUTF-16BE [UTF16]にあることになります。その間に要素ノードがない一連のテキストノードがある場合、これらのテキストノードはそれらを連結することにより1つにマージされます。ゼロ長さのテキストノードは常に無視されます。
Note that validating and non-validating XML processors may generate different DOM trees from the same XML document, due to attribute normalization and default attributes. If DOMHASH is to be used for testing logical equivalence between two XML documents (as opposed to DOM trees), it may be necessary to normalize attributes and supply default attributes prior to DOMHASH calculation.
XMLプロセッサの検証と非検証は、属性正規化とデフォルト属性により、同じXMLドキュメントから異なるDOMツリーを生成する場合があることに注意してください。Domhashが2つのXMLドキュメント間の論理等価性のテストに使用される場合（DOMツリーとは対照的に）、Domhash計算前に属性を正常化し、デフォルトの属性を提供する必要がある場合があります。
Some legacy character encodings (such as ISO-2022-JP) have certain ambiguity in translating into Unicode. This is again dependent on XML processors. Treatment of such processor dependencies is out of scope of this document.
一部のレガシーキャラクターエンコーディング（ISO-2022-JPなど）は、Unicodeに翻訳する際に一定の曖昧さを持っています。これもXMLプロセッサに依存します。このようなプロセッサ依存関係の処理は、このドキュメントの範囲外です。
To avoid the dependence on the namespace prefix, we use "expanded names" to do digest calculation. If an element name or an attribute name is qualified either by a explicit namespace prefix or by a default namespace, the name's LocalPart is prepended by the URI of the namespace (the namespace name as defined in the Namespace specification [NAM]) and a colon before digest calculation. In the following example, the default qualified name "order" is expanded into "http://ecommerce.org/schema:order" while the explicit qualified name "book:title" is expanded into "urn:loc.gov:books:title" before digest calculation.
名前空間プレフィックスへの依存を回避するために、「拡張名」を使用して計算を消化します。要素名または属性名が明示的な名前空間プレフィックスまたはデフォルトの名前空間のいずれかによって資格がある場合、名前のLocalPartが名前空間のURI（名前空間仕様[NAM]で定義されている名前空間名）とコロンによって準備されている場合消化の計算前。次の例では、デフォルトの資格のある名前「注文」が「http://ecommerce.org/schema：order」に拡張され、明示的な資格名「本：タイトル」が「urn：loc.gov：books：タイトル「ダイジェスト計算の前。
<?xml version="1.0"?>
<root xmlns='http://ecommerce.org/schema' xmlns:book='urn:loc.gov:books'> <order> <book:title> ... </book:title> : </order> </root> We define an expanded name (either for element or attribute) as follows:
<root xmlns = 'http：//ecommerce.org/schema' xmlns：book = 'urn：loc.gov：books'> <order> <book：title> ... </book>：</注文> </root>次のように拡張名（要素または属性のいずれか）を定義します。
If a name is not qualified, the expanded name is the name itself.
名前が適格でない場合、拡張された名前は名前自体です。
If a name is qualified with the prefix "xmlns", the expanded name is undefined.
名前がプレフィックス「xmlns」で適格である場合、拡張された名前は未定義です。
If a name is qualified either by default or by an explicit namespace prefix, the expanded name is URI bound to the namespace + ":" + LocalPart
名前がデフォルトまたは明示的な名前空間プレフィックスのいずれかによって資格がある場合、拡張された名前はuriが名前空間にバインドされています "：" localpart
In the following example code, we assume that the getExpandedName() method (which returns the expanded name as defined above) is defined in both Element and Attr interfaces of DOM.
次の例コードでは、getExpandedName（）メソッド（上記のように展開された名前を返す）は、DOMの要素とATTRインターフェイスの両方で定義されていると仮定します。
Note that the digest values are not defined on namespace declarations. In other words, the digest value is not defined for an attribute when
ダイジェスト値は名前空間宣言で定義されていないことに注意してください。言い換えれば、ダイジェスト値は属性に対して定義されていません
- the attribute name is "xmlns", or - the namespace prefix is "xmlns".
- 属性名は「xmlns」、または - 名前空間プレフィックスは「xmlns」です。
In the above example, the two attributes which are namespace declarations do not have digest values and therefore will not participate in the calculation of the digest value of the "root" element.
上記の例では、名前空間宣言である2つの属性には消化値がなく、したがって「ルート」要素のダイジェスト値の計算に参加しません。
The code fragments in the definitions below assume that they are in implementation classes of Node. Therefore, a methods call without an explicit object reference is for the Node itself. For example, getData() returns the text data of the current node if it is a Text node. The parameter digestAlgorithm is to be replaced by an identifier of the digest algorithm, such as "MD5" [MD5] and "SHA-1" [SHA].
以下の定義のコードフラグメントは、それらがノードの実装クラスにあると仮定しています。したがって、明示的なオブジェクト参照のないメソッドコールは、ノード自体のものです。たとえば、getData（）がテキストノードの場合、現在のノードのテキストデータを返します。パラメーター消化器gorthmは、「md5」[md5]や「sha-1」[sha]などのダイジェストアルゴリズムの識別子に置き換えられます。
The computation should begin with a four byte integer that represents the type of the node, such as TEXT_NODE or ELEMENT_NODE.
計算は、text_nodeやelement_nodeなどのノードのタイプを表す4バイト整数で開始する必要があります。
The hash value of a Text node is computed on the four byte header followed by the UTF-16BE encoded text string.
テキストノードのハッシュ値は、4バイトヘッダーで計算され、その後UTF-16BEエンコードされたテキスト文字列が続きます。
- TEXT_NODE (3) in 32 bit network-byte-ordered integer - Text data in UTF-16BE stream (variable length) public byte[] getDigest(String digestAlgorithm) { MessageDigest md = MessageDigest.getInstance(digestAlgorithm); md.update((byte)0); md.update((byte)0); md.update((byte)0); md.update((byte)3); md.update(getData().getBytes("UnicodeBigUnmarked")); return md.digest(); }
- text_node（3）32ビットのネットワークバイト順序整数 - UTF-16BEストリーム（可変長）パブリックバイトのテキストデータ[] getDigest（String DigestalGorithm）{Messaged Md = MessageDigest.getInstance（Digestalgorithm）;md.update（（byte）0）;md.update（（byte）0）;md.update（（byte）0）;md.update（（byte）3）;md.update（getData（）。getBytes（ "UnicodeBigunmarked"））;return md.digest（）;}
Here, MessageDigest is in the package java.security.*, one of the built-in packages of JDK 1.1.
ここでは、MESSAGED GIGESTがパッケージJava.securityにあります。*、JDK 1.1の組み込みパッケージの1つです。
A ProcessingInstruction (PI) node has two components: the target and the data. Accordingly, the hash is computed on the concatenation of both, separated by 'x0000'. PI data is from the first non white space character after the target to the character immediately preceding the "?>".
Processinstruction（PI）ノードには、ターゲットとデータの2つのコンポーネントがあります。したがって、ハッシュは、「x0000」で分離された両方の連結時に計算されます。PIデータは、ターゲットの後の最初の非白色空間文字から、「？>」の直前のキャラクターまでです。
- PROCESSING_INSTRUCTION_NODE (7) in 32 bit network-byte-ordered integer - PI target in UTF-16BE stream (variable length) - 0x00 0x00 - PI data in UTF-16BE stream (variable length)
- Processing_instruction_node（7）32ビットのネットワークバイト順序整数-PiターゲットUTF-16BEストリーム（変数長）-0X00 0x00-UTF-16BEストリームのPIデータ（変数長）
public byte[] getDigest(String digestAlgorithm) {
MessageDigest md = MessageDigest.getInstance(digestAlgorithm);
md.update((byte)0);
md.update((byte)0);
md.update((byte)0);
md.update((byte)7);
md.update(getName().getBytes("UnicodeBigUnmarked"));
md.update((byte)0);
md.update((byte)0);
md.update(getData().getBytes("UnicodeBigUnmarked"));
return md.digest();
}
The digest value of Attr nodes are defined similarly to PI nodes, except that we need a separator between the expanded attribute name and the attribute value. The '0x0000' value in UTF-16BE is allowed nowhere in an XML document, so it can serve as an unambiguous separator. The expanded name must be used as the attribute name because it may be qualified. Note that if the attribute is a namespace declaration (either the attribute name is "xmlns" or its prefix is "xmlns"), the digest value is undefined and the getDigest() method should return null.
アットノードのダイジェスト値は、拡張属性名と属性値の間にセパレーターが必要であることを除いて、PIノードと同様に定義されます。UTF-16BEの「0x0000」値はXMLドキュメントではどこにも許可されていないため、明確なセパレーターとして機能します。拡張された名前は、資格がある可能性があるため、属性名として使用する必要があります。属性が名前空間宣言である場合（属性名が「xmlns」またはそのプレフィックスのいずれかのいずれかが「xmlns」）の場合、ダイジェスト値は未定義であり、getDigest（）メソッドはnullを返す必要があります。
- ATTRIBUTE_NODE (2) in 32 bit network-byte-ordered integer - Expanded attribute name in UTF-16BE stream (variable length) - 0x00 0x00 - Attribute value in UTF-16BE stream (variable length)
- 属性_Node（2）32ビットネットワークバイト順序整数 - UTF-16BEストリームの拡張属性名（変数長） - 0x00 0x00- UTF-16BEストリームの属性値（変数長）
public byte[] getDigest(String digestAlgorithm) {
if (getNodeName().equals("xmlns")
|| getNodeName().startsWith("xmlns:"))
return null;
MessageDigest md = MessageDigest.getInstance(digestAlgorithm);
md.update((byte)0);
md.update((byte)0);
md.update((byte)0);
md.update((byte)2);
md.update(getExpandedName().getBytes("UnicodeBigUnmarked"));
md.update((byte)0);
md.update((byte)0);
md.update(getValue().getBytes("UnicodeBigUnmarked"));
return md.digest();
}
Element nodes are the most complex because they consist of other nodes recursively. Hash values of these component nodes are used to calculate the node's digest so that we can save computation when the structure is partially changed.
要素ノードは、再帰的に他のノードで構成されているため、最も複雑です。これらのコンポーネントノードのハッシュ値は、構造が部分的に変更されたときに計算を保存できるように、ノードのダイジェストを計算するために使用されます。
First, all the attributes except for namespace declarations must be collected. This list is sorted lexicographically by the expanded attribute names (based on Unicode character code points). When no surrogate characters are involved, this is the same as sorting in ascending order in terms of the UTF-16BE encoded expanded attribute names, using the string comparison operator String.compareTo() in Java.
まず、名前空間宣言を除くすべての属性を収集する必要があります。このリストは、拡張された属性名（Unicode文字コードポイントに基づいて）によって辞書化されています。代理文字が関与していない場合、これは、Javaの文字列比較オペレーターString.comPareto（）を使用して、UTF-16BEエンコードされた拡張属性名の観点から昇順でソートすることと同じです。
- ELEMENT_NODE (1) in 32 bit network-byte-ordered integer - Expanded element name in UTF-16BE stream (variable length) - 0x00 0x00 - A number of non-namespace-declaration attributes in 32 bit network-byte-ordered unsigned integer - Sequence of digest values of non-namespace-declaration attributes, sorted lexicographically by expanded attribute names - A number of child nodes (except for Comment nodes) in 32bit
- element_node（1）32ビットのネットワークバイト順序整数 - UTF-16BEストリームの拡張要素名（変数長）-0x000x00- 32ビットネットワークバイト順序付けられていない整数の属性の多くの非ネームズスペースデクラレーション属性 - 拡張された属性名によって辞書化された非namespace-declaration属性のダイジェスト値のシーケンス - 32ビットの多くの子ノード（コメントノードを除く）
network-byte-ordered unsigned integer - Sequence of digest values of each child node except for Comment nodes (variable length) (A sequence of child texts is merged to one text. A zero-length text and Comment nodes are not counted as child)
ネットワークバイト命令の符号なし整数 - コメントノード（可変長）を除く各子ノードのダイジェスト値のシーケンス（子テキストのシーケンスは1つのテキストにマージされます。
public byte[] getDigest(String digestAlgorithm) {
MessageDigest md = MessageDigest.getInstance(digestAlgorithm);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
DataOutputStream dos = new DataOutputStream(baos);
dos.writeInt(ELEMENT_NODE);//This is stored in network byte order
dos.write(getExpandedName().getBytes("UnicodeBigUnmarked"));
dos.write((byte)0);
dos.write((byte)0);
// Collect all attributes except for namespace declarations
NamedNodeMap nnm = this.getAttributes();
int len = nnm.getLength()
// Find "xmlns" or "xmlns:foo" in nnm and omit it.
...
dos.writeInt(len); // This is sorted in the network byte order
// Sort attributes lexicographically by expanded attribute
// names.
...
// Assume that `Attr[] aattr' has sorted Attribute instances.
for (int i = 0; i < len; i ++)
dos.write(aattr[i].getDigest(digestAlgorithm));
Node n = this.getFirstChild();
// Assume that adjoining Texts are merged,
// there is no 0-length Text, and
// comment nodes are removed.
len = this.getChildNodes().getLength();
dos.writeInt(len); // This is stored in the network byte order
while (n != null) {
dos.write(n.getDigest(digestAlgorithm));
n = n.getNextSibling();
}
dos.close();
md.update(baos.toByteArray());
return md.digest();
}
A Document node may have PI nodes before and after the root Element node. The digest value of a Document node is computed based on the sequence of the digest values of the pre-root PI nodes, the root Element node, and the post-root PI nodes in this order. Comment nodes and DocumentType nodes, if any, are ignored.
ドキュメントノードには、ルート要素ノードの前後のPIノードがある場合があります。ドキュメントノードのダイジェスト値は、この順序でのプレルートPIノード、ルート要素ノード、および根ポストPIノードのダイジェスト値のシーケンスに基づいて計算されます。コメントノードとdocumentTypeノードがある場合は無視されます。
- DOCUMENT_NODE (9) in 32 bit network-byte-ordered integer - A number of child nodes (except for Comment and DocumentType nodes) in 32bit network-byte-ordered unsigned integer - Sequence of digest values of each child node except for Comment and DocumentType nodes (variable length)
- document_node（9）32ビットネットワークバイト順序整数 - 32ビットのネットワークバイトバイト順序符号なし整数の多くの子ノード（コメントとdocumentTypeノードを除く） - コメントとdocumentTypeを除く各子供ノードのダイジェスト値のシーケンスノード（変数長）
public byte[] getDigest(String digestAlgorithm) {
MessageDigest md = MessageDigest.getInstance(digestAlgorithm);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
DataOutputStream dos = new DataOutputStream(baos);
dos.writeInt(DOCUMENT_NODE);//This is stored in network byte order
// Assume that Comment and DocumentType nodes are removed and this
// node has only an Element node and PI nodes.
len = this.getChildNodes().getLength();
dos.writeInt(len); // This is stored in the network byte order
Node n = this.getFirstChild();
while (n != null) {
dos.write(n.getDigest(digestAlgorithm));
n = n.getNextSibling();
}
dos.close();
md.update(baos.toByteArray());
return md.digest();
}
The definition described above can be efficiently implemented with any XML processor that is conformant to either DOM and SAX specification. Reference implementations are available on request.
上記の定義は、DOMおよびSAX仕様のいずれかに適合するXMLプロセッサで効率的に実装できます。リクエストに応じて参照実装が利用可能です。
DOMHASH is expected to be used as the basis for digital signatures and other security and integrity uses. It's appropriateness for such uses depends on the security of the hash algorithm used and inclusion of the fundamental characteristics it is desired to check in parts of the DOM model incorporated in the digest by DOMHASH.
Domhashは、デジタル署名やその他のセキュリティおよび整合性の使用の基礎として使用されることが期待されています。そのような用途に対する適切性は、使用されたハッシュアルゴリズムのセキュリティと、Domhashによってダイジェストに組み込まれたDOMモデルの一部をチェックインすることが望まれる基本特性の包含に依存します。
References
参考文献
[DOM] "Document Object Model (DOM), Level 1 Specification", October 1998, http://www.w3.org/TR/REC-DOM-Level-1/
[DOM]「ドキュメントオブジェクトモデル（DOM）、レベル1仕様」、1998年10月、http：//www.w3.org/tr/rec-dom-level-1/
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[NAM] Tim Bray, Dave Hollander, Andrew Layman, "Namespaces in XML", http://www.w3.org/TR/1999/REC-xml-names-19990114.
[nam]ティム・ブレイ、デイブ・ホランダー、アンドリュー・レイマン、「XMLの名前空間」、http：//www.w3.org/tr/1999/rec-xml-names-1990114。
[SAX] David Megginson, "SAX 1.0: The Simple API for XML", http://www.megginson.com/SAX/, May 1998.
[Sax] David Megginson、「Sax 1.0：XMLのシンプルなAPI」、http：//www.megginson.com/sax/、1998年5月。
[SHA] (US) National Institute of Standards and Technology, "Federal Information Processing Standards Publication 180-1: Secure Hash Standard", 17 April 1995.
[SHA]（米国）国立標準技術研究所、「連邦情報処理基準出版180-1：Secure Hash Standard」、1995年4月17日。
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：汎用構文」、RFC 2396、1998年8月。
[UTF16] Hoffman, P., Yergeau, F., "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[UTF16] Hoffman、P.、Yergeau、F。、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、2000年2月。
[XML] Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible Markup Language (XML) 1.0", http://www.w3.org/TR/1998/REC-xml-19980210
[XML]ティム・ブレイ、ジャン・パオリ、C。M。スペルバー・マッキーティーン、「拡張可能なマークアップ言語（XML）1.0」、http：//www.w3.org/tr/1998/rec-xml-1998021010
Authors' Addresses
著者のアドレス
Hiroshi Maruyama, IBM Research, Tokyo Research Laboratory
Maruyama hiroshi、IBM Research、東京研究研究所
EMail: maruyama@jp.ibm.com
Kent Tamura, IBM Research, Tokyo Research Laboratory
Kent Tamura、IBM Research、Tokyo Research Laboratory
EMail: kent@trl.ibm.co.jp
Naohiko Uramoto, IBM Research, Tokyo Research Laboratory
Naohiko Uramoto、IBM Research、東京研究研究所
EMail: uramoto@jp.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgment
了承
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。