[要約] RFC 2802は、IOTPのデジタル署名に関する規格であり、セキュアな取引プロトコルを提供することを目的としています。このRFCは、IOTPのバージョン1.0におけるデジタル署名の実装方法と利点を説明しています。
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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>
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.
David Burdett、Commerce One Andrew Drapp、Hitachi Donald Eastlake 3rd、Motorola、Inc。
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
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は、主に交換され、World Wide Webで提供されたデータの構造化を目的としています。
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メッセージの一部に対して認証と整合性サービスを必要とする多くのケースがあります。
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
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.
この仕様は、主に署名要素として知られる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>
<signature> <manifest>（リソース情報ブロック）（オリジネーター情報ブロック）（受信者情報ブロック）（その他の属性）（署名アルゴリズム情報ブロック）</manifest> <「エンコードスキーム」>（エンコードされた署名値）<値> </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".
したがって、認証は「間接」です。
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リソースへのユニークで明確な参照で構成されています。ロケーターとダイジェスト値データ自体で構成されています。Digestアルゴリズムは、DigestalgorithMrefを介して間接的に参照されているため、Digestアルゴリズムが複数のリソースで共有されるようにします。
<Digest DigestAlgorithmRef='D.1'>
<Locator href='resource locator'/>
<Value>
(Digest value)
</Value>
</Digest>
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]として実装されています。これは、内部および外部リソースのためのユニークなアドレス指定スキームを提供するだけでなく、複合ドキュメントの認証を容易にします。
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>
<cosiintientinfo>（識別情報ブロック）（キーイングマテリアル情報ブロック）</reciontientinfo>
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.
オリジネーター情報要素は必須です。受信者との以前の関係の存在または存在または非存在に応じて、このブロックはデジタル証明書などの公開資格を参照するか、受信者が知っている一意の識別子を表示します。
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.
認証キーの決定が、両当事者が提供するキーイング素材の組み合わせで構成される場合、受信者情報要素を使用することもできます。これは、たとえば、Diffie Hellman [Schneier] Key Exchangeアルゴリズムによってキーを確立する場合です。
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>
Algorithms are required to contain an ID which allows for indirect reference to them from other places in the XML signature.
アルゴリズムは、XML署名の他の場所からそれらを間接的に参照できるIDを含める必要があります。
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]を使用します。
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.
IoTPSINTURES要素は、IOTP署名ブロックのトップレベル要素です。署名要素のコレクションと、オプションの証明書セットで構成されています。
<!ELEMENT IotpSignatures (Signature+, Certificate*) >
<!ATTLIST IotpSignatures
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：承認を実装するときにリソース要素から署名要素全体を参照するために使用できる要素識別子。
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.
署名要素は、この仕様の大部分を構成します。2つのサブエレメントで構成されています。最初のものは、マニフェストとして知られる属性のセットで、実際にはドキュメントの認証された部分を構成します。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.
署名要素内に含まれる値要素は、マニフェスト要素の署名のエンコードされた形式であるため、マニフェストの検証を提供します。
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 >
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：承認を実装するときにリソース要素から署名要素を参照するために使用できる要素識別子。
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 >
<！要素マニフェスト（アルゴリズム、ダイジェスト、属性*、OriginatorInfo、ReciontientInfo、）<！ATTLIST MANIFEST 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.
ReciontientInfo：レシピエントに関連する識別およびキーイングマテリアル情報を提供するオプションの要素。
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マニフェストには以下が含まれる場合があります。
<Manifest LocatorHrefBase='iotp:<globally-unique-tid>'>
And subsequent Locators may be:
そして、後続のロケーターは次のとおりです。
<Locator 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.
実装では、2つのロケーター参照を「＃」と連結して、URL全体を作成する必要があります。詳細については、ダイジェスト要素のロケーター属性の定義を参照してください。
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.
この仕様では、アルゴリズムデータ型を使用して、さまざまな種類のアルゴリズムを示しています。アルゴリズム要素により、サブアルゴリズムをプライマリアルゴリズムのパラメーターとして指定できます。これは、別のアルゴリズムへの参照を提供するアルゴリズム内のパラメーターを介して実行されます。この例は、パラメーターセクションに示されています。
<!ELEMENT Algorithm (Parameter*) >
<!ATTLIST Algorithm
ID ID #REQUIRED
type (digest|signature) #IMPLIED
name 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は、DigestおよびRecipientInfoによって使用され、使用される署名またはDigestアルゴリズムを参照します。
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.
名前：均一なリソース名として表されるアルゴリズムのタイプ。
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つのサブエレメントで構成されています。この最初のものは、指紋の計算に使用されるアルゴリズムを示しています。2番目の要素は、指紋値で構成されています。
<!ELEMENT Digest (Locator, Value) >
<!ATTLIST Digest
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：<Globally-Unique-tid>＃<id-value>'。
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>.
これは、<Global-Unique-Tid>に一致するIoTPTransIDを使用したTransRefBlkブロックを持つIOTPメッセージの<id-Value>と一致する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属性が省略されている場合、<Globaly-Unique-TID>は、マニフェストコンポーネントを含むIOTPメッセージに含まれる現在のIoTPTransIDとして解釈する必要があります。
Value: Encoding of the fingerprint value.
値：指紋値のエンコード。
Attributes Description
属性の説明
DigestAlgorithmRef: ID Reference of algorithm used for computation of the digest.
DigestalgorithmRef：Digestの計算に使用されるアルゴリズムのID参照。
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.
属性要素は、ドキュメントの認証された部分に含まれる補完的な情報で構成されています。この要素は、主に署名要素である程度のカスタマイズを可能にするために定義されています。これは、特定のIOTP実装に直接認証する必要があるカスタム属性を含めることができる領域です。属性要素は、値、タイプ、および臨界で構成されます。
At this time, no IOTP specific attributes are specified.
現時点では、IOTP固有の属性は指定されていません。
<!ELEMENT Attribute ANY >
<!ATTLIST Attribute
type NMTOKEN #REQUIRED
critical ( true | false ) #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.
クリティカル：属性がクリティカル（真）かどうかを示すブール値（false）。受信者は、彼が認識していない重要な属性を含む署名を拒否するものとします。ただし、認識されていない非クリティカルな属性は無視される場合があります。
The OriginatorInfo element is used for providing identification and keying material information for the originator.
OriginatorInfo要素は、オリジネーターに識別およびキーイング材料情報を提供するために使用されます。
<!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.
任意：識別とキーイングの材料情報は、任意の構成要素で構成されている場合があります。このような定義により、アプリケーション固有のスキームの採用が可能になります。
Attributes Description
属性の説明
OriginatorRef: A reference to the IOTP Org ID of the originating signer.
OriginatorRef：発信元署名者のIOTP組織IDへの参照。
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.
ReciontientINFO要素は、受信者に識別およびキーイングマテリアル情報を提供するために使用されます。この要素は、特定の受信者による署名要素の認識を有効にするために、または認証キーの決定が、受信者と創始者の両方が提供するキーイング材料の組み合わせで構成されている場合に使用されます。
The RecipientInfo attributes provide a centralized location where signatures, algorithms, and certificates intended for a particular recipient are specified.
ReciontientInfo属性は、特定の受信者向けの署名、アルゴリズム、および証明書が指定されている集中的な場所を提供します。
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
>
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：この受信者向けに意図された署名ValuEREFに署名するために使用される署名アルゴリズムへの参照。署名アルゴリズムリファレンス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.
ReciintEntRefs：この署名が意図している受信者のIOTP組織IDへの参照のリスト。
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.
キー識別子要素は、以前の関係から利益を得る当事者間の共有されたパブリック/対称キー識別を識別できます。この要素は、RecepientInfo要素に含めることができます。
<!ELEMENT KeyIdentifier EMPTY>
<!ATTLIST KeyIdentifier
value CDATA #REQUIRED
>
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
>
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:
アルゴリズムは、一連のアルゴリズムを計算するときに使用される「サブアルゴリズム」のIDを含んでいます。たとえば、署名アルゴリズムは実際にダイジェストアルゴリズムに署名します。署名を計算するために使用されるアルゴリズムのチェーンを指定するために、アルゴリズムパラメータータイプは次の方法で使用されます。
<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：パラメーター要素の内容は、パラメーターごとのアルゴリズムごとに指定されている有効なコンストラクトで構成されています。
Attributes Description
属性の説明
type: The type of the parameter expressed as a free form string, whose value is specified on a per algorithm basis.
タイプ：フリーフォーム文字列として表されるパラメーターのタイプ。その値は、アルゴリズムごとに指定されています。
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 >
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：ReciontientINFO要素から証明書要素を参照するために使用できる要素識別子。
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]のサポートは、証明書要素を使用する場合、この仕様で必須です。そのような証明書のurnは「urn：x500：x509v3」です。
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 >
Attributes Description
属性の説明
issuer: Name of the issuing certification authority. See [RFC 2253] for RECOMMENDED syntax.
発行者：発行認証局の名前。推奨構文については[RFC 2253]を参照してください。
number: Issuer-specific certificate identification.
番号：発行者固有の証明書識別。
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エンコードされたフォームで、署名またはダイジェストアルゴリズムの「生」データが含まれています。[RFC 2045]を参照して、データをエンコードするために使用されるアルゴリズムを参照してください。
<!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
ID ID #IMPLIED
encoding (base64|none) '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エンコードスキームによってエンコードされています。
The Locator element consists of simple XML link [XLink]. This element allows unambiguous reference to a resource or fragment of a resource.
ロケーター要素は、単純なXMLリンク[Xlink]で構成されています。この要素により、リソースまたはリソースの断片を明確に参照できます。
<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
xml:link CDATA #FIXED 'simple'
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]、フラグメント識別子、またはその両方を含む可能性のあるロケーター値。
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の実装もお勧めします。
This specification contemplates two types of digest algorithms, both of which provide a digest string as a result:
この仕様では、2種類のダイジェストアルゴリズムを検討します。どちらも、結果としてダイジェストストリングを提供します。
Surface string digest algorithms
Surface String Digestアルゴリズム
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
標準消化アルゴリズム
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.
これらのアルゴリズムは、特定のコンテンツタイプに合わせて調整されており、そのようなコンテンツのコアセマンティクスに依存するダイジェスト値を生成します。特定のコンテンツの表面文字列に限定された変更は、コアセマンティックに影響を与えない限り、生成されるダイジェストの値に影響しません。
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].
Digital Signature Standardで使用するためにNISTおよびNSAによって設計されたSurface String Digestアルゴリズム。このアルゴリズムは、160ビットのハッシュ値を生成します。このアルゴリズムは、NIST FIPS Publication 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」です。
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.
IBM Tokyo Research Laboratoryによって提案されたXML Canonical Digestアルゴリズム。このアルゴリズムは、ドキュメントの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-HASHアルゴリズムには、SHA1などのSurface String Digestアルゴリズムを含む単一のパラメーターが必要です。
The DOM-HASH URN used for this specification is "urn:ibm-com:dom-hash".
この仕様に使用されるdom-hash urnは「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.
DOM-HASHは、指紋を計算するためにSurface-String Digestアルゴリズムを使用します。SHA1は、この仕様で推奨されます。
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>
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].
この仕様では、「デジタル署名」の用語を使用して、無関心にデジタル署名とメッセージ認証コードを適格にします。したがって、本明細書で検討されている署名アルゴリズムには、ECDSAなどの公開キーデジタル署名アルゴリズムと、HMAC [RFC 2104]などのメッセージ認証コードが含まれています。
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].
Digital Signature Standardで使用するためにNISTによって提案されたPublic-Key Signatureアルゴリズム。この標準は、NIST FIPS Publication 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は「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.
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つのオクテットストリームの連結で構成されます。Octet-Stream変換への整数は、Kパラメーターを使用したPKCS＃1 [RFC 2437]の仕様に従って、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>
Message Authentication Code proposed by H. Krawczyk et al., and documented in [RFC 2104].
H. Krawczyk et al。によって提案され、[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:
この仕様は、このアルゴリズムの一般的な使用法と少し異なるスキームを採用します。マックの計算は、実際のコンテンツではなく認証されている内容のハッシュで実行されます。そこから、アルゴリズムによる実際の署名値出力は、次のように描写される場合があります。
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.
この仕様は、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つのパラメーターが必要です。最初のものは、標準消化アルゴリズムで構成されています。2つ目はハッシュ関数で構成されています。最後のものはオプションであり、切り捨てられた出力のビットの長さを指定します。この最後のパラメーターがない場合、切り捨ては発生しません。
The HMAC URN used in this specification is "urn:ietf-org:hmac".
この仕様で使用されるHMAC URNは「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またはSurface-String Digestアルゴリズムは、マニフェストフィンガープリントの計算に使用されます。このパラメーターのタイプは、「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値を計算するために使用されます。このパラメーターのタイプは「ハスハルゴリズムのムレフ」に設定されており、このパラメーターの値は、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.
出力-Length：切り捨てられた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.
このアルゴリズムの出力は、大きな整数値として想定できます。署名値は、この整数のオクテットエンコード値で構成されます。Octet-Stream変換への整数は、Kパラメーターを使用した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>
Public-key signature algorithm proposed by RSA Laboratories and documented in PKCS#1 [RFC 2437].
RSA Laboratoriesによって提案され、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：rssdi-com：rsa-dencryption」です。
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>
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].
ニール・コブリッツとビクター・ミラーによって独立して提案されたパブリックキー署名アルゴリズム。このアルゴリズムは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:
署名値エンコーディング：
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つのオクテットストリームの連結で構成されます。Octet-Stream変換への整数は、Kパラメーターを使用したPKCS＃1 [RFC 2437]の仕様に従って、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>
The following is an example signed IOTP message:
以下は、署名されたIOTPメッセージの例です。
<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>
<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
</PackagedContent>
</PaySchemeData>
</PayExchBlk>
</IotpMessage>
<!--
******************************************************
* IOTP SIGNATURES BLOCK DEFINITION *
******************************************************
-->
<!ELEMENT IotpSignatures (Signature+ ,Certificate*) >
<!ATTLIST IotpSignatures
ID ID #IMPLIED
>
<!--
******************************************************
* IOTP SIGNATURE COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
ID ID #IMPLIED
>
<!ELEMENT Manifest ( Algorithm+, Digest+, Attribute*, OriginatorInfo, RecipientInfo+ ) >
<！要素マニフェスト（アルゴリズム、ダイジェスト、属性*、OriginatorInfo、ReciontientInfo）>
<!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 Digest (Locator, Value) >
<!ATTLIST Digest
DigestAlgorithmRef IDREF #REQUIRED
>
<!ELEMENT Attribute ANY >
<!ATTLIST Attribute
type NMTOKEN #REQUIRED
critical ( true | false ) #REQUIRED
>
<!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 KeyIdentifier EMPTY>
<!ATTLIST KeyIdentifier
value CDATA #REQUIRED
>
<!ELEMENT Parameter ANY >
<!ATTLIST Parameter
type CDATA #REQUIRED
>
<!--
******************************************************
* IOTP CERTIFICATE COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Certificate ( IssuerAndSerialNumber, ( Value | Locator ) ) >
<！要素証明書（発行者andSerialNumber、（value | locator））>
<!ATTLIST Certificate
ID ID #IMPLIED
type NMTOKEN #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'
>
<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
xml:link CDATA #FIXED 'simple'
href CDATA #REQUIRED
>
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".
このドキュメント全体は、認証に使用されるIOTP V1プロトコル署名要素に関するものです。[RFC 2801]のセキュリティに関する考慮事項セクション「インターネットオープントレーディングプロトコル-IOTP、バージョン1.0」を参照してください。
References
参考文献
[DSA] Federal Information Processing Standards Publication FIPS PUB 186, "Digital Signature Standard(DSS)", 1994, <http://csrc.nist.gov>
[DSA]連邦情報処理標準出版物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、「パブリックキー暗号化の標準仕様」、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。およびP. Van Oorschot、「ハッシュ関数からの高速MACの構築」、暗号学の進歩 - 暗号'95議事録、コンピューターサイエンスの講義ノート、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。、「MD5メッセージダイジストアルゴリズム」、RFC 1321、1992年4月。
[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。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[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、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[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。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC 2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC 2141] Moats、R。、「Urn Syntax」、RFC 2141、1997年5月。
[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。、およびT. Howes、「Lightweight Directory Access Protocol（V3）：UTF-8文字列名の表現」、RFC 2253、1997年12月。
[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、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications, Version 2.0", RFC 2437, October 1998.
[RFC 2437] Kaliski、B。およびJ. Staddon、「PKCS＃1：RSA暗号仕様、バージョン2.0」、RFC 2437、1998年10月。
[RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP, Version 1.0", RFC 2801, April 2000.
[RFC 2801] Burdett、D。、「インターネットオープントレーディングプロトコル-IOTP、バージョン1.0」、RFC 2801、2000年4月。
[RFC 2803] Maruyama, H., Tamura, K. and N. Uramot, "Digest Values for DOM (DOMHASH)", RFC 2803, April 2000.
[RFC 2803] Maruyama、H.、Tamura、K。およびN. Uramot、「DOM（Domhash）のダイジェスト値」、RFC 2803、2000年4月。
[Schneier] Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C", 1996, John Wiley and Sons
[Schneier] Bruce Schneier、「適用された暗号化：プロトコル、アルゴリズム、ソースコードのC」、1996、John Wiley and Sons
[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 Pub 180-1、「Secure Hash Standard」、国立標準技術研究所、米国商務省、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（1997 e）、「情報技術 - オープンシステムの相互接続 - ディレクトリ：認証フレームワーク」、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]イブ・マラー、スティーブ・デロース、「XMLリンク言語（xlink）」、<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]ティム・ブレイ、ジャン・パオリ、C。M。スペルバー・マックーン、「拡張可能なマークアップ言語（XML）1.0」、<http://www.w3.org/tr/1998/rec-xml-19980210>
Authors' Addresses
著者のアドレス
The authors of this document are:
このドキュメントの著者は次のとおりです。
Kent M. Davidson Differential, Inc. 440 Clyde Ave. Mountain View, CA 94043 USA
Kent M. Davidson Differyial、Inc。440 Clyde Ave. Mountain View、CA 94043 USA
EMail: kent@differential.com
Yoshiaki Kawatsura Hitachi, Ltd. 890-12 Kashimada Saiwai Kawasaki, Kanagawa 2128567 Japan
吉子川岸hitachi、Ltd。890-12 Kashimada Saiwai川崎、川川2128567日本
EMail: kawatura@bisd.hitachi.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。