Date   

Re: problem with proving identity using X.509 certificate

Gari Singh <garis@...>
 

The only way to call chaincode is through the peer. When a client submits a proposal, the peer authenticates the caller by verifying the signature on the proposal using the identity extracted from the creator field in the proposal. The signature can only be verified if the caller possesses the private key which matches the public key in the creator field. The peer then calls the chaincode and the GetCreator() function is a convenience mechanism for getting the identity of the caller. If you are super paranoid, the signed proposal is also available within chaincode so you could again verify the signature, but this would be overkill in my opinion.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: "fabric@..." <fabric@...>
From: "Siddharth Jain"
Sent by: fabric@...
Date: 03/27/2020 12:27AM
Subject: [EXTERNAL] [Hyperledger Fabric] problem with proving identity using X.509 certificate


Hello - If I am not mistaken, Fabric chaincode uses the X.509 certificate of the caller to ID the caller. But the public certificate is meant to be shared and not a secret so what prevents someone (tom) from impersonating as someone else (jerry) using their X.509 certificate?


Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 03/27/2020 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When:
Friday, 27 March 2020
6:00am to 7:00am
(GMT+00:00) Europe/London

Where:
https://zoom.us/j/6223336701

Organizer:
a_o-dowd@... +441962816761

Description:
Documentation workgroup call.
Agenda, minutes and recordings: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group


problem with proving identity using X.509 certificate

Siddharth Jain
 

Hello - If I am not mistaken, Fabric chaincode uses the X.509 certificate of the caller to ID the caller. But the public certificate is meant to be shared and not a secret so what prevents someone (tom) from impersonating as someone else (jerry) using their X.509 certificate?


Re: #hyperledger-fabric Problems after peer channel update: PANI 044 Cannot commit block to the ledger due to config currently at sequence 0, cannot validate config at sequence 2 #hyperledger-fabric

Magno Alves Cavalcante
 

Hello All !
I hope you are in safe and healthy.

I opened an issue at https://jira.hyperledger.org/browse/FABB-147 with my considerations and log files about this problem.

I will appreciate if you help voting in this issue to be analysis by Fabric Team,

Thanks,
Magno Cavalcante


Re: #fabric Impossible instantiate chaincode due to PANIC ERROR on peer: unexpected Previous block hash #fabric

Magno Alves Cavalcante
 

Hello All !
I hope you are in safe and healthy.

I opened an issue at https://jira.hyperledger.org/browse/FABB-147 with my considerations and log files about this problem.

I will aprecciate if you may help voting in this issue to be analisys by Hyperledger Fabric Team.

Thanks,
Magno Cavalcante


Limiting dissemination of hashes of private collection keys and values?

Victor Dods
 

Hi all, I'm wondering if there's a mechanism for specifying that the hashes of private collection keys and values should not be disseminated beyond the peers of that private collection.  Basically my use case is such that I know that a particular private collection's data will never be used outside of the peers of that collection, and the issue regarding having to put nonces into private values and KEYS in particular is a total pain.  Because I don't need this extra-collection verification, I don't want the overhead that comes along with that.

Or failing that, what is a reasonable scheme for putting nonces into the keys of a private collection?  It can't be truly random, otherwise there's no way to recover the nonced key (e.g. "abc@...%00<random-nonce>") from the "bare" key (e.g. "abc@...").  One could make it deterministic by making the nonce a the hashed value of the bare key, but then if an attacker knows which hash function you're using, they could brute force the key in smaller spaces (phone numbers, email addresses, etc).  You could use an HMAC with a specified key, but then you (1) have to manage that HMAC key, (2) have to tie the lifetime of that HMAC key to the lifetime of the key/value pair, and (3) have to use the same HMAC key for all key/value pairs OR have some scheme for using multiple HMAC keys and mapping them to the key/value pairs.  Basically the problem of having to manually embed the nonces in the keys and values really gets in the way.

One thing that comes to mind is using truly random nonces for the keys, and then doing a GetPrivateDataByPartialCompositeKey using the bare key to deal with not knowing the nonce, but then you're in the situation where you've done a range-based query, and are then subject to the limitations detailed here: https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data-arch.html#querying-private-data which is a total pain.

Anyway, I'd generally like to hear about how people have been dealing with this issue.

