RFC 2802 - Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP) 日本語訳

URL : https://tools.ietf.org/html/rfc2802
タイトル : RFC 2802 - v1.0のインターネットオープン取引プロトコル（IOTP）のデジタル署名
翻訳編集 : 自動生成

Network Working Group                                        K. Davidson
Request for Comments: 2802                                  Differential
Category: Informational                                     Y. Kawatsura
                                                                 Hitachi
                                                              April 2000

Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)

v1.0のインターネットオープン取引プロトコル（IOTP）のデジタル署名

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.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2000）。全著作権所有。

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

構文および手順は、インターネットオープン取引プロトコル（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のリチャード・ブラウン社<rdbrown@GlobeSet.com>

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.

デビッド・バーデット、コマースワンアンドリューDrapp、日立ドナルドイーストレイク3日、モトローラ社

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

インターネットオープン取引プロトコル（IOTP）[RFC 2801]に記載されているようにインターネット商取引のための決済システムの独立した相互運用可能なフレームワークを提供します。すべてのIOTPメッセージはXML文書です。 XMLは、拡張マークアップ言語[XML]は、World Wide Webコンソーシアムによって公布された構文の標準です。 XMLは、構造化データを交換し、ワールド・ワイド・ウェブ上で役立った主に対象としています。

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.0 IOTPプロトコルメッセージに適用できるデジタル署名の計算と検証のための構文と手順を提案することです。

-- 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メッセージは、「改ざん防止」作ることができる、または改ざんの検出が明らかになされる手段を提供します相互運用性を実現するためには - 簡単IOTP 1.0仕様の範囲内に統合 - 最小の冗長性と軽量署名を提供 - IOTPメッセージの署名された部分が元の受信者とは異なる署名アルゴリズムを持つ別の取引ロールに「転送」することを許可します

3. Signature Basics

3.署名の基本

3.1 Signature Element

3.1 Signature要素

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

この仕様は、主にSignature要素として知られているXML要素の定義から構成されています。この要素は、2つのサブ要素から構成されています。最初のものは、使用されているリソースに一意の参照が認証されているようなものを含む署名マニフェスト、およびキーイング材料およびアルゴリズムの指標として知られている認証された属性の集合です。第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>

<署名> <マニフェスト>（リソース情報ブロック）（発信元情報ブロック）（受信者情報ブロック）（他の属性）（署名アルゴリズム情報ブロック）</マニフェスト> <値コード「コードスキーム」>（符号化された署名値）<値> </署名>

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.

デジタル署名が認証される情報の断片から直接計算されません。その代わりに、デジタル署名は認証への参照を含む属性（マニフェスト）、及びこれらの情報のダイジェストのセットから計算されます。

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.

ダイジェスト要素は、認証されているXMLリソースへのユニークで明確な参照で構成されています。これは、ロケータとダイジェスト値データそのもので構成されています。ダイジェストアルゴリズムは、複数のリソースで共有することができるように、ダイジェストアルゴリズムは、DigestAlgorithmRefを介して間接的に参照されます。

<Digest DigestAlgorithmRef='D.1'> <Locator href='resource locator'/> <Value> (Digest value) </Value> </Digest>

<ダイジェストDigestAlgorithmRef = 'D.1'> <ロケータHREF = 'リソースロケータ' /> <値>（ダイジェスト値）</値> </ダイジェスト>

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リンク[XLinkの]として実装されています。これは、内部および外部リソースのためのユニークなアドレス指定方式を提供するだけでなく、複合文書の認証を容易にするだけでなく。

3.3 Originator and Recipient Information Elements

3.3発信および受信者の情報要素

The purpose of the Originator and Recipient information elements is to provide identification and keying material for these respective parties.

発信および受信者情報要素の目的は、これらの各当事者の識別およびキーイング材料を提供することです。

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

これら二つの要素の実際の含有量は、使用されている認証方式及び有無又は当事者間の事前の関係の不存在に依存します。いくつかの状況では、識別およびキーイング材料情報を区別することは非常に困難であってもよいです。デジタル証明書に特有の基準の両方を提供します。前の関係は、当事者間に存在するとき、これはまた、口座番号のために真の立つことがあります。

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.

発信元情報要素は必須です。受信者との事前の関係の有無に応じて、このブロックは、デジタル証明書などの公的資格を指すまたは受信者によって知られている一意の識別子を表示するのいずれか。

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.

