Membership Service Providers (MSP)成员资格服务提供者（翻译）

原文：https://hyperledger-fabric.readthedocs.io/en/latest/msp.htm
The document serves to provide details on the setup and best practices for MSPs.
该文档提供了关于MSPs的设置和最佳实践的详细信息。
Membership Service Provider (MSP) is a component that aims to offer an abstraction of a membership operation architecture.
成员资格服务提供者(Membership Service Provider, MSP)是一个旨在提供成员资格操作体系结构的抽象的组件。
In particular, MSP abstracts away all cryptographic mechanisms and protocols behind issuing and validating certificates, and user authentication. An MSP may define their own notion of identity, and the rules by which those identities are governed (identity validation) and authenticated (signature generation and verification).
特别是，MSP抽象出颁发、验证证书和用户身份验证后的所有加密机制和协议。MSP可以定义它们自己的标识概念，以及这些标识被治理(标识验证)和认证(签名生成和验证)的规则。
A Hyperledger Fabric blockchain network can be governed by one or more MSPs. This provides modularity of membership operations, and interoperability across different membership standards and architectures.
一个Hyperledger Fabric区块链网络可以被一个或多个msp控制。这提供了成员资格操作的模块化，以及跨不同成员资格标准和体系结构的互操作性。
In the rest of this document we elaborate on the setup of the MSP implementation supported by Hyperledger Fabric, and discuss best practices concerning its use.
在本文档的其余部分中，我们详细介绍了由Hyperledger Fabric支持的MSP实现的设置，并讨论关于它的使用的最佳实践。

MSP配置

To setup an instance of the MSP, its configuration needs to be specified locally at each peer and orderer (to enable peer, and orderer signing), and on the channels to enable peer, orderer, client identity validation, and respective signature verification (authentication) by and for all channel members.

要设置MSP实例，它的配置需要在每个对等点和定序者(以启用对等点和定序者签名)以及通道上指定，以便为所有通道成员，启用对等点、定序者、客户端标识验证和各自的签名验证(身份验证)。

Firstly, for each MSP a name needs to be specified in order to reference that MSP in the network (e.g. msp1, org2, and org3.divA). This is the name under which membership rules of an MSP representing a consortium, organization or organization division is to be referenced in a channel. This is also referred to as the MSP Identifier or MSP ID. MSP Identifiers are required to be unique per MSP instance. For example, shall two MSP instances with the same identifier be detected at the system channel genesis, orderer setup will fail.
首先，需要为每个MSP指定一个名称，以引用网络中的MSP(例如msp1、org2和org3.divA)。这是代表联盟、组织或组织部门的MSP的成员规则在通道中引用的名称。这也称为MSP标识符或MSP ID，每个MSP实例都要求MSP标识符是唯一的。例如，如果在系统通道发生时检测到两个具有相同标识符的MSP实例，则orderer设置将失败。

In the case of default implementation of MSP, a set of parameters need to be specified to allow for identity (certificate) validation and signature verification. These parameters are deduced by RFC5280, and include:
对于MSP的默认实现，需要指定一组参数，以便进行身份(证书)验证和签名验证。这些参数由RFC5280导出，包括:

• A list of self-signed (X.509) certificates to constitute the root of trust
  -自签名证书(X.509)的列表，它们构成信任的基础
• A list of X.509 certificates to represent intermediate CAs this provider considers for certificate validation; these certificates ought to be certified by exactly one of the certificates in the root of trust; intermediate CAs are optional parameters
  -X.509证书的列表，用于表示提供者考虑进行证书验证的中间CAs;这些证书应该由真正的信托证书中的一个认证;中间CAs是可选参数
• A list of X.509 certificates with a verifiable certificate path to exactly one of the certificates of the root of trust to represent the administrators of this MSP; owners of these certificates are authorized to request changes to this MSP configuration (e.g. root CAs, intermediate CAs)
  -X.509证书的列表，该证书具有可验证的证书路径，刚好指向代表此MSP的管理员的信任根证书之一;这些证书的所有者被授权请求修改MSP配置(例如根CAs、中间CAs)
• A list of Organizational Units that valid members of this MSP should include in their X.509 certificate; this is an optional configuration parameter, used when, e.g., multiple organizations leverage the same root of trust, and intermediate CAs, and have reserved an OU field for their members
  -该MSP的有效成员应在其X.509证书中包含的组织单位列表;这是一个可选的配置参数，用于多个组织利用相同的信任根和中间CAs，并为其成员保留OU字段
