sending proposal, signing certificates?

[martijnlammers]

Hello again, I've created a single node using
$ sudo /opt/ccf/bin/cchost --config=config.ini

; config.ini

enclave-file = ./libjs_generic.enclave.so.signed
enclave-type = release
consensus = cft
rpc-address = 127.0.0.1:443
public-rpc-address = 20.108.20.207:443
node-address = 127.0.0.1:6600
ledger-dir = ./legder/

[start]
network-cert-file = ./certificates/network_cert.pem
member-info = "./certificates/Martijn_cert.pem,./certificates/Martijn_enc_pubk.pem"

Output:

. . .
Azure Quote Provider: libdcap_quoteprov.so [ERROR]: Could not retrieve environment variable for 'AZDCAP_DEBUG_LOG_LEVEL'
2021-10-18T10:43:18.231108Z 100 [info ] ../src/host/main.cpp:833 | Created new node
2021-10-18T10:43:18.231935Z 0 [info ] ../src/enclave/rpc_sessions.h:55 | Setting max open sessions to 1000
2021-10-18T10:43:18.232313Z 0 [info ] ../src/consensus/aft/raft.h:2433 | Becoming leader dea04943686b65213eddc9d5171055c738aa2b4af04006956b2375add04a9b21: 2
2021-10-18T10:43:18.232678Z 0 [info ] ./src/node/rpc/member_frontend.h:826 | Created service
2021-10-18T10:43:18.233116Z 0 [info ] ../src/node/node_state.h:1577 | Network TLS connections now accepted
2021-10-18T10:43:18.233490Z 0 [info ] ../src/node/node_state.h:422 | Created new node dea04943686b65213eddc9d5171055c738aa2b4af04006956b2375add04a9b21
. . .

I'm now currently attempting to change the JS application through proposal using the curl wrapper in a second terminal using
$ /opt/ccf/bin/scurl.sh https://20.108.20.207:443/gov/proposals --cacert ../certificates/network_certificate.pem --key ../certificates/Martijn_privk.pem --cert ../certificates/Martijn_cert.pem --data-binary @set_js_app_proposal.json -H "content-type: application/json"

Output:

Error: No signing certificate found in arguments (--signing-cert)

I seem to be missing signing cert/keys, isn't the wrapper supposed to handle these and if not how do I generate the signing certificates used to send proposals?

[eddyashton]

The args you need to pass to scurl.sh are --signing-key and --signing-key. These are required arguments, which set the identity used to do HTTP signing of the request. The --key and --cert args you're currently passing are optional, and are used to do TLS-client authentication, but not HTTP signing. We provide both so that callers can test signed-but-unauthed commands (sufficient for CCF governance endpoints), or signed-and-authed-with-a-different-identity commands (not used by any builtin CCF endpoint, but could be desired in application logic), or some other combination.

[martijnlammers]

Right, so if I understand it correctly, --key and --cert are not ever used for signing, but only when you're attempting to make an endpoint call that requires you to do so because of the authentication policy user_auth.

[eddyashton]

You're correct that --key and --cert are not used for signing. Generally client-authentication is for use with a user_auth endpoint, where the client identity presented is a user's.

But there are also member_auth endpoints, where the client identity presented must be a member's. For instance in member_frontend.h we define the endpoints that are callable under /gov. Some of these are writes which create proposal or vote state, and we require that those are always signed - the only acceptable auth policy is a member signature (because we want to store those signatures for audit later). So POST /proposals/foo/withdraw must be signed, as indicated by the member_sig_only on line 1130:

CCF/src/node/rpc/member_frontend.h

Lines 1126 to 1132 in 13a889f

	make_endpoint(
	"/proposals/{proposal_id}/withdraw",
	HTTP_POST,
	json_adapter(withdraw_js),
	member_sig_only)
	.set_auto_schema<void, jsgov::ProposalInfo>()
	.install();

Whereas for read-only endpoints we accept multiple auth schemes; either the TLS-client identity or the HTTP signature is sufficient proof that this command came from a member. For instance GET /proposals/foo, which is marked as member_cert_or_sig on line 1053.

CCF/src/node/rpc/member_frontend.h

Lines 1049 to 1055 in 13a889f

	make_read_only_endpoint(
	"/proposals/{proposal_id}",
	HTTP_GET,
	json_read_only_adapter(get_proposal_js),
	member_cert_or_sig)
	.set_auto_schema<void, jsgov::ProposalInfo>()
	.install();

(Note that these are defined in C++ so the endpoints are registered slightly differently than the JS apps, but the same functionality is available in both - the key here is that member_sig_only is equivalent to a "authn_policies": ["member_sig"] in a JS app.json, and member_cert_or_sig is equivalent to "authn_policies": ["member_cert", "member_sig"])

[martijnlammers]

Aha, so the certificates being used solely depend on the policy to where you're filing your requests to, and all the /gov/ ones happened to of course require them to be signed and only be invoked by a member of the consortium to maintain the confidentiality of the network.

Is the closed network only limited to nodes of your own virtual machine or do you have to open the network before nodes from different machines can join the network?

[eddyashton]

There is no limitation based on virtual machine/network location. Any node with a valid CodeID (aka - any node that can produce an SGX attestation which proves they're running one of the mrenclave values that is accepted by the service) can join the network. Before the network is opened, a node that joins like this is automatically added and a full participant. As part of the open_network proposal, the members audit the current set of nodes, check they're happy with the number and attestation of each, and then vote to open the network. Once opened, a newly joining node is marked as Pending, and not a full participant in the network until it is transitioned to Trusted by a governance proposal.