文書が複数の署名情報ブロックが含まれている場合、受信者の情報要素は、各々が特定の受信者のために意図され、使用されてもよいです。受信者情報ブロックの一意の参照は、受信者がそれぞれ署名情報ブロックを特定するのに役立ちます。

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.

認証キーの決定は、両当事者によって提供される鍵材料の組み合わせで構成されている場合、受信者の情報要素を用いてもよいです。これがケースになり、例えば、ディフィーヘルマン[シュナイアー]鍵交換アルゴリズムを用いてキーを確立するとき。

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.

アルゴリズムの要素は、署名されたIOTPメッセージ内で使用されるアルゴリズムのいずれかのタイプを置くための一般的な場所です。アルゴリズムは、署名アルゴリズムまたはダイジェストアルゴリズムであってもよいです。各アルゴリズムは、使用されるアルゴリズムに固有のパラメータが含まれています。

<Algorithm type='digest' ID='12'> (algorithm information block) </Algorithm>

<アルゴリズムTYPE = 'ダイジェスト' 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].

ここで考慮多数の型修飾子の定義に潜在的な名前の衝突を防ぐために、この仕様は統一リソース名[RFC 2141]を使用しています。

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署名ブロックの最上位の要素です。これは、署名要素のコレクション、および証明書のオプションのセットで構成されます。

<!ELEMENT IotpSignatures (Signature+, Certificate*) > <!ATTLIST IotpSignatures ID ID #IMPLIED >

<！ELEMENT IOTP署名（署名、証明書*）> <！ATTLIST IOTP署名ID ID #IMPLIED>

Content Description

コンテンツ記述

Signature: A collection of Signature elements.

署名：署名要素のコレクション。

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：承認を実装する場合、リソース要素から全体Signature要素を参照するために使用することができるエレメントID。

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のサブ要素は、署名値または値から成ります。

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要素内に含まれる値要素には、マニフェスト要素の署名の符号化された形態であり、したがって、マニフェストの検証を提供します。

The process for generating the signed value is a multi-step process, involving a canonicalization algorithm, a digest algorithm, and a signature algorithm.

署名された値を生成するためのプロセスは、正規化アルゴリズム、ダイジェストアルゴリズム、及び署名アルゴリズムを含む、多段階プロセスです。

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.

まず、マニフェストは、マニフェストのアルゴリズム要素内で指定されたアルゴリズムを用いて正規化されます。正規化形式は、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.

この正規化形式は、次に一意正規化文書を識別するダイジェスト形式に変換されます。元の文書内の任意のわずかな変更は非常に異なるダイジェスト値になります。

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.

最後に、ダイジェストは、パブリック/共通鍵暗号を用いて署名されたデジタルスタンプ（利用可能な場合、署名者の証明書を使用して）ダイジェスト。最終的な署名されたダイジェストは、署名の値要素内に格納された値です。

<!ELEMENT Signature (Manifest, Value+) > <!ATTLIST Signature ID ID #IMPLIED >

<！ELEMENT署名（マニフェスト、バリュー+）> <！ATTLIST署名ID ID #IMPLIED>

Content Description

コンテンツ記述

Manifest: A set of attributes that actually constitutes the authenticated part of the document.

マニフェスト：実際に文書の認証済みの一部を構成する属性のセット。

Value: One or more encodings of signature values. Multiple values allow for a multiple algorithms to be supported within a single signature component.

値：署名値の1つのまたは複数のエンコーディング。複数の値は、単一の署名要素内に支持される複数のアルゴリズムを可能にします。

Attributes Description

属性説明

ID: Element identifier that may be used to reference the Signature element from a Resource element when implementing endorsement.

ID：承認を実装する場合、リソース要素からSignature要素を参照するために使用することができるエレメントID。

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.

マニフェスト要素は、リソースへの参照が認証されると、キーイング材料およびアルゴリズムの表示が使用されるようなものを指定する属性の集合から成ります。

<!ELEMENT Manifest ( Algorithm+, Digest+, Attribute*, OriginatorInfo, RecipientInfo+, ) <!ATTLIST Manifest LocatorHRefBase CDATA #IMPLIED >

<！ELEMENTマニフェスト（アルゴリズム+、ダイジェスト+、属性*、OriginatorInfo、のRecipientInfo +、）<！ATTLISTマニフェストLocatorHRefBase CDATA #IMPLIED>

Content Description

コンテンツ記述

Algorithm: A list of algorithms used for signing, digest computation, and 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属性に似た構築物を提供し、暗黙的にマニフェスト内のすべての相対URL参照がHrefBaseへの相対値で設定します。例えば、IOTPマニフェストが含まれる場合があります。