As a side comment for the Fabric maintainers -- I've brought this issue up in the past, and so have others -- why not have Fabric do this sort of nonce bookkeeping automatically?  If everyone is responsible for manually implementing it themselves, how many people are (1) going to do it at all and (2) going to do it correctly?

An idea for how this could work: 
- If a transaction is going to write any private data, require a RNG seed be set using a new SeedRNG method in the chaincode stub (otherwise the transaction fails with error).  This RNG seed would be passed into the endorsing peer via the transient data field.  Potentially the name of the HMAC scheme should be a channel configuration value.
- When a private data write is done, generate a pair of HMAC keys from the seeded RNG, one for the key and one for the value, and keep them in parallel with the key and value.  Thus the diagram in this section https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data/private-data.html#what-is-a-private-data-collection would have a quadruple (k1, k1HMACkey, secret-value, secret-value-HMACkey) for Private State.
- Then instead of hash(k1) and hash(secret-value) being stored in the Channel State, it's HMAC(k1, k1HMACkey) and HMAC(secret-value, secret-value-HMACkey), which can be verified just as easily as before.
- Finally, all the stub's Get/Put/Del methods for private data operate on the "bare" key/value pairs as expected and ideally desired, and there's no interference from the details of the HMAC scheme, and all is well in the world again.

I'd be curious to hear thoughts on this from Fabric maintainers and other interested people.

PS: Thanks to Mike Lodder for educating me on HMACs and other security mechanisms.


Documentation Workgroup: Agenda for Friday, 27 March

Anthony O'Dowd <a_o-dowd@...>
 

All,

We will hold the documentation workgroup call this Friday -- with both an Eastern hemisphere and Western hemisphere call. Please feel free to come along, especially if in these difficult times you'd like to have a chat with some friendly people. If you're in Europe and wish to join the Western hemisphere call, it's still an hour earlier than usual! With the daylight savings shift occurring at the weekend, we in Europe will be moving back to the regular time next week!

You can read all about last week's call at https://wiki.hyperledger.org/display/fabric/2020+03+20+DWG+Agenda It included the now regular V2.x status update from Pam and Joe. It also included a very practical walk through from Joe on how to do a small doc change, including the vital DCO step. Watch the recording if you'd like to do a small doc change - it's easy!

It's also worth watching the discussion on some super material on Hyperledger Fabric and peer and chaincode internals produced by some of our Fabric colleagues in Australia. We discussed how the material might best be socialized with a wider audience.  Look out for more discussion on the contributors call.

You can catch up with the recording: https://wiki.hyperledger.org/display/fabric/Recordings

You'll see that there are lots of interesting items for this week. See  https://wiki.hyperledger.org/display/fabric/2020+03+27+DWG+Agenda for the full agenda.

Please feel free to contribute using the wiki, including helping to build next week's agenda: https://wiki.hyperledger.org/display/fabric/2020+04+03+DWG+Agenda

Thanks!

Pam, Anthony,  Joe, Nik

Meeting Details
-------------
Please use the following link to attend the meeting:  https://zoom.us/j/6223336701

The meeting times are as follows: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Meeting 121A: Friday 27 March
                   1130 India Standard Time
                   1400 China Standard Time
                   1500 Japan Standard Time
                   1700 Australia Eastern Time
                   1400 Singapore Time
                   1000 Gulf Standard Time
                   0900 Moscow Standard Time
                   0600 Greenwich Mean Time
                   0700 Central European Time    

Meeting 121B: Friday 27 Mar
              1100 Central Daylight Time
                   1200 Eastern Daylight Time
                   0900 Pacific Daylight Time
                   1400 Brasil Time (BRT)
                   1600 Greenwich Mean Time
                   1700 Central European Time
                   1800 Moscow Standard Time


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Upcoming Event: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere - Fri, 03/27/2020 6:00am-7:00am #cal-reminder

fabric@lists.hyperledger.org Calendar <fabric@...>
 

Reminder: Hyperledger Fabric Documentation Workgroup call - Eastern hemisphere

When: Friday, 27 March 2020, 6:00am to 7:00am, (GMT+00:00) Europe/London

Where:https://zoom.us/j/6223336701

View Event

Organizer: Anthony O'Dowd a_o-dowd@... +441962816761

