fabric源码解析9——文档翻译之MSP

fabric源码解析9——文档翻译之MSP

只看代码而不读文档，无论是对自己的理解，还是对文章的释明，都容易使之存在困惑之处。因此在此先写fabric官方文档中几个相关主题的译文，作为自己相关主题文章的预热。水平有限，尽量直译，生硬之处很多，错误之处估计也不少而不自知。译文中括号内若是中文，则为解释，若为英文，则是专用名词。

个人觉得fabric的官方文档不好：

文档用语不简。作为说明性文档，个人认为语言应该尽量简明短小，以陈述句为主。而现在的官方文档中，充斥着大量长句，定状语句和指代名词。如果英语水平不高，比如我，读起来相当费劲且容易理解错。在此吐槽一下。

以下是Fabric文档中与MSP相关的主题译文：

安全和会员服务

Fabric加固了一个所有参与者都有一个明确身份的交易网络，并以此网络为基础。公匙基础设施（PKI，Public Key Infrastructure）被用来生成加密证书（cryptographic certificates），这些被试用于组织、网络的构成、终端用户或客户端的应用。结果，数据权限控制可以在广域网络（broader network）和层级频道（channel levels）被操作和支配。这个fabric的“授权”的概念，与channel的存在与能力相配对，帮助实现了隐私和机密为主要考虑的地址方案（address scenarios）

看Membership Service Providers (MSP)主题去更好的理解加密操作，签名，校验，认证（cryptographic implementations, and the sign, verify, authenticate）在fabric中的应用。

Membership Service Providers (MSP)

该文档着力于提供关于MSP的安装，最好的实践的细节。

MSP是一个着眼于提供一个会员关系操作构架的抽象，作为系统的一个组成部分。

特别的，MSP抽象了所有加密机制和协议，隐藏了存在的争论（issuing）、验证证书和用户认证。一个MSP可能定义它自己的一套身份标识，验证规则，签名的生成和认证方法。

fabric区域链网络可能会被一个或多个MSP管理，他们提供了模块化的会员操作和在不同的会员关系标准和构架间协同工作的能力。

下面的文章我们详细的介绍MSP的操作体系，并讨论最好的MSP的相关用途的练习。

MSP配置

为了启动一个MSP，它的配置文件必须在每个peer和orderer（去使能peer并排序签名）的本地中被指定，开启频道上的peer，orderer，客户端的身份认证，所有会员各自的签名认证。

首先，MSP需要指定一个名字在网络中代表自己，如msp1,org2等。这个名字在其会员关系规则中代表一个channel中的一个共同体、组织或者组织分部。也被引用作为MSP对象的ID（MSP Identifier）。每个MSP的ID是唯一的。例如，若检测出来存在两个相同ID的MSP实例存在于系统初创的channel，orderer将会启动失败。

MSP的默认操作的情况下，一个参数集合需要被指定（也就是一个MSP需要哪些成员），用于身份认证（identity (certificate) validation）和签名认证（signature verification）。这些参数由RFC5280指定，包括：

• 一个自己签名出的证书（self-signed）列表，用于作为信任机制的根证书列表（root of trust，这个根证书应该是：把自己签出来的证书分发给他人，他人拿着证书来核对时，在根证书列表中查询核对，如果存在证书存在在这个列表中，则说明这个人是受信任的）。该列表可以用root CAs表示。
• 一个X.509证书列表，用于代表（作为）中间人-CAs证书这个用于证书验证（certificate validation）的提供者（即所说的CA证书）。这些CA证书应该是在root of trust中被鉴定过的。中间人CA证书是可选的（参数）。该列表可以用intermediate CAs表示。
• 一个X.509证书列表，该列表中的证书包含可验证的证书路径，而这些路径对应指向root of trust中的证书。所以该证书列表代表着MSP的管理员的角色。这些证书的拥有者被允许发起请求改变该MSP的配置（即改变root CAs，中间人CAs）。该列表可以用administrator CAs表示。
• 一个组织单位列表，MSP有效的成员应该包含在这些组织单位的X.509证书中。这是一个可选配置参数，当多个组织使用同一个root CAs，intermediate CAs并为组织成员保留了一个OU字段时，才会使用这个列表。该列表可以OU List表示。
• 一个废除证书列表，每一个证书都可以对应到root CAs或intermediate CAs（废除的证书也是从这里面来的，而不是凭空产生的），这是一个可选参数。该列表可以用CRLs表示。
• 一个用于TLS的X.509根证书列表（self-signed (X.509) certificates，TLS root of trust）。
• 一个用于TLS的X.509中间人证书列表。这是一个可选参数。