• A list of certificate revocation lists (CRLs) each corresponding to exactly one of the listed (intermediate or root) MSP Certificate Authorities; this is an optional parameter
  -证书撤销清单(CRLs)，每个清单对应于所列(中间或根)的MSP证书颁发机构之一;这是一个可选参数
• A list of self-signed (X.509) certificates to constitute the TLS root of trust for TLS certificate.
  -自签名证书列表(X.509)，构成TLS证书信任的根。
• A list of X.509 certificates to represent intermediate TLS CAs this provider considers; these certificates ought to be certified by exactly one of the certificates in the TLS root of trust; intermediate CAs are optional parameters.
  -代表该供应商考虑的中间TLS CAs的X.509证书列表;这些证书应该由TLS信托的一个证书进行认证;中间CAs是可选参数。

Valid identities for this MSP instance are required to satisfy the following conditions:
该MSP实例的有效身份必须满足以下条件:

• They are in the form of X.509 certificates with a verifiable certificate path to exactly one of the root of trust certificates;
  它们以X.509证书的形式存在，其证书路径可验证，且恰好是信任证书的根目录;
• They are not included in any CRL;
  它们不包含在任何CRL中
• And they list one or more of the Organizational Units of the MSP configuration in the OU field of their X.509 certificate structure.
  他们列出了他们X.509证书结构的OU字段中，MSP配置的一个或多个组织单元。

For more information on the validity of identities in the current MSP implementation, we refer the reader to MSP Identity Validity Rules.
有关当前MSP实现中身份有效性的更多信息，请参阅MSP身份有效性规则。
In addition to verification related parameters, for the MSP to enable the node on which it is instantiated to sign or authenticate, one needs to specify:
除了与验证相关的参数之外，对于MSP来说，要启用它所实例化的节点来进行签名或验证，还需要指定:

• The signing key used for signing by the node (currently only ECDSA keys are supported), and
  节点(目前只支持ECDSA密钥)签名的签名密钥，以及
• The node’s X.509 certificate, that is a valid identity under the verification parameters of this MSP.
  该节点的X.509证书，在此MSP的验证参数下是有效的标识。

It is important to note that MSP identities never expire; they can only be revoked by adding them to the appropriate CRLs. Additionally, there is currently no support for enforcing revocation of TLS certificates.
重要的是要注意，MSP标识从未过期;只能通过将它们添加到适当的crl来撤销它们。此外，目前还不支持强制撤销TLS证书。

如何生成MSP证书及其签名密钥?

To generate X.509 certificates to feed its MSP configuration, the application can use Openssl. We emphasize that in Hyperledger Fabric there is no support for certificates including RSA keys.
要生成X.509证书以提供MSP配置，应用程序可以使用Openssl。我们强调在超分类结构中不支持包括RSA密钥在内的证书。
Alternatively one can use cryptogen tool, whose operation is explained in Getting Started.
另一种方法是使用加密工具cryptogen，它的操作在入门中进行了说明。
Hyperledger Fabric CA can also be used to generate the keys and certificates needed to configure an MSP.
也可以用Hyperledger Fabric CA，来生成配置MSP所需的密钥和证书。

建立在peer和orderer节点的MSP

To set up a local MSP (for either a peer or an orderer), the administrator should create a folder (e.g. $MY_PATH/mspconfig) that contains six subfolders and a file:
为了设置一个本地MSP(对于一个对等点或一个orderer)，管理员应该创建一个包含六个子文件夹和一个文件的文件夹(例如MY_PATH/mspconfig):

1. a folder admincerts to include PEM files each corresponding to an administrator certificate 文件夹admincerts，用于包含与管理员证书对应的PEM文件
2. a folder cacerts to include PEM files each corresponding to a root CA’s certificate 文件夹cacerts，包含每个对应于根CA证书的PEM文件
3. (optional) a folder intermediatecerts to include PEM files each corresponding to an intermediate CA’s certificate (可选)文件夹intermediatecerts，包含与中级CA证书对应的PEM文件
4. (optional) a file config.yaml to configure the supported Organizational Units and identity classifications (see respective sections below).(可选)配置文件config.yaml，用于配置受支持的组织单元和标识分类(参见下面的各个部分)。
5. (optional) a folder crls to include the considered CRLs (可选)包含考虑的crls的文件夹
6. a folder keystore to include a PEM file with the node’s signing key; we emphasise that currently RSA keys are not supported 文件夹keystore ，包含带有节点签名密钥的PEM文件;我们强调，目前RSA密钥不受支持
7. a folder signcerts to include a PEM file with the node’s X.509 certificate
   文件夹signcerts ，其中包含节点X.509证书的一个PEM文件。