Description: Documentation workgroup call.
Agenda, minutes and recordings: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group


Two ways of registering a user in Node SDK?

Siddharth Jain
 

Looking at the docs for fabric-ca-client Node library, it seems there are 2 ways one could register a new user.

register(req, registrar)

Register the member and return an enrollment secret.
Parameters:
Name Type Description
req RegisterRequest The RegisterRequest
registrar User . The identity of the registrar (i.e. who is performing the registration)
Returns:
The enrollment secret to use when this user enrolls

create(req, registrar)

Create a new identity with the Fabric CA server. An enrollment secret is returned which can then be used, along with the enrollment ID, to enroll a new identity. The caller must have `hf.Registrar` authority.
Parameters:
Name Type Description
req IdentityRequest The IdentityRequest
registrar User The identity of the registrar (i.e. who is performing the registration).
Returns:
Return the secret of this new identity

Is this correct?
Could someone explain why two methods are supported?

And is there a method to check if a user is already registered before trying to enroll them?

getOne(enrollmentID, registrar)

Get an identity. The caller must have `hf.Registrar` authority.
Parameters:
Name Type Description
enrollmentID string Required. The enrollment ID which uniquely identifies an identity
registrar User Required. The identity of the registrar (i.e. who is performing the registration).
Returns:

but not sure. What does the ServiceResponse contain if user is registered vs. not?
Create a new identity with the Fabric CA server. An enrollment secret is returned which can then be used, along with the enrollment ID, to enroll a new identity.
hyperledger.github.io


Re: Hyperleger Fabric 2.0 - How to execute block Query throgh fabric-sdk-node client

Kumari Shweta
 

Thanks Gari for your quick response.

Yes fabric-sdk-node release 1.4's channel class has all these methods.

I am using Hyperleger fabric 2.0 with fabric-sdk-node(Beta).The channel class in beta version is updated a lot
and block related queries are removed from channel class.

I can see Block query in go and java sdk but not in node.

https://github.com/hyperledger/fabric-sdk-java/blob/master/src/main/java/org/hyperledger/fabric/sdk/BlockInfo.java
https://github.com/hyperledger/fabric-sdk-go/blob/master/pkg/client/ledger/ledger.go

Kindly Suggest.

Thanks a lot,

Regards,
Shweta

-----Original Message-----
From: Gari Singh <garis@...>
Sent: Wednesday, March 25, 2020 5:58 PM
To: Kumari Shweta <kumari.shweta@...>
Cc: fabric@...
Subject: Re: [Hyperledger Fabric] Hyperleger Fabric 2.0 - How to execute block Query throgh fabric-sdk-node client

[CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.]

The are all available as methods on the Channel class: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhyperledger.github.io%2Ffabric-sdk-node%2Frelease-1.4%2FChannel.html&;data=02%7C01%7Ckumari.shweta%40hcl.com%7C6640ba33efe74e17a3fb08d7d0b7f116%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C1%7C637207360755222169&amp;sdata=UGvtQCtqz2cyD3BeYLXSFN1515RUVrbIzstMNSJrtW8%3D&amp;reserved=0

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: fabric@...
From: kumari.shweta@...
Sent by: fabric@...
Date: 03/25/2020 06:12AM
Subject: [EXTERNAL] [Hyperledger Fabric] Hyperleger Fabric 2.0 - How to execute block Query throgh fabric-sdk-node client

Hi Team,

In Hyperleger Fabric 2.0 - How to queries QueryInfo, QueryBlock, QueryBlockByHash, QueryBlockByTxID, QueryTransaction and QueryConfig using fabric-sdk-node client. As I can see these methods in java and go sdk client but not in fabric-sdk-node. Kindly Suggest.

Regards,
Shweta


::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________


Re: Hyperleger Fabric 2.0 - How to execute block Query throgh fabric-sdk-node client

Gari Singh <garis@...>
 

The are all available as methods on the Channel class: https://hyperledger.github.io/fabric-sdk-node/release-1.4/Channel.html

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: fabric@...
From: kumari.shweta@...
Sent by: fabric@...
Date: 03/25/2020 06:12AM
Subject: [EXTERNAL] [Hyperledger Fabric] Hyperleger Fabric 2.0 - How to execute block Query throgh fabric-sdk-node client