对于一个MSP对象实例来说，有效的身份需要满足以下条件：
* X.509格式的证书，并包含可验证的证书所在路径，该路径对应到root CAs。
* 不包括在任何一个CRL中。
* 在X.509格式的证书结构体中的OU字段里，存在一个或多个属于OU List的组织单位。

更多的MSP身份的有效性的信息，请阅读MSP Identity Validity Rules。

除了验证相关参数，对于MSP来说，使结点能够去签名或授权，你需要指定：

• 用于结点签名的签名匙（signing key），当前只支持ECDSA keys。
• 结点的X.509证书，该证书必须是在MSP的一些列参数中（root CAs，中间人CAs中）的有效的证书。

需要重点注意的是，MSP中的身份信息永不消失，只能被加入到CRLs中。此外，当前不支持强制废除TLS的证书。

如何生成MSP证书和它们的签名匙

为了生成X.509证书去填MSP的配置，应用我们可以使用openssl。我们强调一下，fabric不支持证书中包含RSA keys。

替代的，我们可以使用cryptogen tool，在Getting Started中有详述。

Hyperledger Fabric CA这个项目也可以用来生成MSP配置所需的keys和证书。

MSP setup on the peer & orderer side

为了建立本地MSP（local MSP），无论是peer还是orderer上的，管理者都要创建一个目录，如$MY_PATH/mspconfig，包含六个子目录和一个文件：
1. admincerts目录，包含pem文件，每个pem文件对应一个administrator证书，即administrator CAs。
2. cacerts目录，包含每个的pem对应一个root证书，即root CAs。
3. （可选）intermediatecerts目录，对应中间人CA。
4. （可选）config.yaml文件，包含关于组织单位OU的信息。会定义如

Channel MSP setup

在系统初创的时候，出现在网络中所有MSP的验证元素（即各种证书，配置）都需要被指定过（即必须已经存在），并被包含到系统channel的创世纪块（genesis block）中。回忆一下，MSP验证元素由MSP身份标识（MSP identifier），root CAs，intermediate CAs，admin CAs，OU List，CRLs。在orderer进行体系解析时，系统的创世纪块被用于orderer，据此orderer被允许去认证channel的创建请求（等于说orderer有认证的材料了，如果创建channel的请求合法才通过该请求）。如果创世纪块包含了两个相同身份标识的MSP，orderer将拒绝此块，自然的，整个网络的引导建立也会失败。

对于应用（application）的channel，其验证的各个组成部分，也就是（只能是）管理该channel的MSP，必须存在于channel的创世纪块中。我们强调，在channel创建一个或多个peer加入该channel之前，保证包含在该channel的创世纪块（或者是最新的配置块）中的MSP配置信息的正确性是应用的责任。

当在configtxgen工具（configtxgen tool）帮助下引导启动一个channel时，通过将MSP的验证元素（如root CAs，中间人CAs等）放置到MSP专用的配置目录，并在configtx.yaml文件中设置相应的选项，我们可以使用configtxgen工具配置该channel的MSP。

重新配置一个channel上的MSP，包括该MSP相关的废止证书列表（CRLs）的公告，通过该MSP中的Admin CAs中的一员（即拥有Admin CA证书的结点，也叫做admin结点）创建一个配置更新对象（config_update object），可以实现。如此之后，被admin管理的客户端应用将宣布这个针对该MSP所在的channel的更新。

Best Practices

在这个部分，我们将详述MSP配置在一般情况下的最好的实践（best practices）。

1）组织单位和MSP之间的映射

我们要求MSP与组织（organizations）之间是一对一的映射。如果选择一个不同的映射类型，需要考虑如下内容：