<マニフェストLocatorHrefBase = 'IOTP：<グローバルにユニーク-TID>'>

And subsequent Locators may be:

そして、その後のロケータは次のようになります。

<ロケータの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つのロケータの参照を連結する必要があります。詳細についてはダイジェスト要素のロケータ属性の定義を参照してください。

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の多くの異なる種類を示しアルゴリズムデータ型を使用しています。アルゴリズムの要素は、一次アルゴリズムのパラメータとしてサブアルゴリズムの仕様を可能にします。これは、別のアルゴリズムへの参照を提供するアルゴリズム内のパラメータを介して行われます。この例は、パラメータのセクションに示されています。

<!ELEMENT Algorithm (Parameter*) > <!ATTLIST Algorithm ID ID #REQUIRED type (digest|signature) #IMPLIED name NMTOKEN #REQUIRED >

<！ELEMENTアルゴリズム（パラメータ*）> <！ATTLISTアルゴリズムID ID #REQUIREDタイプ（ダイジェスト|署名を）#IMPLIED名前NMTOKEN #REQUIRED>

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.

パラメータ：アルゴリズム要素の内容は、アルゴリズムごとに指定されたパラメータ要素の任意のコレクションで構成されています。

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は、署名を参照するか、または使用されるアルゴリズムを消化するためにダイジェストとの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.

名前：統一リソース名として表現アルゴリズムのタイプ。

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.

ダイジェスト要素は、与えられたリソースの指紋から構成されています。この要素は、2つのサブ要素から構成されています。この最初のものは、指紋の計算に使用されるアルゴリズムを示します。第二の要素は、指紋値から成ります。

<!ELEMENT Digest (Locator, Value) > <!ATTLIST Digest DigestAlgorithmRef IDREF #REQUIRED >

<！ELEMENTダイジェスト（ロケータ、バリュー）> <！ATTLISTダイジェストDigestAlgorithmRef IDREF #REQUIRED>

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>＃<ID値>'。

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ブロックを有する任意IOTPメッセージに<ID値>を一致する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属性は、このダイジェスト要素が子となっているマニフェスト要素に設定されている場合、参照されている要素を特定する前に、ロケータ属性の値と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>マニフェスト成分を含むIOTPメッセージに含まれている現在のIotpTransIdとして解釈されるべきです。

Value: Encoding of the fingerprint value.

値：指紋値のエンコーディング。

Attributes Description

属性説明

DigestAlgorithmRef: ID Reference of algorithm used for computation of the digest.

DigestAlgorithmRef：ダイジェストの計算に使用されるアルゴリズムのID参照。

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はANY属性> <！ATTLISTの属性タイプNMTOKEN #REQUIREDが重要| #REQUIRED（真偽）>

Content Description

コンテンツ記述

ANY: The actual value of an attribute depends solely upon its type.

ANY：属性の実際の値は、単にその種類に依存します。

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

The OriginatorInfo element is used for providing identification and keying material information for the originator.

OriginatorInfo要素は、発信用の材料情報を識別を提供し、キーイングのために使用されます。

<!ELEMENT OriginatorInfo ANY > <!ATTLIST OriginatorInfo OriginatorRef NMTOKEN #IMPLIED >

<！ELEMENT OriginatorInfo ANY> <！ATTLIST OriginatorInfo OriginatorRef NMTOKEN #IMPLIED>

Content Description

コンテンツ記述

ANY: Identification and keying material information may consist of ANY construct. Such a definition allows the adoption of application-specific schemes.

ANY：同定およびキーイング材料情報はANY構築物からなっていてもよいです。このような定義は、アプリケーション固有の方式を採用することができます。

Attributes Description

属性説明

OriginatorRef: A reference to the IOTP Org ID of the originating signer.

OriginatorRef：元の署名者のIOTP組織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属性は、特定の受信者のために意図署名、アルゴリズム、および証明書が指定されている集中位置を提供します。

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 >

<！ELEMENTのRecipientInfo ANY> <！ATTLISTのRecipientInfo SignatureAlgorithmRef IDREF #REQUIRED SignatureValueRef IDREF #IMPLIED SignatureCertRef IDREF #IMPLIED RecipientRefs NMTOKENS #IMPLIED>

Content Description

コンテンツ記述

ANY: Identification and keying material information may consist of ANY construct.

