Re: Client TLS CA signing fabcar - how does thepeer know this is genuine?


Brett T Logan <brett.t.logan@...>
 

We take feedback from our community very seriously. And we try to help out every chance we get. We would like for everything to be perfect, but the reality of the situation is sometimes things get missed, and thats the case for every open source project. All we can do is ask our community to help make us aware of the issues so we can address them. I'll add, this is an open source project and anyone can contribute to our codebase (including the doc). Fixing minor issues like dead links is a great way to give back to the community that supports you.
 
We also welcome feedback on our doc, as we can't improve gaps or difficult to digest doc if the community doesn't help make us aware of it. You can open Jira's with feedback/suggested fixes here: https://jira.hyperledger.org/
 
That being said, we are working on re-enabling our link checker and addressing the issues in it. You can follow the progress here: https://github.com/hyperledger/fabric/pull/1658
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: "Abhijeet Bhowmik" <abhijeet@...>
Sent by: fabric@...
To: trevor@..., David Enyeart <enyeart@...>, fabric@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Client TLS CA signing fabcar - how does thepeer know this is genuine?
Date: Thu, Jul 30, 2020 11:54 AM
 
Hey Trevor,
 
I am a newb in HLF and answered your question as proper as I could since I wanted to give back to the community I have been learning from. Arrangements might be flawed but the intent is not. Please use positive criticism to build the community. I don't know what possibly happened with you, but I have personally gotten so much prompt help from this mailing list, forum and rocket chat group, I have claimed to my colleagues that HLF has the best community and indeed it has. I could understand your concern over shortcomings in documentation or maybe HLF vulnerabilities as you say it. But one must not lose, even as a consumer you are a part of it, the sense of responsibility towards a community. Remember, blockchain (bitcoin) itself is an improvement and built on the premise of work done by the community of researchers and problem solvers in the Open Source field of Distributed Systems & Ledgers and Cryptography. Peace out.
 
Thanks and Regards
Abhijeet Bhowmik
 
On Thu, Jul 30, 2020 at 8:41 PM Trevor Lee Oakley <trevor@...> wrote:
I am not replying to the group.
 
The readers makes the judgment not the writer. You write for the reader not the writer. If you want to assess the worth of the docs, then use analytics and test the reading of the pages, use feedbacks and measure responses.
 
I am not randomly reading anything. 
 
Integrity is a subjective comment. I made objective comments about dead links, and repeated details (which happens a lot), and lack of flow. You reply with a subjective view. Anyone can express a subjective view.
 
I can say - users needs to be respected and not offended by poor claims; the integrity of products needs to be supported. You did not mention once users in your statement. 
 
 
 
 
To: "David Enyeart" <enyeart@...>
Cc: trevor@..., fabric@...
Subject: Re: [Hyperledger Fabric] Client TLS CA signing fabcar - how does thepeer know this is genuine?
 
Trevor,
 
I have gone through the documentations and dwelled through the parts of it. I am happy to say, HLF Documentation is the best source of literature one can find on HLF and Blockchain. Topics are well laid out with examples, explained till the depth and operations and usage guides are thoroughly explained. So when you say documentation is disjoint, I think it is so because you randomly land on a topic and try to connect the dots. Try following the pathway from root i.e. getting started with hlf. Topic wise, the concept of Blockchain, as a foundation, and then elements of it are brilliantly explained, not just as a part of Hyperledger, but as concepts belonging to Distributed Systems and Blockchain. I hope you find this in good sense because I personally believe HLF has one of the best Open Source Community whose integrity must be respected.
 
Thanks and Regards
Abhijeet Bhowmik
 
On Thu, Jul 30, 2020 at 4:49 PM David Enyeart <enyeart@...> wrote:

Insulting a group of open source volunteers trying to write documentation and help you in their free time probably isn't the best approach. An invitation is sent every week on this mailing list advertising the Documentation Workgroup call. Providing constructive doc input on that call seems like a much more effective approach.

In the meantime, I've opened a Jira issue to fix the dead links and figure out what happened to the dead link checker that used to be run...
https://jira.hyperledger.org/browse/FAB-18102


Dave Enyeart

"Trevor Lee Oakley" ---07/30/2020 03:40:50 AM---It is alright saying go through the docs, when the docs are very poorly written. The docs need to b