• 一个组织雇佣多种（个）MSP。这对应了一个组织包含多个不同部门，出于独立管理或隐私（权限）的原因，每个部门有一个MSP代表的情况。在这种情况中，一个peer只能被一个MSP所拥有（代表一个层级上的一个部门），也不能从同一组织中其他的MSP中识别出其他peer的身份。这样做的意义在于，一个结点可能通过gossip只与从属于该结点的部门（子部门）分享组织范围内的数据，而不是与组织内的所有成员分享。
• 多个组织使用一个MSP。这对应了多个组织以类似的关系被管理所组成一个的协作整体（consortium，如多个学校组织联合起来成立一个学校联盟）的情况。这里我们需要知道的是，一个组织中的多个peer将传递组织范围内的消息给同属与同一个MSP下的peer，而且会忽略这些peer是否是属于自己的同一个组织。这是一个MSP定义的颗粒度（granularity）和peer结点配置的局限。（最后这句话不太理解）

2）一个组织有不同的部门（称为组织单位-organizational units），针对其中的一个想给予多个不同channel访问权限

两种方法：

• 定义一个MSP，将所有组织的成员纳入到该MSP的成员关系（membership）中（即将所有成员的证书之类的数据纳入到该MSP）。该MSP的配置将由root CAs，intermediate CAs和admin CA组成；会员身份将包括所有的OU。策略（Policies）被定义为获取指定OU的所有成员，该策略可以用于组成一个channel的读写（read/write）策略，或者一个chaincode的背书（endorsement）策略。该方法的一个限制就是gossip peer会把那些在其本地MSP中的peer（即gossip结点的本地的MSP中所有成员）当作是同一个组织内的成员，结果也自然会向这些结点传播组织范围内的数据（比如他们的状态）。
• 为每一个部门定义一个MSP。这将涉及到每一个部门的指定，即每一个部门都需要指定root CAs， intermediate CAs和admin Certs，这样的话，在各个MSP之间没有重叠的证书路径。这就是说，比如，不同的intermediate CA对应不同的子部门。这里的缺点是要管理多个MSP而不是仅仅的一个，但这规避了上一种方法所出现的问题。我们也可以通过使用MSP的OU扩展为每一个部门定义一个MSP。

3）从同一个组织中的众多peer中分离客户端

在很多情况下，可以从身份自身获取身份的类型是需要的（如背书被担保是由peer这种类型的结点产生，而不是客户端或扮演orderer的结点）

以下是对该需求的有限的支持。

一种实现这种分离的方法是为每一类结点都创建一个单独的intermediate CA —— 一个客户端的，一个peer/orderer的；配置两个不同的MSP —— 一个客户端的，一个peer/orderer的。该组织应该（可以）访问的频道，需要同时包含这两个MSP，而背书策略（定义）则只使用代表peer结点的MSP。最终，将会把这个组织映射到两个MSP实例中，自然而然的peer与client可以相互作用（交流）了。

Gossip不会被大幅影响，因为同一个组织的所有peer依然属于同一个MSP。peer们结点可以限制某些系统chaincode的运行到本地的基于策略的MSP。例如，peer将只会执行“joinChannel”请求，如果该请求被客户端类型的MSP（终点用户位于请求的起源处）的admin签名的话。我们可以绕开这点的前后矛盾，如果我们接受，对于peer/orderer的MSP来说，客户端能成为该MSP成员的只能是该MSP的admin。

此种方法另一点需要考虑是，基于请求源头在它本地MSP中所处的地位，peer授权事件注册请求。很明显，因为请求源头是客户端，相较于被请求的peer，请求源头总是注定属于不同的MSP，并且被请求的peer将拒绝该请求。

4）Admin和其证书

MSP的admin证书是独一无二的，与该MSP中root CAs或者intermediate CAs中的证书都不同。这是一种通用的实践：将管理成员关系的责任从证书的验证讨论中脱离出来。

5）intermediate CA黑名单

正如前文提到的，重新配置一个MSP通过重新配置机制（对本地MSP实例手工重配，或者通过构建一个channel中MSP实例的一个配置升级消息）实现。很明显，这里有两种方法去确保一个intermediate CA被拉入黑名单：

1. 重新配置一个不再包含黑名单证书的MSP。对于本地配置，这意味着从intermediatecert CAs目录中移除黑名单证书。
2. 重新配置MSP的CRL，将黑名单证书从root CAs中加入到CRL中（也就是拉黑）。

当前的MSP操作，我们仅支持第一种方法，这种方法更简单，也不需要拉黑不信任的证书。

6）CAs和TLS CAs

MSP的root CAs与TLS的root CAs（相对于中间人CA来说）需要定义在不同的目录中。这样是为了避免在两种不同类型的证书之间产生混淆。关于这点来说，不禁止，但是最好在产品中避免。