8. (optional) a folder tlscacerts to include PEM files each corresponding to a TLS root CA’s certificate 文件夹tlscacerts，包含TLS根CA证书的PEM文件
9. (optional) a folder tlsintermediatecerts to include PEM files each corresponding to an intermediate TLS CA’s certificate
   文件夹tlsintermediatecerts，包含TLS中间CA证书的PEM文件

In the configuration file of the node (core.yaml file for the peer, and orderer.yaml for the orderer), one needs to specify the path to the mspconfig folder, and the MSP Identifier of the node’s MSP. The path to the mspconfig folder is expected to be relative to FABRIC_CFG_PATH and is provided as the value of parameter mspConfigPath for the peer, and LocalMSPDir for the orderer. The identifier of the node’s MSP is provided as a value of parameter localMspId for the peer and LocalMSPID for the orderer. These variables can be overridden via the environment using the CORE prefix for peer (e.g. CORE_PEER_LOCALMSPID) and the ORDERER prefix for the orderer (e.g. ORDERER_GENERAL_LOCALMSPID). Notice that for the orderer setup, one needs to generate, and provide to the orderer the genesis block of the system channel. The MSP configuration needs of this block are detailed in the next section.
在节点的配置文件中(peer的core.yaml文件和orderer节点的orderer.yaml文件)，需要指定到mspconfig文件夹的路径，以及节点MSP的MSP标识符。mspconfig文件夹的路径预期是相对于FABRIC_CFG_PATH的，并由peer节点的参数mspConfigPath和orderer节点的参数LocalMSPDir提供。节点的MSP标识符是peer节点的localMspId，orderer的localMspId。这些参数，可以被环境变量覆盖，如peer的CORE_PEER_LOCALMSPID，orderer的ORDERER_GENERAL_LOCALMSPID。注意，对于orderer设置，需要生成并向orderer提供系统通道的起源块。此块的MSP配置需求将在下一节中详细介绍。
Reconfiguration of a “local” MSP is only possible manually, and requires that the peer or orderer process is restarted. In subsequent releases we aim to offer online/dynamic reconfiguration (i.e. without requiring to stop the node by using a node managed system chaincode).
重新配置“本地”MSP，只能手工进行，并要求重新启动peer或orderer节点。在后续版本中，我们的目标是提供在线/动态重新配置(即不需要使用节点管理的系统链码来停止节点)。

组织单位

In order to configure the list of Organizational Units that valid members of this MSP should include in their X.509 certificate, the config.yaml file needs to specify the organizational unit identifiers. Here is an example:
为了配置组织单元列表，这个MSP的有效成员应该包含X.509证书，config.yaml文件需要指定组织单元标识符。这是一个例子:

OrganizationalUnitIdentifiers:

-Certificate: "cacerts/cacert1.pem"

OrganizationalUnitIdentifier: "commercial"

-Certificate: "cacerts/cacert2.pem"

OrganizationalUnitIdentifier: "administrators"  

The above example declares two organizational unit identifiers: commercial and administrators. An MSP identity is valid if it carries at least one of these organizational unit identifiers. The Certificate field refers to the CA or intermediate CA certificate path under which identities, having that specific OU, should be validated. The path is relative to the MSP root folder and cannot be empty.
上面的示例声明了两个组织单元标识符:commercial 和administrators。如果MSP标识包含至少一个组织单元标识符，那么它就是有效的。Certificate 字段指的是CA或中间CA证书路径，在该路径下，具有特定OU的标识是有效的。路径相对于MSP根文件夹，不能为空。

身份分类

The default MSP implementation allows to further classify identities into clients and peers, based on the OUs of their x509 certificates. An identity should be classified as a client if it submits transactions, queries peers, etc. An identity should be classified as a peer if it endorses or commits transactions. In order to define clients and peers of a given MSP, the config.yaml file needs to be set appropriately. Here is an example:

NodeOUs:

Enable: true
ClientOUIdentifier:

Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "client"

PeerOUIdentifier:

Certificate: "cacerts/cacert.pem"
OrganizationalUnitIdentifier: "peer"  

As shown above, the NodeOUs.Enable is set to true, this enables the identify classification. Then, client (peer) identifiers are defined by setting the following properties for the NodeOUs.ClientOUIdentifier (NodeOUs.PeerOUIdentifier) key:

