Independent Submission M. Joseph
Request for Comments: 7076 J. Susoy
Category: Informational P6R, Inc
ISSN: 2070-1721 November 2013
Independent Submission M. Joseph
Request for Comments: 7076 J. Susoy
Category: Informational P6R, Inc
ISSN: 2070-1721 November 2013
P6R's Secure Shell Public Key Subsystem
P6R的安全外壳公钥子系统
Abstract
摘要
The Secure Shell (SSH) Public Key Subsystem protocol defines a key distribution protocol that is limited to provisioning an SSH server with a user's public keys. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport.
Secure Shell（SSH）公钥子系统协议定义了一个密钥分发协议，该协议仅限于为SSH服务器提供用户的公钥。本文档描述了一个新协议，该协议构建在RFC 4819中定义的协议之上，允许使用SSH传输向服务器提供密钥和证书。
The new protocol allows the calling client to organize keys and certificates in different namespaces on a server. These namespaces can be used by the server to allow a client to configure any application running on the server (e.g., SSH, Key Management Interoperability Protocol (KMIP), Simple Network Management Protocol (SNMP)).
新协议允许调用客户端在服务器上的不同名称空间中组织密钥和证书。服务器可以使用这些名称空间来允许客户端配置服务器上运行的任何应用程序（例如，SSH、密钥管理互操作性协议（KMIP）、简单网络管理协议（SNMP））。
The new protocol provides a server-independent mechanism for clients to add public keys, remove public keys, add certificates, remove certificates, and list the current set of keys and certificates known by the server by namespace (e.g., list all public keys in the SSH namespace).
新协议为客户端提供了一种独立于服务器的机制，用于添加公钥、删除公钥、添加证书、删除证书，以及按命名空间列出服务器已知的当前密钥集和证书（例如，列出SSH命名空间中的所有公钥）。
Rights to manage keys and certificates in a particular namespace are specific and limited to the authorized user and are defined as part of the server's implementation. The described protocol is backward compatible to version 2 defined by RFC 4819.
在特定命名空间中管理密钥和证书的权限是特定的，仅限于授权用户，并定义为服务器实现的一部分。所述协议与RFC 4819定义的版本2向后兼容。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc7076.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7076.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Overview of Extensions to the Public Key Subsystem ..............3
3.1. Extended Status Codes ......................................4
3.2. The Version Packet .........................................4
3.3. The Namespace Attribute ....................................4
4. New Operations ..................................................5
4.1. Adding a Certificate .......................................5
4.2. Removing a Certificate .....................................6
4.3. Listing Certificates .......................................6
4.4. Listing Namespaces .........................................7
5. Extending Public Key Operations .................................8
5.1. Adding a Public Key ........................................8
5.2. Removing a Public Key ......................................8
5.3. Listing Public Keys ........................................9
6. Security Considerations .........................................9
7. IANA Considerations ............................................10
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Overview of Extensions to the Public Key Subsystem ..............3
3.1. Extended Status Codes ......................................4
3.2. The Version Packet .........................................4
3.3. The Namespace Attribute ....................................4
4. New Operations ..................................................5
4.1. Adding a Certificate .......................................5
4.2. Removing a Certificate .....................................6
4.3. Listing Certificates .......................................6
4.4. Listing Namespaces .........................................7
5. Extending Public Key Operations .................................8
5.1. Adding a Public Key ........................................8
5.2. Removing a Public Key ......................................8
5.3. Listing Public Keys ........................................9
6. Security Considerations .........................................9
7. IANA Considerations ............................................10
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
This document describes a new protocol that builds on the protocol defined in RFC 4819 that can be used to configure public keys and certificates in an implementation-independent fashion. The concept of a namespace is added to the protocol's operations; it allows the client to organize keys and certificates by application or organizational structure.
本文档描述了一个新协议，该协议建立在RFC 4819中定义的协议之上，可用于以独立于实现的方式配置公钥和证书。将名称空间的概念添加到协议的操作中；它允许客户端按应用程序或组织结构组织密钥和证书。
P6R's Secure Shell Public Key Subsystem has been designed to run on top of the Secure Shell transport layer [3] and user authentication protocols [4]. It provides a simple mechanism for the client to manage the public keys and certificates on the server related to that client. These keys and certificates are normally used for authentication of the client to a service, but they can be used for encrypting results back to the client as well. Uploaded keys and certificates are meant to be able to configure all protocols running on a server (e.g., SSH, SSL, KMIP [8]) that use keys and certificates, as well as the applications that run on a server.
P6R的安全外壳公钥子系统设计为运行在安全外壳传输层[3]和用户身份验证协议[4]之上。它为客户机提供了一种简单的机制来管理与该客户机相关的服务器上的公钥和证书。这些密钥和证书通常用于客户端到服务的身份验证，但也可以用于将结果加密回客户端。上传的密钥和证书意味着能够配置服务器上运行的所有协议（例如，SSH、SSL、KMIP[8]），这些协议使用密钥和证书，以及服务器上运行的应用程序。
This document should be read only after reading the Secure Shell Public Key Subsystem [1] document. The new protocol described in this document builds on and is meant to be backwards compatible with the protocol described in [1].
只有在阅读Secure Shell公钥子系统[1]文档后，才能阅读此文档。本文件中所述的新协议建立在[1]中所述协议的基础上，并与之向后兼容。
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 RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, list the current public keys known by the server, add certificates, remove certificates, and list the current set of certificates known by the server. This secure key distribution mechanism is implemented by a new SSH subsystem with the name of "publickey@p6r.com".
公钥子系统为客户端提供独立于服务器的机制，用于添加公钥、删除公钥、列出服务器已知的当前公钥、添加证书、删除证书以及列出服务器已知的当前证书集。此安全密钥分发机制由名为“”的新SSH子系统实现publickey@p6r.com".
The status code gives the status in a more machine-readable format (suitable for localization) and can have the following values:
状态代码以更具机器可读性的格式（适用于本地化）提供状态，并且可以具有以下值：
SSH_PUBLICKEY_CERTIFICATE_NOT_FOUND 192 SSH_PUBLICKEY_CERTIFICATE_NOT_SUPPORTED 193 SSH_PUBLICKEY_CERTIFICATE_ALREADY_PRESENT 194 SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED 195 SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE 196
SSH\u公钥\u证书\u未找到192 SSH\u公钥\u证书\u不受支持193 SSH\u公钥\u证书\u已存在194 SSH\u公钥\u操作\u未授权195 SSH\u公钥\u无法\u创建命名空间196
The meaning of the failure codes is as implied by their names. See Security Considerations for the use of the failure code: SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED.
故障代码的含义与其名称相同。有关故障代码的使用，请参阅安全注意事项：SSH\u公钥\u操作\u未授权。
Both sides MUST start a connection by sending a version packet that indicates the version of the protocol they are using.
双方必须通过发送一个版本数据包来启动连接，该数据包指示他们正在使用的协议的版本。
string "version" uint32 protocol-version-number
字符串“版本”uint32协议版本号
This document defines version 3 of the new protocol. We are using version 3 so that it can be backward compatible with the protocol defined by RFC 4819 [1].
本文件定义了新协议的第3版。我们使用的是版本3，因此它可以向后兼容RFC 4819[1]定义的协议。
The "namespace" attribute is added as an extension to what was described in RFC 4819. The purpose of this attribute is to be able to organize the uploaded keys and certificates into groups where each group represents an application or organization structure. This attribute is a string that should not be longer than 300 characters and MUST be specified in UTF-8 format [5].
“namespace”属性作为RFC4819中描述的扩展添加。此属性的目的是能够将上载的密钥和证书组织到组中，每个组表示一个应用程序或组织结构。此属性是长度不应超过300个字符的字符串，必须以UTF-8格式指定[5]。
This new protocol uses the "ssh" namespace for the manipulation of public keys in an SSH server and should be considered as the default namespace when none is provided.
这个新协议使用“ssh”名称空间来操作ssh服务器中的公钥，如果没有提供名称空间，则应将其视为默认名称空间。
As a convention, namespaces used for protocols are lowercase strings of the protocol's standard abbreviation. For example, "ssl" should be the namespace used for the Secure Sockets Layer protocol. Namespaces for applications should contain the product and vendor's name. To help determine what namespaces already exist on a server, a new operation "list-namespaces" is defined in Section 4.
作为惯例，用于协议的名称空间是协议标准缩写的小写字符串。例如，“ssl”应该是用于安全套接字层协议的名称空间。应用程序的名称空间应包含产品和供应商名称。为了帮助确定服务器上已经存在哪些名称空间，在第4节中定义了一个新操作“列出名称空间”。
P6R's Public Key Subsystem extends the functionality defined in RFC 4819 with the following operations: add-certificate, remove-certificate, list-certificates, and list-namespaces.
P6R的公钥子系统通过以下操作扩展RFC4819中定义的功能：添加证书、删除证书、列出证书和列出命名空间。
If the client wishes to add a certificate, the client sends:
如果客户端希望添加证书，则客户端将发送：
string "add-certificate" string certificate format name string certificate blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times
字符串“添加证书”字符串证书格式名称字符串证书blob布尔覆盖uint32属性计数字符串属性名称字符串属性值bool临界重复属性计数次数
This request MUST include at least the "namespace" attribute so that the server knows where to save the certificate. Only one namespace attribute can be used per an add-certificate request. It is possible for the same user to save the same certificate into multiple namespaces, but this must be done with several separate add-certificate requests.
此请求必须至少包含“namespace”属性，以便服务器知道在何处保存证书。每个添加证书请求只能使用一个命名空间属性。同一用户可以将同一证书保存到多个名称空间中，但这必须通过几个单独的添加证书请求来完成。
If the namespace appearing in an add-certificate request does not already exist on a server, then it is created by this operation. However, if the user is not authorized to create a namespace, the server MUST return SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE.
如果添加证书请求中出现的命名空间在服务器上不存在，则此操作将创建该命名空间。但是，如果用户未被授权创建命名空间，服务器必须返回SSH\u PUBLICKEY\u CANNOT\u create\u命名空间。
If the overwrite field is false and the specified certificate already exists in the given namespace, the server MUST return SSH_PUBLICKEY_CERTIFICATE_ALREADY_PRESENT. If the server returns this, the client SHOULD provide an option to the user to overwrite the certificate. If the overwrite field is true and the specified key already exists in the given namespace but cannot be overwritten, the server MUST return SSH_PUBLICKEY_ACCESS_DENIED.
如果覆盖字段为false，并且指定的证书已存在于给定的命名空间中，则服务器必须返回SSH\u PUBLICKEY\u certificate\u ready\u PRESENT。如果服务器返回此消息，客户端应向用户提供覆盖证书的选项。如果overwrite字段为true，并且指定的密钥已存在于给定的命名空间中，但无法覆盖，则服务器必须返回SSH\u PUBLICKEY\u ACCESS\u DENIED。
However, a user may not be authorized to add a certificate to the specified namespace. If the user does not have permission to add a certificate, then the server MUST return SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED.
但是，用户可能无权向指定的命名空间添加证书。如果用户没有添加证书的权限，则服务器必须返回SSH\u PUBLICKEY\u ACTION\u not\u AUTHORIZED。
Examples of possible "certificate format names" are: "X509", "pgp-sign-rsa", and "pgp-sign-dss". The format of the public key and certificate blobs are detailed in Section 6.6, "Public Key
可能的“证书格式名称”示例有：“X509”、“pgp签名rsa”和“pgp签名dss”。公钥和证书blob的格式详见第6.6节“公钥”
Algorithms", of the SSH Transport Protocol document [3], where X.509 certificates are to be encoded using a DER format [6] [7] in a certificate blob.
SSH传输协议文档[3]中的“算法”，其中X.509证书将在证书blob中使用DER格式[6][7]进行编码。
If the client wishes to remove a certificate, the client sends:
如果客户端希望删除证书，则客户端将发送：
string "remove-certificate" string certificate format name string certificate blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times
字符串“删除证书”字符串证书格式名称字符串证书blob uint32属性计数字符串属性名称字符串属性值重复属性计数次数
This request MUST include at least the "namespace" attribute so that the server knows from where to delete the certificate. Only one namespace attribute can be used per remove-certificate request. The server MUST attempt to remove the certificate from the appropriate location.
此请求必须至少包含“namespace”属性，以便服务器知道从何处删除证书。每个删除证书请求只能使用一个命名空间属性。服务器必须尝试从适当的位置删除证书。
However, a user may not be authorized to remove a certificate from the specified namespace. If the user does not have permission to remove the certificate, then the server MUST return SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED.
但是，用户可能无权从指定的命名空间中删除证书。如果用户没有删除证书的权限，则服务器必须返回SSH\u PUBLICKEY\u ACTION\u not\u AUTHORIZED。
Examples of possible "certificate format names" are: "X509", "pgp-sign-rsa", and "pgp-sign-dss".
可能的“证书格式名称”示例有：“X509”、“pgp签名rsa”和“pgp签名dss”。
If the client wishes to list the known certificates, the client sends:
如果客户端希望列出已知证书，则客户端将发送：
string "list-certificates"
字符串“列出证书”
The server will respond with zero or more of the following responses:
服务器将响应以下零个或多个响应：
string "certificate" string certificate format name string certificate blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times
字符串“certificate”字符串证书格式名称字符串证书blob uint32属性计数字符串attrib名称字符串attrib值重复属性计数次数
There is no requirement that the responses be in any particular order. Whilst some server implementations may send the responses in some order, client implementations should not rely on responses being in any order.
没有要求响应按任何特定顺序进行。虽然某些服务器实现可能会以某种顺序发送响应，但客户端实现不应依赖于任何顺序的响应。
This response MUST include at least the "namespace" attribute so that a client can tell in which namespace the certificate resides. Only one namespace attribute can be used per list-certificate request.
此响应必须至少包含“namespace”属性，以便客户端可以知道证书驻留在哪个命名空间中。每个列表证书请求只能使用一个命名空间属性。
Following the last "certificate" response, a status packet MUST be sent.
在最后一个“证书”响应之后，必须发送一个状态数据包。
If the client wishes to know existing namespaces on the server, it sends:
如果客户端希望了解服务器上现有的名称空间，则会发送：
string "list-namespaces"
字符串“列出名称空间”
The server will respond with zero or more of the following responses:
服务器将响应以下零个或多个响应：
string "namespace" string namespace name
字符串“名称空间”字符串名称空间
It is possible that not all namespaces will be visible to every authenticated user. In this case, the responding server will return a subset of existing namespaces. See Security Considerations below.
可能并非所有名称空间对每个经过身份验证的用户都可见。在这种情况下，响应服务器将返回现有名称空间的子集。请参阅下面的安全注意事项。
Following the last "namespace" response, a status packet MUST be sent.
在最后一个“名称空间”响应之后，必须发送一个状态数据包。
In addition to adding new operations, this document describes extensions to the operations defined in RFC 4819.
除了添加新操作外，本文档还描述了RFC 4819中定义的操作的扩展。
If the client wishes to add a public key, the client sends:
如果客户端希望添加公钥，则客户端将发送：
string "add" string public key algorithm name string public key blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times
字符串“添加”字符串公钥算法名称字符串公钥blob布尔覆盖uint32属性计数字符串attrib名称字符串attrib值bool临界重复属性计数次数
This request MAY include one "namespace" attribute so that a client can save the public key into a specific namespace. It is possible for the same user to save the same key into multiple namespaces, but this requires multiple add requests.
此请求可能包含一个“名称空间”属性，以便客户端可以将公钥保存到特定名称空间中。同一用户可以将同一密钥保存到多个名称空间中，但这需要多个add请求。
If the namespace appearing in an add public key request does not already exist on a server, then it is created by this operation. However, if the user is not authorized to create a namespace the server MUST return SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE,
如果添加公钥请求中出现的命名空间在服务器上不存在，则此操作将创建该命名空间。但是，如果用户无权创建命名空间，服务器必须返回SSH\u PUBLICKEY\u无法\u创建\u命名空间，
If the client wishes to remove a public key, the client sends:
如果客户端希望删除公钥，则客户端将发送：
string "remove" string public key algorithm name string public key blob uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times
字符串“删除”字符串公钥算法名称字符串公钥blob uint32属性计数字符串attrib名称字符串attrib值bool临界重复属性计数次数
This extension allows attributes to be added to a remove request. This request MAY include one "namespace" attribute so that a client can remove the public key from a specific namespace.
此扩展允许将属性添加到删除请求中。此请求可能包含一个“名称空间”属性，以便客户端可以从特定名称空间中删除公钥。
If the client wishes to list the known public keys, the client sends:
如果客户端希望列出已知公钥，则客户端发送：
string "list" uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times
字符串“列表”uint32属性计数字符串属性名称字符串属性值布尔临界重复属性计数次数
This extension allows attributes to be added to a list request. This request MAY include one "namespace" attribute so that a client can list the public keys from a specific namespace.
此扩展允许将属性添加到列表请求中。此请求可能包含一个“namespace”属性，以便客户端可以列出特定命名空间中的公钥。
The server will respond with zero or more of the following responses:
服务器将响应以下零个或多个响应：
string "publickey" string public key algorithm name string public key blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times
字符串“publickey”字符串公钥算法名称字符串公钥blob uint32属性计数字符串attrib名称字符串attrib值重复属性计数次数
This response MAY include the "namespace" attribute so that a client can tell in which namespace the key resides.
此响应可能包括“namespace”属性，以便客户机可以知道密钥驻留在哪个命名空间中。
This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks.
此协议假定它在安全通道上运行，并且通道的端点已通过身份验证。因此，该协议假定它受到外部保护，免受网络级攻击。
This protocol provides a mechanism that allows key and certificate material to be uploaded and manipulated into a server application. It is the responsibility of the server implementation to enforce access controls that may be required to limit any particular user's access to the data in a namespace. For example, one user may be allowed to list only the contents of a namespace but not add or remove keys or certificates to/from it. The server MUST return SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED when a user's action goes against its defined access controls.
该协议提供了一种机制，允许将密钥和证书材料上载并操纵到服务器应用程序中。服务器实现负责实施访问控制，这可能是限制任何特定用户对命名空间中数据的访问所必需的。例如，可能只允许一个用户列出名称空间的内容，而不允许向其添加或删除密钥或证书。当用户的操作违反其定义的访问控制时，服务器必须返回SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED。
This protocol requires the client to assume that the server will correctly implement and observe attributes applied to keys. Implementation errors in the server could cause clients to authorize keys and certificates for access they were not intended to have, or to apply fewer restrictions than were intended.
此协议要求客户端假定服务器将正确实现并观察应用于密钥的属性。服务器中的实现错误可能会导致客户端授权密钥和证书以进行他们不打算拥有的访问，或者应用比预期更少的限制。
Although Section 3.1 defines four new status codes, these are in the 'Private Use' range of IANA's Publickey Subsystem Status Codes registry as defined by Section 6.6.1 ("Conventions") in [1]. No IANA actions are required for this document.
尽管第3.1节定义了四个新的状态代码，但这些代码属于IANA公钥子系统状态代码注册表的“私人使用”范围，如[1]第6.6.1节（“约定”）所定义。本文件无需IANA操作。
[1] Galbraith, J., Van Dyke, J., and J. Bright, "Secure Shell Public Key Subsystem", RFC 4819, March 2007.
[1] Galbraith，J.，Van Dyke，J.，和J.Bright，“安全外壳公钥子系统”，RFC 4819，2007年3月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[3] 《安全外壳（SSH）传输层协议》，RFC 4253，2006年1月。
[4] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[4] 《安全外壳（SSH）认证协议》，RFC4252，2006年1月。
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.translate error, please retry
[6] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[6] Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[7] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[7] ITU-T建议X.690（2002）| ISO/IEC 8825-1:2002，信息技术——ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范。
[8] OASIS, "Key Management Interoperability Protocol (KMIP) 1.1", January 2013, <http://docs.oasis-open.org/kmip/spec/v1.1/os/ kmip-spec-v1.1-os.html>.
[8] OASIS，“密钥管理互操作性协议（KMIP）1.1”，2013年1月<http://docs.oasis-open.org/kmip/spec/v1.1/os/ kmip-spec-v1.1-os.html>。
Authors' Addresses
作者地址
Mark Joseph, PhD P6R, Inc 1840 41st Ave Suite 102-139 Capitola, CA 95010 US
美国加利福尼亚州卡皮托拉市41大街1840号102-139室马克·约瑟夫博士P6R公司，邮编95010
Phone: +1 888 452 2580 (x702)
EMail: mark@p6r.com
Phone: +1 888 452 2580 (x702)
EMail: mark@p6r.com
Jim Susoy P6R, Inc 1840 41st Ave Suite 102-139 Capitola, CA 95010 US
Jim Susoy P6R公司美国加利福尼亚州卡皮托拉41大街1840号102-139室，邮编95010
Phone: +1 888 452 2580 (x701)
EMail: jim@p6r.com
Phone: +1 888 452 2580 (x701)
EMail: jim@p6r.com