1

I want 4 intermediate CAs for a peer organization: ICA1, ICA2, ICA3 and ICA4 - one for every Node OU (peer, orderer, admin and client).

Let's say if I place ICA1 as the cacerts attribute in the Peer Node OU of the channel configuration, then will a peer identity under a different ICA (ICA2, ICA3 or ICA4), be able to satisfy a policy which says signature of "OrgMSP.peer"?

  • If yes, then how can I make sure that only the set of roles under a specific department can satisfy a policy given by OrgMSP.<role>? I do not wish to create an MSP definition for every department or team in the organization. So, is it achievable without that?
  • If no, then can I also specify a group of ICAs in the Node OU configuration of the channel for a particular OU so that I can leverage very complex policies like "Signature of one-of 'OrgMSP.peer'" and let's say that here, cacerts property for the peer OU will be ICA1 and ICA3. Is this achievable?
Chintan Rajvir
  • 689
  • 6
  • 20

1 Answers1

2

When you specify the nodeOU configuration, you may simply supply the OU name corresponding to the role (it sounds like this is what you've done), or you may specify the OU name and an issuing certificate. This could be a root CA, or an intermediate CA, but in either case, in order to satisfy that role, the certificate must have both the OU specified and be issued by the specified CA.

Note: Each role/certificate pair informs the MSP of a valid issuer for certificates satisfying a role. So, if you have CA1, CA2, ICA1, and ICA2, you may specify a given role twice, once for CA1 and once for ICA2. Then only certificates (directly) issued by either CA1 or ICA2 may satisfy the role.

If you look in the sample MSP configuration, you can see that certificate may be specified, but is omitted by default.

You can see more details about how this certificate is used in the actual proto documentation.

Jason Yellick
  • 1,584
  • 9
  • 12
  • So, this means that if I create policy `OrgMSP.admin` and give ICA1 as the `cacert` for `admin` role in OU definition, then only `admin` identities under ICA1 will be able to perform the operation, right? Let's say `admin` type identities under ICA2 will not be able to satisfy that policy. Correct? If I am not wrong, `cacerts` value could be set to only one PEM certificate, right? – Chintan Rajvir Jun 17 '20 at 04:27
  • If I edit the `FabricNodeOUs` message block here: https://github.com/hyperledger/fabric-protos/blob/9944f8f73cfe0585a477f4b7d56a090374d0c7b6/msp/msp_config.proto#L196:L211 then I can have custom roles too. Right? Which is currently not actually supported by Fabric. But are there any other implications, on some different components of the Fabric? – Chintan Rajvir Jun 17 '20 at 04:31
  • Yes, if you specify a CA certificate associated to a particular NodeOU, then that cert and OU combination is considered valid for that role. Note, you can specify the role multiple times, and have multiple issuing certs. You may pick custom OU names for the roles, but you may not specify custom roles. If you want arbitrary roles, you can construct policies based on OU, not on role. – Jason Yellick Jun 17 '20 at 15:24
  • I understood. Does your last statement mean I can have something like `OR('OrgMSP.dept1')` as a policy, where `dept1` is an OU in the channel MSP configuration for every organization? Because roles are fixed: `peer`, `orderer`, `admin` and `client`, but like you told, OU can be cutomized as per our wish. So, is the given understanding good? – Chintan Rajvir Jun 18 '20 at 04:39
  • 1
    The answer is a little nuanced. It's possible to craft policies directly using their JSON/protobuf representation which refer to OUs. But, the "policy language" used by the CLI tools like `configtxgen` or `peer` only support referencing roles. It shouldn't be too difficult to extend the policy language, and there is an open work item for it https://jira.hyperledger.org/browse/FAB-15296 but for now, although it's possible internally to define a policy based on OU, we have no good way to externally represent it. – Jason Yellick Jun 18 '20 at 13:08
  • Does that imply, I can simply modify channel policies as `peer channel update` later on once the channel is functioning, instead of adding the custom OUs while creating the channel.tx file or will that be still invalidated until I modify the fabric code? – Chintan Rajvir Jun 18 '20 at 13:19
  • 1
    For most use cases, the roles of 'admin', 'peer', 'client', and 'orderer' are adequate. If this addresses your needs, I would use those. If you really need arbitrary OU based policies, you can define arbitrary OUs associated to particular issuers, and manually (in code) craft custom policies using these OUs. I recommend against the latter if you can avoid it, as it is much more work. As far as whether these things must be done at bootstrap, or can be modified later -- in general, any parameters, like MSPs and policies set at bootstrap can be updated later. It's just a bit more painful. – Jason Yellick Jun 18 '20 at 17:47