1. OrganizationalUnitIdentifier: Set this to the value that matches the OU that the x509 certificate of a client (peer) should contain.
2. Certificate: Set this to the CA or intermediate CA under which client (peer) identities should be validated. The field is relative to the MSP root folder. It can be empty, meaning that the identity’s x509 certificate can be validated under any CA defined in the MSP configuration.

When the classification is enabled, MSP administrators need to be clients of that MSP, meaning that their x509 certificates need to carry the OU that identifies the clients. Notice also that, an identity can be either a client or a peer. The two classifications are mutually exclusive. If an identity is neither a client nor a peer, the validation will fail.

Finally, notice that for upgraded environments the 1.1 channel capability needs to be enabled before identify classification can be used.

MSP通道设置

At the genesis of the system, verification parameters of all the MSPs that appear in the network need to be specified, and included in the system channel’s genesis block. Recall that MSP verification parameters consist of the MSP identifier, the root of trust certificates, intermediate CA and admin certificates, as well as OU specifications and CRLs. The system genesis block is provided to the orderers at their setup phase, and allows them to authenticate channel creation requests. Orderers would reject the system genesis block, if the latter includes two MSPs with the same identifier, and consequently the bootstrapping of the network would fail.
在系统产生时，需要指定出现在网络中的所有msp的验证参数，并将其包含在系统通道的创世块中。回想一下，MSP验证参数包括MSP标识符、信任证书的根、中间CA和管理证书，以及OU规范和CRLs。系统创世块在它们的设置阶段提供给orderers，并允许它们对通道创建请求进行身份验证。Orderers将拒绝系统创世块，如果后者包含两个具有相同标识符的MSPs，因此，网络的引导将失败。
For application channels, the verification components of only the MSPs that govern a channel need to reside in the channel’s genesis block. We emphasize that it is the responsibility of the application to ensure that correct MSP configuration information is included in the genesis blocks (or the most recent configuration block) of a channel prior to instructing one or more of their peers to join the channel.
对于应用程序通道，只有管理通道的MSPs的验证组件需要驻留在通道的genesis块中。我们强调，应用程序的责任是确保正确的MSP配置信息包含在通道的起源块(或最近的配置块)中，然后指示一个或多个对等节点加入通道。
When bootstrapping a channel with the help of the configtxgen tool, one can configure the channel MSPs by including the verification parameters of MSP in the mspconfig folder, and setting that path in the relevant section in configtx.yaml.

Reconfiguration of an MSP on the channel, including announcements of the certificate revocation lists associated to the CAs of that MSP is achieved through the creation of a config_update object by the owner of one of the administrator certificates of the MSP. The client application managed by the admin would then announce this update to the channels in which this MSP appears.

最佳实践

In this section we elaborate on best practices for MSP configuration in commonly met scenarios.
在本节中，我们将详细介绍常见场景中MSP配置的最佳实践。
1) Mapping between organizations/corporations and MSPs
组织/公司和MSPs之间的映射
We recommend that there is a one-to-one mapping between organizations and MSPs. If a different type of mapping is chosen, the following needs to be to considered:
我们建议组织和MSPs之间要有一对一的映射。如果选择了不同类型的映射，需要考虑以下内容:

• One organization employing various MSPs. This corresponds to the case of an organization including a variety of divisions each represented by its MSP, either for management independence reasons, or for privacy reasons. In this case a peer can only be owned by a single MSP, and will not recognize peers with identities from other MSPs as peers of the same organization. The implication of this is that peers may share through gossip organization-scoped data with a set of peers that are members of the same subdivision, and NOT with the full set of providers constituting the actual organization.
• Multiple organizations using a single MSP. This corresponds to a case of a consortium of organizations that are governed by similar membership architecture. One needs to know here that peers would propagate organization-scoped messages to the peers that have an identity under the same MSP regardless of whether they belong to the same actual organization. This is a limitation of the granularity of MSP definition, and/or of the peer’s configuration.
  2) One organization has different divisions (say organizational units), to which it wants to grant access to different channels.

一个组织有不同的部门(比如组织单位)，它希望向这些部门授予访问不同渠道的权限。
Two ways to handle this:

