RFC2802 日本語訳
2802 Digital Signatures for the v1.0 Internet Open Trading Protocol(IOTP). K. Davidson, Y. Kawatsura. April 2000. (Format: TXT=52756 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Davidson
Request for Comments: 2802 Differential
Category: Informational Y. Kawatsura
Hitachi
April 2000
コメントを求めるワーキンググループK.ディヴィッドソン要求をネットワークでつないでください: 2802年の特異なカテゴリ: 情報のY.Kawatsura日立2000年4月
Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)
v1.0インターネットオープンTradingプロトコルのためのデジタルSignatures(IOTP)
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
Abstract
要約
A syntax and procedures are described for the computation and verification of digital signatures for use within Version 1.0 of the Internet Open Trading Protocol (IOTP).
構文と手順は使用のためのデジタル署名の計算と検証のためにインターネットオープンTradingプロトコル(IOTP)のバージョン1.0の中で説明されます。
Acknowledgment
承認
This document is based on work originally done on general XML digital signatures by:
このドキュメントは以下で一般的なXMLデジタル署名のときに元々行われた仕事に基づいています。
Richard Brown of GlobeSet, Inc. <rdbrown@GlobeSet.com>
GlobeSet、 Inc. <rdbrown@GlobeSet.com のリチャード・ブラウン、gt。
Other contributors to the design of the IOTP DSIG DTD include, in alphabetic order:
IOTP DSIG DTDのデザインへの他の貢献者はアルファバット順で以下を入れます。
David Burdett, Commerce One
Andrew Drapp, Hitachi
Donald Eastlake 3rd, Motorola, Inc.
デヴィッドBurdett、商業1アンドリューDrapp、日立ドナルドイーストレーク3番目、モトローラ
Davidson & Kawatsura Informational [Page 1] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[1ページ]のRFC2802デジタル署名
Table of Contents
目次
1. Introduction............................................3 2. Objective and Requirements..............................3 3. Signature Basics........................................3 3.1 Signature Element......................................3 3.2 Digest Element.........................................4 3.3 Originator and Recipient Information Elements..........5 3.4 Algorithm Element......................................5 4. Detailed Signature Syntax...............................6 4.1 Uniform Resource Names.................................6 4.2 IotpSignatures.........................................6 4.3 Signature Component....................................6 4.3.1 Signature............................................6 4.3.2 Manifest.............................................7 4.3.3 Algorithm............................................9 4.3.4 Digest...............................................9 4.3.5 Attribute...........................................10 4.3.6 OriginatorInfo......................................11 4.3.7 RecipientInfo.......................................11 4.3.8 KeyIdentifier.......................................12 4.3.9 Parameter...........................................13 4.4 Certificate Component.................................13 4.4.1 Certificate.........................................13 4.4.2 IssuerAndSerialNumber...............................14 4.5 Common Components.....................................15 4.5.1 Value...............................................15 4.5.2 Locator.............................................15 5. Supported Algorithms...................................16 5.1 Digest Algorithms.....................................16 5.1.1 SHA1................................................16 5.1.2 DOM-HASH............................................17 5.2 Signature Algorithms..................................17 5.2.1 DSA.................................................17 5.2.2 HMAC................................................18 5.2.3 RSA.................................................20 5.2.4 ECDSA...............................................20 6. Examples...............................................21 7. Signature DTD..........................................23 8. Security Considerations................................25 References................................................26 Authors' Addresses........................................28 Full Copyright Statement..................................29
1. 序論…3 2. 目的と要件…3 3. 署名基礎…3 3.1署名要素…3 3.2 要素を消化してください…4 3.3創始者と受取人Information Elements…5 3.4アルゴリズム要素…5 4. 詳細な署名構文…6 4.1 一定のリソース名…6 4.2IotpSignatures…6 4.3署名コンポーネント…6 4.3 .1署名…6 4.3 .2 現れます。7 4.3 .3アルゴリズム…9 4.3 .4 読みこなしてください…9 4.3 .5 結果と考えます。10 4.3 .6OriginatorInfo…11 4.3 .7RecipientInfo…11 4.3 .8KeyIdentifier…12 4.3 .9パラメタ…13 4.4 コンポーネントを証明してください…13 4.4 .1 証明します。13 4.4 .2IssuerAndSerialNumber…14 4.5個の共通成分…15 4.5 .1 値…15 4.5 .2ロケータ…15 5. アルゴリズムであるとサポートされます…16 5.1 アルゴリズムを読みこなしてください…16 5.1 .1SHA1…16 5.1 .2ドム-ハッシュ…17 5.2 署名アルゴリズム…17 5.2 .1DSA…17 5.2 .2HMAC…18 5.2 .3RSA…20 5.2 .4ECDSA…20 6. 例…21 7. 署名DTD…23 8. セキュリティ問題…25の参照箇所…26人の作者のアドレス…28 完全な著作権宣言文…29
Davidson & Kawatsura Informational [Page 2] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[2ページ]のRFC2802デジタル署名
1. Introduction
1. 序論
The Internet Open Trading Protocol (IOTP) provides a payment system independent interoperable framework for Internet commerce as documented in [RFC 2801]. All IOTP messages are XML documents. XML, the Extensible Markup Language [XML], is a syntactical standard promulgated by the World Wide Web Consortium. XML is intended primarily for structuring data exchanged and served over the World Wide Web.
インターネットオープンTradingプロトコル(IOTP)は[RFC2801]に記録されるように決済システムの独立している共同利用できるフレームワークをインターネット商業に提供します。 すべてのIOTPメッセージがXMLドキュメントです。 XML(拡張マークアップ言語[XML])はワールドワイドウェブコンソーシアムによって公表された構文の規格です。 XMLは、主としてWWWの上で交換されて、役立たれるデータを構造化するために意図します。
Although IOTP assumes that any payment system used with it provides its own security, there are numerous cases where IOTP requires authentication and integrity services for portions of the XML messages it specifies.
IOTPは、それと共に使用されるどんな決済システムもそれ自身のセキュリティを提供すると仮定しますが、多数のケースがIOTPがそれが指定するXMLメッセージの部分のための認証と保全サービスを必要とするところにあります。
2. Objective and Requirements
2. 目的と要件
This document covers how digital signatures may be used with XML documents to provide authentication and tamper-proof protocol messages specifically for Version 1.0 of the IOTP protocol. The reader should recognize that an effort towards general XML digital signatures exists but is unlikely to produce its final result in time for IOTP Version 1.0. Future versions of IOTP will probably adopt by reference the results of this general XML digital signature effort.
このドキュメントはデジタル署名が特にIOTPプロトコルのバージョン1.0への認証と干渉防止プロトコルメッセージを提供するのにXMLドキュメントと共にどう使用されるかもしれないかをカバーしています。 読者は、一般的なXMLデジタル署名に向かった取り組みが存在すると認めるべきですが、IOTPバージョン1.0に間に合うように最終的な結果を生みそうにはありません。 IOTPの将来のバージョンはたぶん参照でこの一般的なXMLデジタル署名取り組みの結果を採用するでしょう。
The objective of this document is to propose syntax and procedures for the computation and verification of digital signatures applicable to Version 1.0 IOTP protocol messages, providing for:
このドキュメントの目的が構文を提案することであり、バージョン1.0IOTPに適切なデジタル署名の計算と検証のための手順はメッセージについて議定書の中で述べます、以下に提供して
-- Authentication of IOTP transactions
-- Provide a means by which an IOTP message may be made "tamper-
proof", or detection of tampering is made evident
-- Describe a set of available digest and signature algorithms at
least one of which is mandatory to implement for interoperability
-- Easily integrate within the IOTP 1.0 Specification
-- Provide lightweight signatures with minimal redundancy
-- Allow signed portions of IOTP message to be "forwarded" to another
trading roles with different signature algorithms than the
original recipient
-- IOTPトランザクションの認証--「タンパー証拠」、または改ざんの検出をIOTPメッセージが作られているかもしれない手段に提供するのを明白にします--少なくともそれの1つが相互運用性のために実装するために義務的である1セットの利用可能なダイジェストと署名アルゴリズムを説明してください; IOTP1.0Specificationの中で容易に統合してください--最小量の冗長を軽量の署名に提供してください--オリジナルの受取人より異なった署名アルゴリズムに役割を取り引きする別のものに「進められるべき」IOTPメッセージの署名している部分を許容してください。
3. Signature Basics
3. 署名基礎
3.1 Signature Element
3.1 署名要素
This specification consists primarily of the definition of an XML element known as the Signature element. This element consists of two sub-elements. The first one is a set of authenticated attributes, known as the signature Manifest, which comprises such things as a
この仕様は主としてSignature要素として知られているXML要素の定義から成ります。 この要素は2つの下位要素から成ります。 最初の1つはaのようなものを包括する署名Manifestとして知られている1セットの認証された属性です。
Davidson & Kawatsura Informational [Page 3] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[3ページ]のRFC2802デジタル署名
unique reference to the resources being authenticated and an indication of the keying material and algorithms being used. The second sub-element consists of the digital signature value.
リソースの認証されるユニークな参照と使用される合わせることの材料とアルゴリズムのしるし。 2番目の下位要素はデジタル署名価値から成ります。
<Signature>
<Manifest>
(resource information block)
(originator information block)
(recipient information block)
(other attributes)
(signature algorithms information block)
</Manifest>
<Value encoding 'encoding scheme'>
(encoded signature value)
<Value>
</Signature>
'体系'>(署名値をコード化する)<Value></署名>をコード化します'をコード化する<署名><Manifest>(リソース情報ブロック)(創始者情報ブロック)(受取人情報ブロック)(他の属性)(署名アルゴリズム情報ブロック)</顕現><Value
The digital signature is not computed directly from the pieces of information to be authenticated. Instead, the digital signature is computed from a set of authenticated attributes (the Manifest), which include references to, and a digests of, those pieces of information.
デジタル署名は、認証されるために直接情報の断片から計算されません。 代わりに、デジタル署名が認証されることのセットが指示するものを含んでいる(Manifest)を結果と考えて、aが読みこなすaから計算される、それらの情報。
The authentication is therefore "indirect".
したがって、認証は「間接的です」。
3.2 Digest Element
3.2 ダイジェスト要素
The Digest element consists of a unique and unambiguous reference to the XML resources being authenticated. It is constructed of a locator and the digest value data itself. The Digest algorithm is referred to indirectly via a DigestAlgorithmRef, so that Digest algorithms may be shared by multiple resources.
Digest要素は認証されるXMLリソースのユニークで明白な参照から成ります。 それはロケータとダイジェスト値のデータ自体について組み立てられます。 Digestアルゴリズムは、複数のリソースでDigestアルゴリズムを共有できるように間接的にDigestAlgorithmRefを通して示されます。
<Digest DigestAlgorithmRef='D.1'>
<Locator href='resource locator'/>
<Value>
(Digest value)
</Value>
</Digest>
'D.1'><<ダイジェストDigestAlgorithmRef=Locator hrefは'リソースロケータ'/><Value>(ダイジェスト値)</価値の></ダイジェスト>と等しいです。
The resource locator is implemented as a simple XML Link [XLink]. This not only provides a unique addressing scheme for internal and external resources, but also facilitates authentication of composite documents.
リソースロケータは簡単なXML Link[XLink]として実装されます。 これは内部の、そして、外部のリソースのユニークなアドレシング体系を提供するだけではなく、合成ドキュメントの認証を容易にもします。
Davidson & Kawatsura Informational [Page 4] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[4ページ]のRFC2802デジタル署名
3.3 Originator and Recipient Information Elements
3.3 創始者と受取人Information Elements
The purpose of the Originator and Recipient information elements is to provide identification and keying material for these respective parties.
OriginatorとRecipient情報要素の目的が識別を提供することであり、これらのためにそれぞれのである材料を合わせるのはパーティーへ行きます。
<OriginatorInfo>
(identification information block)
(keying material information block)
</OriginatorInfo>
<OriginatorInfo>(識別情報ブロック)(物質的な情報ブロックを合わせる)</OriginatorInfo>。
<RecipientInfo>
(identification information block)
(keying material information block)
</RecipientInfo>
<RecipientInfo>(識別情報ブロック)(物質的な情報ブロックを合わせる)</RecipientInfo>。
The actual content of these two elements depends on the authentication scheme being used and the existence or non-existence of a prior relationship between the parties. In some circumstances, it may be quite difficult to distinguish between identification and keying material information. A unique reference to a digital certificate provides for both. This may also stand true for an account number when a prior relationship exists between the parties.
これらの2つの要素の実際の内容はパーティーの間の先の関係の使用される認証体系と存在か非存在に依存します。 いくつかの事情では、識別と物質的な情報を合わせるとき区別するのはかなり難しいかもしれません。 デジタル証明書のユニークな参照は両方に備えます。 また、先の関係がパーティーの間に存在するとき、これは口座番号のために本当に立つかもしれません。
The Originator information element is mandatory. Depending on the existence or non-existence of a prior relationship with the recipient, this block either refers to a public credential such as a digital certificate or displays a unique identifier known by the recipient.
Originator情報要素は義務的です。 受取人との先の関係の存在か非存在によって、このブロックは、デジタル証明書などの公共の資格証明書について言及するか、または受取人によって知られていたユニークな識別子を表示します。
The Recipient information element may be used when a document contains multiple signature information blocks, each being intended for a particular recipient. A unique reference in the Recipient information block helps the recipients identify their respective Signature information block.
ドキュメントが複数の署名情報ブロックを含むとき、Recipient情報要素は使用されるかもしれません、特定の受取人のためにそれぞれ意図して。 Recipient情報ブロックでのユニークな参照は、受取人が彼らのそれぞれのSignature情報ブロックを特定するのを助けます。
The Recipient information element may also be used when determination of the authentication key consists of a combination of keying material provided by both parties. This would be the case, for example, when establishing a key by means of Diffie Hellman [Schneier] Key Exchange algorithm.
また、認証キーの決断が組み合わせから成るとき、Recipient情報要素も双方によって供給された材料を合わせるのにおいて使用されているかもしれません。 ディフィー・ヘルマンによる主要な[シュナイアー]主要なExchangeアルゴリズムを確立するとき、例えば、これはそうでしょう。
3.4 Algorithm Element
3.4 アルゴリズム要素
The Algorithm element is a generalized place to put any type of algorithm used within the signed IOTP message. The Algorithm may be a Signature algorithm or a Digest algorithm. Each algorithm contains parameters specific to the algorithm used.
Algorithm要素は署名しているIOTPメッセージの中で使用されたどんなタイプのアルゴリズムも置く一般化された場所です。 AlgorithmはSignatureアルゴリズムかDigestアルゴリズムであるかもしれません。 各アルゴリズムは使用されるアルゴリズムに特定のパラメタを含んでいます。
Davidson & Kawatsura Informational [Page 5] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[5ページ]のRFC2802デジタル署名
<Algorithm type='digest' ID='12'>
(algorithm information block)
</Algorithm>
<アルゴリズムタイプ=はID=12年の'>(アルゴリズム情報ブロック)</アルゴリズム>'を'読みこなします'。
Algorithms are required to contain an ID which allows for indirect reference to them from other places in the XML signature.
アルゴリズムが、XML署名における他の場所からそれらの間接的な言及を考慮するIDを含むのに必要です。
4. Detailed Signature Syntax
4. 詳細な署名構文
4.1 Uniform Resource Names
4.1 一定のリソース名
To prevent potential name conflicts in the definition of the numerous type qualifiers considered herein, this specification uses Uniform Resource Names [RFC 2141].
ここに考えられた多数の型限定子の定義における潜在的名前闘争を防ぐために、この仕様はUniform Resource Names[RFC2141]を使用します。
4.2 IotpSignatures
4.2 IotpSignatures
The IotpSignatures element is the top-level element in an IOTP signature block. It consists of a collection of Signature elements, and an optional set of Certificates.
IotpSignatures要素はIOTP署名欄のトップレベル要素です。 それはSignature要素の収集、およびCertificatesの任意のセットから成ります。
<!ELEMENT IotpSignatures (Signature+, Certificate*) >
<!ATTLIST IotpSignatures
ID ID #IMPLIED >
<!要素IotpSignatures(署名+、証明書*)><!ATTLIST IotpSignatures ID ID#は>を含意しました。
Content Description
満足している記述
Signature: A collection of Signature elements.
署名: Signature要素の収集。
Certificate: Zero or more certificates used for signing
以下を証明してください。 署名に使用されるゼロか、より多くの証明書
Attributes Description
属性記述
ID: Element identifier that may be used to reference the entire Signature element from a Resource element when implementing endorsement.
ID: 裏書きを実装するとき、Resource要素から全体のSignature要素に参照をつけるのに使用されるかもしれない要素識別子。
4.3 Signature Component
4.3 署名コンポーネント
4.3.1 Signature
4.3.1 署名
The Signature element constitutes the majority of this specification. It is comprised of two sub-elements. The first one is a set of attributes, known as the Manifest, which actually constitutes the authenticated part of the document. The second sub-element consists of the signature value or values.
Signature要素はこの仕様の大部分を成立させます。 それは2つの下位要素から成ります。 最初の1つは実際にドキュメントの認証された部分を構成するManifestとして知られている1セットの属性です。 2番目の下位要素は署名値か値から成ります。
Davidson & Kawatsura Informational [Page 6] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[6ページ]のRFC2802デジタル署名
The Value element contained within the Signature element is the encoded form of the signature of the Manifest element, and thus provides the verification of the Manifest.
Signature要素の中に含まれたValue要素は、Manifest要素の署名のコード化されたフォームであり、その結果、Manifestの検証を提供します。
The process for generating the signed value is a multi-step process, involving a canonicalization algorithm, a digest algorithm, and a signature algorithm.
署名している値を生成するためのプロセスは多段階プロセスです、canonicalizationアルゴリズム、ダイジェストアルゴリズム、および署名アルゴリズムにかかわって。
First, the Manifest is canonicalized with an algorithm specified within the Algorithm element of the Manifest. The canonicalized form removes any inconsistencies in white space introduced by XML parsing engines.
まず最初に、アルゴリズムがManifestのAlgorithm要素の中で指定されている状態で、Manifestはcanonicalizedされます。 canonicalizedフォームはXML構文解析エンジンによって導入された余白でどんな矛盾も取り除きます。
This canonicalized form is then converted into a digest form which uniquely identifies the canonicalized document. Any slight modification in the original document will result in a very different digest value.
そして、このcanonicalizedフォームは唯一canonicalizedドキュメントを特定するダイジェストフォームに変換されます。 正本におけるどんなわずかな変更も非常に異なったダイジェスト値をもたらすでしょう。
Finally, the digest is then signed using a public/symmetric key algorithm which digitally stamps the digest (with the certificate of the signer if available). The final signed digest is the value which is stored within the Signature's Value element.
次に、ダイジェストをデジタルに押し込む公共の、または、左右対称の主要なアルゴリズムを使用することで最終的に、ダイジェストが署名される、(署名者の証明書、利用可能である、) 最終的な署名しているダイジェストはSignatureのValue要素の中に保存される値です。
<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
ID ID #IMPLIED >
<!要素署名(顕現、値+)><!ATTLIST署名ID ID#は>を含意しました。
Content Description
満足している記述
Manifest: A set of attributes that actually constitutes the authenticated part of the document.
以下を表してください。 実際にドキュメントの認証された部分を構成する1セットの属性。
Value: One or more encodings of signature values. Multiple values allow for a multiple algorithms to be supported within a single signature component.
値: 署名値の1encodings。 複数の値で、アルゴリズムは倍数のために単記署名コンポーネントの中でサポートします。
Attributes Description
属性記述
ID: Element identifier that may be used to reference the Signature element from a Resource element when implementing endorsement.
ID: 裏書きを実装するとき、Resource要素からSignature要素に参照をつけるのに使用されるかもしれない要素識別子。
4.3.2 Manifest
4.3.2 顕現
The Manifest element consists of a collection of attributes that specify such things as references to the resources being authenticated and an indication of the keying material and algorithms to be used.
Manifest要素は、使用されるために認証されるリソースの参照のようなものを指定する属性の収集と合わせることの材料とアルゴリズムのしるしから成ります。
Davidson & Kawatsura Informational [Page 7] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[7ページ]のRFC2802デジタル署名
<!ELEMENT Manifest
( Algorithm+,
Digest+,
Attribute*,
OriginatorInfo,
RecipientInfo+,
)
<!ATTLIST Manifest
LocatorHRefBase CDATA #IMPLIED
>
<!要素顕現(アルゴリズム+、ダイジェスト+、属性*、OriginatorInfo、RecipientInfo+)<!ATTLISTの明白なLocatorHRefBase CDATA#は>を含意しました。
Content Description
満足している記述
Algorithm: A list of algorithms used for signing, digest computation, and canonicalization.
アルゴリズム: 署名、ダイジェスト計算、およびcanonicalizationに使用されるアルゴリズムのリスト。
Digest: A list of digests of resources to be authentication and signed.
以下を読みこなしてください。 認証であって署名するべきリソースのダイジェストのリスト。
Attribute: Optional element that consists of a collection of complementary attributes to be authenticated.
以下を結果と考えてください。 認証されるために補足的な属性の収集から成る随意的な要素。
OriginatorInfo: Element that provides identification and keying material information related to the originator.
OriginatorInfo: 識別を提供する要素と物質的な情報を合わせると、創始者は関連しました。
RecipientInfo: Optional element that provides identification and keying material information related to the recipient.
RecipientInfo: 識別を提供する随意的な要素と物質的な情報を合わせると、受取人は関連しました。
Attributes Description
属性記述
LocatorHrefBase: The LocatorHrefBase provides a similar construct to the HTML HREFBASE attribute and implicitly sets all relative URL references within the Manifest to be relative to the HrefBase. For example, the IOTP Manifest may contain:
LocatorHrefBase: LocatorHrefBaseは、HTML HREFBASE属性に同様の構造物を前提として、Manifestの中のすべての相対的なURL参照にHrefBaseに比例しているようにそれとなく設定します。 例えば、IOTP Manifestは以下を含むかもしれません。
<Manifest LocatorHrefBase='iotp:<globally-unique-tid>'>
'<の明白なLocatorHrefBase=iotp: <のグローバルにユニークなtidの>'>'
And subsequent Locators may be:
そして、その後のLocatorsは以下の通りです。
<Locator href='C.9'>
<ロケータhref='C.9'>'
An implementation should concatenate the two locator references with "#" to create the entire URL. See definition of the Locator attribute on the Digest element for more detail.
実装は、全体のURLを作成するために「#」で2つのロケータ参照箇所を連結するべきです。 その他の詳細に関してDigest要素におけるLocator属性の定義を見てください。
Davidson & Kawatsura Informational [Page 8] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[8ページ]のRFC2802デジタル署名
4.3.3 Algorithm
4.3.3 アルゴリズム
This specification uses an Algorithm data type which indicates many different types of algoirithms. The Algorithm element allows for specification of sub-algorithms as parameters of the primary algorithm. This is performed via a parameter within the algorithm that provides a reference to another Algorithm. An example of this is shown in the Parameter section.
この仕様はalgoirithms Algorithm要素の多くの異なったタイプがプライマリアルゴリズムのパラメタとしてサブアルゴリズムの仕様を考慮するのを示すAlgorithmデータ型を使用します。 これは別のAlgorithmの参照を提供するアルゴリズムの中のパラメタで実行されます。 この例はParameter部で示されます。
<!ELEMENT Algorithm (Parameter*) >
<!ATTLIST Algorithm
ID ID #REQUIRED
type (digest|signature) #IMPLIED
name NMTOKEN #REQUIRED >
ATTLIST Algorithm ID ID#REQUIREDタイプ(ダイジェスト| 署名)#IMPLIEDがNMTOKEN#REQUIRED>と命名する<!ELEMENT Algorithm(パラメタ*)><!
Content Description
満足している記述
Parameter: The contents of an Algorithm element consists of an optional collection of Parameter elements which are specified on a per algorithm basis.
パラメタ: Algorithm要素のコンテンツはアルゴリズム基礎あたりのaで指定されるParameter要素の任意の収集から成ります。
Attributes Description
属性記述
ID: The ID of the algorithm is used by the Digest and RecipientInfo to refer to the signing or digest algorithm used.
ID: アルゴリズムのIDは、使用される署名かダイジェストアルゴリズムを示すのにDigestとRecipientInfoによって使用されます。
type: The type of algorithm, either a digest or signature. This is implied by the element to which the algorithm is referred. That is, if the DigestAlgorithmRef refers to an algorithm, it is implicit by reference that the targeted algorithm is a digest.
以下をタイプしてください。 アルゴリズム(ダイジェストか署名のどちらか)のタイプ。 これはアルゴリズムが参照される要素によって含意されます。 すなわち、DigestAlgorithmRefがアルゴリズムを示すなら、参照で、狙っているアルゴリズムがダイジェストであることは暗黙です。
name: The type of the algorithm expressed as a Uniform Resource Name.
以下を命名してください。 Uniform Resource Nameとして言い表されたアルゴリズムのタイプ。
4.3.4 Digest
4.3.4 ダイジェスト
The Digest element consists of the fingerprint of a given resource. This element is constructed of two sub-elements. This first one indicates the algorithm to be used for computation of the fingerprint. The second element consists of the fingerprint value.
Digest要素は与えられたリソースの指紋から成ります。 この要素は2つの下位要素について構成されます。 この最初の人は、指紋の計算に使用されるためにアルゴリズムを示します。 2番目の要素は指紋価値から成ります。
<!ELEMENT Digest (Locator, Value) >
<!ATTLIST Digest
DigestAlgorithmRef IDREF #REQUIRED
>
<!要素ダイジェスト(ロケータ、値)><!ATTLISTダイジェストDigestAlgorithmRef IDREF#は>を必要としました。
Davidson & Kawatsura Informational [Page 9] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[9ページ]のRFC2802デジタル署名
Content Description
満足している記述
Locator: Contains a "HREF" or URL Locator for the resources to be fingerprinted. For use within IOTP a "scheme" with the value "iotp" may be used with the following structure:
ロケータ: リソースが指紋を採取される"HREF"かURLロケータを含んでいます。 IOTPの中の使用のために、値の"iotp"がある「体系」は以下の構造と共に使用されるかもしれません:
'iotp:<globally-unique-tid>#<id-value>'.
'iotp: <のグローバルにユニークなtidの>#<イド価値の>'。
This should be interpreted as referring to an element with an ID attribute that matches <id-value> in any IOTP Message that has a TransRefBlk Block with an IotpTransId that matches <globally-unique- tid>.
これは、<のグローバルにユニークなtidの>に合っているIotpTransIdと共にTransRefBlk Blockを持っているどんなIOTP Messageでも<イド価値の>に合っているID属性がある要素を示しながら、解釈されるべきです。
If the LocatorHrefBase attribute is set on the Manifest element of which this Digest element is a child, then concatenate the value of the LocatorHrefBase attribute with the value of the Locator attribute before identifying the element that is being referred to.
LocatorHrefBase属性がこのDigest要素が子供であるManifest要素の上に設定されるなら、示されている要素を特定する前に、Locator属性の値でLocatorHrefBase属性の値を連結してください。
If the LocatorHrefBase attribute is omitted, <globally-unique-tid> should be interpreted as the current IotpTransId, which is included in the IOTP message which contains the Manifest component.
LocatorHrefBase属性が省略されるなら、<のグローバルにユニークなtidの>は現在のIotpTransIdとして解釈されるべきです。(IotpTransIdはManifestの部品を含むIOTPメッセージに含まれています)。
Value: Encoding of the fingerprint value.
値: 指紋価値はコード化されます。
Attributes Description
属性記述
DigestAlgorithmRef: ID Reference of algorithm used for computation of the digest.
DigestAlgorithmRef: ダイジェストの計算に使用されるアルゴリズムのID Reference。
4.3.5 Attribute
4.3.5 属性
The Attribute element consists of a complementary piece of information, which shall be included in the authenticated part of the document. This element has been defined primarily for enabling some level of customization in the signature element. This is the area where a specific IOTP implementation may include custom attributes which must be authenticated directly. An Attribute element consists of a value, a type, and a criticality.
Attribute要素は補足的な情報から成ります。(それは、ドキュメントの認証された部分に含まれているものとします)。 この要素は、主として署名要素のある程度の注文設計を可能にするために定義されました。 これは特定のIOTP実装が直接認証しなければならないカスタム属性を含むかもしれない領域です。 Attribute要素は値、タイプ、および臨界から成ります。
At this time, no IOTP specific attributes are specified.
このとき、どんなIOTPの特定の属性も指定されません。
<!ELEMENT Attribute ANY >
<!ATTLIST Attribute
type NMTOKEN #REQUIRED
critical ( true | false ) #REQUIRED
>
<!ELEMENT Attribute、><!ATTLIST AttributeタイプNMTOKEN#REQUIRED重要である、何でも(本当である、| 偽) #REQUIRED>。
Davidson & Kawatsura Informational [Page 10] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[10ページ]のRFC2802デジタル署名
Content Description
満足している記述
ANY: The actual value of an attribute depends solely upon its type.
少しも: 属性の実価は唯一タイプに頼っています。
Attributes Description
属性記述
type: Type of the attribute.
以下をタイプしてください。 属性のタイプ。
critical: Boolean value that indicates if the attribute is critical (true) or not (false). A recipient shall reject a signature that contains a critical attribute that he does not recognize. However, an unrecognized non-critical attribute may be ignored.
重要: 属性がきわどいかどうかを(本当の)(誤った)示すブール値。 受取人は彼が認めないきわどい属性を含む署名を拒絶するものとします。 しかしながら、認識されていない非臨界属性は無視されるかもしれません。
4.3.6 OriginatorInfo
4.3.6 OriginatorInfo
The OriginatorInfo element is used for providing identification and keying material information for the originator.
OriginatorInfo要素は、創始者のために識別を提供して、物質的な情報を合わせるのに使用されます。
<!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo
OriginatorRef NMTOKEN #IMPLIED
>
<!要素OriginatorInfoはあらゆる>の<!の#暗示しているATTLIST OriginatorInfo OriginatorRef NMTOKEN>です。
Content Description
満足している記述
ANY: Identification and keying material information may consist of ANY construct. Such a definition allows the adoption of application-specific schemes.
少しも: 識別と物質的な情報を合わせるのはどんな構造物からも成るかもしれません。 そのような定義はアプリケーション特有の体系の採用を許します。
Attributes Description
属性記述
OriginatorRef: A reference to the IOTP Org ID of the originating signer.
OriginatorRef: 起因する署名者のIOTP Org IDの参照。
4.3.7 RecipientInfo
4.3.7 RecipientInfo
The RecipientInfo element is used for providing identification and keying material information for the recipient. This element is used either for enabling recognition of a Signature element by a given recipient or when determination of the authentication key consists of the combination of keying material provided by both the recipient and the originator.
RecipientInfo要素は、受取人のために識別を提供して、物質的な情報を合わせるのに使用されます。 この要素は、与えられた受取人かそれとも認証キーの決断がいつ受取人と創始者の両方によって供給された合わせることの材料の組み合わせから成るか時までにSignature要素の認識を可能にするのに使用されます。
The RecipientInfo attributes provide a centralized location where signatures, algorithms, and certificates intended for a particular recipient are specified.
RecipientInfo属性は特定の受取人のために意図する署名、アルゴリズム、および証明書が指定される集結された位置を提供します。
Davidson & Kawatsura Informational [Page 11] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[11ページ]のRFC2802デジタル署名
The signature certificate reference ID MUST point to a certificate object.
署名証明書参照IDは証明書オブジェクトを示さなければなりません。
<!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo
SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #IMPLIED
SignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED
>
<!要素RecipientInfoはあらゆる>の<!のATTLIST RecipientInfo SignatureAlgorithmRef IDREFの必要な#暗示しているSignatureCertRef IDREF#暗示しているRecipientRefs NMTOKENS SignatureValueRef IDREF##暗示している>です。
Content Description
満足している記述
ANY: Identification and keying material information may consist of ANY construct.
少しも: 識別と物質的な情報を合わせるのはどんな構造物からも成るかもしれません。
Attributes Description
属性記述
SignatureAlgorithmRef: A reference to the signature algorithm used to sign the SignatureValueRef intended for this recipient. The signature algorithm reference ID MUST point to a signature algorithm within the Manifest.
SignatureAlgorithmRef: 署名アルゴリズムの参照は以前はよくこの受取人のために意図するSignatureValueRefに署名していました。 署名アルゴリズム参照IDはManifestの中に署名アルゴリズムを示さなければなりません。
SignatureValueRef: A reference to the signature value for this recipient. The signature value reference ID MUST point to a value structure directly included within a Manifest. This reference can be omitted if the application can specify the digest value.
SignatureValueRef: 署名値のこの受取人の参照。 署名値の参照IDはManifestの中に直接含まれていた価値構造を示さなければなりません。 アプリケーションがダイジェスト値を指定できるなら、この参照を省略できます。
SignatureCertRef: A reference to the certificate used to sign the Value pointed to by the SignatureValueRef. This reference can be omitted if the application can identify the certificate.
SignatureCertRef: 証明書の参照は以前はよくSignatureValueRefによって示されたValueに署名していました。 アプリケーションが証明書を特定できるなら、この参照を省略できます。
RecipientRefs: A list of references to the IOTP Org ID of the recipients this signature is intended for.
RecipientRefs: この署名が意図する受取人のIOTP Org IDへの参考文献一覧。
4.3.8 KeyIdentifier
4.3.8 KeyIdentifier
The key identifier element can identify the shared public/symmetric key identification between parties that benefit from a prior relationship. This element can be included in the ReceipientInfo Element.
主要な識別子要素は先の関係の利益を得るパーティーの間の共有された公共の、または、左右対称の主要な識別を特定できます。 ReceipientInfo Elementにこの要素を含むことができます。
<!ELEMENT KeyIdentifier EMPTY>
<!ATTLIST KeyIdentifier
value CDATA #REQUIRED
>
<!ELEMENT KeyIdentifier EMPTY><!ATTLIST KeyIdentifier値のCDATA#REQUIRED>。
Davidson & Kawatsura Informational [Page 12] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[12ページ]のRFC2802デジタル署名
4.3.9 Parameter
4.3.9 パラメタ
A Parameter element provides the value of a particular algorithm parameter, whose name and format have been specified for the algorithm considered.
Parameter要素は特定のアルゴリズムパラメタの値を提供します。(名前とパラメタの形式は考えられたアルゴリズムに指定されました)。
<!ELEMENT Parameter ANY >
<!ATTLIST Parameter
type CDATA #REQUIRED
>
<!ELEMENT Parameterはあらゆる><!ATTLIST ParameterタイプCDATA#REQUIRED>です。
For IOTP 1.0, the following parameter type is standardized: "AlgorithmRef".
IOTP1.0に関しては、以下のパラメータの型は標準化されます: "AlgorithmRef"。
An AlgorithmRef contains an ID of a "sub-Algorithm" used when computing a sequence of algorithms. For example, a signature algorithm actually signs a digest algorithm. To specify a chain of algorithms used to compute a signature, AlgorithmRef parameter types are used in the following manner:
AlgorithmRefはアルゴリズムの系列を計算するとき使用される「サブアルゴリズム」のIDを含んでいます。例えば、署名アルゴリズムは実際にダイジェストアルゴリズムに署名します。 署名を計算するのに使用されるアルゴリズムのチェーンを指定するために、AlgorithmRefパラメータの型は以下の方法で使用されます:
<Algorithm ID='A1' type='digest' name='urn:ibm-com:dom-hash'>
<Parameter type='AlgorithmRef'>A2</Parameter>
</Algorithm>
<Algorithm ID='A2' type='digest' name='urn:nist-gov:sha1'>
</Algorithm>
<Algorithm ID='A3' type='signature' name='urn:rsasdi-com:rsa-encryption'>
<Parameter type='AlgorithmRef'>A1</Parameter>
</Algorithm>
<Algorithm ID='A1' type='digest' name='urn:ibm-com:dom-hash'> <Parameter type='AlgorithmRef'>A2</Parameter> </Algorithm> <Algorithm ID='A2' type='digest' name='urn:nist-gov:sha1'> </Algorithm> <Algorithm ID='A3' type='signature' name='urn:rsasdi-com:rsa-encryption'> <Parameter type='AlgorithmRef'>A1</Parameter> </Algorithm>
Content Description
満足している記述
ANY: The contents of a Parameter element consists of ANY valid construct, which is specified on a per algorithm per parameter basis.
ANY: The contents of a Parameter element consists of ANY valid construct, which is specified on a per algorithm per parameter basis.
Attributes Description
Attributes Description
type: The type of the parameter expressed as a free form string, whose value is specified on a per algorithm basis.
type: The type of the parameter expressed as a free form string, whose value is specified on a per algorithm basis.
4.4 Certificate Component
4.4 Certificate Component
4.4.1 Certificate
4.4.1 Certificate
The Certificate element may be used for either providing the value of a digital certificate or specifying a location from where it may be retrieved.
The Certificate element may be used for either providing the value of a digital certificate or specifying a location from where it may be retrieved.
Davidson & Kawatsura Informational [Page 13] RFC 2802 Digital Signatures for IOTP April 2000
Davidson & Kawatsura Informational [Page 13] RFC 2802 Digital Signatures for IOTP April 2000
<!ELEMENT Certificate
( IssuerAndSerialNumber,
( Value | Locator ) )
>
<!ATTLIST Certificate
ID ID #IMPLIED
type NMTOKEN #REQUIRED >
<!ELEMENT Certificate ( IssuerAndSerialNumber, ( Value | Locator ) ) > <!ATTLIST Certificate ID ID #IMPLIED type NMTOKEN #REQUIRED >
Content Description
Content Description
IssuerAndSerialNumber: Unique identifier of this certificate. This element has been made mandatory is order to prevent unnecessary decoding during validation of a certificate chain. This feature also helps certificates caching, especially when the value is not directly provided.
IssuerAndSerialNumber: Unique identifier of this certificate. This element has been made mandatory is order to prevent unnecessary decoding during validation of a certificate chain. This feature also helps certificates caching, especially when the value is not directly provided.
Value: Encoding of the certificate value. The actual value to be encoded depends upon the type of the certificate.
Value: Encoding of the certificate value. The actual value to be encoded depends upon the type of the certificate.
Locator: XML link element that could be used for retrieving a copy of the digital certificate. The actual value being returned by means of this locator depends upon the security protocol being used.
Locator: XML link element that could be used for retrieving a copy of the digital certificate. The actual value being returned by means of this locator depends upon the security protocol being used.
Attributes Description
Attributes Description
ID: Element identifier that may be used to reference the Certificate element from a RecipientInfo element.
ID: Element identifier that may be used to reference the Certificate element from a RecipientInfo element.
type: Type of the digital certificate. This attribute is specified as a Universal Resource Name. Support for the X.509 version 3 certificate [X.509] is mandatory in this specification if the Certificate element is used. The URN for such certificates is "urn:X500:X509v3".
type: Type of the digital certificate. This attribute is specified as a Universal Resource Name. Support for the X.509 version 3 certificate [X.509] is mandatory in this specification if the Certificate element is used. The URN for such certificates is "urn:X500:X509v3".
4.4.2 IssuerAndSerialNumber
4.4.2 IssuerAndSerialNumber
The IssuerAndSerialNumber element identifies a certificate, and thereby an entity and a public key, by the name of the certificate issuer and an issuer-specific certificate identification.
The IssuerAndSerialNumber element identifies a certificate, and thereby an entity and a public key, by the name of the certificate issuer and an issuer-specific certificate identification.
<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber
issuer CDATA #REQUIRED
number CDATA #REQUIRED >
<!ELEMENT IssuerAndSerialNumber EMPTY > <!ATTLIST IssuerAndSerialNumber issuer CDATA #REQUIRED number CDATA #REQUIRED >
Davidson & Kawatsura Informational [Page 14] RFC 2802 Digital Signatures for IOTP April 2000
Davidson & Kawatsura Informational [Page 14] RFC 2802 Digital Signatures for IOTP April 2000
Attributes Description
Attributes Description
issuer: Name of the issuing certification authority. See [RFC 2253] for RECOMMENDED syntax.
issuer: Name of the issuing certification authority. See [RFC 2253] for RECOMMENDED syntax.
number: Issuer-specific certificate identification.
number: Issuer-specific certificate identification.
4.5 Common Components
4.5 Common Components
4.5.1 Value
4.5.1 Value
A value contains the "raw" data of a signature or digest algorithm, usually in a base-64 encoded form. See [RFC 2045] for algorithm used to base-64 encode data.
A value contains the "raw" data of a signature or digest algorithm, usually in a base-64 encoded form. See [RFC 2045] for algorithm used to base-64 encode data.
<!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
ID ID #IMPLIED
encoding (base64|none) 'base64'
>
<!ELEMENT Value ( #PCDATA ) > <!ATTLIST Value ID ID #IMPLIED encoding (base64|none) 'base64' >
Content Description
Content Description
PCDATA: Content value after adequate encoding.
PCDATA: Content value after adequate encoding.
Attributes Description
Attributes Description
encoding: This attribute specifies the decoding scheme to be employed for recovering the original byte stream from the content of the element. This document recognizes the following two schemes:
encoding: This attribute specifies the decoding scheme to be employed for recovering the original byte stream from the content of the element. This document recognizes the following two schemes:
none: the content has not been subject to any particular encoding. This does not preclude however the use of native XML encoding such as CDATA section or XML escaping.
none: the content has not been subject to any particular encoding. This does not preclude however the use of native XML encoding such as CDATA section or XML escaping.
base64: The content has been encoded by means of the base64 encoding scheme.
base64: The content has been encoded by means of the base64 encoding scheme.
4.5.2 Locator
4.5.2 Locator
The Locator element consists of simple XML link [XLink]. This element allows unambiguous reference to a resource or fragment of a resource.
The Locator element consists of simple XML link [XLink]. This element allows unambiguous reference to a resource or fragment of a resource.
<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
xml:link CDATA #FIXED 'simple'
href CDATA #REQUIRED >
<!ELEMENT Locator EMPTY> <!ATTLIST Locator xml:link CDATA #FIXED 'simple' href CDATA #REQUIRED >
Davidson & Kawatsura Informational [Page 15] RFC 2802 Digital Signatures for IOTP April 2000
Davidson & Kawatsura Informational [Page 15] RFC 2802 Digital Signatures for IOTP April 2000
Attributes Description
Attributes Description
xml:link: Required XML link attribute that specifies the nature of the link (simple in this case).
xml:link: Required XML link attribute that specifies the nature of the link (simple in this case).
href: Locator value that may contains either a URI [RFC 2396], a fragment identifier, or both.
href: Locator value that may contains either a URI [RFC 2396], a fragment identifier, or both.
5. Supported Algorithms
5. Supported Algorithms
The IOTP specification 1.0 requires the implementation of the DSA, DOM-HASH, SHA1, HMAC algorithms. Implementation of RSA is also recommended.
The IOTP specification 1.0 requires the implementation of the DSA, DOM-HASH, SHA1, HMAC algorithms. Implementation of RSA is also recommended.
5.1 Digest Algorithms
5.1 Digest Algorithms
This specification contemplates two types of digest algorithms, both of which provide a digest string as a result:
This specification contemplates two types of digest algorithms, both of which provide a digest string as a result:
Surface string digest algorithms
Surface string digest algorithms
These algorithms do not have any particular knowledge about the content being digested and operate on the raw content value. Any changes in the surface string of a given content affect directly the value of the digest being produced.
These algorithms do not have any particular knowledge about the content being digested and operate on the raw content value. Any changes in the surface string of a given content affect directly the value of the digest being produced.
Canonical digest algorithms
Canonical digest algorithms
These algorithms have been tailored for a particular content type and produce a digest value that depends upon the core semantics of such content. Changes limited to the surface string of a given content do not affect the value of the digest being produced unless they affect the core semantic.
These algorithms have been tailored for a particular content type and produce a digest value that depends upon the core semantics of such content. Changes limited to the surface string of a given content do not affect the value of the digest being produced unless they affect the core semantic.
5.1.1 SHA1
5.1.1 SHA1
Surface string digest algorithm designed by NIST and NSA for use with the Digital Signature Standard. This algorithm produces a 160-bit hash value. This algorithm is documented in NIST FIPS Publication 180-1 [SHA1].
Surface string digest algorithm designed by NIST and NSA for use with the Digital Signature Standard. This algorithm produces a 160-bit hash value. This algorithm is documented in NIST FIPS Publication 180-1 [SHA1].
This algorithm does not require any parameter.
This algorithm does not require any parameter.
The SHA1 URN used for this specification is "urn:nist-gov:sha1".
The SHA1 URN used for this specification is "urn:nist-gov:sha1".
Davidson & Kawatsura Informational [Page 16] RFC 2802 Digital Signatures for IOTP April 2000
Davidson & Kawatsura Informational [Page 16] RFC 2802 Digital Signatures for IOTP April 2000
5.1.2 DOM-HASH
5.1.2 DOM-HASH
XML canonical digest algorithm proposed by IBM Tokyo Research Laboratory. This algorithm operates on the DOM representation of the document and provides an unambiguous means for recursive computation of the hash value of the nodes that constitute the DOM tree [RFC 2803]. This algorithm has many applications such as computation of digital signature and synchronization of DOM trees. However, because the hash value of an element is computed from the hash values of the inner elements, this algorithm is better adapted to small documents that do not require one-pass processing.
XML canonical digest algorithm proposed by IBM Tokyo Research Laboratory. This algorithm operates on the DOM representation of the document and provides an unambiguous means for recursive computation of the hash value of the nodes that constitute the DOM tree [RFC 2803]. This algorithm has many applications such as computation of digital signature and synchronization of DOM trees. However, because the hash value of an element is computed from the hash values of the inner elements, this algorithm is better adapted to small documents that do not require one-pass processing.
As of today, this algorithm is limited to the contents of an XML document and, therefore, does not provide for authentication of the internal or external subset of the DTD.
As of today, this algorithm is limited to the contents of an XML document and, therefore, does not provide for authentication of the internal or external subset of the DTD.
The DOM-HASH algorithm requires a single parameter, which shall include a surface string digest algorithm such as SHA1.
The DOM-HASH algorithm requires a single parameter, which shall include a surface string digest algorithm such as SHA1.
The DOM-HASH URN used for this specification is "urn:ibm-com:dom- hash".
The DOM-HASH URN used for this specification is "urn:ibm-com:dom- hash".
The DOM-HASH uses a surface-string digest algorithm for computation of a fingerprint. The SHA1 is recommended in this specification.
The DOM-HASH uses a surface-string digest algorithm for computation of a fingerprint. The SHA1 is recommended in this specification.
Example <Algorithm name='urn:fips:sha1' type='digest' ID='P.3'> </Algorithm>
Example <Algorithm name='urn:fips:sha1' type='digest' ID='P.3'> </Algorithm>
<Algorithm name='urn:ibm:dom-hash' type='digest' ID='P.5'>
<Parameter type='AlgorithmRef'>P.3</Parameter>
</Algorithm>
<Algorithm name='urn:ibm:dom-hash' type='digest' ID='P.5'> <Parameter type='AlgorithmRef'>P.3</Parameter> </Algorithm>
5.2 Signature Algorithms
5.2 Signature Algorithms
This specification uses the terminology of 'digital signature' for qualifying indifferently digital signature and message authentication codes. Thus, the signature algorithms contemplated herein include public key digital signature algorithms such as ECDSA and message authentication codes such as HMAC [RFC 2104].
This specification uses the terminology of 'digital signature' for qualifying indifferently digital signature and message authentication codes. Thus, the signature algorithms contemplated herein include public key digital signature algorithms such as ECDSA and message authentication codes such as HMAC [RFC 2104].
5.2.1 DSA
5.2.1 DSA
Public-key signature algorithm proposed by NIST for use with the Digital Signature Standard. This standard is documented in NIST FIPS Publication 186 [DSS] and ANSI X9.30 [X9.30].
Public-key signature algorithm proposed by NIST for use with the Digital Signature Standard. This standard is documented in NIST FIPS Publication 186 [DSS] and ANSI X9.30 [X9.30].
Davidson & Kawatsura Informational [Page 17] RFC 2802 Digital Signatures for IOTP April 2000
Davidson & Kawatsura Informational [Page 17] RFC 2802 Digital Signatures for IOTP April 2000
The DSA algorithm requires a single parameter, which includes the canonical digest algorithm to be used for computing the fingerprint of the signature Manifest.
The DSA algorithm requires a single parameter, which includes the canonical digest algorithm to be used for computing the fingerprint of the signature Manifest.
The DSA URN used in this specification is "urn:nist-gov:dsa".
The DSA URN used in this specification is "urn:nist-gov:dsa".
The DSA uses a canonical or surface-string digest algorithm for computation of the Manifest fingerprint. The DOM-HASH is recommended in this specification.
The DSA uses a canonical or surface-string digest algorithm for computation of the Manifest fingerprint. The DOM-HASH is recommended in this specification.
Signature Value Encoding:
Signature Value Encoding:
The output of this algorithm consists of a pair of integers usually referred by the pair (r, s). The signature value shall consist of the concatenation of two octet-streams that respectively result from the octet-encoding of the values r and s. Integer to octet-stream conversion shall be done according to PKCS#1 [RFC 2437] specification with a k parameter equals to 20.
The output of this algorithm consists of a pair of integers usually referred by the pair (r, s). The signature value shall consist of the concatenation of two octet-streams that respectively result from the octet-encoding of the values r and s. Integer to octet-stream conversion shall be done according to PKCS#1 [RFC 2437] specification with a k parameter equals to 20.
Example
<Algorithm name='urn:nist-gov:dsa' type='signature' ID='P.3'>
<Parameter type='AlgorithmRef'>P.4</Parameter>
</Algorithm>
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5</Parameter>
</Algorithm>
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
</Algorithm>
Example <Algorithm name='urn:nist-gov:dsa' type='signature' ID='P.3'> <Parameter type='AlgorithmRef'>P.4</Parameter> </Algorithm> <Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'> <Parameter type='AlgorithmRef'>P.5</Parameter> </Algorithm> <Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'> </Algorithm>
5.2.2 HMAC
5.2.2 HMAC
Message Authentication Code proposed by H. Krawczyk et al., and documented in [RFC 2104].
Message Authentication Code proposed by H. Krawczyk et al., and documented in [RFC 2104].
This specification adopts a scheme that differs a bit from the common usage of this algorithm -- computation of the MAC is performed on the hash of the contents being authenticated instead of the actual contents. Thence, the actual signature value output by the algorithm might be depicted as follows:
This specification adopts a scheme that differs a bit from the common usage of this algorithm -- computation of the MAC is performed on the hash of the contents being authenticated instead of the actual contents. Thence, the actual signature value output by the algorithm might be depicted as follows:
SignatureValue = HMAC( SecretKey, H(Manifest))
SignatureValue = HMAC( SecretKey, H(Manifest))
This specification also considered HMAC output truncation such as proposed by Preneel and van Oorschot. In their paper [PV] these two researchers have shown some analytical advantages of truncating the output of hash-based MAC functions. Such output truncation is also considered in the RFC document.
This specification also considered HMAC output truncation such as proposed by Preneel and van Oorschot. In their paper [PV] these two researchers have shown some analytical advantages of truncating the output of hash-based MAC functions. Such output truncation is also considered in the RFC document.
Davidson & Kawatsura Informational [Page 18] RFC 2802 Digital Signatures for IOTP April 2000
Davidson & Kawatsura Informational [Page 18] RFC 2802 Digital Signatures for IOTP April 2000
HMAC requires three parameters. The first one consists of a canonical digest algorithm. The second one consists of a hash function. The last one is optional and specifies the length in bit of the truncated output. If this last parameter is absent, no truncation shall occur.
HMAC requires three parameters. The first one consists of a canonical digest algorithm. The second one consists of a hash function. The last one is optional and specifies the length in bit of the truncated output. If this last parameter is absent, no truncation shall occur.
The HMAC URN used in this specification is "urn:ietf-org:hmac".
The HMAC URN used in this specification is "urn:ietf-org:hmac".
Canonical digest algorithm: Canonical or surface-string digest algorithm is to be used for computation of the Manifest fingerprint. The type of this parameter is set to "AlgorithmRef". The recommended value of this Parameter should be the ID reference for the Algorithm element DOM-HASH.
Canonical digest algorithm: Canonical or surface-string digest algorithm is to be used for computation of the Manifest fingerprint. The type of this parameter is set to "AlgorithmRef". The recommended value of this Parameter should be the ID reference for the Algorithm element DOM-HASH.
Hash-function: Hash function is to be used to compute the MAC value from the secret key and the fingerprint of the signature Manifest. The type of this parameter is set to "HashAlgorithmRef" and the value of this parameter should be set to the ID reference for the Algorithm element of SHA1.
Hash-function: Hash function is to be used to compute the MAC value from the secret key and the fingerprint of the signature Manifest. The type of this parameter is set to "HashAlgorithmRef" and the value of this parameter should be set to the ID reference for the Algorithm element of SHA1.
Output-length: Length in bits of the truncated MAC value. The type of this parameter is set to "KeyLength" and the value of this parameter is set the length in bits of the truncated MAC value.
Output-length: Length in bits of the truncated MAC value. The type of this parameter is set to "KeyLength" and the value of this parameter is set the length in bits of the truncated MAC value.
Signature Value Encoding:
Signature Value Encoding:
The output of this algorithm can be assumed as a large integer value. The signature value shall consist of the octet-encoded value of this integer. Integer to octet-stream conversion shall be done according to PKCS#1 [RFC 2437] specification with a k parameter equals to ((Hlen +7) mod8), Mlen being the length in bits of the MAC value.
The output of this algorithm can be assumed as a large integer value. The signature value shall consist of the octet-encoded value of this integer. Integer to octet-stream conversion shall be done according to PKCS#1 [RFC 2437] specification with a k parameter equals to ((Hlen +7) mod8), Mlen being the length in bits of the MAC value.
Example
<Algorithm name='urn:ietf-org:hmac' type='signature' ID='P.3'>
<Parameter type='AlgorithmRef'>P.4</Parameter>
<Parameter type='HashAlgorithmRef'>P.5</Parameter>
<Parameter type='KeyLength'>128</Parameter>
</Algorithm>
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5</Parameter>
</Algorithm>
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
</Algorithm>
Example <Algorithm name='urn:ietf-org:hmac' type='signature' ID='P.3'> <Parameter type='AlgorithmRef'>P.4</Parameter> <Parameter type='HashAlgorithmRef'>P.5</Parameter> <Parameter type='KeyLength'>128</Parameter> </Algorithm> <Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'> <Parameter type='AlgorithmRef'>P.5</Parameter> </Algorithm> <Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'> </Algorithm>
Davidson & Kawatsura Informational [Page 19] RFC 2802 Digital Signatures for IOTP April 2000
Davidson & Kawatsura Informational [Page 19] RFC 2802 Digital Signatures for IOTP April 2000
5.2.3 RSA
5.2.3 RSA
Public-key signature algorithm proposed by RSA Laboratories and documented in PKCS#1 [RFC 2437].
Public-key signature algorithm proposed by RSA Laboratories and documented in PKCS#1 [RFC 2437].
This specification adopts the RSA encryption algorithm with padding block type 01. For computing the signature value, the signer shall first digest the signature Manifest and then encrypt the resulting digest with his private key.
This specification adopts the RSA encryption algorithm with padding block type 01. For computing the signature value, the signer shall first digest the signature Manifest and then encrypt the resulting digest with his private key.
This signature algorithm requires a single parameter, which consists of the canonical digest algorithm to be used for computing the fingerprint of the signature Manifest.
This signature algorithm requires a single parameter, which consists of the canonical digest algorithm to be used for computing the fingerprint of the signature Manifest.
Specifications
Specifications
The RSA URN used in this specification is "urn:rsasdi-com:rsa- encription".
The RSA URN used in this specification is "urn:rsasdi-com:rsa- encription".
The RSA uses a canonical or surface-string digest algorithm for computation of the Manifest fingerprint. The DOM-HASH is recommended in this specification.
The RSA uses a canonical or surface-string digest algorithm for computation of the Manifest fingerprint. The DOM-HASH is recommended in this specification.
Signature Value Encoding:
Signature Value Encoding:
The output of this algorithm consists of single octet-stream. No further encoding is required.
The output of this algorithm consists of single octet-stream. No further encoding is required.
Example
<Algorithm name='urn:rsasdi-com:rsa-encription'
type='signature' ID='P.3'>
<Parameter type='AlgorithmRef'>P.4</Parameter>
</Algorithm>
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5</Parameter>
</Algorithm>
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
</Algorithm>
Example <Algorithm name='urn:rsasdi-com:rsa-encription' type='signature' ID='P.3'> <Parameter type='AlgorithmRef'>P.4</Parameter> </Algorithm> <Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'> <Parameter type='AlgorithmRef'>P.5</Parameter> </Algorithm> <Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'> </Algorithm>
5.2.4 ECDSA
5.2.4 ECDSA
Public-key signature algorithm proposed independently by Neil Koblitz and Victor Miller. This algorithm is being proposed as an ANSI standard and is documented in ANSI X9.62 standard proposal [X9.62] and IEEE/P1363 standard draft proposal [IEEE P1363].
Public-key signature algorithm proposed independently by Neil Koblitz and Victor Miller. This algorithm is being proposed as an ANSI standard and is documented in ANSI X9.62 standard proposal [X9.62] and IEEE/P1363 standard draft proposal [IEEE P1363].
Davidson & Kawatsura Informational [Page 20] RFC 2802 Digital Signatures for IOTP April 2000
Davidson & Kawatsura Informational [Page 20] RFC 2802 Digital Signatures for IOTP April 2000
The ECDSA algorithm requires a single parameter, which consists of the canonical digest algorithm to be used for computing the fingerprint of the signature Manifest.
The ECDSA algorithm requires a single parameter, which consists of the canonical digest algorithm to be used for computing the fingerprint of the signature Manifest.
Specifications
Specifications
The ECDSA URN used in this specification is "urn:ansi-org:ecdsa".
The ECDSA URN used in this specification is "urn:ansi-org:ecdsa".
The ECDSA uses a canonical or surface-string digest algorithm for computation of the Manifest fingerprint. The DOM-HASH [RFC 2803] is recommended in this specification.
The ECDSA uses a canonical or surface-string digest algorithm for computation of the Manifest fingerprint. The DOM-HASH [RFC 2803] is recommended in this specification.
Signature Value Encoding:
Signature Value Encoding:
The output of this algorithm consists of a pair of integers usually referred by the pair (r, s). The signature value shall consist of the concatenation of two octet-streams that respectively result from the octet-encoding of the values r and s. Integer to octet-stream conversion shall be done according to PKCS#1 [RFC 2437] specification with a k parameter equals to 20.
The output of this algorithm consists of a pair of integers usually referred by the pair (r, s). The signature value shall consist of the concatenation of two octet-streams that respectively result from the octet-encoding of the values r and s. Integer to octet-stream conversion shall be done according to PKCS#1 [RFC 2437] specification with a k parameter equals to 20.
Example
<Algorithm name='urn:ansi-org:ecdsa' type='signature' ID='P.3'>
<Parameter type='AlgorithmRef'>P.4</Parameter>
</Algorithm>
<Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5</Parameter>
</Algorithm>
<Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
</Algorithm>
Example <Algorithm name='urn:ansi-org:ecdsa' type='signature' ID='P.3'> <Parameter type='AlgorithmRef'>P.4</Parameter> </Algorithm> <Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'> <Parameter type='AlgorithmRef'>P.5</Parameter> </Algorithm> <Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'> </Algorithm>
6. Examples
6. Examples
The following is an example signed IOTP message:
The following is an example signed IOTP message:
<IotpMessage>
<TransRefBlk ID='M.1'>
<TransId
ID='M.2'
version='1.0'
IotpTransID='19990809215923@www.iotp.org'
IotpTransType='BaselinePurchase'
TransTimeStamp='1999-08-09T12:58:40.000Z+9'>
</TransId>
<MsgId xml:lang='en' SoftwareID='Iotp wallet version 1.0'>
</MsgId>
</TransRefBlk>
<IotpSignatures>
<IotpMessage> <TransRefBlk ID='M.1'> <TransId ID='M.2' version='1.0' IotpTransID='19990809215923@www.iotp.org' IotpTransType='BaselinePurchase' TransTimeStamp='1999-08-09T12:58:40.000Z+9'> </TransId> <MsgId xml:lang='en' SoftwareID='Iotp wallet version 1.0'> </MsgId> </TransRefBlk> <IotpSignatures>
Davidson & Kawatsura Informational [Page 21] RFC 2802 Digital Signatures for IOTP April 2000
Davidson & Kawatsura Informational [Page 21] RFC 2802 Digital Signatures for IOTP April 2000
<Signature>
<Manifest>
<Algorithm name='urn:nist-gov:sha1'
type='digest' ID='P.3'>
</Algorithm>
<Algorithm name='urn:nist-gov:dsa'
type='signature' ID='P.4'>
<Parameter type='AlgorithmRef'>P.5</Parameter>
</Algorithm>
<Algorithm name='urn:ibm-com:dom-hash'
type='digest' ID='P.5'>
<Parameter type='AlgorithmRef'>P.3</Parameter>
</Algorithm>
<Digest DigestAlgorithmRef='P.6'>
<Locator href='P.1'/>
<Value>
xsqsfasDys2h44u4ehJDe54he5j4dJYTJ
</Value>
</Digest>
<OriginatorInfo
<IssuerAndSerialNumber
issuer='o=Iotp Ltd., c=US'
number='12345678987654'/>
</OriginatorInfo>
<RecipientInfo
SignatureAlgorithmRef='P.4'
</RecipientInfo>
</Manifest>
<Value>
9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0
</Value>
</Signature>
<Certificate type='urn:X500:X509v3'>
<IssuerAndSerialNumber
issuer='o=GlobeSet Inc., c=US'
number='123456789102356'/>
<Value>
xsqsfasDys2h44u4ehJDe54he5j4dJYTJ=
</Value>
</Certificate>
</IotpSignatures>
<PayExchBlk ID='P.1'>
<PaySchemeData
ID='P.2'
PaymentRef='M.5'
ContentSoftwareId='abcdefg'>
<PackagedContent Name='FirstPiece'>
snroasdfnas934k
<Signature> <Manifest> <Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.3'> </Algorithm> <Algorithm name='urn:nist-gov:dsa' type='signature' ID='P.4'> <Parameter type='AlgorithmRef'>P.5</Parameter> </Algorithm> <Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.5'> <Parameter type='AlgorithmRef'>P.3</Parameter> </Algorithm> <Digest DigestAlgorithmRef='P.6'> <Locator href='P.1'/> <Value> xsqsfasDys2h44u4ehJDe54he5j4dJYTJ </Value> </Digest> <OriginatorInfo <IssuerAndSerialNumber issuer='o=Iotp Ltd., c=US' number='12345678987654'/> </OriginatorInfo> <RecipientInfo SignatureAlgorithmRef='P.4' </RecipientInfo> </Manifest> <Value> 9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0 </Value> </Signature> <Certificate type='urn:X500:X509v3'> <IssuerAndSerialNumber issuer='o=GlobeSet Inc., c=US' number='123456789102356'/> <Value> xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= </Value> </Certificate> </IotpSignatures> <PayExchBlk ID='P.1'> <PaySchemeData ID='P.2' PaymentRef='M.5' ContentSoftwareId='abcdefg'> <PackagedContent Name='FirstPiece'> snroasdfnas934k
Davidson & Kawatsura Informational [Page 22] RFC 2802 Digital Signatures for IOTP April 2000
Davidson & Kawatsura Informational [Page 22] RFC 2802 Digital Signatures for IOTP April 2000
</PackagedContent>
</PaySchemeData>
</PayExchBlk>
</IotpMessage>
</PackagedContent> </PaySchemeData> </PayExchBlk> </IotpMessage>
7. Signature DTD
7. Signature DTD
<!-- ****************************************************** * IOTP SIGNATURES BLOCK DEFINITION * ****************************************************** -->
<!-- ****************************************************** * IOTP SIGNATURES BLOCK DEFINITION * ****************************************************** -->
<!ELEMENT IotpSignatures (Signature+ ,Certificate*) >
<!ATTLIST IotpSignatures
ID ID #IMPLIED
>
<!ELEMENT IotpSignatures (Signature+ ,Certificate*) > <!ATTLIST IotpSignatures ID ID #IMPLIED >
<!-- ****************************************************** * IOTP SIGNATURE COMPONENT DEFINITION * ****************************************************** -->
<!-- ****************************************************** * IOTP SIGNATURE COMPONENT DEFINITION * ****************************************************** -->
<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
ID ID #IMPLIED
>
<!ELEMENT Signature (Manifest, Value+) > <!ATTLIST Signature ID ID #IMPLIED >
<!ELEMENT Manifest
( Algorithm+,
Digest+,
Attribute*,
OriginatorInfo,
RecipientInfo+
)
>
<!ELEMENT Manifest ( Algorithm+, Digest+, Attribute*, OriginatorInfo, RecipientInfo+ ) >
<!ATTLIST Manifest
LocatorHRefBase CDATA #IMPLIED
>
<!ATTLIST Manifest LocatorHRefBase CDATA #IMPLIED >
<!ELEMENT Algorithm (Parameter*) >
<!ATTLIST Algorithm
ID ID #REQUIRED
type (digest|signature) #IMPLIED
name NMTOKEN #REQUIRED
>
<!ELEMENT Algorithm (Parameter*) > <!ATTLIST Algorithm ID ID #REQUIRED type (digest|signature) #IMPLIED name NMTOKEN #REQUIRED >
Davidson & Kawatsura Informational [Page 23] RFC 2802 Digital Signatures for IOTP April 2000
Davidson & Kawatsura Informational [Page 23] RFC 2802 Digital Signatures for IOTP April 2000
<!ELEMENT Digest (Locator, Value) >
<!ATTLIST Digest
DigestAlgorithmRef IDREF #REQUIRED
>
<!ELEMENT Digest (Locator, Value) > <!ATTLIST Digest DigestAlgorithmRef IDREF #REQUIRED >
<!ELEMENT Attribute ANY >
<!ATTLIST Attribute
type NMTOKEN #REQUIRED
critical ( true | false ) #REQUIRED
>
<!ELEMENT Attribute ANY > <!ATTLIST Attribute type NMTOKEN #REQUIRED critical ( true | false ) #REQUIRED >
<!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo
OriginatorRef NMTOKEN #IMPLIED
>
<!ELEMENT OriginatorInfo ANY > <!ATTLIST OriginatorInfo OriginatorRef NMTOKEN #IMPLIED >
<!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo
SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #IMPLIED
SignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED
>
<!ELEMENT RecipientInfo ANY > <!ATTLIST RecipientInfo SignatureAlgorithmRef IDREF #REQUIRED SignatureValueRef IDREF #IMPLIED SignatureCertRef IDREF #IMPLIED RecipientRefs NMTOKENS #IMPLIED >
<!ELEMENT KeyIdentifier EMPTY>
<!ATTLIST KeyIdentifier
value CDATA #REQUIRED
>
<!ELEMENT KeyIdentifier EMPTY> <!ATTLIST KeyIdentifier value CDATA #REQUIRED >
<!ELEMENT Parameter ANY >
<!ATTLIST Parameter
type CDATA #REQUIRED
>
<!ELEMENT Parameter ANY > <!ATTLIST Parameter type CDATA #REQUIRED >
<!-- ****************************************************** * IOTP CERTIFICATE COMPONENT DEFINITION * ****************************************************** -->
<!-- ****************************************************** * IOTP CERTIFICATE COMPONENT DEFINITION * ****************************************************** -->
<!ELEMENT Certificate
( IssuerAndSerialNumber, ( Value | Locator ) )
>
<!ELEMENT Certificate ( IssuerAndSerialNumber, ( Value | Locator ) ) >
<!ATTLIST Certificate
ID ID #IMPLIED
type NMTOKEN #REQUIRED
>
<!ATTLIST Certificate ID ID #IMPLIED type NMTOKEN #REQUIRED >
Davidson & Kawatsura Informational [Page 24] RFC 2802 Digital Signatures for IOTP April 2000
Davidson & Kawatsura Informational [Page 24] RFC 2802 Digital Signatures for IOTP April 2000
<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber
issuer CDATA #REQUIRED
number CDATA #REQUIRED
>
<!ELEMENT IssuerAndSerialNumber EMPTY > <!ATTLIST IssuerAndSerialNumber issuer CDATA #REQUIRED number CDATA #REQUIRED >
<!--
******************************************************
* IOTP SHARED COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
ID ID #IMPLIED
encoding (base64|none 'base64'
>
<!-- ****************************************************** * IOTP SHARED COMPONENT DEFINITION * ****************************************************** --> <!ELEMENT Value ( #PCDATA ) > <!ATTLIST Value ID ID #IMPLIED encoding (base64|none 'base64' >
<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
xml:link CDATA #FIXED 'simple'
href CDATA #REQUIRED
>
<!ELEMENT Locator EMPTY> <!ATTLIST Locator xml:link CDATA #FIXED 'simple' href CDATA #REQUIRED >
8. Security Considerations
8. Security Considerations
This entire document concerns the IOTP v1 protocol signature element which is used for authentication. See the Security Considerations section of [RFC 2801] "Internet Open Trading Protocol - IOTP, Version 1.0".
This entire document concerns the IOTP v1 protocol signature element which is used for authentication. See the Security Considerations section of [RFC 2801] "Internet Open Trading Protocol - IOTP, Version 1.0".
Davidson & Kawatsura Informational [Page 25] RFC 2802 Digital Signatures for IOTP April 2000
Davidson & Kawatsura Informational [Page 25] RFC 2802 Digital Signatures for IOTP April 2000
References
References
[DSA] Federal Information Processing Standards Publication
FIPS PUB 186, "Digital Signature Standard(DSS)", 1994,
<http://csrc.nist.gov>
[DSA] Federal Information Processing Standards Publication FIPS PUB 186, "Digital Signature Standard(DSS)", 1994, <http://csrc.nist.gov>
[IEEE P1363] IEEE P1363, "Standard Specifications for Public-Key
Cryptography", Work in Progress, 1997,
<http://stdsbbs.ieee.org/>
[IEEE P1363] IEEE P1363, "Standard Specifications for Public-Key Cryptography", Work in Progress, 1997, <http://stdsbbs.ieee.org/>
[PV] Preneel, B. and P. van Oorschot, "Building fast MACs
from hash functions", Advances in Cryptology --
CRYPTO'95 Proceedings, Lecture Notes in Computer
Science, Springer-Verlag Vol.963, 1995, pp. 1-14.
[PV] Preneel, B. and P. van Oorschot, "Building fast MACs from hash functions", Advances in Cryptology -- CRYPTO'95 Proceedings, Lecture Notes in Computer Science, Springer-Verlag Vol.963, 1995, pp. 1-14.
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC 2046] Freed N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC 2046] Freed N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997.
[RFC 2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC 2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC 2253] Wahl, W., Kille, S. and T. Howes, "Lightweight Directory
Access Protocol (v3): UTF-8 String Representation of
Distinguished Names", RFC 2253, December 1997.
[RFC 2253] Wahl, W., Kille, S. and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[RFC 2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC 2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
Specifications, Version 2.0", RFC 2437, October 1998.
[RFC2437] Kaliski、B.、およびJ.Staddon、「PKCS#1:」 RSA暗号仕様、バージョン2インチ、RFC2437、1998年10月。
[RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP,
Version 1.0", RFC 2801, April 2000.
[RFC2801] バーデット、D.、「2000年4月にIOTP、バージョン1インチ、RFCプロトコル--2801を取り引きする開いているインターネット。」
[RFC 2803] Maruyama, H., Tamura, K. and N. Uramot, "Digest Values
for DOM (DOMHASH)", RFC 2803, April 2000.
[RFC2803] 丸山とH.と田村とK.とN.Uramot、「ドム(DOMHASH)のためのダイジェスト値」、RFC2803、2000年4月。
Davidson & Kawatsura Informational [Page 26] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[26ページ]のRFC2802デジタル署名
[Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and
Sons
[シュナイアー]ブルース・シュナイアー、「適用された暗号:」 「C」、1996、ジョン・ワイリー、およびソンスのプロトコル、アルゴリズム、およびソースコード
[SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department
of Commerce, April 1995.
[SHA1]NIST FIPSパブ180-1、「安全な細切れ肉料理規格」、米国商務省標準技術局、米国商務省、1995年4月。
[X.509] ITU-T Recommendation X.509 (1997 E), "Information
Technology - Open Systems Interconnection - The
Directory: Authentication Framework", June 1997.
[X.509]ITU-T推薦X.509(1997E)、「情報技術--オープン・システム・インターコネクション--ディレクトリ:、」 1997年6月の「認証枠組み。」
[X9.30] ASC X9 Secretariat: American Bankers Association,
"American National Standard for Financial Services -
Public Key Cryptography Using Irreversible Algorithms
for the Financial Services Industry - Part 1: The
Digital Signature Algorithm(DSA)", 1995.
[X9.30]ASC X9事務局: アメリカ銀行家協会、「金融サービス--金融サービス業界に逆にできないアルゴリズムを使用する公開鍵暗号--第1部のための米国標準規格:」 「デジタル署名アルゴリズム(DSA)」、1995。
[X9.62] ASC X9 Secretariat: American Bankers
Association,"American National Standard for Financial
Services - Public Key Cryptography Using Irreversible
Algorithms for the Financial Services Industry - The
Elliptic Curve Digital Signature Algorithm (ECDSA)",
Work in Progress, 1997.
[X9.62]ASC X9事務局: アメリカ銀行家協会、「金融サービス--金融サービス業界に逆にできないアルゴリズムを使用する公開鍵暗号--楕円曲線デジタル署名アルゴリズム(ECDSA)のための米国標準規格」は進歩、1997年に働いています。
[XLink] Eve Maler, Steve DeRose, "XML Linking Language (XLink)",
<http://www.w3.org/TR/1998/WD-xlink-19980303>
[XLink] イブMaler、スティーブDeRose、「言語(XLink)をリンクするXML」、<http://www.w3.org/TR/1998/WD-xlink-19980303>。
[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] ティムBray、ジーン・パオリ、C.M.スペルバー-マックィーン、「拡張マークアップ言語(XML)1インチ、<http://www.w3.org/TR/1998/REC-xml-19980210>」
Davidson & Kawatsura Informational [Page 27] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[27ページ]のRFC2802デジタル署名
Authors' Addresses
作者のアドレス
The authors of this document are:
このドキュメントの作者は以下の通りです。
Kent M. Davidson Differential, Inc. 440 Clyde Ave. Mountain View, CA 94043 USA
ケントM.ディヴィッドソン特異なInc.440クライドAve。 マウンテンビュー、カリフォルニア94043米国
EMail: kent@differential.com
メール: kent@differential.com
Yoshiaki Kawatsura Hitachi, Ltd. 890-12 Kashimada Saiwai Kawasaki, Kanagawa 2128567 Japan
川崎、Yoshiaki Kawatsura日立890-12幸神奈川日本鹿島田2128567
EMail: kawatura@bisd.hitachi.co.jp
メール: kawatura@bisd.hitachi.co.jp
Davidson & Kawatsura Informational [Page 28] RFC 2802 Digital Signatures for IOTP April 2000
IOTP2000年4月のためのディヴィッドソンとKawatsuraの情報[28ページ]のRFC2802デジタル署名
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Davidson & Kawatsura Informational [Page 29]
ディヴィッドソンとKawatsura情報です。[29ページ]
一覧
スポンサーリンク