ANY：同定およびキーイング材料情報はANY構築物からなっていてもよいです。

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は、マニフェスト内の署名アルゴリズムを指していなければなりません。

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を直接マニフェスト内に含まれる値の構造を指していなければなりません。アプリケーションは、ダイジェスト値を指定することができた場合、この参照は、省略することができます。

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によって指さ署名するために使用される証明書を参照。アプリケーションは、証明書を識別することができた場合、この参照は、省略することができます。

RecipientRefs: A list of references to the IOTP Org ID of the recipients this signature is intended for.

RecipientRefs：このシグネチャは、のために意図された受信者のIOTP組織IDへの参照のリスト。

4.3.8 KeyIdentifier

4.3.8キー識別子

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 KeyIdentifier EMPTY> <!ATTLIST KeyIdentifier value CDATA #REQUIRED >

<！ELEMENT KeyIdentifier EMPTY> <！ATTLIST KeyIdentifier値CDATA #REQUIRED>

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.

パラメータ要素は、名前およびフォーマット考えアルゴリズムに指定された特定のアルゴリズムパラメータの値を提供します。

<!ELEMENT Parameter ANY > <!ATTLIST Parameter type CDATA #REQUIRED >

<！ELEMENTパラメーターANY> <！ATTLISTパラメータタイプCDATA #REQUIRED>

For IOTP 1.0, the following parameter type is standardized: "AlgorithmRef".

IOTP 1.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パラメータタイプは、次のように使用されています。

<アルゴリズムID = 'A1' タイプ= 'ダイジェスト' 名= 'URN：IBM-COM：DOM-ハッシュ'> <パラメータタイプ= 'AlgorithmRef'> A2 </パラメータ> </アルゴリズム> <アルゴリズムID = 'A2'タイプ= 'ダイジェスト' 名= 'URN：NIST-GOV：SHA1'> </アルゴリズム> <アルゴリズムID = 'A3' タイプは、= '署名の' name = 'URN：rsasdi-COM：RSA暗号化'> <パラメータタイプ= 'AlgorithmRef'> A1 </パラメータ> </アルゴリズム>

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：パラメータ要素の内容は、アルゴリズムごとにパラメータごとに指定されている任意の有効な構築物で構成されています。

Attributes Description

属性説明

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証明書のコンポーネント

4.4.1 Certificate

4.4.1証明書

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.

証明書の要素は、デジタル証明書の値を提供するか、検索することができる場所から場所を特定のいずれかのために使用することができます。

<!ELEMENT Certificate ( IssuerAndSerialNumber, ( Value | Locator ) ) > <!ATTLIST Certificate ID ID #IMPLIED type NMTOKEN #REQUIRED >

<！ELEMENT証明書（IssuerAndSerialNumber、（バリュー|ロケータ））> <！ATTLIST証明書ID ID #IMPLIEDタイプNMTOKEN #REQUIRED>

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：この証明書の一意の識別子。この要素は必須でなされたものであり、証明書チェーンの検証中に、不要な復号化を防止するためです。この機能は、値が直接提供されていない場合は特に、証明書のキャッシングに役立ちます。

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.

ロケータ：デジタル証明書のコピーを取得するために使用することができ、XMLのリンク要素。このロケータによって返される実際の値が使用されているセキュリティプロトコルに依存します。

Attributes Description

属性説明

ID: Element identifier that may be used to reference the Certificate element from a RecipientInfo element.

ID：のRecipientInfo要素から証明書の要素を参照するために使用することができるエレメントID。

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

タイプ：デジタル証明書のタイプ。この属性は、ユニバーサル・リソース名として指定されています。証明書要素が使用される場合X.509バージョン3証明書[X.509]のサポートは、本明細書では必須です。 "書X509v3：：X500壷" などの証明書のためのURNです。

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.

IssuerAndSerialNumber要素は、証明書発行者および発行者固有の証明書の識別名で、それによってエンティティ及び公開鍵証明書を識別し、。

<!ELEMENT IssuerAndSerialNumber EMPTY > <!ATTLIST IssuerAndSerialNumber issuer CDATA #REQUIRED number CDATA #REQUIRED >

<！ELEMENT IssuerAndSerialNumber EMPTY> <！ATTLIST IssuerAndSerialNumber発行者CDATA #REQUIRED数CDATA #REQUIRED>

Attributes Description

属性説明

issuer: Name of the issuing certification authority. See [RFC 2253] for RECOMMENDED syntax.

発行者：発行認証局の名前。推奨構文については、[RFC 2253]を参照してください。

number: Issuer-specific certificate identification.

番号：発行者固有の証明書識別。

4.5 Common Components

4.5共通コンポーネント

4.5.1 Value

4.5.1値

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.