From: "Trevor Lee Oakley" <trevor@...>
To: "Abhijeet Bhowmik" <abhijeet@...>
Cc: <fabric@...>
Date: 07/30/2020 03:40 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Client TLS CA signing fabcar - how does thepeer know this is genuine?
Sent by: fabric@...





It is alright saying go through the docs, when the docs are very poorly written. The docs need to be properly written. They are highly disjointed, much of the material is unclear, and much of the material is repeated.

Even something as simple as dead links, the docs have many. Here is an example -
https://wiki.hyperledger.org/projects/fabric which is referenced in the docs; also -
https://hyperledger-fabric.readthedocs.io/en/release-2.0/policies/msp.html

Dead links are easily found by utils and this is as basic as it gets. In 1995 people complained about dead links and by 1998 it was rare on many sites, now in 2020 Hyperledger Fabric docs fail even 1998 standards.

But the main issue is the lack of flow. It is all thrown into a site and is lacks a flow and message, it is very hard to see the purpose of it. It clearly was not written by a writer.

This is how docs should be written -
https://docs.oracle.com/en/database/oracle/oracle-database/19/security.html

RTFM is fine but first you need to WTFM.




 


From: "Abhijeet Bhowmik" <abhijeet@...>
Sent: 30 July 2020 03:11
To: trevor@...
Subject: Re: [Hyperledger Fabric] Client TLS CA signing fabcar - how does thepeer know this is genuine?

Dear Trevor,

If you would have gone through, there are crypto sections in json of genesis.pb. You could find admin certs, root certs and tls certs. Admin cert can help in recognising who are admin of an Org, root cert is the CA's cert and tls cert used to verify TLSing certs. Now in the above code, you specified trustedRoots hereby known as CERT_1, suppose you provided CA-1's root cert, then your application will expect, while connecting with CA-1,
1. CA will send it's certificate hereby known as CERT_ROOT, the one that it signed for itself hence he himself will be the issuer;

2. Application (client) will verify the issuer, basically compare both the certificates and if "verify" attribute is set to true, it will verify signature as follows:
2.1 Using the public key of CERT_1, verify signature of CERT_ROOT (you might need to get an idea of how public key digital signature works).
2.2 Verify aspects like hostname, SANS etc. For example CA-Server is replying from IP 11.19.1.5, then that IP must be listed in CERT_ROOT's hosts section
3. On completion of step 2, TLS connection established successfully. Now your application has surety it's talking to genuine CA-Server.
4. While submitting a txn to a channel, you can use any of the Org's peer's, client's or admin's certificate to sign it hereby known as CERT_3.
Following conditions should meet: (I have attached a screenshot of how following mentioned certs are listed in channel config block)
a. CERT_3 must be signed by root_cert of OrgMSP section.
b. If CERT_3 is admin's cert, it must be included in admins section of OrgMSP section.
c. if TLSing, step 2 is carried out but now Application will be talking to Orderer/Peer.
d. channel will then consult channel policy to command easement of the proposer of the txn (for example: if channel policy says only a Admin's signed txn is considered as valid, CERT_3 must be admin cert).
5. On successful completion of step 4, channel is now sure txn is from authorized client.


I hope this helps. This is a very rudimentary understanding of mine I have developed studying documentations. Any wrong information or mistake is completely worthy of being pointed out and corrected and further elaborate my knowledge of HLF.

Thanks and Regards
Abhijeet Bhowmik

On Wed, Jul 29, 2020 at 5:32 PM Trevor Lee Oakley <trevor@...> wrote:
  • I have the code below and I am not sure how the peer recognises the certificate. If the client CA reads the pem and issues the new admin for the client wallet, how does the peer then recognise that?

    Here is the code from fabcar -


    const ccpPath = path.resolve(__dirname, '..', '..', 'test-network', 'organizations', 'peerOrganizations', 'org1.example.com', 'connection-org1.json');
    const ccp = JSON.parse(fs.readFileSync(ccpPath, 'utf8'));


    // Create a new CA client for interacting with the CA.
    const caInfo = ccp.certificateAuthorities['ca.org1.example.com'];
    const caTLSCACerts = caInfo.tlsCACerts.pem;
    const ca = new FabricCAServices(caInfo.url, { trustedRoots: caTLSCACerts, verify: false }, caInfo.caName);



     

     

     

     

     

     




 

 

 

 

 

Join fabric@lists.hyperledger.org to automatically receive all group messages.