Internet Engineering Task Force (IETF) J. Pechanec
Request for Comments: 7512 D. Moffat
Category: Standards Track Oracle Corporation
ISSN: 2070-1721 April 2015
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统一资源标识符（URI）方案，用于标识PKCS#11令牌中存储的PKCS#11对象，以及标识PKCS#11令牌、插槽或库。URI方案基于“PKCS#11 v2.20：加密令牌接口标准”中PKCS#11对象、令牌、插槽和库的标识方式。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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：加密令牌接口标准”[PKCS11]为保存加密信息并执行加密功能的设备指定了一个称为Cryptoki的API。Cryptoki（发音为“crypto key”，缩写为“Cryptok interface”）遵循一种简单的基于对象的方法，解决了技术独立性（可以使用任何类型的设备）和资源共享（多个应用程序可以访问多个设备）的目标，为应用程序提供了一个通用的，设备的逻辑视图--加密令牌。
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
使用PKCS#11令牌的应用程序或库需要接受一个公共标识符，消费者可以使用该标识符识别PKCS#11令牌中的现有PKCS#11存储对象、现有令牌本身、插槽或现有Cryptoki库（也称为生产者、模块或提供者）。可存储在PKCS#11令牌中的存储对象类型集包括一个证书；数据对象；以及公共、私人或秘密密钥。这些对象可以通过本文档中定义的PKCS#11 URI方案进行唯一标识。描述存储对象的属性集可以包含对象标签、类型和ID。标识PKCS#11令牌的属性集可以包含令牌标签、制造商名称、序列号和令牌型号。可以标识插槽的属性包括插槽ID、说明和制造商。可以识别Cryptoki库的属性是库
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.
制造商、说明和版本。如果多个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方案定义使用“统一资源标识符（URI）：通用语法”[RFC3986]文档中定义的方案、路径和查询组件。URI方案不使用路径中命名机构的分层元素，因为该机构部分无法映射到PKCS#11 API元素。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的生产者，则可以使用查询组件模块属性。但是，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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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是一系列属性值对，它们之间用分号分隔，形成一个一级路径组件，可以选择后跟一个查询。除本节后面定义的“id”属性值外，这些属性值对和查询组件完全由文本数据组成，因此，根据[RFC3986]第2.5节，应首先根据UTF-8字符编码[RFC3629]将所有属性值对和查询组件编码为八位字节；然后，只有与非保留集中的字符或保留集中允许的字符不对应的八位字节才应进行百分比编码。请注意，“id”属性的值不应编码为UTF-8，因为它可以包含非文本数据，而应完全采用百分比编码。请参阅第2.5节和第5节中有关使用包含US-ASCII字符集以外字符的UTF-8字符串的重要注意事项。
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，因为该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
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生产者提供的一级层次结构中的资源的属性。查询组件可以包含检索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.
路径和查询组件都可能包含特定于供应商的属性。此类属性名称不得与现有属性名称冲突。请注意，根据[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. |
+----------------------+---------------------+----------------------+
| 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. |
+----------------------+---------------------+----------------------+
| 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. |
+----------------------+---------------------+----------------------+
+----------------------+---------------------+----------------------+
| 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.
下表显示了“类型”属性值与相应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 |
+-----------------+-----------------------+
+-----------------+-----------------------+
| 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源”指定应用程序或库应在何处找到普通用户的令牌pin，“pin值”属性直接提供普通用户的pin值（如果需要），“模块名称”和“模块路径”属性修改访问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#11uri路径组件中最多只能出现一次。除了本文档中定义的查询属性外，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#u ID”对象属性可以包含任意二进制数据。
Therefore, the whole value of the "id" attribute SHOULD be percent-encoded.
因此，“id”属性的整个值应该进行百分比编码。
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.
“库版本”属性表示库的主版本号和次版本号，其格式为“M.N”。两个数字的大小都是一个字节；有关更多信息，请参见[PKCS11]中CK_信息结构的“libraryVersion”成员。属性的值“M”对于库的主要版本必须解释为“M”，对于库的次要版本必须解释为“0”。如果属性存在，则需要主版本号。“M”和“N”都必须是十进制数。
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可用于提高令牌识别的精度。在其他场景中，使用插槽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源”属性值格式和解释留待具体实现。但是，“pin源”属性的值应按降序遵循以下规则：
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的对象。这样的URI可以是“文件：”、“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 如果该值包含“|<绝对命令路径>”，则实现应从使用绝对路径“<绝对命令路径>”指定的应用程序的输出中读取PIN。请注意，表示管道的字符“|”不必在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源”和“pin值”查询属性，则该URI应被视为无效而拒绝。
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值”属性可能会产生与安全相关的后果。在使用该属性之前，应参考第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提供程序的默认设置。
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模块名称（而不是路径或文件名），且不带系统特定的词缀；例如，所述词缀可以是“.so”或“.DLL”后缀，也可以是“lib”前缀。不使用特定于系统的词缀有望提高PKCS#11 URI在不同系统之间的可移植性。搜索PKCS#11模块的URI使用者应使用特定于系统或应用程序的位置，根据属性中提供的名称查找模块。
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 属性“模块路径”应包含指向PKCS#11模块的系统特定绝对路径或指向PKCS#11模块所在目录的系统特定绝对路径。出于安全原因，应拒绝此属性中具有相对路径的URI。
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使用者可能拒绝接受其中一个属性，或同时接受两个属性。如果不接受使用URI字符串中的属性，则应向URI提供程序显示警告消息，并应使用系统特定的模块位置。
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表示的实体。
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.
在这些查询属性名称中，选择了单词“module”而不是单词“library”，以避免与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可以标识四种不同类型的实体，因此可能需要使用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路径组件中无法识别的属性（包括特定于供应商的属性）应导致匹配的资源集为空。在这种情况下，消费者可以考虑向用户呈现的错误消息是否合适。
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.
比较两个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:
如果作为字符串的URI与[RFC3986]第6.2.1节中规定的相同，或者如果满足以下两个规则，则两个PKCS#11 URI称为相等：
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 路径组件属性“库描述”、“库制造商”、“制造商”、“模型”、“对象”、“序列”、“插槽描述”、“插槽制造商”、“令牌”、“类型”和查询组件属性“模块名称”的值必须使用简单的字符串比较进行比较，如[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 在使用大写字母对数字A-F对所有字节进行百分比编码后，必须使用简单字符串比较来比较属性“id”的值。
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 如[RFC3986]第6.2.2节所述，在应用基于语法的完整规范化后，如果“pin source”的值包含“file:”URI或“|<absolute command path>”，则必须使用简单字符串比较来比较。如果“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节的规定，在应用完全基于语法的规范化后，必须使用简单字符串比较来比较属性“模块路径”的值。
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中使用的确切属性集本质上是特定于上下文的。如果模板捕获了必要的上下文，则URI生成应用程序可以提供PKCS#11 URI模板[RFC6570]支持，以列出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时应忽略空白。另请注意，作为URI一部分的所有空格都按照[RFC3986]附录A中的规定进行百分比编码。
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.
最简单和最有用的形式之一可能是PKCS#11URI，它只指定对象标签及其类型。使用默认标记，因此URI不会指定它。请注意，指定公共对象时，可能不需要令牌PIN。
pkcs11:object=my-pubkey;type=public
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源”属性、“pin值”或特定于应用程序的方法。请注意，“/”在“pin source”属性值中没有百分比编码，因为该属性是查询组件的一部分，而不是路径组件，因此由“？”与URI的其余部分隔开。
pkcs11:object=my-key;type=private?pin-source=file:/etc/token
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.
以下示例标识软件令牌中的证书。请注意，属性“serial”使用空值，它只匹配“CK_TOKEN_INFO”结构的空“serialNumber”成员。还请注意，“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
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.
下一个示例介绍如何使用“模块名”查询属性。考虑到模块位于/usr/lib/libmypkcs11.so.1文件中，属性值为“mypkcs11”，这意味着只有模块名，没有完整路径，也没有特定于平台的“lib”前缀和“.so.1”后缀。
pkcs11:object=my-sign-key;
type=private
?module-name=mypkcs11
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.
下面的示例介绍如何使用“模块路径”查询属性。例如，如果用户需要通过存储在可移动媒体上的PKCS#11模块提供密钥，则该属性可能很有用。获取PIN以访问此处的私钥将取决于应用程序。
pkcs11:object=my-sign-key;
type=private
?module-path=/mnt/libmypkcs11.so.1
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。在使用“pin值”属性之前，应参考第6节。
pkcs11:token=Software%20PKCS%2311%20softtoken;
manufacturer=Snake%20Oil,%20Inc.
?pin-value=the-pin
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:插槽描述=Sun%20Metaslot
The Cryptoki library alone can be also identified without specifying a PKCS #11 token or object.
也可以单独识别Cryptoki库，而无需指定PKCS#11标记或对象。
pkcs11:library-manufacturer=Snake%20Oil,%20Inc.;
library-description=Soft%20Token%20Library;
library-version=1.23
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.
以下示例显示带有分号的属性值。在这种情况下，必须对其进行百分比编码。令牌属性值必须读取为“我的令牌；由Joe创建”。小写字母可用于百分比编码，如下所示的“id”属性值，但请注意，[RFC3986]第2.1节和第6.2.2.1节规定，所有百分比编码字符应使用大写十六进制数字。更具体地说，如果要比较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
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
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.
下一个示例包括令牌名称中带有acute的小a。它必须根据UTF-8字符编码以八位字节编码，然后按百分比编码。假设一个小的带有acute的a是U+225 Unicode码点，UTF-8编码是十进制的195 161，即百分比编码的“%C3%A1”。另请参见第5节“标签使用US-ASCII字符集以外的字符”。
pkcs11:token=Name%20with%20a%20small%20A%20with%20acute:%20%C3%A1;
object=my-certificate;
type=cert
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
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#11uri的已知消费者列表包括GnuTLS、Gnome、p11工具包、oraclesolaris11及更高版本、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>
Contact: Jan Pechanec <Jan.Pechanec@Oracle.com>, Darren Moffat
<Darren.Moffat@Oracle.com>
Author/Change Controller: IESG <iesg@ietf.org>
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#u 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]。出于同样的原因，PKCS#11库、插槽（令牌读取器）和令牌应仅在其名称中使用US-ASCII字符，如果不可能，则应将其名称规范化为NFC。在列出PKCS#11库、插槽、令牌和/或对象时，如果需要US-ASCII字符集以外的字符，应用程序应将它们的名称规范化为NFC。将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.
出于这些安全考虑，[RFC3986]的第7.1节适用，因为不能保证相同的PKCS#11 URI将来总是标识相同的对象、令牌、插槽或库。
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节适用，因为通过接受查询组件属性“模块名称”或“模块路径”，使用者可能允许将任意代码加载到进程中。
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可用于世界可读的命令行参数中以运行应用程序、存储在公共配置文件中或以明文形式使用。因此，只有当URI字符串本身受到与令牌pin本身相同的安全级别的保护时，才应该使用“pin value”属性。
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
PKCS#11规范未提供向用户验证设备的方法；它仅将用户验证为令牌。相反，需要本地和物理安全：用户必须拥有他们的令牌，并且系统必须将令牌插入其插槽中
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.
插入的用户令牌必须是安全的。因此，关于正常化的常规安全考虑没有出现。出于同样的原因，也不会出现易混淆的脚本问题。尽管如此，如果需要使用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，“统一资源标识符（URI）：通用语法”，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]Crocker，D.，Ed.和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]圣安德烈，P.，克罗克，D.，和M.诺丁汉，“反对应用协议中的“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实验室，“PKCS#11 v2.20：加密令牌接口标准”，公钥加密标准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]Gregorio，J.，Fielding，R.，Hadley，M.，Nottingham，M.，和D.Orchard，“URI模板”，RFC 65702012年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]Davis，M.，Ed.和K.Whistler，Ed.，“Unicode标准附录#15：Unicode规范化格式”，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美国加利福尼亚州圣克拉拉网络圈95054
EMail: Jan.Pechanec@Oracle.com
URI: http://www.oracle.com
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
Darren J.Moffat甲骨文公司甲骨文大道泰晤士河谷公园阅读RG6 1RA英国
EMail: Darren.Moffat@Oracle.com
URI: http://www.oracle.com
EMail: Darren.Moffat@Oracle.com
URI: http://www.oracle.com