• Define one MSP to accommodate membership for all organization’s members. Configuration of that MSP would consist of a list of root CAs, intermediate CAs and admin certificates; and membership identities would include the organizational unit (OU) a member belongs to. Policies can then be defined to capture members of a specific OU, and these policies may constitute the read/write policies of a channel or endorsement policies of a chaincode. A limitation of this approach is that gossip peers would consider peers with membership identities under their local MSP as members of the same organization, and would consequently gossip with them organization-scoped data (e.g. their status).定义一个MSP以容纳所有组织成员的成员。
• Defining one MSP to represent each division. This would involve specifying for each division, a set of certificates for root CAs, intermediate CAs, and admin Certs, such that there is no overlapping certification path across MSPs. This would mean that, for example, a different intermediate CA per subdivision is employed. Here the disadvantage is the management of more than one MSPs instead of one, but this circumvents the issue present in the previous approach. One could also define one MSP for each division by leveraging an OU extension of the MSP configuration.定义一个MSP来表示每个部门。
  3) Separating clients from peers of the same organization.

将客户端与同一组织的peer分离。
In many cases it is required that the “type” of an identity is retrievable from the identity itself (e.g. it may be needed that endorsements are guaranteed to have derived by peers, and not clients or nodes acting solely as orderers).
在许多情况下，需要从身份本身中检索标识的“类型”(例如，可能需要背书是由peer节点派生的，而不是客户机或仅作为orderers的节点)。
There is limited support for such requirements.
对这种要求的支持是有限的。
One way to allow for this separation is to create a separate intermediate CA for each node type - one for clients and one for peers/orderers; and configure two different MSPs - one for clients and one for peers/orderers. Channels this organization should be accessing would need to include both MSPs, while endorsement policies will leverage only the MSP that refers to the peers. This would ultimately result in the organization being mapped to two MSP instances, and would have certain consequences on the way peers and clients interact.
允许这种分离的一种方法是为每个节点类型创建一个单独的中间CA—一个用于客户端，一个用于peer/orderer;并配置两个不同的msp—一个用于客户端，一个用于peer/orderer。该组织访问的通道将需要包含两个MSP，而背书策略将仅利用peer的MSP。这最终会导致组织被映射到两个MSP实例，并对peer和客户端交互的方式产生一定的影响。
Gossip would not be drastically impacted as all peers of the same organization would still belong to one MSP. Peers can restrict the execution of certain system chaincodes to local MSP based policies. For example, peers would only execute “joinChannel” request if the request is signed by the admin of their local MSP who can only be a client (end-user should be sitting at the origin of that request). We can go around this inconsistency if we accept that the only clients to be members of a peer/orderer MSP would be the administrators of that MSP.

Another point to be considered with this approach is that peers authorize event registration requests based on membership of request originator within their local MSP. Clearly, since the originator of the request is a client, the request originator is always deemed to belong to a different MSP than the requested peer and the peer would reject the request.

4) Admin and CA certificates.
管理和CA证书
It is important to set MSP admin certificates to be different than any of the certificates considered by the MSP for root of trust, or intermediate CAs. This is a common (security) practice to separate the duties of management of membership components from the issuing of new certificates, and/or validation of existing ones.
重要的是，要将MSP管理证书设置为与MSP考虑的信任根证书或中间CAs的任何证书不同。这是一种常见的(安全)实践，将成员组成部分的管理职责与新证书的颁发和/或现有证书的验证分离开来。

5) Blacklisting an intermediate CA.
将一个中间CA列入黑名单
As mentioned in previous sections, reconfiguration of an MSP is achieved by reconfiguration mechanisms (manual reconfiguration for the local MSP instances, and via properly constructed config_update messages for MSP instances of a channel). Clearly, there are two ways to ensure an intermediate CA considered in an MSP is no longer considered for that MSP’s identity validation:

Reconfigure the MSP to no longer include the certificate of that intermediate CA in the list of trusted intermediate CA certs. For the locally configured MSP, this would mean that the certificate of this CA is removed from the intermediatecerts folder.
Reconfigure the MSP to include a CRL produced by the root of trust which denounces the mentioned intermediate CA’s certificate.
In the current MSP implementation we only support method (1) as it is simpler and does not require blacklisting the no longer considered intermediate CA.

6) CAs and TLS CAs
证书颁发机构和TLS证书颁发机构
MSP identities’ root CAs and MSP TLS certificates’ root CAs (and relative intermediate CAs) need to be declared in different folders. This is to avoid confusion between different classes of certificates. It is not forbidden to reuse the same CAs for both MSP identities and TLS certificates but best practices suggest to avoid this in production.
需要在不同的文件夹中，声明MSP标识的根CAs和MSP TLS证书的根CAs(以及相关的中间CAs)。这是为了避免不同类型的证书之间的混淆。对于MSP标识和TLS证书，并不禁止重用相同的CAs，但最佳实践建议在生产中避免这种情况。