Hi Team,

In Hyperleger Fabric 2.0 - How to queries QueryInfo, QueryBlock, QueryBlockByHash, QueryBlockByTxID, QueryTransaction and QueryConfig using fabric-sdk-node client. As I can see these methods in java and go sdk client but not in fabric-sdk-node. Kindly Suggest.

Regards,
Shweta


Hyperleger Fabric 2.0 -Life cycle endorsement with “Any Majority” is not working. #fabric-questions

Kumari Shweta
 

Chain code life cycle endorsement is not working when following changes made in configtx.yaml.

LifecycleEndorsement:
    Type: ImplicitMeta
    Rule: "ANY Endorsement"
Endorsement:
    Type: ImplicitMeta
    Rule: "ANY Endorsement"

Network contains:

  • one ordering service cluster with five orderers running Raft
  • three organizations (Org1, Org2 and Org3), each of which has one peer (peer0)
  • one channel mychannel is created, and peers in all organizations join the channel

Package SACC into chaincode package

  • Install chaincode package to peers of all the three organizations
  • Org1 approves chaincode package, and tries to commit the chaincode. It fails and getting Endorsement policy error.

But chain code should be commited as LifecycleEndorsement has "Any Endorsement" rule.


Hyperleger Fabric 2.0 - How to execute block Query throgh fabric-sdk-node client

Kumari Shweta
 

Hi Team,

In Hyperleger Fabric 2.0 -
 How to queries QueryInfo, QueryBlock, QueryBlockByHash,  QueryBlockByTxID, QueryTransaction and QueryConfig using fabric-sdk-node client.
As I can see these methods in java and go sdk client but not in fabric-sdk-node.
Kindly Suggest.

Regards,
Shweta
 


Re: RAFT based orderer crash #fabric-orderer #raft #fabric

Jean-Gaël Dominé <jgdomine@...>
 

Hi,

We had the same issue in our network.
To solve it, we found a way to persist the following folder in each orderer: /var/hyperledger/production/orderer/etcdraft
Without it restored after a restart, the orderer could not recover.

https://lists.hyperledger.org/g/fabric/topic/raft_orderer_issue/68228360?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,68228360
https://lists.hyperledger.org/g/fabric/topic/32652092

JG



Re: Signature Byte Isn't Valid Warning On Gossip After Addition of a New Org #hyperledger-fabric #configtxgen #raft

Yacov
 

this is not a "bug", this is a natural product of messages being gossiped out of order which is how gossip works.
This is a warning, not an error... if you see it repeatedly only then you should be worried



From:        "Faisal" <mfaisaltariq@...>
To:        fabric@...
Date:        03/24/2020 09:04 PM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Signature Byte Isn't Valid Warning On Gossip After Addition of a New Org #hyperledger-fabric #configtxgen #raft
Sent by:        fabric@...




Is this fixed in the 1.4.4 version LTS as we plan to upgrade the network in the coming weeks?




Re: Signature Byte Isn't Valid Warning On Gossip After Addition of a New Org #hyperledger-fabric #configtxgen #raft

Faisal
 

Is this fixed in the 1.4.4 version LTS as we plan to upgrade the network in the coming weeks?


Re: Signature Byte Isn't Valid Warning On Gossip After Addition of a New Org #hyperledger-fabric #configtxgen #raft

Yacov
 

Ignore it, it's a transient warning.

It happens if you get a state info message signed from a node which you did not yet receive its certificate.
You will eventually receive the certificate and be able to validate the signature.



From:        "Faisal" <mfaisaltariq@...>
To:        fabric@...
Date:        03/24/2020 03:16 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Signature Byte Isn't Valid Warning On Gossip After Addition of a New Org #hyperledger-fabric #configtxgen #raft
Sent by:        fabric@...




Environment

HLF (1.4.2)
Orderer (RAFT 3 Node)
2 Orgs (adding 3rd Org)
Running on multiple hosts (Docker Swarm Cluster)


Steps Followed

Configtx.yaml file contents

# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#

---
################################################################################
#
# Section: Organizations
#
# - This section defines the different organizational identities which will
# be referenced later in the configuration.
#
################################################################################
Organizations:
-&SFDA
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name:SFDAMSP