値は、署名の「生の」データを含むか、通常ベース64符号化された形式で、ダイジェストアルゴリズム。ベース64に符号化データを使用するアルゴリズムについては[RFC 2045]参照。

<!ELEMENT Value ( #PCDATA ) > <!ATTLIST Value ID ID #IMPLIED encoding (base64|none) 'base64' >

<！ELEMENT値（#PCDATA）> <ATTLISTバリューID ID #IMPLIEDエンコーディング（base64で|なし）！ 'base64で'>

Content Description

コンテンツ記述

PCDATA: Content value after adequate encoding.

PCDATA：十分な符号化後のコンテンツ値。

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:

符号化：この属性は、要素の内容から元のバイトストリームを回復するために使用される復号方式を指定します。このドキュメントは、次の2つのスキームを認識します。

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.

なし：コンテンツは任意の特定のエンコーディングの対象とされていません。しかし、これは、このようなCDATAセクションやXMLのエスケープなどのネイティブXMLエンコーディングの使用を排除するものではありません。

base64: The content has been encoded by means of the base64 encoding scheme.

BASE64：コンテンツがBASE64符号化方式によって符号化されています。

4.5.2 Locator

4.5.2ロケータ

The Locator element consists of simple XML link [XLink]. This element allows unambiguous reference to a resource or fragment of a resource.

ロケータ要素は、[XLinkの]単純なXMLリンクから構成されています。この要素は、リソースのリソースまたはその断片に明確な参照を可能にします。

<!ELEMENT Locator EMPTY> <!ATTLIST Locator xml:link CDATA #FIXED 'simple' href CDATA #REQUIRED >

<！ELEMENTロケータEMPTY> <！ATTLISTロケータのxml：リンクCDATA #FIXED 'シンプル' のhref CDATA #REQUIRED>

Attributes Description

属性説明

xml:link: Required XML link attribute that specifies the nature of the link (simple in this case).

XML：リンク：リンク（この場合は、単純な）の性質を指定する必要XMLリンク属性。

href: Locator value that may contains either a URI [RFC 2396], a fragment identifier, or both.

HREF：かもしれないが、URI [RFC 2396]、フラグメント識別子、またはその両方のいずれかを含むロケータ値。

5. Supported Algorithms

5.サポートされるアルゴリズム

The IOTP specification 1.0 requires the implementation of the DSA, DOM-HASH, SHA1, HMAC algorithms. Implementation of RSA is also recommended.

IOTP仕様1.0は、DSA、DOM-HASH、SHA1、HMACアルゴリズムを実装する必要があります。 RSAの実装も推奨されます。

5.1 Digest Algorithms

5.1ダイジェストアルゴリズム

This specification contemplates two types of digest algorithms, both of which provide a digest string as a result:

この仕様は、結果としてのダイジェストストリングを提供どちらのダイジェストアルゴリズムの2種類を企図します。

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.

これらのアルゴリズムは、消化されているコンテンツについての特定の知識を持ち、生のコンテンツ値では動作しません。所与のコンテンツの面列の変更は、直接製造されるダイジェストの値に影響を与えます。

Canonical digest algorithms

Canonicalのダイジェストアルゴリズム

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

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

表面の文字列は、デジタル署名の標準で使用するためにNISTとNSAによって設計されたダイジェストアルゴリズム。このアルゴリズムは、160ビットのハッシュ値を生成します。このアルゴリズムは、NIST FIPSパブリケーション180-1 [SHA1]に記載されています。

This algorithm does not require any parameter.

このアルゴリズムは、任意のパラメータを必要としません。

The SHA1 URN used for this specification is "urn:nist-gov:sha1".

SHA1 URNは、この仕様のために使用される "URN：NIST-GOV：SHA1" です。

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の標準的なは、IBM東京基礎研究所が提案したアルゴリズムをダイジェスト。このアルゴリズムは、ドキュメントのDOM表現に動作し、DOMツリー[RFC 2803]構成するノードのハッシュ値の再帰的計算のための明確な手段を提供します。このアルゴリズムは、デジタル署名やDOMツリーの同期の計算などの多くの用途を有します。要素のハッシュ値は、内側要素のハッシュ値から計算されるためしかし、このアルゴリズムは、より良好なワンパス処理を必要としない小さなドキュメントに適合されます。

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.

今日のように、このアルゴリズムは、XML文書の内容に限定されており、そのため、DTDの内部または外部サブセットの認証のために提供されていません。

The DOM-HASH algorithm requires a single parameter, which shall include a surface string digest algorithm such as SHA1.

DOMハッシュアルゴリズムは、表面ストリングは、SHA1などのダイジェストアルゴリズムを含まなければならない単一のパラメータを必要とします。

The DOM-HASH URN used for this specification is "urn:ibm-com:dom-hash".

この仕様のために使用DOM-HASHのURNは、 "：IBM-COM：DOM-ハッシュURN" です。

The DOM-HASH uses a surface-string digest algorithm for computation of a fingerprint. The SHA1 is recommended in this specification.

DOM-HASHは、指紋の計算のためのアルゴリズムをダイジェスト表面文字列を使用します。 SHA1は、この仕様で推奨されています。

Example <Algorithm name='urn:fips:sha1' type='digest' ID='P.3'> </Algorithm>

例<アルゴリズム名= 'URN：FIPS：SHA1' タイプ= 'ダイジェスト' ID = 'P.3'> </アルゴリズム>

<アルゴリズム名= 'URN：IBM：DOM-ハッシュ' タイプ= 'ダイジェスト' ID = 'P.5'> <パラメータタイプ= 'AlgorithmRef'> P.3 </パラメータ> </アルゴリズム>

5.2 Signature Algorithms

5.2署名アルゴリズム

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

本明細書では区別せず、デジタル署名およびメッセージ認証コードを修飾するための「デジタル署名」の用語を使用します。したがって、本明細書で企図署名アルゴリズムは、HMAC [RFC 2104]のようなECDSAとメッセージ認証コードとして公開鍵デジタル署名アルゴリズムを含みます。

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

公開鍵署名アルゴリズムは、デジタル署名の標準で使用するためにNISTによって提案されました。この標準は、NIST FIPSパブリケーション186 [DSS]とANSI X9.30 [X9.30]に記載されています。

The DSA algorithm requires a single parameter, which includes the canonical digest algorithm to be used for computing the fingerprint of the signature Manifest.

DSAアルゴリズムは、署名マニフェストのフィンガープリントを計算するために使用される正規ダイジェストアルゴリズムを含む単一のパラメータを必要とします。

The DSA URN used in this specification is "urn:nist-gov:dsa".

本明細書中で使用されるDSAのURNは "：NIST-GOV：DSA URN" です。

The DSA uses a canonical or surface-string digest algorithm for computation of the Manifest fingerprint. The DOM-HASH is recommended in this specification.

DSAは、カノニカルまたは表面ストリングマニフェスト指紋の計算のためのダイジェストアルゴリズムを使用します。 DOM-HASHは、この仕様で推奨されます。

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.

このアルゴリズムの出力は、通常、ペア（R、S）によって参照される整数の組から成ります。署名値は、それぞれ、値rおよびsのオクテット符号化から生じる2オクテットストリームの連結で構成されなければなりません。整数オクテットストリームへの変換は、PKCS＃1 [RFC 2437]パラメータは20に等しいkの仕様に従って行われなければなりません。

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>

例<アルゴリズム名= 'URN：NIST-GOV：DSA' TYPE = '署名' ID = 'P.3'> <パラメータ・タイプ= 'AlgorithmRef'> P.4 </パラメータ> </アルゴリズム> <アルゴリズム名= 'URN：IBM-COM：DOM-ハッシュ' タイプ= 'ダイジェスト' ID = 'P.4'> <パラメータタイプ= 'AlgorithmRef'> P.5 </パラメータ> </アルゴリズム> <アルゴリズム名= 'URN： NIST-GOV：SHA1' TYPE = 'ダイジェスト' ID = 'P.5'> </アルゴリズム>

5.2.2 HMAC

Message Authentication Code proposed by H. Krawczyk et al., and documented in [RFC 2104].

メッセージ認証コード。H. Krawczykらによって提案され、[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:

この仕様は、このアルゴリズムの一般的な使用から少し異なる方式を採用 - MACの計算は、代わりに実際のコンテンツの認証されたコンテンツのハッシュに行われます。次のようにそこから、アルゴリズムによって実際の署名値出力が示されるかもしれません。

SignatureValue = HMAC( SecretKey, H(Manifest))

SignatureValue = HMAC（のSecretKey、H（マニフェスト））

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.

本明細書はまた、Preneelおよびvan Oorschotによって提案されているようにHMACの出力の切捨てを検討しました。彼らの論文[PV]では、これらの2人の研究者は、ハッシュベースのMAC機能の出力を切り詰めるのいくつかの分析の利点を示しています。このような出力の切り捨ては、RFC文書に考えられています。

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は、3つのパラメータが必要です。最初のものは正規のダイジェストアルゴリズムで構成されています。二つ目は、ハッシュ関数から成ります。最後のものはオプションであり、切り捨てられた出力のビットの長さを指定します。この最後のパラメータが存在しない場合は、切り捨てが生じてはなりません。

The HMAC URN used in this specification is "urn:ietf-org:hmac".

本明細書中で使用されるHMAC URNは "：IETF-ORG：HMAC URN" です。

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.

カノニカルダイジェストアルゴリズム：カノニカルまたは表面文字列がダイジェストアルゴリズムマニフェスト指紋の計算に使用されます。このパラメータの種類は、「AlgorithmRef」に設定されています。このパラメータの推奨値は、アルゴリズム要素DOM-HASHのID参照すべきです。

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.

ハッシュ関数：ハッシュ関数は、秘密鍵及び署名マニフェストの指紋からMAC値を計算するために使用されます。このパラメータのタイプは、「HashAlgorithmRef」に設定され、このパラメータの値は、SHA1のアルゴリズム要素のID基準に設定されるべきです。

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.

出力長：切り捨てMAC値のビット単位の長さ。このパラメータのタイプは、「KEYLENGTH」に設定されていると、このパラメーターの値は、切り捨てられたMAC値のビットの長さを設定されています。

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.

このアルゴリズムの出力は、大きな整数値として想定することができます。署名値は、この整数のオクテットでエンコードされた値で構成されなければなりません。 kパラメータは、MAC値のビット単位の長さである（（HLEN +7）mod8）、MLENに等しいと整数にオクテットストリーム変換は、PKCS＃1 [RFC 2437]の仕様に従って行われなければなりません。

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>

例<アルゴリズム名= 'URN：IETF-ORG：HMAC' TYPE = '署名' ID = 'P.3'> <パラメータ・タイプ= 'AlgorithmRef'> P.4 </パラメータ> <パラメータタイプ= 'HashAlgorithmRef'> P.5 </パラメータ> <パラメータタイプ= 'KEYLENGTH'> 128 </パラメータ> </アルゴリズム> <アルゴリズム名= 'URN：IBM-COM：DOM-ハッシュ' タイプ= 'ダイジェスト' ID = 'P.4 '> <パラメータ・タイプ=' AlgorithmRef '> P.5 </パラメータ> </アルゴリズム> <アルゴリズム名=' URN：NIST-GOV：SHA1' TYPE = 'ダイジェスト' ID = 'P.5'> </アルゴリズム>

5.2.3 RSA

Public-key signature algorithm proposed by RSA Laboratories and documented in PKCS#1 [RFC 2437].

公開鍵署名アルゴリズムは、RSA研究所によって提案され、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.

本明細書は、署名値を計算するためのパディング・ブロック・タイプ01とRSA暗号化アルゴリズムを採用し、署名者は、まずマニフェスト署名を消化した後、得られた彼の秘密鍵でダイジェストを暗号化しなければなりません。

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

仕様

The RSA URN used in this specification is "urn:rsasdi-com:rsa-encription".

RSA URNは、本明細書で使用する "URN：RSA SDI-COM：RSA暗号化" です。

The RSA uses a canonical or surface-string digest algorithm for computation of the Manifest fingerprint. The DOM-HASH is recommended in this specification.

RSAは、カノニカルまたは表面ストリングマニフェスト指紋の計算のためのダイジェストアルゴリズムを使用します。 DOM-HASHは、この仕様で推奨されます。

Signature Value Encoding:

署名値のエンコード：

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>

例<アルゴリズム名= 'URN：rsasdi-COM：RSA-encription' TYPE = '署名' ID = 'P.3'> <パラメータ・タイプ= 'AlgorithmRef'> P.4 </パラメータ> </アルゴリズム> <アルゴリズム名前= 'URN：IBM-COM：DOM-ハッシュ' タイプ=は、IDを= 'P.4'> <パラメータタイプ= 'AlgorithmRef'> P.5 </パラメータ> </アルゴリズム> <アルゴリズム名=」 'ダイジェスト' URN：NIST-GOV：SHA1' TYPE = 'ダイジェスト' ID = 'P.5'> </アルゴリズム>

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

ニールKoblitzとビクター・ミラーが独自に提案した公開鍵署名アルゴリズム。このアルゴリズムは、ANSI規格として提案されており、ANSI X9.62標準案[X9.62]及びIEEE / P1363標準案[IEEE P1363]に記載されています。

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.

ECDSAアルゴリズムはマニフェスト署名のフィンガープリントを計算するために使用される正規ダイジェストアルゴリズムから成る単一のパラメータを必要とします。

Specifications

仕様

The ECDSA URN used in this specification is "urn:ansi-org:ecdsa".

ECDSA URNは、本明細書で使用する "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.

ECDSAは、カノニカルまたは表面ストリングマニフェスト指紋の計算のためのダイジェストアルゴリズムを使用します。 DOM-HASH [RFC 2803]はこの仕様で推奨されます。

Signature Value Encoding:

署名値のエンコード：

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>

例<アルゴリズム名= 'URN：ANSI-ORG：ECDSA' TYPE = '署名' ID = 'P.3'> <パラメータ・タイプ= 'AlgorithmRef'> P.4 </パラメータ> </アルゴリズム> <アルゴリズム名= 'URN：IBM-COM：DOM-ハッシュ' タイプ= 'ダイジェスト' ID = 'P.4'> <パラメータタイプ= 'AlgorithmRef'> P.5 </パラメータ> </アルゴリズム> <アルゴリズム名= 'URN： NIST-GOV：SHA1' TYPE = 'ダイジェスト' ID = 'P.5'> </アルゴリズム>

6. Examples

6.例

The following is an example signed IOTP message:

以下はIOTPメッセージ署名された例です。

<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

<署名> <マニフェスト> <アルゴリズム名= 'URN：NIST-GOV：SHA1' TYPE = 'ダイジェスト' ID = 'P.3'> </アルゴリズム> <アルゴリズム名= 'URN：NIST-GOV：DSA' タイプ= '署名' ID = 'P.4'> <パラメータタイプ= 'AlgorithmRef'> P.5 </パラメータ> </アルゴリズム> <アルゴリズム名= 'URN：IBM-COM：DOM-ハッシュ' TYPE = 'ダイジェスト'ID =' P.5 '> <パラメータ・タイプ=' AlgorithmRef '> P.3 </パラメータ> </アルゴリズム> <ダイジェストDigestAlgorithmRef =' P.6 '> <ロケータHREF =' P.1' /> <値> xsqsfasDys2h44u4ehJDe54he5j4dJYTJ </ value>の</ダイジェスト> <OriginatorInfo <IssuerAndSerialNumber発行者= '0 = IOTP（株）、C = US' 数= '12345678987654' /> </ OriginatorInfo> <のRecipientInfo SignatureAlgorithmRef = 'P.4' </ RecipientInfo> </マニフェスト> <値> 9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0 </バリュー> </署名> <証明書の種類= 'URN：X500：書X509v3'> <IssuerAndSerialNumber発行者= '0 = GlobeSet社、C = US' 数= '123456789102356' /> <値> xsqsfasDys2h44u4ehJDe54he5j4dJYTJ = </値> </証明> </ IotpSignatures> <PayExchBlk ID = 'P.1'> <PaySchemeData ID = 'P.2' PaymentRef = 'M.5' ContentSoftwareId = 'ABCDEFG'> <PackagedContent名= 'FirstPiece'> snroasdfnas934k

</PackagedContent> </PaySchemeData> </PayExchBlk> </IotpMessage>

</ PackagedContent> </ PaySchemeData> </ PayExchBlk> </ IotpMessage>

7. Signature DTD

7.署名のDTD

<！ - ********************************************** ******** * IOTP署名ブロック定義* ************************************ ****************** - >

<!ELEMENT IotpSignatures (Signature+ ,Certificate*) > <!ATTLIST IotpSignatures ID ID #IMPLIED >

<！ELEMENT IOTP署名（署名、証明書*）> <！ATTLIST IOTP署名ID ID #IMPLIED>

<！ - ********************************************** ******** * IOTPのSIGNATUREコンポーネント定義* ************************************ ****************** - >

<!ELEMENT Signature (Manifest, Value+) > <!ATTLIST Signature ID ID #IMPLIED >

<！ELEMENT署名（マニフェスト、バリュー+）> <！ATTLIST署名ID ID #IMPLIED>

<!ELEMENT Manifest ( Algorithm+, Digest+, Attribute*, OriginatorInfo, RecipientInfo+ ) >

<！ELEMENTマニフェスト（アルゴリズム、ダイジェスト+、属性*、発信情報、のRecipientInfo）>

<!ATTLIST Manifest LocatorHRefBase CDATA #IMPLIED >

<！ATTLISTマニフェストLocatorHRefBase CDATA #IMPLIED>