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


Abhijeet Bhowmik <abhijeet@...>
 

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.