# ID to load the MSP definition as
ID:SFDAMSP

MSPDir:crypto-config/peerOrganizations/sfda.example.com/msp

# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
Policies:
Readers:
Type:Signature
Rule:"OR('SFDAMSP.admin', 'SFDAMSP.peer', 'SFDAMSP.client')"
Writers:
Type:Signature
Rule:"OR('SFDAMSP.admin', 'SFDAMSP.client')"
Admins:
Type:Signature
Rule:"OR('SFDAMSP.admin')"

# leave this flag set to true.
AnchorPeers:
# AnchorPeers defines the location of peers which can be used
# for cross org gossip communication. Note, this value is only
# encoded in the genesis block in the Application section context
-Host:peer0.sfda.example.com
Port:7051



crypto-config.yaml

# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#

# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:
# ---------------------------------------------------------------------------
# Org3
# ---------------------------------------------------------------------------
-Name:SFDA
Domain:sfda.example.com
EnableNodeOUs:true
Template:
Count:2
Users:
Count:1


1- Generated Certs

cryptogen generate --config=./crypto-config.yaml


2- Generated Configuration

configtxgen -printOrg SFDAMSP > ./SFDA.json


3- Copied Certs and configuration file into cli

4- Set environment variables for Orderer in CLI and channel name

5- Ran the following set of commands

```
peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA
configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config >config.json
```

Append the configuration of the new org in **SFDA.json**file into the **config.json**file. Change the file name and MSP in the below command accordingly.
```
jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"SFDAMSP":.[1]}}}}}' config.json ./SFDA.json > modified_config.json
```
Verify that the file has been updated
```
diff config.json modified_config.json
```

Package updated configuration into a block and then create a block that is delta of the old and new configuration
```
# Pack config again, create a delta of new and old config
configtxlator proto_encode --input config.json --type common.Config >original_config.pb
configtxlator proto_encode --input modified_config.json --type common.Config >modified_config.pb
configtxlator compute_update --channel_id $CHANNEL_NAME --original original_config.pb --updated modified_config.pb >config_update.pb
```
Convert the Delta Block **config_update.pb**block to JSON again, append the header to it and create a package again. Modify the channel name in the second command accordingly
```
configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate >config_update.json
echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . > config_update_in_envelope.json
configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope >update-block-env.pb
```


6- Set the environment for Peer0 Org1 and Signed the update-block-env.pb

peer channel signconfigtx -f update-block-env.pb


7- Set the environment for Peer0 Org2 and send the transaction to orderer

peer channel update -f update-block-env.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA


8- Deployed the peer and couchdbs
9- Installed chaincode on all peers including new peers added
10- Upgraded the chaincode with the new endorsement policy
11- Sent a transaction and received the following warning.



What would be the implications of this warning in the future or can it can be ignored?





Signature Byte Isn't Valid Warning On Gossip After Addition of a New Org #hyperledger-fabric #configtxgen #raft

Faisal
 

Environment

HLF (1.4.2)
Orderer (RAFT 3 Node)
2 Orgs (adding 3rd Org)
Running on multiple hosts (Docker Swarm Cluster)

Steps Followed
Configtx.yaml file contents

# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#

---
################################################################################
#
# Section: Organizations
#
# - This section defines the different organizational identities which will
# be referenced later in the configuration.
#
################################################################################
Organizations:
- &SFDA
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: SFDAMSP

# ID to load the MSP definition as
ID: SFDAMSP

MSPDir: crypto-config/peerOrganizations/sfda.example.com/msp

# Policies defines the set of policies at this level of the config tree
# For organization policies, their canonical path is usually
# /Channel/<Application|Orderer>/<OrgName>/<PolicyName>
Policies:
Readers:
Type: Signature
Rule: "OR('SFDAMSP.admin', 'SFDAMSP.peer', 'SFDAMSP.client')"
Writers:
Type: Signature
Rule: "OR('SFDAMSP.admin', 'SFDAMSP.client')"
Admins:
Type: Signature
Rule: "OR('SFDAMSP.admin')"

# leave this flag set to true.
AnchorPeers:
# AnchorPeers defines the location of peers which can be used
# for cross org gossip communication. Note, this value is only
# encoded in the genesis block in the Application section context
- Host: peer0.sfda.example.com
Port: 7051



