[要約] RFC 7512は、PKCS #11 URIスキームに関する仕様であり、PKCS #11モジュールへのアクセスを容易にするための統一された方法を提供します。このRFCの目的は、PKCS #11モジュールへのアクセスを簡素化し、セキュリティトークンや暗号モジュールの統合を促進することです。
Internet Engineering Task Force (IETF) J. Pechanec
Request for Comments: 7512 D. Moffat
Category: Standards Track Oracle Corporation
ISSN: 2070-1721 April 2015
The PKCS #11 URI Scheme
PKCS＃11 URIスキーム
Abstract
概要
This memo specifies a PKCS #11 Uniform Resource Identifier (URI) Scheme for identifying PKCS #11 objects stored in PKCS #11 tokens and also for identifying PKCS #11 tokens, slots, or libraries. The URI scheme is based on how PKCS #11 objects, tokens, slots, and libraries are identified in "PKCS #11 v2.20: Cryptographic Token Interface Standard".
このメモは、PKCS＃11トークンに格納されているPKCS＃11オブジェクトを識別し、PKCS＃11トークン、スロット、またはライブラリを識別するためのPKCS＃11 Uniform Resource Identifier（URI）スキームを指定します。 URIスキームは、PKCS＃11オブジェクト、トークン、スロット、およびライブラリが「PKCS＃11 v2.20：暗号化トークンインターフェース標準」で識別される方法に基づいています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7512.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7512で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. PKCS #11 URI Scheme Definition ..................................4
2.1. PKCS #11 URI Scheme Name ...................................4
2.2. PKCS #11 URI Scheme Status .................................4
2.3. PKCS #11 URI Scheme Syntax .................................4
2.4. PKCS #11 URI Scheme Query Attribute Semantics ..............9
2.5. PKCS #11 URI Matching Guidelines ..........................11
2.6. PKCS #11 URI Comparison ...................................12
2.7. Generating PKCS #11 URIs ..................................14
3. Examples of PKCS #11 URIs ......................................14
4. IANA Considerations ............................................17
4.1. URI Scheme Registration ...................................17
5. Internationalization Considerations ............................18
6. Security Considerations ........................................18
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................19
Contributors ......................................................20
Authors' Addresses ................................................20
"PKCS #11 v2.20: Cryptographic Token Interface Standard" [PKCS11] specifies an API, called Cryptoki, for devices that hold cryptographic information and perform cryptographic functions. Cryptoki (pronounced "crypto-key" and short for "cryptographic token interface") follows a simple object-based approach, addressing the goals of technology independence (any kind of device may be used) and resource sharing (multiple applications may access multiple devices), presenting applications with a common, logical view of the device -- a cryptographic token.
「PKCS＃11 v2.20：Cryptographic Token Interface Standard」[PKCS11]は、暗号化情報を保持し、暗号化機能を実行するデバイス用のCryptokiと呼ばれるAPIを指定します。 Cryptoki（発音は「暗号鍵」、「暗号トークンインターフェース」の略）は、シンプルなオブジェクトベースのアプローチに従い、技術の独立性（あらゆる種類のデバイスを使用できます）とリソース共有（複数のアプリケーションが複数のデバイスにアクセスする可能性があります）の目標に取り組みます）、デバイスの一般的な論理ビューをアプリケーションに提示します-暗号トークン。
It is desirable for applications or libraries that work with PKCS #11 tokens to accept a common identifier that consumers could use to identify an existing PKCS #11 storage object in a PKCS #11 token, an existing token itself, a slot, or an existing Cryptoki library (also called a producer, module, or provider). The set of storage object types that can be stored in a PKCS #11 token includes a certificate; a data object; and a public, private, or secret key. These objects can be uniquely identifiable via the PKCS #11 URI scheme defined in this document. The set of attributes describing a storage object can contain an object label, its type, and its ID. The set of attributes that identifies a PKCS #11 token can contain a token label, manufacturer name, serial number, and token model. Attributes that can identify a slot are a slot ID, description, and manufacturer. Attributes that can identify a Cryptoki library are a library manufacturer, description, and version. Library attributes may be necessary to use if more than one Cryptoki library provides a token and/or PKCS #11 objects of the same name. A set of query attributes is provided as well.
PKCS＃11トークンを使用するアプリケーションまたはライブラリは、コンシューマがPKCS＃11トークン内の既存のPKCS＃11ストレージオブジェクト、既存のトークン自体、スロット、または既存のIDを識別するために使用できる共通の識別子を受け入れることが望ましいCryptokiライブラリ（プロデューサー、モジュール、プロバイダーとも呼ばれます）。 PKCS＃11トークンに格納できるストレージオブジェクトタイプのセットには、証明書が含まれています。データオブジェクト;公開鍵、秘密鍵、または秘密鍵。これらのオブジェクトは、このドキュメントで定義されているPKCS＃11 URIスキームを介して一意に識別できます。ストレージオブジェクトを記述する属性のセットには、オブジェクトラベル、そのタイプ、およびそのIDを含めることができます。 PKCS＃11トークンを識別する属性のセットには、トークンラベル、メーカー名、シリアル番号、およびトークンモデルを含めることができます。スロットを識別できる属性は、スロットID、説明、および製造元です。 Cryptokiライブラリを識別できる属性は、ライブラリの製造元、説明、およびバージョンです。複数のCryptokiライブラリが同じ名前のトークンやPKCS＃11オブジェクトを提供する場合は、ライブラリ属性を使用する必要がある場合があります。クエリ属性のセットも提供されます。
A PKCS #11 URI cannot identify other objects defined in the specification [PKCS11] aside from storage objects. For example, objects not identifiable by a PKCS #11 URI include a hardware feature and mechanism. Note that a Cryptoki library does not have to provide for storage objects at all. The URI can still be used to identify a specific PKCS #11 token, slot, or an API producer in such a case.
PKCS＃11 URIは、仕様[PKCS11]で定義されている、ストレージオブジェクト以外のオブジェクトを識別できません。たとえば、PKCS＃11 URIで識別できないオブジェクトには、ハードウェア機能とメカニズムが含まれています。 Cryptokiライブラリは、ストレージオブジェクトを提供する必要がないことに注意してください。そのような場合でも、URIを使用して特定のPKCS＃11トークン、スロット、またはAPIプロデューサーを識別することができます。
A subset of existing PKCS #11 structure members and object attributes was chosen to uniquely identify a PKCS #11 storage object, token, slot, or library in a configuration file, on a command line, or in a configuration property of something else. Should there be a need for a more complex information exchange on PKCS #11 entities, a different means of data marshalling should be chosen accordingly.
既存のPKCS＃11構造メンバーとオブジェクト属性のサブセットは、構成ファイル、コマンドライン、または他の構成プロパティでPKCS＃11ストレージオブジェクト、トークン、スロット、またはライブラリを一意に識別するために選択されました。 PKCS＃11エンティティでより複雑な情報交換が必要な場合は、それに応じてデータマーシャリングの別の方法を選択する必要があります。
A PKCS #11 URI is not intended to be used to create new PKCS #11 objects in tokens or to create PKCS #11 tokens. It is solely to be used to identify and work with existing storage objects, tokens, and slots through the PKCS #11 API, or to identify Cryptoki libraries themselves.
PKCS＃11 URIは、トークン内に新しいPKCS＃11オブジェクトを作成するため、またはPKCS＃11トークンを作成するために使用することを意図していません。 PKCS＃11 APIを介して既存のストレージオブジェクト、トークン、およびスロットを識別して操作するため、またはCryptokiライブラリ自体を識別するためにのみ使用されます。
The URI scheme defined in this document is designed specifically with a mapping to the PKCS #11 API in mind. The URI scheme definition uses the scheme, path, and query components defined in the "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986] document. The URI scheme does not use the hierarchical element for a naming authority in the path since the authority part could not be mapped to PKCS #11 API elements. The URI scheme does not use the fragment component.
このドキュメントで定義されているURIスキームは、特にPKCS＃11 APIへのマッピングを考慮して設計されています。 URIスキーム定義は、「Uniform Resource Identifier（URI）：Generic Syntax」[RFC3986]ドキュメントで定義されたスキーム、パス、およびクエリコンポーネントを使用します。権限部分をPKCS＃11 API要素にマップできなかったため、URIスキームはパス内の命名機関に階層要素を使用しません。 URIスキームはフラグメントコンポーネントを使用しません。
If an application has no access to a producer or producers of the PKCS #11 API, the query component module attributes can be used. However, the PKCS #11 URI consumer can always decide to provide its own adequate user interface to locate and load PKCS #11 API producers.
アプリケーションがPKCS＃11 APIの1つまたは複数のプロデューサーにアクセスできない場合、クエリコンポーネントモジュールの属性を使用できます。ただし、PKCS＃11 URIコンシューマーは常に、PKCS＃11 APIプロデューサーを見つけてロードするための独自の適切なユーザーインターフェイスを提供することを決定できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
In accordance with [RFC4395], this section provides the information required to register the PKCS #11 URI scheme.
[RFC4395]に従い、このセクションでは、PKCS＃11 URIスキームを登録するために必要な情報を提供します。
pkcs11
pkcs11
Permanent
永久
A PKCS #11 URI is a sequence of attribute value pairs separated by a semicolon that form a one-level path component, optionally followed by a query. Except for the value of the "id" attribute defined later in this section, these attribute value pairs and query components are composed entirely of textual data and therefore SHOULD all first be encoded as octets according to the UTF-8 character encoding [RFC3629], in accordance with Section 2.5 of [RFC3986]; then, only those octets that do not correspond to characters in the unreserved set or to permitted characters from the reserved set SHOULD be percent-encoded. Note that the value of the "id" attribute SHOULD NOT be encoded as UTF-8 because it can contain non-textual data, instead it SHOULD be entirely percent-encoded. See important caveats in Sections 2.5 and 5 regarding working with UTF-8 strings containing characters outside the US-ASCII character set.
PKCS＃11 URIは、セミコロンで区切られた属性値のペアのシーケンスであり、1レベルのパスコンポーネントを形成し、オプションでクエリが続きます。このセクションの後半で定義される「id」属性の値を除いて、これらの属性値のペアとクエリコンポーネントは完全にテキストデータで構成されているため、最初にすべてUTF-8文字エンコーディング[RFC3629]に従ってオクテットとしてエンコードする必要があります。 [RFC3986]のセクション2.5に準拠。次に、予約されていないセットの文字または予約されたセットの許可された文字に対応しないオクテットのみがパーセントエンコードされる必要があります。 「id」属性の値は非テキストデータを含む可能性があるため、UTF-8としてエンコードするべきではないことに注意してください。代わりに、完全にパーセントエンコードする必要があります（SHOULD）。 US-ASCII文字セット以外の文字を含むUTF-8文字列の操作に関するセクション2.5および5の重要な注意事項を参照してください。
Grammar rules "unreserved" and "pct-encoded" in the PKCS #11 URI scheme definition below are imported from [RFC3986]. As a special case, note that according to Appendix A of [RFC3986], a space must be percent-encoded.
以下のPKCS＃11 URIスキーマ定義の「予約されていない」および「pctエンコードされた」文法規則は、[RFC3986]からインポートされます。特別なケースとして、[RFC3986]の付録Aに従って、スペースはパーセントエンコードする必要があることに注意してください。
The PKCS #11 specification imposes various limitations on the value of attributes, be it a more restrictive character set for the "serial" attribute or fixed-size buffers for almost all the others, including "token", "manufacturer", and "model" attributes. The syntax of the PKCS #11 URI scheme does not impose such limitations. However, if the consumer of a PKCS #11 URI encounters values that would not be accepted by the PKCS #11 specification, it MUST refuse the URI as invalid.
PKCS＃11仕様では、「シリアル」属性のより制限的な文字セット、または「トークン」、「メーカー」、「モデル」を含む他のほとんどすべての固定サイズバッファーなど、属性の値にさまざまな制限が課されます。 "属性。 PKCS＃11 URIスキームの構文では、このような制限はありません。ただし、PKCS＃11 URIのコンシューマーがPKCS＃11仕様で受け入れられない値を検出した場合、URIを無効として拒否する必要があります。
A PKCS #11 URI takes the following form (for explanation of Augmented BNF, see [RFC5234]):
PKCS＃11 URIは次の形式を取ります（拡張BNFの説明については、[RFC5234]を参照してください）。
pk11-URI = "pkcs11:" pk11-path [ "?" pk11-query ]
; Path component and its attributes. Path may be empty.
pk11-path = [ pk11-pattr *(";" pk11-pattr) ]
pk11-pattr = pk11-token / pk11-manuf / pk11-serial /
pk11-model / pk11-lib-manuf /
pk11-lib-ver / pk11-lib-desc /
pk11-object / pk11-type / pk11-id /
pk11-slot-desc / pk11-slot-manuf /
pk11-slot-id / pk11-v-pattr
; Query component and its attributes. Query may be empty.
pk11-qattr = pk11-pin-source / pk11-pin-value /
pk11-module-name / pk11-module-path /
pk11-v-qattr
pk11-query = [ pk11-qattr *("&" pk11-qattr) ]
; Section 2.2 of [RFC3986] mandates all potentially reserved characters
; that do not conflict with actual delimiters of the URI do not have
; to be percent-encoded.
pk11-res-avail = ":" / "[" / "]" / "@" / "!" / "$" /
"'" / "(" / ")" / "*" / "+" / "," / "="
pk11-path-res-avail = pk11-res-avail / "&"
; "/" and "?" in the query component MAY be unencoded but "&" MUST
; be encoded since it functions as a delimiter within the component.
pk11-query-res-avail = pk11-res-avail / "/" / "?" / "|"
pk11-pchar = unreserved / pk11-path-res-avail / pct-encoded
pk11-qchar = unreserved / pk11-query-res-avail / pct-encoded
pk11-token = "token" "=" *pk11-pchar
pk11-manuf = "manufacturer" "=" *pk11-pchar
pk11-serial = "serial" "=" *pk11-pchar
pk11-model = "model" "=" *pk11-pchar
pk11-lib-manuf = "library-manufacturer" "=" *pk11-pchar
pk11-lib-desc = "library-description" "=" *pk11-pchar
pk11-lib-ver = "library-version" "=" 1*DIGIT [ "." 1*DIGIT ]
pk11-object = "object" "=" *pk11-pchar
pk11-type = "type" "=" ( "public" / "private" / "cert" /
"secret-key" / "data" )
pk11-id = "id" "=" *pk11-pchar
pk11-slot-manuf = "slot-manufacturer" "=" *pk11-pchar
pk11-slot-desc = "slot-description" "=" *pk11-pchar
pk11-slot-id = "slot-id" "=" 1*DIGIT
pk11-pin-source = "pin-source" "=" *pk11-qchar
pk11-pin-value = "pin-value" "=" *pk11-qchar
pk11-module-name = "module-name" "=" *pk11-qchar
pk11-module-path = "module-path" "=" *pk11-qchar
pk11-v-attr-nm-char = ALPHA / DIGIT / "-" / "_"
; The permitted value of a vendor-specific attribute is based on
; whether the attribute is used in the path or in the query.
pk11-v-pattr = 1*pk11-v-attr-nm-char "=" *pk11-pchar
pk11-v-qattr = 1*pk11-v-attr-nm-char "=" *pk11-qchar
The URI path component contains attributes that identify a resource in a one-level hierarchy provided by Cryptoki producers. The query component can contain a few attributes that may be needed to retrieve the resource identified by the URI path component. Attributes in the path component are delimited by the ';' character, attributes in the query component use '&' as a delimiter.
URIパスコンポーネントには、Cryptokiプロデューサーによって提供される1レベルの階層内のリソースを識別する属性が含まれています。クエリコンポーネントには、URIパスコンポーネントで識別されたリソースを取得するために必要ないくつかの属性を含めることができます。パスコンポーネントの属性は「;」で区切られます。文字、クエリコンポーネントの属性は区切り文字として「＆」を使用します。
Both path and query components MAY contain vendor-specific attributes. Such attribute names MUST NOT clash with existing attribute names. Note that in accordance with [BCP178], the previously used convention of starting vendor attributes with an "x-" prefix is now deprecated.
パスコンポーネントとクエリコンポーネントの両方に、ベンダー固有の属性が含まれている場合があります。そのような属性名は、既存の属性名と衝突してはなりません（MUST NOT）。 [BCP178]に従って、ベンダー属性を「x-」プレフィックスで開始するという以前に使用されていた規則は、現在は推奨されていません。
The general '/' delimiter MUST be percent-encoded in the path component so that generic URI parsers never split the path component into multiple segments. It MAY be unencoded in the query component. The delimiter '?' MUST be percent-encoded in the path component since the PKCS #11 URI scheme uses a query component. The delimiter '#' MUST be always percent-encoded so that generic URI parsers do not treat a hash as a beginning of a fragment identifier component. All other generic delimiters MAY be used unencoded (':', '[', ']', and '@') in a PKCS #11 URI.
一般的な「/」区切り文字は、パスコンポーネントでパーセントエンコードする必要があります。これにより、汎用URIパーサーがパスコンポーネントを複数のセグメントに分割することはありません。クエリコンポーネントではエンコードされていない場合があります。区切り文字「？」 PKCS＃11 URIスキームはクエリコンポーネントを使用するため、パスコンポーネントでパーセントエンコードする必要があります。デリミタ「＃」は常にパーセントエンコードする必要があるため、汎用URIパーサーはハッシュをフラグメント識別子コンポーネントの始まりとして処理しません。他のすべての汎用区切り文字は、PKCS＃11 URIでエンコードせずに使用できます（ '：'、 '['、 ']'、および '@'）。
The following table presents mapping between the PKCS #11 URI path component attributes and the PKCS #11 API structure members and object attributes. Given that PKCS #11 URI users may be quite ignorant about the PKCS #11 specification, the mapping is a product of a necessary compromise between how precisely the URI attribute names are mapped to the names in the specification and the ease of use and understanding of the URI scheme.
次の表は、PKCS＃11 URIパスコンポーネント属性とPKCS＃11 API構造メンバーおよびオブジェクト属性の間のマッピングを示しています。 PKCS＃11 URIユーザーはPKCS＃11仕様をまったく知らない可能性があるため、マッピングは、URI属性名が仕様内の名前にどの程度正確にマップされるかと、使いやすさと理解の容易さの間で必要な妥協の産物です。 URIスキーム。
+----------------------+---------------------+----------------------+
| URI component path | Attribute | PKCS #11 |
| attribute name | represents | specification |
| | | counterpart |
+----------------------+---------------------+----------------------+
| id | key identifier for | "CKA_ID" object |
| | object | attribute |
+----------------------+---------------------+----------------------+
| library-description | character-string | "libraryDescription" |
| | description of the | member of CK_INFO |
| | library | structure. It is a |
| | | UTF-8 string. |
+----------------------+---------------------+----------------------+
| library-manufacturer | ID of the Cryptoki | "manufacturerID" |
| | library | member of the |
| | manufacturer | CK_INFO structure. |
| | | It is a UTF-8 |
| | | string. |
+----------------------+---------------------+----------------------+
| library-version | Cryptoki library | "libraryVersion" |
| | version number | member of the |
| | | CK_INFO structure. |
+----------------------+---------------------+----------------------+
| manufacturer | ID of the token | "manufacturerID" |
| | manufacturer | member of |
| | | CK_TOKEN_INFO |
| | | structure. It is a |
| | | UTF-8 string. |
+----------------------+---------------------+----------------------+
| model | token model | "model" member of |
| | | CK_TOKEN_INFO |
| | | structure. It is a |
| | | UTF-8 string. |
+----------------------+---------------------+----------------------+
| object | description (name) | "CKA_LABEL" object |
| | of the object | attribute. It is a |
| | | UTF-8 string. |
+----------------------+---------------------+----------------------+
| serial | character-string | "serialNumber" |
| | serial number of | member of |
| | the token | CK_TOKEN_INFO |
| | | structure. |
+----------------------+---------------------+----------------------+
| slot-description | slot description | "slotDescription" |
| | | member of |
| | | CK_SLOT_INFO |
| | | structure. It is a |
| | | UTF-8 string. |
+----------------------+---------------------+----------------------+
| slot-id | Cryptoki-assigned | decimal number of |
| | value that | "CK_SLOT_ID" type. |
| | identifies a slot | |
+----------------------+---------------------+----------------------+
| slot-manufacturer | ID of the slot | "manufacturerID" |
| | manufacturer | member of |
| | | CK_SLOT_INFO |
| | | structure. It is a |
| | | UTF-8 string. |
+----------------------+---------------------+----------------------+
| token | application-defined | "label" member of |
| | label, assigned | the CK_TOKEN_INFO |
| | during token | structure. It is a |
| | initialization | UTF-8 string. |
+----------------------+---------------------+----------------------+
| type | object class (type) | "CKA_CLASS" object |
| | | attribute. |
+----------------------+---------------------+----------------------+
Table 1: Mapping between URI Path Component Attributes and PKCS #11 Specification Names
表1：URIパスコンポーネント属性とPKCS＃11仕様名の間のマッピング
The following table presents mapping between the "type" attribute values and corresponding PKCS #11 object classes.
次の表は、「type」属性値と対応するPKCS＃11オブジェクトクラス間のマッピングを示しています。
+-----------------+-----------------------+
| Attribute value | PKCS #11 object class |
+-----------------+-----------------------+
| cert | CKO_CERTIFICATE |
| data | CKO_DATA |
| private | CKO_PRIVATE_KEY |
| public | CKO_PUBLIC_KEY |
| secret-key | CKO_SECRET_KEY |
+-----------------+-----------------------+
Table 2: Mapping between the "type" Attribute and PKCS #11 Object Classes
表2：「type」属性とPKCS＃11オブジェクトクラス間のマッピング
The query component attribute "pin-source" specifies where the application or library should find the normal user's token PIN, the "pin-value" attribute provides the normal user's PIN value directly, if needed, and the "module-name" and "module-path" attributes modify default settings for accessing PKCS #11 providers. For the definition of a "normal user", see [PKCS11].
クエリコンポーネント属性「pin-source」は、アプリケーションまたはライブラリが通常のユーザーのトークンPINを見つける場所を指定し、「pin-value」属性は、必要に応じて通常のユーザーのPIN値を直接提供し、「module-name」と「 module-path "属性は、PKCS＃11プロバイダーにアクセスするためのデフォルト設定を変更します。 「通常のユーザー」の定義については、[PKCS11]を参照してください。
The ABNF rules above are a best-effort definition, and this paragraph specifies additional constraints. A PKCS #11 URI MUST NOT contain duplicate attributes of the same name in the URI path component. It means that each attribute may be present at most once in the PKCS #11 URI path component. Aside from the query attributes defined in this document, duplicate (vendor) attributes MAY be present in the URI query component and it is up to the URI consumer to decide on how to deal with such duplicates.
上記のABNFルールはベストエフォートの定義であり、この段落では追加の制約を指定します。 PKCS＃11 URIは、URIパスコンポーネントに同じ名前の重複した属性を含んではいけません。これは、各属性がPKCS＃11 URIパスコンポーネントに最大1回存在する可能性があることを意味します。このドキュメントで定義されているクエリ属性とは別に、重複（ベンダー）属性がURIクエリコンポーネントに存在する場合があり、そのような重複の処理方法を決定するのはURIコンシューマ次第です。
As stated earlier in this section, the value of the "id" attribute can contain non-textual data. This is because the corresponding PKCS #11 "CKA_ID" object attribute can contain arbitrary binary data.
このセクションで前述したように、「id」属性の値には非テキストデータを含めることができます。これは、対応するPKCS＃11 "CKA_ID"オブジェクト属性に任意のバイナリデータを含めることができるためです。
Therefore, the whole value of the "id" attribute SHOULD be percent-encoded.
したがって、「id」属性の値全体をパーセントでエンコードする必要があります（SHOULD）。
The "library-version" attribute represents the major and minor version number of the library and its format is "M.N". Both numbers are one byte in size; see the "libraryVersion" member of the CK_INFO structure in [PKCS11] for more information. Value "M" for the attribute MUST be interpreted as "M" for the major and "0" for the minor version of the library. If the attribute is present, the major version number is REQUIRED. Both "M" and "N" MUST be decimal numbers.
「library-version」属性は、ライブラリのメジャーバージョン番号とマイナーバージョン番号を表し、その形式は「M.N」です。どちらの数値もサイズは1バイトです。詳細については、[PKCS11]のCK_INFO構造体の「libraryVersion」メンバーを参照してください。属性の値「M」は、ライブラリのメジャーバージョンでは「M」、マイナーバージョンでは「0」として解釈する必要があります。属性が存在する場合、メジャーバージョン番号が必要です。 「M」と「N」はどちらも10進数でなければなりません。
Slot ID is a Cryptoki-assigned number that is not guaranteed to be stable across PKCS #11 module initializations. However, there are certain libraries and modules that provide stable slot identifiers. For these cases, when the slot description and manufacturer ID is not sufficient to uniquely identify a specific reader, the slot ID MAY be used to increase the precision of the token identification. In other scenarios, using the slot IDs is likely to cause usability issues.
スロットIDはCryptokiが割り当てた番号で、PKCS＃11モジュールの初期化全体で安定しているとは限りません。ただし、安定したスロット識別子を提供する特定のライブラリとモジュールがあります。これらのケースでは、スロットの説明と製造元IDが特定のリーダーを一意に識別するのに十分でない場合、スロットIDを使用してトークン識別の精度を高めることができます（MAY）。他のシナリオでは、スロットIDを使用すると、ユーザビリティの問題が発生する可能性があります。
An empty PKCS #11 URI path component attribute that does allow for an empty value matches a corresponding structure member or an object attribute with an empty value. Note that according to the PKCS #11 specification [PKCS11], empty character values in a PKCS #11 API producer must be padded with spaces and should not be NULL terminated.
空の値を許可する空のPKCS＃11 URIパスコンポーネント属性は、対応する構造体メンバーまたは空の値を持つオブジェクト属性と一致します。 PKCS＃11仕様[PKCS11]によると、PKCS＃11 APIプロデューサーの空の文字値はスペースで埋める必要があり、NULLで終了しないでください。
An application can always ask for a PIN by any means it decides to. What is more, in order not to limit PKCS #11 URI portability, the "pin-source" attribute value format and interpretation is left to be implementation specific. However, the following rules SHOULD be followed in descending order for the value of the "pin-source" attribute:
アプリケーションは、決定した方法で常にPINを要求できます。さらに、PKCS＃11 URIの移植性を制限しないために、「pin-source」属性値の形式と解釈は実装に固有のままです。ただし、「pin-source」属性の値は、降順で次の規則に従う必要があります（SHOULD）。
o If the value represents a URI, it SHOULD be treated as an object containing the PIN. Such a URI may be "file:", "https:", another PKCS #11 URI, or something else.
o 値がURIを表す場合、PINを含むオブジェクトとして扱われる必要があります（SHOULD）。そのようなURIは、「file：」、「https：」、別のPKCS＃11 URI、またはその他の何かです。
o If the value contains "|<absolute-command-path>", the implementation SHOULD read the PIN from the output of an application specified with absolute path "<absolute-command-path>". Note that character "|" representing a pipe does not have to be percent-encoded in the query component of a PKCS #11 URI.
o 値に「| <absolute-command-path>」が含まれている場合、実装は、絶対パス「<absolute-command-path>」で指定されたアプリケーションの出力からPINを読み取る必要があります（SHOULD）。文字「|」に注意してくださいパイプを表すことは、PKCS＃11 URIのクエリコンポーネントでパーセントエンコードする必要はありません。
o Interpret the value as needed in an implementation-dependent way.
o 実装依存の方法で、必要に応じて値を解釈します。
If a URI contains both "pin-source" and "pin-value" query attributes, the URI SHOULD be refused as invalid.
URIに「pin-source」と「pin-value」の両方のクエリ属性が含まれている場合、URIは無効として拒否する必要があります（SHOULD）。
Use of the "pin-value" attribute may have security-related consequences. Section 6 should be consulted before this attribute is ever used. Standard percent-encoding rules SHOULD be followed for the attribute value.
「pin-value」属性を使用すると、セキュリティ関連の結果が生じる可能性があります。この属性を使用する前に、セクション6を参照してください。属性値については、標準のパーセントエンコードルールに従う必要があります。
A consumer of PKCS #11 URIs MAY accept query component attributes "module-name" and "module-path" in order to modify default settings for accessing a PKCS #11 provider or providers.
PKCS＃11 URIのコンシューマーは、PKCS＃11プロバイダーにアクセスするためのデフォルト設定を変更するために、クエリコンポーネント属性「module-name」および「module-path」を受け入れることができます。
Processing the URI query module attributes SHOULD follow these rules:
URIクエリモジュール属性の処理は、次のルールに従う必要があります。
o The attribute "module-name" SHOULD contain a case-insensitive PKCS #11 module name (not path nor filename) without system-specific affixes; said affix could be a ".so" or ".DLL" suffix, or a "lib" prefix, for example. Not using system-specific affixes is expected to increase portability of PKCS #11 URIs among different systems. A URI consumer searching for PKCS #11 modules SHOULD use a system or application-specific locations to find modules based on the name provided in the attribute.
o 属性 "module-name"には、システム固有の接頭辞のない、大文字と小文字を区別しないPKCS＃11モジュール名（パスやファイル名ではない）を含める必要があります（SHOULD）。たとえば、接尾辞は「.so」または「.DLL」接尾辞、または「lib」接頭辞などです。システム固有の接頭辞を使用しないことで、異なるシステム間でのPKCS＃11 URIの移植性が向上すると予想されます。 PKCS＃11モジュールを検索するURIコンシューマーは、システムまたはアプリケーション固有の場所を使用して、属性で指定された名前に基づいてモジュールを検索する必要があります（SHOULD）。
o The attribute "module-path" SHOULD contain a system-specific absolute path to the PKCS #11 module or a system-specific absolute path to the directory of where PKCS #11 modules are located. For security reasons, a URI with a relative path in this attribute SHOULD be rejected.
o 属性 "module-path"には、PKCS＃11モジュールへのシステム固有の絶対パス、またはPKCS＃11モジュールが配置されているディレクトリへのシステム固有の絶対パスを含める必要があります（SHOULD）。セキュリティ上の理由から、この属性に相対パスを持つURIは拒否されるべきです（SHOULD）。
o The URI consumer MAY refuse to accept either of the attributes, or both. If use of the attribute present in the URI string is not accepted, a warning message SHOULD be presented to the provider of the URI and system-specific module locations SHOULD be used.
o URIコンシューマは、属性のいずれか、または両方を受け入れることを拒否してもよい（MAY）。 URI文字列に存在する属性の使用が受け入れられない場合は、警告メッセージをURIのプロバイダーに提示する必要があり（SHOULD）、システム固有のモジュールの場所を使用する必要があります（SHOULD）。
o If either of the module attributes is present, only those modules found matching these query attributes SHOULD be used to search for an entity represented by the URI.
o いずれかのモジュール属性が存在する場合、これらのクエリ属性に一致するモジュールのみが、URIで表されるエンティティの検索に使用されるべきです（SHOULD）。
o The use of the module attributes does not suppress matching of any other URI path component attributes present in a URI.
o モジュール属性を使用しても、URIに存在する他のURIパスコンポーネント属性のマッチングは抑制されません。
o The semantics of using both attributes in the same URI string is implementation specific but such use SHOULD be avoided. Attribute "module-name" is preferred to "module-path" due to its system-independent nature, but the latter may be more suitable for development and debugging.
o 同じURI文字列で両方の属性を使用するセマンティクスは実装固有ですが、そのような使用は避けてください。属性「module-name」は、システムに依存しない性質のため、「module-path」よりも優先されますが、後者は開発とデバッグにより適している場合があります。
o A URI MUST NOT contain multiple module attributes of the same name.
o URIには、同じ名前の複数のモジュール属性を含めることはできません。
Use of the module attributes may have security-related consequences. Section 6 should be consulted before these attributes are ever used.
モジュール属性を使用すると、セキュリティ関連の結果が生じる可能性があります。これらの属性を使用する前に、セクション6を参照してください。
A word "module" was chosen over a word "library" in these query attribute names to avoid confusion with semantically different library attributes used in the URI path component.
URIパスコンポーネントで使用される意味的に異なるライブラリ属性との混同を避けるために、これらのクエリ属性名では「ライブラリ」という単語よりも「モジュール」という単語が選ばれました。
A PKCS #11 URI can identify PKCS #11 storage objects, tokens, slots, or Cryptoki libraries. Note that since a URI may identify four different types of entities, the context within which the URI is used may be needed to determine the type. For example, a URI with only library attributes may either represent all objects in all tokens in all Cryptoki libraries identified by the URI, all tokens in those libraries, or just the libraries.
PKCS＃11 URIは、PKCS＃11ストレージオブジェクト、トークン、スロット、またはCryptokiライブラリを識別できます。 URIは4つの異なるタイプのエンティティを識別できるため、URIが使用されるコンテキストがタイプを決定するために必要になる場合があることに注意してください。たとえば、ライブラリ属性のみのURIは、URIで識別されるすべてのCryptokiライブラリのすべてのトークンのすべてのオブジェクト、それらのライブラリのすべてのトークン、またはライブラリのみを表す場合があります。
The following guidelines can help a PKCS #11 URI consumer (e.g., an application accepting PKCS #11 URIs) to match the URI with the desired resource.
次のガイドラインは、PKCS＃11 URIコンシューマー（たとえば、PKCS＃11 URIを受け入れるアプリケーション）がURIを目的のリソースと一致させるのに役立ちます。
o The consumer needs to know whether the URI is to identify PKCS #11 storage object(s), token(s), slot(s), or Cryptoki producer(s).
o コンシューマーは、URIがPKCS＃11ストレージオブジェクト、トークン、スロット、またはCryptokiプロデューサーを識別するためのものかどうかを知る必要があります。
o If the consumer is willing to accept query component module attributes, only those PKCS #11 providers matching these attributes SHOULD be worked with. See Section 2.4 for more information.
o コンシューマがクエリコンポーネントモジュールの属性を受け入れる用意がある場合は、これらの属性に一致するPKCS＃11プロバイダのみを操作する必要があります。詳細については、セクション2.4を参照してください。
o An unrecognized attribute in the URI path component, including a vendor-specific attribute, SHOULD result in an empty set of matched resources. The consumer can consider whether an error message presented to the user is appropriate in such a case.
o ベンダー固有の属性を含む、URIパスコンポーネント内の認識されない属性は、一致するリソースの空のセットを生成する必要があります（SHOULD）。消費者は、ユーザーに表示されるエラーメッセージがそのような場合に適切かどうかを検討できます。
o An unrecognized attribute in the URI query SHOULD be ignored. The consumer can consider whether a warning message presented to the user is appropriate in such a case.
o URIクエリの認識されない属性は無視してください。消費者は、ユーザーに提示される警告メッセージがそのような場合に適切であるかどうかを検討することができます。
o An attribute not present in the URI path component but known to a consumer matches everything. Each additional attribute present in the URI path component further restricts the selection.
o URIパスコンポーネントには存在しないが、コンシューマに認識されている属性は、すべてに一致します。 URIパスコンポーネントに存在する追加の各属性は、選択をさらに制限します。
o A logical extension of the above is that a URI with an empty path component matches everything. For example, if used to identify storage objects, it matches all accessible objects in all tokens provided by all relevant PKCS #11 API producers.
o 上記の論理的な拡張は、空のパスコンポーネントを持つURIがすべてに一致することです。たとえば、ストレージオブジェクトの識別に使用する場合、関連するすべてのPKCS＃11 APIプロデューサーによって提供されるすべてのトークン内のすべてのアクセス可能なオブジェクトと一致します。
o Note that use of PIN attributes may change the set of storage objects visible to the consumer.
o PIN属性を使用すると、コンシューマに表示されるストレージオブジェクトのセットが変わる可能性があることに注意してください。
o In addition to query component attributes defined in this document, vendor-specific query attributes may contain further information about how to perform the selection or other related information.
o このドキュメントで定義されているクエリコンポーネント属性に加えて、ベンダー固有のクエリ属性には、選択の実行方法やその他の関連情報に関する詳細情報が含まれている場合があります。
As noted in Section 5, the PKCS #11 specification is not clear about how to normalize UTF-8-encoded Unicode characters [RFC3629]. For that reason, it is RECOMMENDED not to use characters outside the US-ASCII character set for labels and names. However, those who discover a need to use such characters should be cautious, conservative, and expend extra effort to be sure they know what they are doing and that failure to do so may create both operational and security risks. It means that when matching UTF-8 string-based attributes (see Table 1) with characters outside the US-ASCII repertoire, normalizing all UTF-8 strings before string comparison may be the only safe approach. For example, for objects (keys), it means that PKCS #11 attribute search template would only contain attributes that are not UTF-8 strings and another pass through returned objects is then needed for UTF-8 string comparison after the normalization is applied.
セクション5で述べたように、PKCS＃11仕様では、UTF-8でエンコードされたUnicode文字を正規化する方法が明確ではありません[RFC3629]。そのため、US-ASCII文字セット以外の文字をラベルと名前に使用しないことをお勧めします。ただし、そのような文字を使用する必要性を発見した人は、慎重で保守的であり、彼らが何をしているかを確実に理解するために余分な労力を費やすべきであり、そうしないと、運用とセキュリティの両方のリスクが生じる可能性があります。つまり、UTF-8文字列ベースの属性（表1を参照）をUS-ASCIIレパートリー外の文字と照合する場合、文字列比較の前にすべてのUTF-8文字列を正規化することが唯一の安全なアプローチである可能性があります。たとえば、オブジェクト（キー）の場合、PKCS＃11属性検索テンプレートにはUTF-8文字列ではない属性のみが含まれ、正規化が適用された後、UTF-8文字列の比較には返されたオブジェクトの別のパスが必要になることを意味します。
Comparison of two URIs is a way of determining whether the URIs are equivalent without comparing the actual resource to which the URIs point. The comparison of URIs aims to minimize false negatives while strictly avoiding false positives. When working with UTF-8 strings with characters outside the US-ASCII character sets, see important caveats in Sections 2.5 and 5.
2つのURIの比較は、URIが指す実際のリソースを比較することなく、URIが同等かどうかを判断する方法です。 URIの比較は、偽陽性を厳密に回避しながら偽陰性を最小限に抑えることを目的としています。 US-ASCII文字セット以外の文字を含むUTF-8文字列を操作する場合は、セクション2.5および5の重要な警告を参照してください。
Two PKCS #11 URIs are said to be equal if URIs as character strings are identical as specified in Section 6.2.1 of [RFC3986], or if both of the following rules are fulfilled:
2つのPKCS＃11 URIは、文字列としてのURIが[RFC3986]のセクション6.2.1で指定されているものと同一である場合、または次の両方のルールが満たされている場合、等しいと見なされます。
o The set of attributes present in the URI is equal. Note that the ordering of attributes in the URI string is not significant for the mechanism of comparison.
o URIに存在する属性のセットは同じです。 URIストリング内の属性の順序は、比較メカニズムにとって重要ではないことに注意してください。
o The values of respective attributes are equal based on rules specified below
o 以下に指定されたルールに基づいて、各属性の値は等しい
The rules for comparing values of respective attributes are:
各属性の値を比較するためのルールは次のとおりです。
o The values of path component attributes "library-description", "library-manufacturer", "manufacturer", "model", "object", "serial", "slot-description", "slot-manufacturer", "token", "type", and the query component attribute "module-name" MUST be compared using a simple string comparison, as specified in Section 6.2.1 of [RFC3986], after the case and the percent-encoding normalization were both applied as specified in Section 6.2.2 of [RFC3986].
o パスコンポーネント属性の値「library-description」、「library-manufacturer」、「manufacturer」、「model」、「object」、「serial」、「slot-description」、「slot-manufacturer」、「token」、 「type」とクエリコンポーネント属性「module-name」は、[RFC3986]のセクション6.2.1で指定されているように、ケースとパーセントエンコーディングの正規化の両方が、 [RFC3986]のセクション6.2.2。
o The value of the attribute "id" MUST be compared using the simple string comparison after all bytes are percent-encoded using uppercase letters for digits A-F.
o 属性 "id"の値は、すべてのバイトが数字A〜Fに大文字を使用してパーセントエンコードされた後、単純な文字列比較を使用して比較する必要があります。
o The value of the attribute "library-version" MUST be processed as a specific scheme-based normalization permitted by Section 6.2.3 of [RFC3986]. The value MUST be split into a major and minor version with character '.' (dot) serving as a delimiter. A library-version "M" MUST be treated as "M" for the major version and "0" for the minor version. Then, resulting minor and major version numbers MUST be separately compared numerically.
o 属性「library-version」の値は、[RFC3986]のセクション6.2.3で許可されている特定のスキームベースの正規化として処理する必要があります。値は、文字「。」を使用してメジャーバージョンとマイナーバージョンに分割する必要があります。 （ドット）区切り文字として機能します。ライブラリバージョンの「M」は、メジャーバージョンの場合は「M」、マイナーバージョンの場合は「0」として扱う必要があります。次に、結果のマイナーバージョン番号とメジャーバージョン番号を別々に数値で比較する必要があります。
o The value of the attribute "slot-id" MUST be processed as a specific scheme-based normalization permitted by Section 6.2.3 of [RFC3986] and compared numerically.
o 属性「slot-id」の値は、[RFC3986]のセクション6.2.3で許可されている特定のスキームベースの正規化として処理され、数値で比較される必要があります。
o The value of "pin-source", if containing a "file:" URI or "|<absolute-command-path>", MUST be compared using the simple string comparison after the full syntax-based normalization, as specified in Section 6.2.2 of [RFC3986], is applied. If the value of the "pin-source" attribute is believed to be overloaded, the case and percent-encoding normalization SHOULD be applied before the values are compared, but the exact mechanism of comparison is left to the application.
o 「file：」URIまたは「| <absolute-command-path>」が含まれている場合、「pin-source」の値は、セクション6.2で指定されているように、完全な構文ベースの正規化の後に単純な文字列比較を使用して比較する必要があります。 [RFC3986]の.2が適用されます。 「pin-source」属性の値が過負荷であると考えられる場合、値と比較する前に大文字小文字とパーセントエンコーディングの正規化を適用する必要がありますが、正確な比較メカニズムはアプリケーションに委ねられます。
o The value of the attribute "module-path" MUST be compared using the simple string comparison after the full syntax-based normalization, as specified in Section 6.2.2 of [RFC3986], is applied.
o [RFC3986]のセクション6.2.2で指定されている完全な構文ベースの正規化が適用された後、属性「module-path」の値は、単純な文字列比較を使用して比較する必要があります。
o When comparing vendor-specific attributes, the case and percent-encoding normalization, as specified in Section 6.2.2 of [RFC3986], SHOULD be applied before the values are compared, but the exact mechanism of such a comparison is left to the application.
o [RFC3986]のセクション6.2.2で指定されているように、ベンダー固有の属性、ケース、パーセントエンコーディングの正規化を比較する場合、値を比較する前に適用する必要がありますが、そのような比較の正確なメカニズムはアプリケーションに委ねられます。
When generating URIs for PKCS #11 resources, the exact set of attributes used in a URI is inherently context specific. A PKCS #11 URI template [RFC6570] support MAY be provided by a URI-generating application to list URIs to access the same resource(s) again if the template captured the necessary context.
PKCS＃11リソースのURIを生成する場合、URIで使用される属性の正確なセットは本質的にコンテキスト固有です。 PKCS＃11 URIテンプレート[RFC6570]のサポートは、テンプレートが必要なコンテキストを取得した場合にURIをリストして同じリソースに再度アクセスするために、URI生成アプリケーションによって提供される場合があります。
This section contains some examples of how PKCS #11 token objects, tokens, slots, and libraries can be identified using the PKCS #11 URI scheme. Note that in some of the following examples, line breaks and spaces were inserted for better readability. As specified in Appendix C of [RFC3986], whitespace SHOULD be ignored when extracting the URI. Also note that all spaces that are part of the URIs are percent-encoded, as specified in Appendix A of [RFC3986].
このセクションには、PKCS＃11 URIスキームを使用してPKCS＃11トークンオブジェクト、トークン、スロット、およびライブラリを識別する方法のいくつかの例が含まれています。次の例の一部では、読みやすくするために改行とスペースが挿入されていることに注意してください。 [RFC3986]の付録Cで指定されているように、URIを抽出するときは空白を無視する必要があります（SHOULD）。 [RFC3986]の付録Aで指定されているように、URIの一部であるすべてのスペースはパーセントでエンコードされていることにも注意してください。
An empty PKCS #11 URI might be useful to PKCS #11 consumers. See Section 2.5 for more information on semantics of such a URI.
空のPKCS＃11 URIは、PKCS＃11コンシューマーに役立つ場合があります。そのようなURIのセマンティクスの詳細については、セクション2.5を参照してください。
pkcs11:
pkcs11：
One of the simplest and most useful forms might be a PKCS #11 URI that specifies only an object label and its type. The default token is used so the URI does not specify it. Note that when specifying public objects, a token PIN may not be required.
最も単純で最も有用な形式の1つは、オブジェクトラベルとそのタイプのみを指定するPKCS＃11 URIです。デフォルトのトークンが使用されるため、URIはそれを指定しません。パブリックオブジェクトを指定する場合、トークンPINは必要ない場合があることに注意してください。
pkcs11:object=my-pubkey;type=public
When a private key is specified, either the "pin-source" attribute, "pin-value", or an application-specific method would be usually used. Note that '/' is not percent-encoded in the "pin-source" attribute value since this attribute is part of the query component, not the path component, and thus is separated by '?' from the rest of the URI.
秘密鍵が指定されている場合、「pin-source」属性、「pin-value」、またはアプリケーション固有のメソッドのいずれかが通常使用されます。 「/」は「pin-source」属性値ではパーセントエンコードされないことに注意してください。この属性はパスコンポーネントではなくクエリコンポーネントの一部であり、「？」で区切られているためです。残りのURIから。
pkcs11:object=my-key;type=private?pin-source=file:/etc/token
The following example identifies a certificate in the software token. Note the use of an empty value for the attribute "serial", which matches only empty "serialNumber" member of the "CK_TOKEN_INFO" structure. Also note that the "id" attribute value is entirely percent-encoded, as recommended. While ',' is in the reserved set, it does not have to be percent-encoded since it does not conflict with any sub-delimiters used. The '#' character, as in "The Software PKCS #11 Softtoken", MUST be percent-encoded.
次の例では、ソフトウェアトークン内の証明書を識別します。 「CK_TOKEN_INFO」構造の空の「serialNumber」メンバーにのみ一致する属性「serial」に空の値を使用していることに注意してください。また、推奨されるように、「id」属性値は完全にパーセントエンコードされていることに注意してください。 '、'は予約済みのセットにありますが、使用するサブ区切り文字と競合しないため、パーセントエンコードする必要はありません。 「ソフトウェアPKCS＃11 Softtoken」のように、「＃」文字はパーセントでエンコードする必要があります。
pkcs11:token=The%20Software%20PKCS%2311%20Softtoken;
manufacturer=Snake%20Oil,%20Inc.;
model=1.0;
object=my-certificate;
type=cert;
id=%69%95%3E%5C%F4%BD%EC%91;
serial=
?pin-source=file:/etc/token_pin
The next example covers how to use the "module-name" query attribute. Considering that the module is located in the /usr/lib/ libmypkcs11.so.1 file, the attribute value is "mypkcs11", meaning only the module name without the full path and without the platform-specific "lib" prefix and ".so.1" suffix.
次の例では、「module-name」クエリ属性の使用方法を説明しています。モジュールが/ usr / lib / libmypkcs11.so.1ファイルにあることを考えると、属性値は「mypkcs11」です。これは、フルパスとプラットフォーム固有の「lib」プレフィックスと「なし」のモジュール名のみを意味します。 so.1 "サフィックス。
pkcs11:object=my-sign-key;
type=private
?module-name=mypkcs11
The following example covers how to use the "module-path" query attribute. The attribute may be useful if a user needs to provide the key via a PKCS #11 module stored on a removable media, for example. Getting the PIN to access the private key here is left to be application specific.
次の例は、「module-path」クエリ属性の使用方法を示しています。たとえば、ユーザーがリムーバブルメディアに保存されているPKCS＃11モジュールを介してキーを提供する必要がある場合に、この属性が役立ちます。ここで秘密鍵にアクセスするためのPINの取得は、アプリケーション固有です。
pkcs11:object=my-sign-key;
type=private
?module-path=/mnt/libmypkcs11.so.1
In the context of where a token is expected, the token can be identified without specifying any PKCS #11 objects. A PIN might still be needed in the context of listing all objects in the token, for example. Section 6 should be consulted before the "pin-value" attribute is ever used.
トークンが期待される状況では、PKCS＃11オブジェクトを指定せずにトークンを識別できます。たとえば、トークン内のすべてのオブジェクトを一覧表示する場合、PINが必要になる場合があります。 「ピン値」属性を使用する前に、セクション6を参照してください。
pkcs11:token=Software%20PKCS%2311%20softtoken;
manufacturer=Snake%20Oil,%20Inc.
?pin-value=the-pin
In the context where a slot is expected, the slot can be identified without specifying any PKCS #11 objects in any token that may be inserted in the slot.
スロットが想定されるコンテキストでは、スロットに挿入される可能性のあるトークンにPKCS＃11オブジェクトを指定しなくても、スロットを識別できます。
pkcs11:slot-description=Sun%20Metaslot
pkcs11：slot-description = Sun％20Metaslot
The Cryptoki library alone can be also identified without specifying a PKCS #11 token or object.
PKCS＃11トークンまたはオブジェクトを指定せずに、Cryptokiライブラリーのみを識別することもできます。
pkcs11:library-manufacturer=Snake%20Oil,%20Inc.;
library-description=Soft%20Token%20Library;
library-version=1.23
The following example shows an attribute value with a semicolon. In such a case, it MUST be percent-encoded. The token attribute value MUST be read as "My token; created by Joe". Lowercase letters MAY be used in percent-encoding, as shown below in the "id" attribute value, but note that Sections 2.1 and 6.2.2.1 of [RFC3986] state that all percent-encoded characters SHOULD use the uppercase hexadecimal digits. More specifically, if the URI string were to be compared, the algorithm defined in Section 2.6 explicitly requires percent-encoding to use the uppercase digits A-F in the "id" attribute values. And as explained in Section 2.3, library version "3" MUST be interpreted as "3" for the major and "0" for the minor version of the library.
次の例は、セミコロン付きの属性値を示しています。そのような場合は、パーセントでエンコードする必要があります。トークン属性値は、「My token; Created by Joe」として読み取る必要があります。以下の「id」属性値で示すように、小文字はパーセントエンコーディングで使用できますが、[RFC3986]のセクション2.1および6.2.2.1では、すべてのパーセントエンコード文字は大文字の16進数を使用する必要があることに注意してください。より具体的には、URIストリングを比較する場合、セクション2.6で定義されたアルゴリズムでは、「id」属性値で大文字の数字A-Fを使用するためにパーセントエンコードが明示的に必要です。セクション2.3で説明したように、ライブラリバージョン「3」は、ライブラリのメジャーバージョンでは「3」、マイナーバージョンでは「0」と解釈する必要があります。
pkcs11:token=My%20token%25%20created%20by%20Joe;
library-version=3;
id=%01%02%03%Ba%dd%Ca%fe%04%05%06
If there is any need to include a literal "%;" substring, for example, both characters MUST be escaped. The token value MUST be read as "A name with a substring %;".
リテラル「％;」を含める必要がある場合。たとえば、部分文字列は両方の文字をエスケープする必要があります。トークン値は、「部分文字列％;を含む名前」として読み取る必要があります。
pkcs11:token=A%20name%20with%20a%20substring%20%25%3B;
object=my-certificate;
type=cert
The next example includes a small A with acute in the token name. It MUST be encoded in octets according to the UTF-8 character encoding and then percent-encoded. Given that a small A with acute is U+225 Unicode code point, the UTF-8 encoding is 195 161 in decimal, and that is "%C3%A1" in percent-encoding. See also Section 5 on the use of characters outside the US-ASCII character set for labels.
次の例には、トークン名にアキュートが付いた小さなAが含まれています。 UTF-8文字エンコーディングに従ってオクテットでエンコードし、パーセントエンコードする必要があります。アクセント付きの小さなAがU + 225 Unicodeコードポイントであるとすると、UTF-8エンコーディングは10進数で195 161であり、パーセントエンコーディングでは "％C3％A1"です。ラベルにUS-ASCII文字セット以外の文字を使用する場合は、セクション5も参照してください。
pkcs11:token=Name%20with%20a%20small%20A%20with%20acute:%20%C3%A1;
object=my-certificate;
type=cert
Both the path and query components MAY contain vendor-specific attributes. Attributes in the query component MUST be delimited by '&'.
パスコンポーネントとクエリコンポーネントの両方に、ベンダー固有の属性が含まれている場合があります。クエリコンポーネントの属性は「＆」で区切る必要があります。
pkcs11:token=my-token;
object=my-certificate;
type=cert;
vendor-aaa=value-a
?pin-source=file:/etc/token_pin
&vendor-bbb=value-b
This document moves the "pkcs11" URI scheme from the "Provisional URI Schemes" registry to the "Permanent URI Schemes" registry. The registration request complies with [RFC4395].
このドキュメントでは、「pkcs11」URIスキームを「暫定URIスキーム」レジストリから「永続URIスキーム」レジストリに移動します。登録リクエストは[RFC4395]に準拠しています。
URI scheme name: pkcs11
URIスキーム名：pkcs11
URI scheme status: permanent
URIスキームのステータス：永続的
URI scheme syntax: Defined in Section 2.3 of [RFC7512].
URIスキームの構文：[RFC7512]のセクション2.3で定義されています。
URI scheme semantics: Defined in Section 1 of [RFC7512].
URIスキームのセマンティクス：[RFC7512]のセクション1で定義されています。
Encoding considerations: See Sections 2.3 and 5 of [RFC7512].
エンコーディングに関する考慮事項：[RFC7512]のセクション2.3および5を参照してください。
Applications/protocols that use this URI scheme name: For general information, see Section 1 of [RFC7512]. A list of known consumers of the PKCS #11 URI include GnuTLS, Gnome, p11-kit, Oracle Solaris 11 and higher, OpenSC, OpenConnect, and FreeIPA.
このURIスキーム名を使用するアプリケーション/プロトコル：一般情報については、[RFC7512]のセクション1を参照してください。 PKCS＃11 URIの既知のコンシューマーのリストには、GnuTLS、Gnome、p11-kit、Oracle Solaris 11以降、OpenSC、OpenConnect、およびFreeIPAが含まれます。
Interoperability considerations: See Section 5 of [RFC7512].
相互運用性に関する考慮事項：[RFC7512]のセクション5をご覧ください。
Security considerations: See Section 6 of [RFC7512].
セキュリティに関する考慮事項：[RFC7512]のセクション6をご覧ください。
Contact: Jan Pechanec <Jan.Pechanec@Oracle.com>, Darren Moffat
<Darren.Moffat@Oracle.com>
Author/Change Controller: IESG <iesg@ietf.org>
References: [RFC7512]
参照：[RFC7512]
The PKCS #11 specification does not specify a canonical form for strings of characters of the CK_UTF8CHAR type. This presents the usual false negative and false positive (aliasing) concerns that arise when dealing with unnormalized strings. Because all PKCS #11 items are local and local security is assumed, these concerns are mainly about usability and interoperability.
PKCS＃11仕様では、CK_UTF8CHARタイプの文字列の標準形式は指定されていません。これは、正規化されていない文字列を処理するときに発生する通常の偽陰性と偽陽性（エイリアシング）の懸念を示します。すべてのPKCS＃11アイテムはローカルであり、ローカルセキュリティが想定されているため、これらの懸念事項は主にユーザビリティと相互運用性に関するものです。
In order to improve the user experience, it is RECOMMENDED that applications that create PKCS #11 objects or label tokens not use characters outside the US-ASCII character set for the labels. If that is not possible, labels SHOULD be normalized to Normalization Form C (NFC) [UAX15]. For the same reason, PKCS #11 libraries, slots (token readers), and tokens SHOULD use US-ASCII characters only for their names, and if that is not possible, they SHOULD normalize their names to NFC. When listing PKCS #11 libraries, slots, tokens, and/or objects, an application SHOULD normalize their names to NFC if characters outside of the US-ASCII character set are expected. When matching PKCS #11 URIs to libraries, slots, tokens, and/or objects, applications MAY convert names to a chosen normalization form before the string comparison for matching, as those might predate these recommendations. See also Section 2.5.
ユーザーエクスペリエンスを向上させるために、PKCS＃11オブジェクトまたはラベルトークンを作成するアプリケーションでは、ラベルにUS-ASCII文字セット以外の文字を使用しないことをお勧めします。それが不可能な場合は、ラベルを正規化フォームC（NFC）[UAX15]に正規化する必要があります（SHOULD）。同じ理由で、PKCS＃11ライブラリ、スロット（トークンリーダー）、およびトークンは、名前にのみUS-ASCII文字を使用する必要があり（SHOULD）、それが不可能な場合は、名前をNFCに正規化する必要があります（SHOULD）。 PKCS＃11ライブラリ、スロット、トークン、オブジェクトをリストする場合、US-ASCII文字セット以外の文字が予想される場合、アプリケーションはそれらの名前をNFCに正規化する必要があります（SHOULD）。 PKCS＃11 URIをライブラリ、スロット、トークン、オブジェクトに照合する場合、アプリケーションは文字列を比較する前に、選択された正規化形式に名前を変換する場合があります。セクション2.5も参照してください。
There are general security considerations for URI schemes discussed in Section 7 of [RFC3986].
[RFC3986]のセクション7で説明されているURIスキームの一般的なセキュリティ上の考慮事項があります。
From those security considerations, Section 7.1 of [RFC3986] applies since there is no guarantee that the same PKCS #11 URI will always identify the same object, token, slot, or a library in the future.
これらのセキュリティ上の考慮事項から、同じPKCS＃11 URIが将来同じオブジェクト、トークン、スロット、またはライブラリを常に識別する保証はないため、[RFC3986]のセクション7.1が適用されます。
Section 7.2 of [RFC3986] applies since by accepting query component attributes "module-name" or "module-path", the consumer potentially allows loading of arbitrary code into a process.
[RFC3986]のセクション7.2が適用されます。これは、クエリコンポーネントの属性「module-name」または「module-path」を受け入れることにより、コンシューマが任意のコードをプロセスにロードできるようになる可能性があるためです。
Section 7.5 of [RFC3986] applies since a PKCS #11 URI may be used in world-readable command-line arguments to run applications, stored in public configuration files, or otherwise used in clear text. For that reason, the "pin-value" attribute should only be used if the URI string itself is protected with the same level of security as the token PIN itself otherwise is.
[RFC3986]のセクション7.5が適用されるのは、PKCS＃11 URIがアプリケーションを実行するために世界中で読み取り可能なコマンドライン引数で使用されたり、パブリック構成ファイルに保存されたり、クリアテキストで使用されたりする場合があるためです。そのため、「pin-value」属性は、URI文字列自体がトークンPIN自体と同じレベルのセキュリティで保護されている場合にのみ使用する必要があります。
The PKCS #11 specification does not provide means to authenticate devices to users; it only authenticates users to tokens. Instead, local and physical security are demanded: the user must be in possession of their tokens, and the system into whose slots the users' tokens are inserted must be secure. As a result, the usual security considerations regarding normalization do not arise. For the same reason, confusable script issues also do not arise. Nonetheless, if use of characters outside the US-ASCII character set is required, it is best to normalize to NFC all strings appearing in PKCS #11 API elements. See also Section 5.
PKCS＃11仕様は、ユーザーに対してデバイスを認証する手段を提供していません。トークンに対してユーザーを認証するだけです。代わりに、ローカルおよび物理的なセキュリティが要求されます。ユーザーは自分のトークンを所有している必要があり、ユーザーのトークンが挿入されるスロットのシステムは安全でなければなりません。その結果、正規化に関する通常のセキュリティの考慮事項は発生しません。同じ理由で、混乱を招くスクリプトの問題も発生しません。それでも、US-ASCII文字セット以外の文字を使用する必要がある場合は、PKCS＃11 API要素に表示されるすべての文字列をNFCに正規化するのが最善です。セクション5も参照してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月、<http://www.rfc-editor.org/info/rfc3629>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月、<http：//www.rfc- editor.org/info/rfc3986>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", RFC 6648, BCP 178, June 2012, <http://www.rfc-editor.org/info/bcp178>.
[BCP178] Saint-Andre、P.、Crocker、D。、およびM. Nottingham、「アプリケーションプロトコルでの「X-」プレフィックスおよび類似の構成の非推奨」、RFC 6648、BCP 178、2012年6月、<http：// www.rfc-editor.org/info/bcp178>。
[PKCS11] RSA Laboratories, "PKCS #11 v2.20: Cryptographic Token Interface Standard", Public Key Cryptography Standards PKCS#11-v2.20, June 2004.
[PKCS11] RSA Laboratories、「PKCS＃11 v2.20：Cryptographic Token Interface Standard」、Public Key Cryptography Standards PKCS＃11-v2.20、2004年6月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006, <http://www.rfc-editor.org/info/rfc4395>.
[RFC4395] Hansen、T.、Hardie、T。、およびL. Masinter、「新しいURIスキームのガイドラインと登録手順」、BCP 35、RFC 4395、2006年2月、<http://www.rfc-editor.org / info / rfc4395>。
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, March 2012, <http://www.rfc-editor.org/info/rfc6570>.
[RFC6570]グレゴリオ、J。、フィールディング、R。、ハドリー、M。、ノッティンガム、M。、およびD.オーチャード、「URIテンプレート」、RFC 6570、2012年3月、<http：//www.rfc-editor。 org / info / rfc6570>。
[UAX15] Davis, M., Ed. and K. Whistler, Ed., "Unicode Standard Annex #15: Unicode Normalization Forms", Version Unicode 7.0.0, June 2014, <http://unicode.org/reports/tr15/>.
[UAX15]デービス、M。、エド。 K.ウィスラー編、「Unicode Standard Annex＃15：Unicode Normalization Forms」、バージョンUnicode 7.0.0、2014年6月、<http://unicode.org/reports/tr15/>。
Contributors
貢献者
Stef Walter, Nikos Mavrogiannopoulos, Nico Williams, Dan Winship, Jaroslav Imrich, and Mark Phalan contributed to the development of this document. Shawn Emery shepherded the document.
Stef Walter、Nikos Mavrogiannopoulos、Nico Williams、Dan Winship、Jaroslav Imrich、およびMark Phalanがこのドキュメントの開発に貢献しました。ショーン・エメリーは文書をシェパードしました。
Authors' Addresses
著者のアドレス
Jan Pechanec Oracle Corporation 4180 Network Circle Santa Clara, CA 95054 United States
Jan Pechanec Oracle Corporation 4180 Network Circle Santa Clara、CA 95054 United States
EMail: Jan.Pechanec@Oracle.com
URI: http://www.oracle.com
Darren J. Moffat Oracle Corporation Oracle Parkway Thames Valley Park Reading RG6 1RA United Kingdom
ダレンJ.モファットオラクルコーポレーションオラクルパークウェイテムズバレーパークレディングRG6 1RAイギリス
EMail: Darren.Moffat@Oracle.com
URI: http://www.oracle.com