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，但最佳實踐建議在生産中避免這種情況。