crypto-config.yaml

# Copyright IBM Corp. All Rights Reserved.
#
# SPDX-License-Identifier: Apache-2.0
#

# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:
# ---------------------------------------------------------------------------
# Org3
# ---------------------------------------------------------------------------
- Name: SFDA
Domain: sfda.example.com
EnableNodeOUs: true
Template:
Count: 2
Users:
Count: 1


1- Generated Certs

cryptogen generate --config=./crypto-config.yaml


2- Generated Configuration

configtxgen -printOrg SFDAMSP > ./SFDA.json


3- Copied Certs and configuration file into cli

4- Set environment variables for Orderer in CLI and channel name

5- Ran the following set of commands

```
peer channel fetch config config_block.pb -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA
configtxlator proto_decode --input config_block.pb --type common.Block | jq .data.data[0].payload.data.config >config.json
```

Append the configuration of the new org in **SFDA.json** file into the **config.json** file. Change the file name and MSP in the below command accordingly.
```
jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"SFDAMSP":.[1]}}}}}' config.json ./SFDA.json > modified_config.json
```
Verify that the file has been updated
```
diff config.json modified_config.json
```

Package updated configuration into a block and then create a block that is delta of the old and new configuration
```
# Pack config again, create a delta of new and old config
configtxlator proto_encode --input config.json --type common.Config >original_config.pb
configtxlator proto_encode --input modified_config.json --type common.Config >modified_config.pb
configtxlator compute_update --channel_id $CHANNEL_NAME --original original_config.pb --updated modified_config.pb >config_update.pb
```
Convert the Delta Block **config_update.pb** block to JSON again, append the header to it and create a package again. Modify the channel name in the second command accordingly
```
configtxlator proto_decode --input config_update.pb --type common.ConfigUpdate >config_update.json
echo '{"payload":{"header":{"channel_header":{"channel_id":"mychannel", "type":2}},"data":{"config_update":'$(cat config_update.json)'}}}' | jq . > config_update_in_envelope.json
configtxlator proto_encode --input config_update_in_envelope.json --type common.Envelope >update-block-env.pb
```


6- Set the environment for Peer0 Org1 and Signed the update-block-env.pb

peer channel signconfigtx -f update-block-env.pb


7- Set the environment for Peer0 Org2 and send the transaction to orderer

peer channel update -f update-block-env.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA


8- Deployed the peer and couchdbs
9- Installed chaincode on all peers including new peers added
10- Upgraded the chaincode with the new endorsement policy
11- Sent a transaction and received the following warning.


What would be the implications of this warning in the future or can it can be ignored?


Unable to revoke a certificate #fabric #hyperledger-fabric #fabric-sdk-node

p.kamesh.cse@...
 

We could revoke an user successfully. But, unable to update the channel with crl details. We are getting below error 

Unexpected error error applying config update to existing channel 'trusttrace': initializing channelconfig failed: could not create channel Application sub-group config: setting up the MSP manager failed: admin 0 is invalid: could not validate identity against certification chain: The certificate has been revoked

We have followed below standard steps to revoke an user certificate by using node.js fabric library,

1) revoke an user by serial, AKI for a given certificate
caClient.revoke({
serial: serial,
aki: aki
}, adminUser)
2) Generated CRL for the same 
caClient.generateCRL({}, adminUser)
3) fetching the channelconfig  and updating the config with crl
original_config_json.channel_group.groups.Application.groups[orgName].values.MSP.value.config.revocation_list = [crl];
4) computing delta w.r.t modified changes and signing the same with org admin / registrar and updating the channel
 


Re: Does Hyperledger Fabric support RSA key? #hyperledger-fabric #fabric-ca

Baohua Yang
 

Fabric supports ECDSA for signature currently.
There're several non-official work to let it support other crypto standards.
For chaincode/client encryption, you can choose whatever type.

On Mon, Mar 23, 2020 at 12:23 PM Matthew Sykes <matthew.sykes@...> wrote:
> I then wonder why latest fabric-ca user guide mentions about supporting RSA?

Because fabric-ca supports the management of certificates using RSA; you just can't use them with Fabric.

--
Matthew Sykes
matthew.sykes@...



--
Best wishes!

Baohua Yang