JonathanLevi (Fri, 03 Feb 2017 07:58:20 GMT):
Will a daily digest of #fabric-crypto be a good source of randomness?
cca88 (Fri, 03 Feb 2017 08:20:00 GMT):
Has joined the channel.
grapebaba (Fri, 03 Feb 2017 11:23:03 GMT):
Has joined the channel.
silliman (Fri, 03 Feb 2017 13:56:21 GMT):
Has joined the channel.
gormand (Fri, 03 Feb 2017 14:42:42 GMT):
Has joined the channel.
yacovm (Fri, 03 Feb 2017 15:24:32 GMT):
Has joined the channel.
jyellick (Fri, 03 Feb 2017 16:06:54 GMT):
Has joined the channel.
oiakovlev (Fri, 03 Feb 2017 19:24:42 GMT):
Has joined the channel.
fz (Fri, 03 Feb 2017 19:29:51 GMT):
Has joined the channel.
jimthematrix (Fri, 03 Feb 2017 19:37:58 GMT):
Has joined the channel.
karkal (Fri, 03 Feb 2017 19:50:24 GMT):
Has joined the channel.
mwklein (Fri, 03 Feb 2017 20:21:27 GMT):
Has joined the channel.
zmanian (Fri, 03 Feb 2017 22:04:56 GMT):
Has joined the channel.
ericmvaughn (Fri, 03 Feb 2017 22:05:22 GMT):
Has joined the channel.
eddie.allen (Fri, 03 Feb 2017 22:54:30 GMT):
Has joined the channel.
JonathanTan (Sat, 04 Feb 2017 02:59:15 GMT):
Has joined the channel.
genggjh (Sat, 04 Feb 2017 03:44:02 GMT):
Has joined the channel.
bfuentes@fr.ibm.com (Sat, 04 Feb 2017 09:19:53 GMT):
Has joined the channel.
muralisr (Sat, 04 Feb 2017 14:48:30 GMT):
Has joined the channel.
patchpon (Sun, 05 Feb 2017 10:07:22 GMT):
Has joined the channel.
schwentker2 (Sun, 05 Feb 2017 15:47:06 GMT):
Has joined the channel.
rickr (Sun, 05 Feb 2017 18:31:35 GMT):
Has joined the channel.
bryanhuang (Mon, 06 Feb 2017 04:32:30 GMT):
Has joined the channel.
gennadyl (Mon, 06 Feb 2017 08:19:09 GMT):
Has joined the channel.
david.peyronnin (Mon, 06 Feb 2017 09:48:26 GMT):
Has joined the channel.
aarenw (Mon, 06 Feb 2017 10:02:36 GMT):
Has joined the channel.
HieuDoan (Mon, 06 Feb 2017 14:09:30 GMT):
Has joined the channel.
harrijk (Mon, 06 Feb 2017 15:13:59 GMT):
Has joined the channel.
DennisM330 (Mon, 06 Feb 2017 15:38:21 GMT):
Has joined the channel.
elli-androulaki (Mon, 06 Feb 2017 16:06:07 GMT):
Has joined the channel.
vpaprots (Mon, 06 Feb 2017 19:00:11 GMT):
Has joined the channel.
weeds (Mon, 06 Feb 2017 20:24:18 GMT):
Has joined the channel.
ashutosh_kumar (Mon, 06 Feb 2017 23:40:35 GMT):
Has joined the channel.
hartm (Tue, 07 Feb 2017 01:04:28 GMT):
Has joined the channel.
crazybit (Tue, 07 Feb 2017 05:31:26 GMT):
Has joined the channel.
adc (Tue, 07 Feb 2017 07:30:20 GMT):
Has joined the channel.
bur (Tue, 07 Feb 2017 07:33:28 GMT):
Has joined the channel.
zlliu (Tue, 07 Feb 2017 08:18:00 GMT):
Has joined the channel.
vitaly.ilinykh (Tue, 07 Feb 2017 08:40:50 GMT):
Has joined the channel.
ikruiper (Tue, 07 Feb 2017 14:53:53 GMT):
Has joined the channel.
MartinMateev (Tue, 07 Feb 2017 15:10:37 GMT):
Has joined the channel.
cbf (Tue, 07 Feb 2017 15:13:20 GMT):
Has joined the channel.
mpage (Tue, 07 Feb 2017 15:31:01 GMT):
Has joined the channel.
sukrit.handa@gmail.com (Tue, 07 Feb 2017 15:57:25 GMT):
Has joined the channel.
umasuthan (Tue, 07 Feb 2017 16:04:08 GMT):
Has joined the channel.
troyronda (Tue, 07 Feb 2017 16:32:48 GMT):
Has joined the channel.
tuand (Tue, 07 Feb 2017 17:52:57 GMT):
Has joined the channel.
tuand (Tue, 07 Feb 2017 19:17:04 GMT):
for context ... I'm a client running the SDK and I receive a signed ProposalResponse from an endorser
tuand (Tue, 07 Feb 2017 19:17:33 GMT):
i have the endorser's certificate in the ProposalResponse ...
tuand (Tue, 07 Feb 2017 19:17:55 GMT):
how do I determine the signature algorithm ?
elli-androulaki (Tue, 07 Feb 2017 20:16:22 GMT):
The signature algorithm you can figure out from the type of the key inside the certificate
ashutosh_kumar (Tue, 07 Feb 2017 20:44:21 GMT):
@elli-androulaki , there is no guarantee that the algo inside the cert should be the same the algo that the user has signed the transaction with.
elli-androulaki (Tue, 07 Feb 2017 20:44:39 GMT):
well it should no?
ashutosh_kumar (Tue, 07 Feb 2017 20:44:53 GMT):
not necessarily.
elli-androulaki (Tue, 07 Feb 2017 20:44:53 GMT):
or you mean the hash used?
ashutosh_kumar (Tue, 07 Feb 2017 20:45:13 GMT):
in our case , we have defaulted to ECDSA,
ashutosh_kumar (Tue, 07 Feb 2017 20:45:27 GMT):
and hash is based on BCCSP config.
elli-androulaki (Tue, 07 Feb 2017 20:45:34 GMT):
and the curve.. right
ashutosh_kumar (Tue, 07 Feb 2017 20:45:47 GMT):
so if we use default BCCSP , then it all works fine.
ashutosh_kumar (Tue, 07 Feb 2017 20:46:14 GMT):
curve , we get from Cert which is GO implementation.
elli-androulaki (Tue, 07 Feb 2017 20:46:49 GMT):
I remember there was at some point discussion with @adc to include some prefix in the signature itself that would indicate the type of the signature algo and hash function used to generate it. Following a standard.
elli-androulaki (Tue, 07 Feb 2017 20:47:12 GMT):
Wait
ashutosh_kumar (Tue, 07 Feb 2017 20:47:20 GMT):
so the default bccsp hash should map to curve in cert.
JonathanLevi (Tue, 07 Feb 2017 20:47:41 GMT):
Hold on.
ashutosh_kumar (Tue, 07 Feb 2017 20:47:50 GMT):
In my TCERT option 2 , I am asking client to specify signature algo.
JonathanLevi (Tue, 07 Feb 2017 20:48:22 GMT):
A leading question: How many different algos/schemes does it currently support?
JonathanLevi (Tue, 07 Feb 2017 20:48:31 GMT):
@ashutosh_kumar: one, right?
JonathanLevi (Tue, 07 Feb 2017 20:48:38 GMT):
That's not what @elli-androulaki suggests.
ashutosh_kumar (Tue, 07 Feb 2017 20:48:39 GMT):
no , 4.
elli-androulaki (Tue, 07 Feb 2017 20:48:41 GMT):
So, the certificates include a key-type, along with the key in X509
ashutosh_kumar (Tue, 07 Feb 2017 20:49:07 GMT):
2 each for SHA2 and SHA3.
JonathanLevi (Tue, 07 Feb 2017 20:49:31 GMT):
Key length/size does not define a NEW scheme.
ashutosh_kumar (Tue, 07 Feb 2017 20:49:39 GMT):
Sig algo == hash algo.
elli-androulaki (Tue, 07 Feb 2017 20:50:00 GMT):
hm, i think they work in combination these two...
JonathanLevi (Tue, 07 Feb 2017 20:50:00 GMT):
We have also disabled some others (i'm talking about the full end-to-end). From SDKs all the way down.
ashutosh_kumar (Tue, 07 Feb 2017 20:50:03 GMT):
as we are defaulting to ec,
kostas (Tue, 07 Feb 2017 20:50:23 GMT):
Has joined the channel.
JonathanLevi (Tue, 07 Feb 2017 20:50:25 GMT):
Yes, we have the (algo + size)
ashutosh_kumar (Tue, 07 Feb 2017 20:50:25 GMT):
so AFAIK , we are using default BCCSP.
ashutosh_kumar (Tue, 07 Feb 2017 20:50:25 GMT):
so AFAIK , we are using default BCCSP CONFIG.
JonathanLevi (Tue, 07 Feb 2017 20:50:55 GMT):
But what if we don't? And that new BCCSP' has different "defaults"
JonathanLevi (Tue, 07 Feb 2017 20:51:34 GMT):
Oh, `config` [just saw the edit]
JonathanLevi (Tue, 07 Feb 2017 20:51:52 GMT):
I think we should have an identifier...
JonathanLevi (Tue, 07 Feb 2017 20:52:15 GMT):
And pre-agree strings to define these. I will be a nightmare to support otherwise.
JonathanLevi (Tue, 07 Feb 2017 20:52:15 GMT):
And pre-agree strings to define these. It will be a nightmare to support otherwise.
JonathanLevi (Tue, 07 Feb 2017 20:52:15 GMT):
And pre-agreed strings to define these. It will be a nightmare to support otherwise.
elli-androulaki (Tue, 07 Feb 2017 20:53:30 GMT):
Correct. So two things: (i) for the fabric platform related structures (e.g., signatures included in the proto messages) genesis block would include the hash algorithm used within. Adding @jyellick to confirm here.
elli-androulaki (Tue, 07 Feb 2017 20:55:05 GMT):
For the client/peer generated signatures using one of the existing MSPs, well MSPs should either be aware that they would support only one type of signatures and use that default type to verify their members' signatures, or (if they support multiple key types) they would need to prepend to signatures some standard label.
ashutosh_kumar (Tue, 07 Feb 2017 20:55:34 GMT):
second statement makes sense.
JonathanLevi (Tue, 07 Feb 2017 20:55:48 GMT):
(that's what I meant by 1 scheme, above - yes, thank you @elli-androulaki )
elli-androulaki (Tue, 07 Feb 2017 20:56:15 GMT):
Perhaps @vpaprots can identify the standard of the label pre-pended to the signatures :)
elli-androulaki (Tue, 07 Feb 2017 20:56:24 GMT):
@JonathanLevi , sure!
beauson45 (Tue, 07 Feb 2017 20:56:27 GMT):
Has joined the channel.
JonathanLevi (Tue, 07 Feb 2017 20:56:38 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=zipAtvuN2RZEANW6J) @JonathanLevi
ashutosh_kumar (Tue, 07 Feb 2017 20:57:00 GMT):
4 hash algo.
JonathanLevi (Tue, 07 Feb 2017 20:57:30 GMT):
Here is the problem. Assume someone is not allowed to deploy a certain set of crypto (algo strength/key length)
vpaprots (Tue, 07 Feb 2017 20:57:57 GMT):
(I have been wanting to talk about this!! :D)
JonathanLevi (Tue, 07 Feb 2017 20:58:00 GMT):
And that lost-little-lamb, is trying to use something that is beyond his means...
JonathanLevi (Tue, 07 Feb 2017 20:58:00 GMT):
And that lost-little-lamb, is trying to use something that is beyond his means... (say cryptographically/location/jurisdiction- wise)
JonathanLevi (Tue, 07 Feb 2017 20:58:35 GMT):
How does a Fabric - compliant MSP implementation deal with it, in a graceful way?
JonathanLevi (Tue, 07 Feb 2017 20:59:15 GMT):
Of course we can have one very basic MSP that works with key size of 16 (bits, not bytes ;-))
JonathanLevi (Tue, 07 Feb 2017 20:59:31 GMT):
[I'm joking]
JonathanLevi (Tue, 07 Feb 2017 20:59:59 GMT):
What I mean to say is that we do not want to use the bare-minimum/allowed crypto everywhere.
JonathanLevi (Tue, 07 Feb 2017 21:00:26 GMT):
And of course, we may need to change things in the future.
JonathanLevi (Tue, 07 Feb 2017 21:01:42 GMT):
I can't see us always working with just the default.
elli-androulaki (Tue, 07 Feb 2017 21:04:13 GMT):
You mean we should enable configurable key algo and length inside an MSP or in BCCSP that is used by an MSP?
vpaprots (Tue, 07 Feb 2017 21:04:50 GMT):
I see BCCSP as a golang version of Java JCE. In fact we were thinking with Angelo of splitting it out and proposing it to gophercon (I know some people going) or just asking the golang community to include it part of the language.. but I digress.. another tangent.. it would be nice to have one 'string' specifying' all the algorithms used, TLS style.. "FABRIC_SIGNATURE_HASH..." or something..
elli-androulaki (Tue, 07 Feb 2017 21:04:55 GMT):
Cause BCCSP you can also specify a specific hashing algorithm, and uses the default only if you dont specify it afaik
elli-androulaki (Tue, 07 Feb 2017 21:04:55 GMT):
Cause in BCCSP you can also specify a specific hashing algorithm, and uses the default only if you dont specify it afaik
tuand (Tue, 07 Feb 2017 21:05:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=LLtzNQJJXzFgZj48o) can I suggest we standardize on http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html ? I see that Go crypto has its own set of names
vpaprots (Tue, 07 Feb 2017 21:05:45 GMT):
Angelo and I want to remove the notion of 'default algorithm' from BCCSP.
vpaprots (Tue, 07 Feb 2017 21:06:07 GMT):
(different then 'default BCCSP' !)
elli-androulaki (Tue, 07 Feb 2017 21:06:11 GMT):
Right, that I am aware of. I think it was there for simplicity at the beginning
ashutosh_kumar (Tue, 07 Feb 2017 21:06:12 GMT):
In TCert option 2 , I am asking SDK to pass signature algo.
JonathanLevi (Tue, 07 Feb 2017 21:06:29 GMT):
Ash, this has to flow all the way through.
ashutosh_kumar (Tue, 07 Feb 2017 21:06:38 GMT):
and call BCCSP API accordingly.
ashutosh_kumar (Tue, 07 Feb 2017 21:06:49 GMT):
yup , I agree.
vpaprots (Tue, 07 Feb 2017 21:07:37 GMT):
ok, another thought.. can we mix algorithms?
elli-androulaki (Tue, 07 Feb 2017 21:07:40 GMT):
@vlad, good remark.
elli-androulaki (Tue, 07 Feb 2017 21:07:40 GMT):
@vpaprots , good remark (for the default algo vs default Bccsp).
vpaprots (Tue, 07 Feb 2017 21:08:20 GMT):
one MSP has ECDSA P384, another P256 and yet another SM3?
elli-androulaki (Tue, 07 Feb 2017 21:08:22 GMT):
mix algorithms in what sense? support a variety of algos?
vpaprots (Tue, 07 Feb 2017 21:08:28 GMT):
cross-border 'trading'
JonathanLevi (Tue, 07 Feb 2017 21:08:32 GMT):
OMG !
elli-androulaki (Tue, 07 Feb 2017 21:08:35 GMT):
yes, that should be possible I would say
vpaprots (Tue, 07 Feb 2017 21:08:49 GMT):
I think in Germany, they want Brainpool curves actually
JonathanLevi (Tue, 07 Feb 2017 21:08:58 GMT):
And in Russia ? ;-)
elli-androulaki (Tue, 07 Feb 2017 21:09:02 GMT):
thts one of the advantages of MSPs being modular :)
vpaprots (Tue, 07 Feb 2017 21:09:03 GMT):
will that go into the config block?
vpaprots (Tue, 07 Feb 2017 21:09:19 GMT):
(@JonathanLevi :D)
elli-androulaki (Tue, 07 Feb 2017 21:09:50 GMT):
Well, here is the thing. The MSP type should be supported by the peer's code.
JonathanLevi (Tue, 07 Feb 2017 21:10:01 GMT):
I know a Russian bank that had to re-write the entire memberservc because of the government restrcition.
JonathanLevi (Tue, 07 Feb 2017 21:10:06 GMT):
Yup
elli-androulaki (Tue, 07 Feb 2017 21:10:18 GMT):
in the config block you can put hashes of source code corresponding to each MSP type
elli-androulaki (Tue, 07 Feb 2017 21:10:20 GMT):
in that case
JonathanLevi (Tue, 07 Feb 2017 21:10:26 GMT):
That's why I am so into configurations.
elli-androulaki (Tue, 07 Feb 2017 21:10:30 GMT):
plus the assumed MSPs' configuration
elli-androulaki (Tue, 07 Feb 2017 21:10:44 GMT):
aha
vpaprots (Tue, 07 Feb 2017 21:11:13 GMT):
Yep, I know of a chinese firm working on the SM* algorithms, I suggested to them that they implement their own BCCSP for that.. thats the scalable extension point I want to use..
vpaprots (Tue, 07 Feb 2017 21:12:11 GMT):
so.. if we get a BCCSP configuration from a country/company/whatever with their own crypto considerations.. can we pick it up in the rest of fabric
vpaprots (Tue, 07 Feb 2017 21:13:16 GMT):
(and we dont get stuck implementing 3 dozen algorithms! In fact.. I think I would not even be allowed to ;) )
JonathanLevi (Tue, 07 Feb 2017 21:14:14 GMT):
___
Was there any downside to going ahead with Angelo's proposition for having string identifiers?
JonathanLevi (Tue, 07 Feb 2017 21:14:40 GMT):
Sounds like many here agree with it (and so am I)
vpaprots (Tue, 07 Feb 2017 21:15:10 GMT):
(is the string identifier for the config/genesis block?)
vpaprots (Tue, 07 Feb 2017 21:18:23 GMT):
About @tuand suggestion about JCE names. Yes! (well, me biased). 'Small' issue.. no official name for SHA3 yet, and SHA2 name is 'bad', easy to confuse with SHA3. We work with oracle though, they already have names, just prepend SHA3-bits
vpaprots (Tue, 07 Feb 2017 21:18:23 GMT):
About @tuand suggestion about JCE names. Yes! (well, me biased). 'Small' issue.. no official name for SHA3 yet, and SHA2 name is 'bad', easy to confuse with SHA1. We work with oracle though, they already have names, just prepend SHA3-bits
ckeyer (Wed, 08 Feb 2017 02:06:31 GMT):
Has joined the channel.
tcz001 (Wed, 08 Feb 2017 02:07:17 GMT):
Has joined the channel.
johnm (Wed, 08 Feb 2017 02:26:32 GMT):
Has joined the channel.
rnsastry (Wed, 08 Feb 2017 04:11:06 GMT):
Has joined the channel.
vigneswaran.r (Wed, 08 Feb 2017 04:25:43 GMT):
Has joined the channel.
sachikoy (Wed, 08 Feb 2017 04:43:10 GMT):
Has joined the channel.
niteshsolanki (Wed, 08 Feb 2017 08:54:54 GMT):
Has joined the channel.
aso (Wed, 08 Feb 2017 10:30:10 GMT):
Has joined the channel.
aso (Wed, 08 Feb 2017 10:31:49 GMT):
heads up: https://gerrit.hyperledger.org/r/#/c/5703/ changes the `FabricMSPConfig` protobuf definition to include intermediate certificates
pipor (Wed, 08 Feb 2017 13:47:10 GMT):
Has joined the channel.
kushnir.grigoriy (Wed, 08 Feb 2017 13:49:14 GMT):
Has joined the channel.
shaih (Wed, 08 Feb 2017 13:58:59 GMT):
Has joined the channel.
elli-androulaki (Wed, 08 Feb 2017 14:43:53 GMT):
Hi, for the crypto-squad Jira items under fabric-crypto, and Sprint 11 contain the list of pending items that correspond to @mastersingh24 's list.
In summary, our pending work items, blockers and estimated effort in PDs (= Person Days):
1) Channel ACL in endorser, orderer, and gossip logic [~ 2 x 3 PDs]. We are blocked by channel policy setup through genesis, and pending design on LCCC instantiation
2) Minimum level of replay protection [0.5 PD]
3) MSP-implementation completion (intermediate CAs, admin/OrganizationUnit) [1.5 PD]
4) Code todos that are not covered by the items listed before
5) Application libraries for ACL [ETA: end of month]
6) Research paper (ETA: end of month)
7) Security review of new designs in CC2CC, deployment model, and reconfiguration
mastersingh24 (Wed, 08 Feb 2017 14:43:54 GMT):
Has joined the channel.
haidong (Wed, 08 Feb 2017 14:51:30 GMT):
Has joined the channel.
shalinigpt (Wed, 08 Feb 2017 15:56:25 GMT):
Has joined the channel.
jkirke (Wed, 08 Feb 2017 16:33:50 GMT):
Has joined the channel.
warong (Thu, 09 Feb 2017 02:52:40 GMT):
Has joined the channel.
tzipih0 (Thu, 09 Feb 2017 03:17:33 GMT):
Has joined the channel.
guhaihua (Thu, 09 Feb 2017 03:32:13 GMT):
Has joined the channel.
eragnoli (Thu, 09 Feb 2017 10:54:45 GMT):
Has joined the channel.
cdaughtr (Thu, 09 Feb 2017 15:26:28 GMT):
Has joined the channel.
jimthematrix (Thu, 09 Feb 2017 15:43:55 GMT):
@aso @jeffgarratt I have a question on the `join channel` request, and it's probably best to ask it in the context of Jeff's bddtest `bootstrap.feature`, the following statement at line 130:
```
When user "dev0Org0" using cert alias "dev0Org0App1" requests to join channel using genesis block "genesisBlockForMyNewChannel" on peers with result "joinChannelResult"
```
jeffgarratt (Thu, 09 Feb 2017 15:43:55 GMT):
Has joined the channel.
jimthematrix (Thu, 09 Feb 2017 15:45:07 GMT):
how does the peer2 in organization peerOrg1 validate the cert `dev0Org0App1` that's signed by peerOrg1 CA?
jeffgarratt (Thu, 09 Feb 2017 15:45:59 GMT):
the peer's each have the org CA's in their cacerts for the localMspConfig
jimthematrix (Thu, 09 Feb 2017 15:46:50 GMT):
ok that's what i'm confused about: i thought localMspConfig is only for signing purposes, not for validating incoming certs and signatures
jeffgarratt (Thu, 09 Feb 2017 15:47:09 GMT):
it may be
jimthematrix (Thu, 09 Feb 2017 15:47:41 GMT):
and a related question is, how would the app know what "mspid" to use in the request? i assume it needs to be set to the id matching each peer's localMspConfig
jeffgarratt (Thu, 09 Feb 2017 15:48:14 GMT):
it collects the peer template info (which is really the reference to the orgs)
jeffgarratt (Thu, 09 Feb 2017 15:48:57 GMT):
And the user "dev0Org0" creates a peer template "template1" with chaincode deployment policy using chain creation policy name "chainCreatePolicy1" and peer organizations:
| Organization |
| peerOrg0 |
| peerOrg1 |
jeffgarratt (Thu, 09 Feb 2017 15:49:03 GMT):
line 95
jeffgarratt (Thu, 09 Feb 2017 15:49:30 GMT):
that then creates the MSPCOnfigItems for the join chain
jeffgarratt (Thu, 09 Feb 2017 15:49:46 GMT):
I mean chain create
jeffgarratt (Thu, 09 Feb 2017 15:50:48 GMT):
It creates these...
jeffgarratt (Thu, 09 Feb 2017 15:50:50 GMT):
Header {
type: 2
version: 1
timestamp {
seconds: 1486595190
}
chainID: "com.acme.blockchain.jdoe.Channel1"
}
Type: MSP
ModificationPolicy: "NewConfigurationItemPolicy"
Key: "peerOrg0"
Value: "\022\340\006\n\010peerOrg0\022\250\003-----BEGIN CERTIFICATE-----\nMIIBDTCBtQICA+gwCgYIKoZIzj0EAwIwEzERMA8GA1UEAwwIcGVlck9yZzAwHhcN\nMTcwMjA4MjMwNjMxWhcNMTgwMjA4MjMwNjMxWjATMREwDwYDVQQDDAhwZWVyT3Jn\nMDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABCX1czJinJJB8eI4Bfhjej/L9c6L\n157UJ2h620lOJhmoyTYnknV0Q0l9HLOE8IiuzJZTt3WRbwrQoDcl/4bJ/JowCgYI\nKoZIzj0EAwIDRwAwRAIgUnnBg3vmpvIF6/TmAH0YGNPlWkuFt2XrzKKHw6wGXd0C\nIDkpYSmhJi/fwx3w7eAsPY0Dhb+oXLwxayzx4P6nkZIb\n-----END CERTIFICATE-----\n\032\250\003-----BEGIN CERTIFICATE-----\nMIIBDTCBtQICA+gwCgYIKoZIzj0EAwIwEzERMA8GA1UEAwwIcGVlck9yZzAwHhcN\nMTcwMjA4MjMwNjMxWhcNMTgwMjA4MjMwNjMxWjATMREwDwYDVQQDDAhwZWVyT3Jn\nMDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABCX1czJinJJB8eI4Bfhjej/L9c6L\n157UJ2h620lOJhmoyTYnknV0Q0l9HLOE8IiuzJZTt3WRbwrQoDcl/4bJ/JowCgYI\nKoZIzj0EAwIDRwAwRAIgUnnBg3vmpvIF6/TmAH0YGNPlWkuFt2XrzKKHw6wGXd0C\nIDkpYSmhJi/fwx3w7eAsPY0Dhb+oXLwxayzx4P6nkZIb\n-----END CERTIFICATE-----\n"
jeffgarratt (Thu, 09 Feb 2017 15:51:06 GMT):
the Key: "peerOrg0" matches the key in the cacerts
jeffgarratt (Thu, 09 Feb 2017 15:51:37 GMT):
one for each org referenced in the template (peerOrg0, and peerOrg1)
jeffgarratt (Thu, 09 Feb 2017 15:52:01 GMT):
the value is a serialized FabricMspConfig
jeffgarratt (Thu, 09 Feb 2017 15:52:11 GMT):
which has the cacerts
jeffgarratt (Thu, 09 Feb 2017 15:52:27 GMT):
the MSPConfig with "identity" setting
jeffgarratt (Thu, 09 Feb 2017 15:52:31 GMT):
make sense?
jeffgarratt (Thu, 09 Feb 2017 15:52:41 GMT):
so nix my prior, there it is
jeffgarratt (Thu, 09 Feb 2017 15:52:41 GMT):
:)
jimthematrix (Thu, 09 Feb 2017 15:52:43 GMT):
ok, but I think my problem is slightly different, when I send this join request to the peer, I sign it and the peer needs to validate my cert
jeffgarratt (Thu, 09 Feb 2017 15:53:01 GMT):
correct, that comes from the localMSp
jeffgarratt (Thu, 09 Feb 2017 15:53:05 GMT):
I believe
jeffgarratt (Thu, 09 Feb 2017 15:53:10 GMT):
@aso can verify
jeffgarratt (Thu, 09 Feb 2017 15:53:34 GMT):
I create a devOrg0App1 reference to a cert for devOrg0 signed by peerOrg0
jeffgarratt (Thu, 09 Feb 2017 15:53:45 GMT):
that is used for signing, and is in the peer's localMspConfig
jeffgarratt (Thu, 09 Feb 2017 15:54:09 GMT):
When user "dev0Org0" using cert alias "dev0Org0App1" requests to join channel using genesis block "genesisBlockForMyNewChannel" on peers with result "joinChannelResult"
| Peer |
| peer0 |
| peer2 |
jeffgarratt (Thu, 09 Feb 2017 15:54:21 GMT):
using cert alias "..." means it uses that cert to sign
aso (Thu, 09 Feb 2017 15:54:32 GMT):
> ok that's what i'm confused about: i thought localMspConfig is only for signing purposes, not for validating incoming certs and signatures

validating a join channel request is the one exception to that rule
jeffgarratt (Thu, 09 Feb 2017 15:54:33 GMT):
or supplies it with the signature
aso (Thu, 09 Feb 2017 15:55:08 GMT):
@elli-androulaki can confirm
jimthematrix (Thu, 09 Feb 2017 15:55:14 GMT):
and as peers always do, it first looks at the mspid that comes along with the cert in the "creator" field, this mspid should represent my app's signing identify which is really mapped to the peerOrg0. so the peer's local msp config is already configured with that (ca certs for peerOrg0), then it can validate
jimthematrix (Thu, 09 Feb 2017 15:56:12 GMT):
@aso "validating a join channel request is the one exception to that rule" - aha that makes sense now
aso (Thu, 09 Feb 2017 15:56:52 GMT):
yeah - for all other cases we can use the trust setup from the genesis block, but on a join channel we have no genesis block
elli-androulaki (Thu, 09 Feb 2017 15:57:03 GMT):
@aso, confirmed :)
jimthematrix (Thu, 09 Feb 2017 15:57:05 GMT):
@jeffgarratt thank goodness again for your bddtest steps ;-)
jeffgarratt (Thu, 09 Feb 2017 15:57:16 GMT):
your welcome!! :)
jimthematrix (Thu, 09 Feb 2017 15:57:22 GMT):
@elli-androulaki got it
jeffgarratt (Thu, 09 Feb 2017 15:57:37 GMT):
gonna be pushing doc gen soon
jeffgarratt (Thu, 09 Feb 2017 15:57:59 GMT):
will document all the steps the bdd is actually taking with links to artifacts, etc.
jeffgarratt (Thu, 09 Feb 2017 15:58:20 GMT):
have to rebase today, and accomodate any changes in config over the last few days
jimthematrix (Thu, 09 Feb 2017 15:58:34 GMT):
@aso "for all other cases we can use the trust setup from the genesis block, but on a join channel we have no genesis block" - yeah was discussing this with @cdaughtr and I realize this was a chicken-n-egg problem, but using local msp makes sense
C0rWin (Thu, 09 Feb 2017 15:58:49 GMT):
Has joined the channel.
tuand (Thu, 09 Feb 2017 15:58:54 GMT):
anxiously waiting @jeffgarratt ... no pressure though ;)
jeffgarratt (Thu, 09 Feb 2017 15:59:56 GMT):
will send you a shot
jeffgarratt (Thu, 09 Feb 2017 16:00:54 GMT):
@tuand shot you an example in old slack side
tuand (Thu, 09 Feb 2017 16:01:05 GMT):
i owe you a beer (maybe 2 )
jeffgarratt (Thu, 09 Feb 2017 16:01:10 GMT):
:)
jeffgarratt (Thu, 09 Feb 2017 16:01:20 GMT):
netscape will actually render the network diagram :)
jeffgarratt (Thu, 09 Feb 2017 16:01:25 GMT):
I mean firefox
jimthematrix (Thu, 09 Feb 2017 16:02:55 GMT):
so my next question then is when the join channel request is sent to peer0, we need to set the "mspid" in the "creator" field to the value matching peer0's local msp, and same for peer2 in a different org. and as a result we'll have to construct each request targeting peers in different orgs separately right?
jeffgarratt (Thu, 09 Feb 2017 16:03:14 GMT):
correct
jeffgarratt (Thu, 09 Feb 2017 16:03:30 GMT):
exactly, you would have to go through the whole template... blah blah process again
jeffgarratt (Thu, 09 Feb 2017 16:03:37 GMT):
choose separate orgs, etc.
jeffgarratt (Thu, 09 Feb 2017 16:03:52 GMT):
you can simply copy and paste the behave steps to join multiple channels if you like
jeffgarratt (Thu, 09 Feb 2017 16:03:59 GMT):
it is a DSL, so have at it
jeffgarratt (Thu, 09 Feb 2017 16:04:47 GMT):
I would caution that with new config changes, then may be slightly askew for a bit
jeffgarratt (Thu, 09 Feb 2017 16:04:50 GMT):
aka not working
jimthematrix (Thu, 09 Feb 2017 16:04:53 GMT):
aha so that's another epiphany ;-)
jeffgarratt (Thu, 09 Feb 2017 16:05:15 GMT):
think people have been underestimating the amount of workflow like steps involved in reasoning about the usage
jimthematrix (Thu, 09 Feb 2017 16:05:19 GMT):
(in reference to using different mspids for the creator field)
jimthematrix (Thu, 09 Feb 2017 16:05:31 GMT):
indeed
binhn (Thu, 09 Feb 2017 16:15:36 GMT):
Has joined the channel.
binhn (Thu, 09 Feb 2017 16:28:05 GMT):
the joinchannel request comes with the genesis block, which must include the peer orgs, so I would prefer to open up the block and set up MSP mgr. I know it is chicken and egg, but the process is quite odd at the API/SDK level otherwise. Thoughts?
yacovm (Thu, 09 Feb 2017 16:31:03 GMT):
from what I know- the join channel that has the genesis block, is signed by the "admin private key" which any peer can verify using its local MSP
yacovm (Thu, 09 Feb 2017 16:31:03 GMT):
from what I know- the join channel that has the genesis block, is signed by the "admin private key" which any peer in that org can verify using its local MSP
binhn (Thu, 09 Feb 2017 16:35:16 GMT):
right, but peers in different orgs would require the app the switch to their orgs certs to sign the joinchannel proposal request
yacovm (Thu, 09 Feb 2017 16:36:52 GMT):
to switch to their admin keys, yes I would assume so... but I fail to see the problem, I thought that's how that was to work ?
yacovm (Thu, 09 Feb 2017 16:36:52 GMT):
to switch to their admin keys, yes I would assume so... but I fail to see the problem, I thought that's how that was planned to work ?
mastersingh24 (Thu, 09 Feb 2017 16:44:38 GMT):
@jimthematrix - each "org" is responsible for calling join channel on its own peers
mastersingh24 (Thu, 09 Feb 2017 16:45:24 GMT):
(if there was going to be a central authority, of course you could handle this by having a common root cert - in addition to the org cert - in each peers local msp)
jimthematrix (Thu, 09 Feb 2017 17:39:43 GMT):
@mastersingh24 yeah i agree that'll be the logical conclusion that the app on a per-user basis is only able to send the join channel request to the peer in its own org because it won't have the private key needed to sign something that can be validated/verified by a different org. unless like you said there's a common root cert
jimthematrix (Thu, 09 Feb 2017 17:39:43 GMT):
@mastersingh24 yeah i agree that'll be the logical conclusion, that the app on a per-user basis is only able to send the join channel request to the peer in its own org because it won't have the private key needed to sign something that can be validated/verified by a different org. unless like you said there's a common root cert
Vadim (Fri, 10 Feb 2017 09:17:49 GMT):
Has joined the channel.
mastersingh24 (Fri, 10 Feb 2017 10:15:39 GMT):
@aso @adc - either of you around?
mbaizan (Fri, 10 Feb 2017 10:47:13 GMT):
Has joined the channel.
adc (Fri, 10 Feb 2017 12:15:51 GMT):
Hey @mastersingh24, I'm here. Sorry for the late reply. I don't get the notifications :(
mastersingh24 (Fri, 10 Feb 2017 12:32:45 GMT):
no worries
mastersingh24 (Fri, 10 Feb 2017 12:32:48 GMT):
quick question
mastersingh24 (Fri, 10 Feb 2017 12:34:00 GMT):
I think we have some basics in place for this, but do we currently support using the same root CA / issuer across multiple MSPs (with the MSP differentiated by say the O / OU in the actual issued certificates)?
aso (Fri, 10 Feb 2017 13:17:14 GMT):
hey Gari. I'll soon (today) drop a CS that permits policy verification based on OU
aso (Fri, 10 Feb 2017 13:17:48 GMT):
basically a policy can specify that it requires a signature by a member of MSP foo that has OU = bar
aso (Fri, 10 Feb 2017 13:18:02 GMT):
which - if I got your Q correctly - should address that point
mastersingh24 (Fri, 10 Feb 2017 13:38:07 GMT):
hmm - ok - I'll look at the CS and make comments / suggestions ;)
mastersingh24 (Fri, 10 Feb 2017 14:33:16 GMT):
if still there, are we checking certificate usage? I am pretty sure that Go's crypto implementation does this by default?
ashutosh_kumar (Fri, 10 Feb 2017 15:05:04 GMT):
AFAIK , Go does not do by default. I might be wrong.
elli-androulaki (Fri, 10 Feb 2017 15:05:18 GMT):
you mean key-usage?
ashutosh_kumar (Fri, 10 Feb 2017 15:05:57 GMT):
yeah.
ashutosh_kumar (Fri, 10 Feb 2017 15:06:46 GMT):
by usage you mean like encryption and code signing /
elli-androulaki (Fri, 10 Feb 2017 15:07:11 GMT):
sorry, my bad, just checked it out
ashutosh_kumar (Fri, 10 Feb 2017 15:09:54 GMT):
what was the outcome ? I am curious like curious george.
ashutosh_kumar (Fri, 10 Feb 2017 15:09:54 GMT):
what was the outcome ? I am curious like curious george, which I watch all the time.
mastersingh24 (Fri, 10 Feb 2017 15:34:14 GMT):
For example, I know that within the TLS stack, it actually checks for proper usage for both the certificate and the issuer of the certificate
mastersingh24 (Fri, 10 Feb 2017 15:34:39 GMT):
for client certificates that is
mastersingh24 (Fri, 10 Feb 2017 15:40:51 GMT):
does not look like the ecdsa package checks for usage
robear (Fri, 10 Feb 2017 18:47:19 GMT):
Has joined the channel.
ashutosh_kumar (Fri, 10 Feb 2017 20:41:24 GMT):
you are correct @mastersingh24
ashutosh_kumar (Fri, 10 Feb 2017 20:42:43 GMT):
I was looking into Go Crypto package and found that it supports only Weierstrass curve with a=-3 , which to me seems to be severe limitation.
ashutosh_kumar (Fri, 10 Feb 2017 20:43:33 GMT):
whereas Bouncy Castle java implementation provides number of curves as per NIST.
ashutosh_kumar (Fri, 10 Feb 2017 20:44:36 GMT):
We might have requirement from customers to have Curve with higher N value so that subgroup with secure K value can be found.
ashutosh_kumar (Fri, 10 Feb 2017 20:45:43 GMT):
we need to think, how we can intergrate , say , Bouncy Caste java implementation to , say , BCCSP.
ashutosh_kumar (Fri, 10 Feb 2017 20:48:39 GMT):
otherwise we'll spend rest of life implementing those curves.:grin:
ashutosh_kumar (Fri, 10 Feb 2017 20:48:46 GMT):
:grimacing:
jimthematrix (Fri, 10 Feb 2017 21:01:31 GMT):
@aso @adc @elli-androulaki @mastersingh24 question on when MSP is loaded from a config, how is crypto parameters like security level, hash family and digital signature algo are decided. we could get that from the admincert or signercert, or specify that in the chain policy. i see this is pending in the peer code ATM:
mspimpl.go, line 63:
```
// TODO: security level, hash family and keystore should
// be probably set in the appropriate way.
```
jimthematrix (Fri, 10 Feb 2017 21:01:31 GMT):
@aso @adc @elli-androulaki @mastersingh24 question on when MSP is loaded from a config, how is crypto parameters like security level, hash family and digital signature algo are decided. we could get that from the admincert or signercert, or specify that in the chain policy. i see this is pending in the peer code ATM:
mspimpl.go, line 63:
```
// TODO: security level, hash family and keystore should
// be probably set in the appropriate way.
bccsp, err := sw.NewDefaultSecurityLevelWithKeystore(&sw.DummyKeyStore{})
```
jimthematrix (Fri, 10 Feb 2017 21:05:16 GMT):
presumably each chain can use a different parameter, and I think the peer code are set up to handle that (node SDK as well), but what source this information comes from is the question
vpaprots (Fri, 10 Feb 2017 21:40:38 GMT):
@jimthematrix your answer is in https://gerrit.hyperledger.org/r/#/c/4877/5
vpaprots (Fri, 10 Feb 2017 21:41:17 GMT):
was going to have it ready today, too many meetings.. had a rebasing issue that I missed
vpaprots (Fri, 10 Feb 2017 21:41:55 GMT):
default will come from a config file
hanhzf (Sat, 11 Feb 2017 03:41:55 GMT):
Has joined the channel.
jimthematrix (Sat, 11 Feb 2017 04:56:43 GMT):
thanks @vpaprots will take a look at the PR
ashutosh_kumar (Sat, 11 Feb 2017 14:24:33 GMT):
here is the list of curves supported by openssl : secp112r1 : SECG/WTLS curve over a 112 bit prime field
secp112r2 : SECG curve over a 112 bit prime field
secp128r1 : SECG curve over a 128 bit prime field
secp128r2 : SECG curve over a 128 bit prime field
secp160k1 : SECG curve over a 160 bit prime field
secp160r1 : SECG curve over a 160 bit prime field
secp160r2 : SECG/WTLS curve over a 160 bit prime field
secp192k1 : SECG curve over a 192 bit prime field
secp224k1 : SECG curve over a 224 bit prime field
secp224r1 : NIST/SECG curve over a 224 bit prime field
secp256k1 : SECG curve over a 256 bit prime field
secp384r1 : NIST/SECG curve over a 384 bit prime field
secp521r1 : NIST/SECG curve over a 521 bit prime field
prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
prime192v2: X9.62 curve over a 192 bit prime field
prime192v3: X9.62 curve over a 192 bit prime field
prime239v1: X9.62 curve over a 239 bit prime field
prime239v2: X9.62 curve over a 239 bit prime field
prime239v3: X9.62 curve over a 239 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field
sect113r1 : SECG curve over a 113 bit binary field
sect113r2 : SECG curve over a 113 bit binary field
sect131r1 : SECG/WTLS curve over a 131 bit binary field
sect131r2 : SECG curve over a 131 bit binary field
sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
sect163r1 : SECG curve over a 163 bit binary field
sect163r2 : NIST/SECG curve over a 163 bit binary field
sect193r1 : SECG curve over a 193 bit binary field
sect193r2 : SECG curve over a 193 bit binary field
sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
sect239k1 : SECG curve over a 239 bit binary field
sect283k1 : NIST/SECG curve over a 283 bit binary field
sect283r1 : NIST/SECG curve over a 283 bit binary field
sect409k1 : NIST/SECG curve over a 409 bit binary field
sect409r1 : NIST/SECG curve over a 409 bit binary field
sect571k1 : NIST/SECG curve over a 571 bit binary field
sect571r1 : NIST/SECG curve over a 571 bit binary field
c2pnb163v1: X9.62 curve over a 163 bit binary field
c2pnb163v2: X9.62 curve over a 163 bit binary field
c2pnb163v3: X9.62 curve over a 163 bit binary field
c2pnb176v1: X9.62 curve over a 176 bit binary field
c2tnb191v1: X9.62 curve over a 191 bit binary field
c2tnb191v2: X9.62 curve over a 191 bit binary field
c2tnb191v3: X9.62 curve over a 191 bit binary field
c2pnb208w1: X9.62 curve over a 208 bit binary field
c2tnb239v1: X9.62 curve over a 239 bit binary field
c2tnb239v2: X9.62 curve over a 239 bit binary field
c2tnb239v3: X9.62 curve over a 239 bit binary field
c2pnb272w1: X9.62 curve over a 272 bit binary field
c2pnb304w1: X9.62 curve over a 304 bit binary field
c2tnb359v1: X9.62 curve over a 359 bit binary field
c2pnb368w1: X9.62 curve over a 368 bit binary field
c2tnb431r1: X9.62 curve over a 431 bit binary field
wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field
wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field
wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field
wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field
wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field
wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field
wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field
wap-wsg-idm-ecid-wtls12: WTLS curvs over a 224 bit prime field
Oakley-EC2N-3:
IPSec/IKE/Oakley curve #3 over a 155 bit binary field.
Not suitable for ECDSA.
Questionable extension field!
Oakley-EC2N-4:
IPSec/IKE/Oakley curve #4 over a 185 bit binary field.
Not suitable for ECDSA.
Questionable extension field!
mastersingh24 (Sat, 11 Feb 2017 22:12:27 GMT):
@ashutosh_kumar - I don't think really pressing issues with the elliptic curve support in Go currently
ashutosh_kumar (Sat, 11 Feb 2017 23:14:22 GMT):
I agree @mastersingh24 , this it is not pressing immediate issue. But something to keep in mind.
frankylu (Sun, 12 Feb 2017 00:07:55 GMT):
Has joined the channel.
vpaprots (Sun, 12 Feb 2017 02:25:49 GMT):
@mastersingh24 @ashutosh_kumar Actually, this is _precisely_ why @adc and I (and few more people) want BCCSP. We (the fabric team) get out of the business of writing crypto primitives. (And Ash.. actually I dont see the brainpool or the chinese curves ;) ). The point of BCCSP is exactly 'fabric provides a few samples, you want other algorithms, you are welcome to write 'BrainpoolBCCSP'.
vpaprots (Sun, 12 Feb 2017 02:26:43 GMT):
We are not quite there yet.
- Step 1: configure which BCCSP to use
- Step 2: configure the _custom_ _name_ of algorithm to use
vpaprots (Sun, 12 Feb 2017 02:30:00 GMT):
@mastersingh24 I am not quiet sure how to get Step2 above done.. It kind of ties into what @jimthematrix was discussing (and @JonathanLevi and I earlier), where to specify a custom signature algorithm name. I suspect it will be somewhere in the protobuf structs..
vpaprots (Sun, 12 Feb 2017 02:30:50 GMT):
in which case it would be nicer to adjust protobufs now, even if we just hardcode to ecdsa-sha3-p256 or something (or OID..)
mgk (Sun, 12 Feb 2017 18:11:46 GMT):
Has joined the channel.
jimthematrix (Sun, 12 Feb 2017 20:31:18 GMT):
yeah bccsp is one level of abstraction that enables different algos and (for EC variations) curves to be plugged in. my question earlier was definitely your step 2 above, which would be on another abstraction level the MSPs. in the current code i think it's possible to make these params (algo, hash family, key length) a per-channel setting, so that the peers and orderers all follow the same set of params when signing and verifying. this requires orderers and peers to use per-channel-per-org MSPs (since the same org may be using different algo/hash/keylen on different channels). in real practice though i wonder if this level of complexity is needed or not. could this be decided by the consortium so all channels use the same? if v1.0 does this (statically set to a common setting throughout the network) will it cover 80% of use cases?
ashutosh_kumar (Sun, 12 Feb 2017 20:54:09 GMT):
Curve is algtogether beast by itself. It gives you point as Public Key on the curve. Curve and Algorithms are kind of orthogonal to each other.
ashutosh_kumar (Sun, 12 Feb 2017 20:55:19 GMT):
e.g same sig algo can be applied to different curves but getting generator of a curve is real pain.
ashutosh_kumar (Sun, 12 Feb 2017 20:57:37 GMT):
So coming up with Algo String is not going to solve the problem of adding support for different crypto providers , I think. Main issue is providing support of curve. For that BCCSP should be able to provide different crypto provider implemented in plethora of languages.
eheads (Mon, 13 Feb 2017 07:09:35 GMT):
Has joined the channel.
manu (Mon, 13 Feb 2017 10:16:26 GMT):
Has joined the channel.
mastersingh24 (Mon, 13 Feb 2017 13:14:54 GMT):
@aso @jyellick - I am now a bit confused on all this MSP stuff
mastersingh24 (Mon, 13 Feb 2017 13:14:54 GMT):
@aso @jyellick - I am now a bit confused on all this MSP stuff with regards to config, policies, etc
mastersingh24 (Mon, 13 Feb 2017 13:18:28 GMT):
I see 2 high level methods for identifying a "peer org" for X509-based providers:
1) Each peer org has its own "issuer" (i.e. unique root and/or intermediate certificates)
2) Multiple peer orgs "share" a common issuer but we distinguish different orgs based on the OU in the issued certificates
mastersingh24 (Mon, 13 Feb 2017 13:18:55 GMT):
we then have MSPConfig and MSPPrincipals
mastersingh24 (Mon, 13 Feb 2017 13:20:50 GMT):
so how exactly do we expect this to be "configured"?
elli-androulaki (Mon, 13 Feb 2017 13:48:15 GMT):
Hi @mastersingh24, there are two ways one can use to accommodate this need: i) the OUs is part of the configuration of an MSP in which case one need to extend (the current MSP implementation to accept as valid only certificates that are not only signed by a specific CA but rather also include a specific OU in them)
elli-androulaki (Mon, 13 Feb 2017 13:48:51 GMT):
ii) leave MSPs configuration as they are and allow the OU-based separation at the access policy level, which is what @aso's CR allows for.
elli-androulaki (Mon, 13 Feb 2017 13:49:42 GMT):
So, you say, I want a certain resource to be allowed by members of MSP with id X and belong to OU: "Payment Division
elli-androulaki (Mon, 13 Feb 2017 13:49:42 GMT):
So, you say, I want a certain resource to be allowed by members of MSP with id X and belong to OU: "Org1.Payment Division"
mastersingh24 (Mon, 13 Feb 2017 14:01:53 GMT):
Ok - right - so if one chooses a model where each "peer org" has its own issuer, there would be a separate MSP per "peer org". Correct?
mastersingh24 (Mon, 13 Feb 2017 14:03:15 GMT):
and if one chooses the "OU" for each "peer org", you would only need a single MSP
elli-androulaki (Mon, 13 Feb 2017 14:05:02 GMT):
correct, one could go either way
elli-androulaki (Mon, 13 Feb 2017 14:05:33 GMT):
what do you think is the simplest?
mastersingh24 (Mon, 13 Feb 2017 14:05:36 GMT):
but then the question is: how do these MSPs get distributed? And then we have MSPPrincipal used in policies. So you need to define these MSPPrincipals. For the OU case, seems that MSPPrincipal.principal should be serialized bytes of OrganizationUnit (which reference an MSP - so where is that MSP configured / distributed)?
mastersingh24 (Mon, 13 Feb 2017 14:06:11 GMT):
and in the case where you use MSPPrincipal to be a "member" own"admin" is that the serialization of the actual MSP itself?
mastersingh24 (Mon, 13 Feb 2017 14:06:41 GMT):
I am a bit torn as to which way to go - on the one hand, not having to duplicate the MSP in the OU case is nice
mastersingh24 (Mon, 13 Feb 2017 14:07:17 GMT):
on the other hand, having a consistent way to identity orgs is nice as well
elli-androulaki (Mon, 13 Feb 2017 14:09:55 GMT):
Yes, so say we have two orgs A and B that have the same root CA. If they agree that they will always be served by that CA and that a single (list of) admin(s) would serve both needs, (in other words that the same MSP configuration would serve their needs), we can use one MSP and have distinction based on OUs at the policy level.
mastersingh24 (Mon, 13 Feb 2017 14:11:01 GMT):
or we simply move "OU" under the MSPConfig and everything is based on MSPID
elli-androulaki (Mon, 13 Feb 2017 14:11:07 GMT):
However, if we want to keep the membership of each org seperately, we may as well define two MSPs (each with the same CAs, but perhaps different admins) and still define policies based on OUs or,
elli-androulaki (Mon, 13 Feb 2017 14:11:15 GMT):
Correct!
elli-androulaki (Mon, 13 Feb 2017 14:11:28 GMT):
Which would be ideal actually, but not sure if the time permits
elli-androulaki (Mon, 13 Feb 2017 14:11:43 GMT):
> mastersingh24 3:11 PM
> or we simply move "OU" under the MSPConfig and everything is based on MSPID
mastersingh24 (Mon, 13 Feb 2017 14:14:15 GMT):
I think it should simplify things actually if we go that route now. This way we can have a consistent way of identifying "orgs" - I think @aso should be able to modify the code so that in the case of member/admin, if for the given MSP OU is populated just make the OU check at that point?
mastersingh24 (Mon, 13 Feb 2017 14:15:27 GMT):
(BTW - this is how I was originally thinking things might work - hence why I was "confused" ;) )
elli-androulaki (Mon, 13 Feb 2017 14:15:58 GMT):
got it!
aso (Mon, 13 Feb 2017 14:19:24 GMT):
so, what should I do?
mastersingh24 (Mon, 13 Feb 2017 14:27:54 GMT):
Hi @aso
So here's what I think we (well you ;) ) should do ( @elli-androulaki please correct me if I'm off anywhere):
1) I think we go with a model where an MSP actually contains both the issuer (root/intermediates) and the OU (so you'd need to add an OU to the MSPConfig)
2) Instead of having a principal type of OrganizationalUnit, just have ROLE and IDENTITY
3) For ROLE, when you check things, you'll now need to see if the MSP specified on OU and if so make sure that the principal is not only from the issue in the MSP but also contains the OU specified as part of the MSP definition)
mastersingh24 (Mon, 13 Feb 2017 14:29:38 GMT):
so hopefully it's more or less adding a field to an MSP and then rearranging the code you have a bit in the implementation
mastersingh24 (Mon, 13 Feb 2017 14:30:02 GMT):
(sometimes I am an optimist ;) )
elli-androulaki (Mon, 13 Feb 2017 15:15:48 GMT):
So, i think for (2) we can leave mspprincipals as they are today, given that they support identities, admins, members (where members now would be forced to have a specifig OU inside their X509 cert?), and OUs that would make sense if there are multiple OUs within the same MSP (do you think the latter is a valid use-case)?
mastersingh24 (Mon, 13 Feb 2017 15:22:58 GMT):
we could probably leave the OU principal type in there for now
mastersingh24 (Mon, 13 Feb 2017 15:23:51 GMT):
question:
mastersingh24 (Mon, 13 Feb 2017 15:26:33 GMT):
members would not be "forced" unless the MSP has a list of OUs
mastersingh24 (Mon, 13 Feb 2017 15:43:44 GMT):
@elli-androulaki @aso - so do we just stick with what we have now and add to it (maybe later)?
mastersingh24 (Mon, 13 Feb 2017 15:44:38 GMT):
the current model lends itself well to having a "central" membership provider which differentiates orgs by OU but still has centralized control of the CA.
aso (Mon, 13 Feb 2017 15:52:23 GMT):
so we would stay in a model (the current) where a principal must match an MSP ID *and* an OU?
mastersingh24 (Mon, 13 Feb 2017 15:52:31 GMT):
re-thiniking - I think https://gerrit.hyperledger.org/r/#/c/5939/ is good
mastersingh24 (Mon, 13 Feb 2017 15:52:38 GMT):
yep
mastersingh24 (Mon, 13 Feb 2017 15:52:43 GMT):
I think it's fine
aso (Mon, 13 Feb 2017 15:52:59 GMT):
@elli-androulaki are you good as well?
mastersingh24 (Mon, 13 Feb 2017 15:53:25 GMT):
if people want to do things differently, we could add that later, but I think that the notion of OU to distiguish orgs is really geared towards the model with a central issuer
mastersingh24 (Mon, 13 Feb 2017 15:53:53 GMT):
but we still need to differentiate orgs in that model for policy enforcement. so @aso what we did in the CR makes perfect sense to me
elli-androulaki (Mon, 13 Feb 2017 15:58:13 GMT):
Sure, fine for me.
aso (Mon, 13 Feb 2017 15:58:18 GMT):
ok - thx! Still pending an ok from @elli-androulaki I'll polish up that CS, add what reviewers requested and push again
aso (Mon, 13 Feb 2017 15:58:23 GMT):
ah u beat me to it
aso (Mon, 13 Feb 2017 15:58:23 GMT):
:)
elli-androulaki (Mon, 13 Feb 2017 15:58:27 GMT):
:D
elli-androulaki (Mon, 13 Feb 2017 15:58:44 GMT):
I can add as an addition (time-permitting) to add OUs as optional part of MSPs
elli-androulaki (Mon, 13 Feb 2017 15:59:01 GMT):
and see where work takes us. But for us not to forget. Wdyt?
jimthematrix (Mon, 13 Feb 2017 16:04:16 GMT):
so the above discussion settles the "msp-per-org" vs. "msp-per-issuer" question, what about the "msp-per-chain" question I had above, as I thought the same issuer can sign certs with different parameters (algo, hash, curves), no?
jimthematrix (Mon, 13 Feb 2017 16:04:16 GMT):
so the above discussion settles the "msp-per-org" vs. "msp-per-issuer" question, what about the "msp-per-chain" question I had above, as I thought the same issuer could sign certs with different parameters (algo, hash, curves), no?
jimthematrix (Mon, 13 Feb 2017 16:07:13 GMT):
therefore, the same org uses ecdsa/256/sha2 for chain A but rsa/384/sha3 for chain B, and as such would need two separate local MSPs for each chain
jimthematrix (Mon, 13 Feb 2017 16:07:13 GMT):
therefore, the same org uses ecdsa/256/sha2 for chain A but rsa/384/sha3 for chain B, and as such would need two separate local MSPs, one for each chain
mastersingh24 (Mon, 13 Feb 2017 16:07:55 GMT):
that is a disastrous want to go
mastersingh24 (Mon, 13 Feb 2017 16:07:55 GMT):
that is a disastrous way to go
mastersingh24 (Mon, 13 Feb 2017 16:08:35 GMT):
if you are asking about being able to set the "cyrptosuite" on a per channel basis, then that is something else ;)
jimthematrix (Mon, 13 Feb 2017 16:08:58 GMT):
good question
jimthematrix (Mon, 13 Feb 2017 16:09:01 GMT):
i think I am
jimthematrix (Mon, 13 Feb 2017 16:14:35 GMT):
so first question is if the fabric wants to support different chains using different signing parameters. and if so, the preferred way is to use a single MSP by with different bccsp, instead of multiple MSPs
jimthematrix (Mon, 13 Feb 2017 16:14:35 GMT):
so first question is if the fabric wants to support different chains using different signing parameters. and if so, i guess the preferred way is to use a single MSP by with different bccsp, instead of multiple MSPs
ashutosh_kumar (Mon, 13 Feb 2017 16:28:54 GMT):
can single MSP have different BCCSP ?
ashutosh_kumar (Mon, 13 Feb 2017 16:28:54 GMT):
can single MSP have multiple BCCSP ?
ashutosh_kumar (Mon, 13 Feb 2017 16:29:38 GMT):
I do not think so , I might be wrong.
ashutosh_kumar (Mon, 13 Feb 2017 16:30:09 GMT):
as bccsp is tied to Private Key.
aso (Mon, 13 Feb 2017 16:30:27 GMT):
Has left the channel.
ashutosh_kumar (Mon, 13 Feb 2017 16:33:34 GMT):
I think , we can instantiate single BCCSP per MSP and call , say , verify method , based on algo that is being passed.
ashutosh_kumar (Mon, 13 Feb 2017 16:33:34 GMT):
I think , we can instantiate single BCCSP per MSP and call , say , verify method , based on sig algo that is being passed.
kostas (Mon, 13 Feb 2017 19:00:51 GMT):
What is the most up-to-date high-level document on how MSPs are supposed to work?
kostas (Mon, 13 Feb 2017 19:01:07 GMT):
Trying to catch up so I may have missed it.
kostas (Mon, 13 Feb 2017 19:02:03 GMT):
Last document I had bumped into was this https://docs.google.com/document/d/1Qg7ZEccOIsrShSHSNl4kBHOFvLYRhQ3903srJ6c_AZE/edit but there are some 3-week level questions there that are still unanswered.
kostas (Mon, 13 Feb 2017 19:03:19 GMT):
(And I have a good feeling that several pieces in there must be, or already being reworked.)
vpaprots (Mon, 13 Feb 2017 19:22:49 GMT):
So I ran into a problem that I don't quite know how to address.. Been staring at this for a day now. Would appreciate some new thoughts.
vpaprots (Mon, 13 Feb 2017 19:24:03 GMT):
With https://gerrit.hyperledger.org/r/#/c/4877/8 I insist that BEFORE one uses BCCSP you _must_ call `factory.InitFactories(config OR nil)`
vpaprots (Mon, 13 Feb 2017 19:25:10 GMT):
The second part of that idea is here: https://gerrit.hyperledger.org/r/#/c/5897/1. Modifies the `orderer.yaml` and `core.yaml`
vpaprots (Mon, 13 Feb 2017 19:26:15 GMT):
seems to work fine.. problem.. none of the test cases actually call `factory.InitFactories(nil)`. And there are a lot of those..
vpaprots (Mon, 13 Feb 2017 19:27:14 GMT):
I am debating the idea that for the peer, BCCSP config should be part of MSP config
vpaprots (Mon, 13 Feb 2017 19:28:08 GMT):
but, just like last couple of questions, I am not entirely clear how MSP is configured.
vpaprots (Mon, 13 Feb 2017 19:29:26 GMT):
func GetLocalMSP() msp.MSP { << would be nice to have viper access here?
...
if lclMsp == nil {
..
lclMsp, err = msp.NewBccspMsp()
vpaprots (Mon, 13 Feb 2017 19:30:08 GMT):
@binhn @mastersingh24 ^^ any thoughts on whom I can bug for this? dead in the water here..
mastersingh24 (Mon, 13 Feb 2017 20:04:51 GMT):
I think "type" of MSP is associated with a type of BCCSP - but I don't think that the config for bccsp should be in individual MSPs
mastersingh24 (Mon, 13 Feb 2017 20:06:35 GMT):
I think the "real" question is where do we define the crypto parameters for the blockchain. do we do it "global" to the entire blockchain? do we do it per channel?
mastersingh24 (Mon, 13 Feb 2017 20:06:56 GMT):
I would not think that we define signing algorithm within an MSP
mastersingh24 (Mon, 13 Feb 2017 20:08:30 GMT):
for X509, I guess we could have a mismatch for EC versus RSA (and I supposed even ECDSA versus some other EC signing mechanism - e.g. EdDSA)
ashutosh_kumar (Mon, 13 Feb 2017 20:45:23 GMT):
I think , there is one-to-one mapping between private key and bccsp.
vpaprots (Mon, 13 Feb 2017 20:50:35 GMT):
@mastersingh24 Let me reword somewhat. You are right, there are many configuration questions. The one I am stuck on is 'I want this executable to use THIS crypto implementation (BCCSP)'. So the way I approached it.. `ls build/bin` great, I need to patch `orderer` and `peer`. That seems to make sense to me.. except all the `go test` executions also produce an executable
mastersingh24 (Mon, 13 Feb 2017 21:13:29 GMT):
@vpaprots - so in
```
func GetDefault() bccsp.BCCSP {
if defaultBCCSP == nil {
panic("BCCSP Factory: Must call InitFactories before using BCCSP!")
}
```
mastersingh24 (Mon, 13 Feb 2017 21:13:45 GMT):
why not just call InitFactories here?
mastersingh24 (Mon, 13 Feb 2017 21:14:53 GMT):
mind you that was not a deep look at all the code ;)
vpaprots (Mon, 13 Feb 2017 21:15:13 GMT):
typically, I want the config available.. if you could have a look at https://gerrit.hyperledger.org/r/#/c/5897/1/peer/common/common.go
vpaprots (Mon, 13 Feb 2017 21:15:40 GMT):
for default init, I am just fine calling InitFactories(nil)
vpaprots (Mon, 13 Feb 2017 21:15:59 GMT):
but typically, this comes from viper.Unmarshall
vpaprots (Mon, 13 Feb 2017 21:18:18 GMT):
@mastersingh24 ^
vpaprots (Mon, 13 Feb 2017 21:19:35 GMT):
well.. that does remind me of a decision made of not having viper inside bccsp..
mastersingh24 (Mon, 13 Feb 2017 21:25:53 GMT):
yeah - well the whole config stuff is a bit messy
vpaprots (Mon, 13 Feb 2017 21:26:07 GMT):
:(
vpaprots (Mon, 13 Feb 2017 21:26:21 GMT):
its been making me cry!! :)
mastersingh24 (Mon, 13 Feb 2017 21:26:29 GMT):
but it seems that GetDefault is supposed to more or less load the default setting - which I assume would come from config
vpaprots (Mon, 13 Feb 2017 21:26:42 GMT):
yeah
mastersingh24 (Mon, 13 Feb 2017 21:28:27 GMT):
so if you did InitFactories(nil) in GetDefault, wouldn't that basically be the same as how things work today?
vpaprots (Mon, 13 Feb 2017 21:28:58 GMT):
thats what I do here: https://gerrit.hyperledger.org/r/#/c/4877/8/bccsp/factory/opts.go
vpaprots (Mon, 13 Feb 2017 21:29:01 GMT):
line 36
vpaprots (Mon, 13 Feb 2017 21:29:21 GMT):
that patch set is ready..
vpaprots (Mon, 13 Feb 2017 21:29:35 GMT):
the next one is trying to actually make it configurable
vpaprots (Mon, 13 Feb 2017 21:29:49 GMT):
(there are two 'related' patch sets)
vpaprots (Mon, 13 Feb 2017 21:31:09 GMT):
(as a side benefit.. I am getting free review from you! :D)
mastersingh24 (Mon, 13 Feb 2017 21:31:41 GMT):
yeah - but I guess in code which just calls GetDefault without going through the whole config path, it seems that instead of panicing in GetDefault that calling InitFactories(nil) would actually be the right them to do? else you'd have to modify all code that calls GetDefault
vpaprots (Mon, 13 Feb 2017 21:32:05 GMT):
hmm
vpaprots (Mon, 13 Feb 2017 21:32:24 GMT):
if not initialized, call initfactories(nil)
vpaprots (Mon, 13 Feb 2017 21:32:33 GMT):
well.. that could work..
vpaprots (Mon, 13 Feb 2017 21:32:49 GMT):
I think I like that..
mastersingh24 (Mon, 13 Feb 2017 21:32:56 GMT):
still hacky and would not be the case for normal operation through the peer / orderer
mastersingh24 (Mon, 13 Feb 2017 21:33:06 GMT):
only via component test paths methinks
vpaprots (Mon, 13 Feb 2017 21:33:19 GMT):
I get worried with defaults in crypto code.. typical attack vector would force the 'fallback'
mastersingh24 (Mon, 13 Feb 2017 21:33:23 GMT):
so I think it is the easiest solution to get things moving
vpaprots (Mon, 13 Feb 2017 21:33:27 GMT):
yeah
vpaprots (Mon, 13 Feb 2017 21:34:13 GMT):
thanks @mastersingh24 !!
JonathanLevi (Mon, 13 Feb 2017 21:48:39 GMT):
I think that at some point, in one way or another, we will also need to also think about the *usability* of the "entire" solution.
JonathanLevi (Mon, 13 Feb 2017 21:49:50 GMT):
That is, we have a few different "configurable" components... whether they are the default ones in some cases, or specific ones that a "deployer" would like to use... say in the "roll you own crypto" scenario.
JonathanLevi (Mon, 13 Feb 2017 21:50:38 GMT):
We should be able to make sure that the system does what is intended... especially in terms of matching the various components and their versions.
JonathanLevi (Mon, 13 Feb 2017 21:52:36 GMT):
So a few things: We need to have the "pluggable" architecture, where one can replace components as needed, at the same time, I don't like viper, and I don't want it to be too complex to bootstrap.
JonathanLevi (Mon, 13 Feb 2017 21:54:38 GMT):
Let's get things moving and also make sure we have enough time to work out a/the few "flows" that are plausible and are well tested... so that we can point people to a few working examples (that include some good non-default components/behavior)...
s.narayanan (Mon, 13 Feb 2017 23:05:03 GMT):
Has joined the channel.
vpaprots (Tue, 14 Feb 2017 03:15:52 GMT):
Onto my next 'argument'. KeyImports of Clear text PEM vs GetKey of SKI PEM ;) protobuf: `FabricMSPConfig`-> `SigningIdentityInfo`-> `KeyInfo`
vpaprots (Tue, 14 Feb 2017 03:16:22 GMT):
// KeyInfo represents a (secret) key that is either already stored
// in the bccsp/keystore or key material to be imported to the
// bccsp key-store. In later versions it may contain also a
// keystore identifier
type KeyInfo struct {
// Identifier of the key inside the default keystore; this for
// the case of Software BCCSP as well as the HSM BCCSP would be
// the SKI of the key
KeyIdentifier string `protobuf:"bytes,1,opt,name=key_identifier,json=keyIdentifier" json:"key_identifier,omitempty"`
// KeyMaterial (optional) for the key to be imported; this is
// properly encoded key bytes, prefixed by the type of the key
KeyMaterial []byte `protobuf:"bytes,2,opt,name=key_material,json=keyMaterial,proto3" json:"key_material,omitempty"`
}
vpaprots (Tue, 14 Feb 2017 03:17:03 GMT):
(is there a better way for code snippets? :thinking: )
vpaprots (Tue, 14 Feb 2017 03:17:57 GMT):
Great.. well.. I kinda wish the 'KeyMaterial' element wasnt present at all, but I will admit that I can 'live' with it as an 'option'..
vpaprots (Tue, 14 Feb 2017 03:18:35 GMT):
`KeyIdentifier` is an SKI, and `KeyMaterial` is empty.
vpaprots (Tue, 14 Feb 2017 03:19:34 GMT):
Can we agree that that is indeed a valid usage?
msp/configbuilder.go: keyinfo := &msp.KeyInfo{KeyIdentifier: "PEER", KeyMaterial: keys[0]}
msp/mspwithintermediatecas_test.go: keyinfo := &msp.KeyInfo{KeyIdentifier: "PEER", KeyMaterial: []byte(key)}
"PEER" does _not_ looks like an SKI
vpaprots (Tue, 14 Feb 2017 03:20:07 GMT):
in fact `KeyIdentifier` should also be a `[]byte`.. whom do I talk to about protobuf changes!?
vpaprots (Tue, 14 Feb 2017 03:20:07 GMT):
in fact `KeyIdentifier` should also be a `[]byte`.. whom do I talk to about protobuf changes?
JonathanLevi (Tue, 14 Feb 2017 10:12:37 GMT):
"whom do I talk to about protobuf changes?" *JIRA*
JonathanLevi (Tue, 14 Feb 2017 10:13:46 GMT):
The easiest probably to open a detailed JIRA ticket, explaining why/what and how you suggest to resolve as well... and we can push this through @vpaprots
JonathanLevi (Tue, 14 Feb 2017 10:14:14 GMT):
@vpaprots: The easiest is probably to open a detailed JIRA ticket, explaining why/what and how you suggest to resolve as well... and we can push this through.
niteshsolanki (Wed, 15 Feb 2017 05:49:53 GMT):
Hi. In v0.6 when the peer is started, tls.cert and tls.key files are generated in peer's directory. what these files are used for? is it used for tls-set up?
dave.enyeart (Wed, 15 Feb 2017 11:57:35 GMT):
Has joined the channel.
dave.enyeart (Wed, 15 Feb 2017 11:59:33 GMT):
@muralisr and all, today when testing end-to-end I'm getting the following error. Do I need to do something different now?
dave.enyeart (Wed, 15 Feb 2017 11:59:40 GMT):
vagrant@hyperledger-devenv:v0.3.0-36bbeb6:/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode$ CORE_PEER_ADDRESS=0.0.0.0:7051 peer chaincode install -n marbles2 -p github.com/hyperledger/fabric/examples/chaincode/go/marbles02 -v 2
panic: Fatal error when setting up MSP from directory msp/sampleconfig: err Could not load a valid ca certificate from directory msp/sampleconfig/cacerts, err Could not read directory open msp/sampleconfig/cacerts: no such file or directory, err msp/sampleconfig/cacerts
dave.enyeart (Wed, 15 Feb 2017 12:00:17 GMT):
nevermind... I was in the wrong directory...
cdaughtr (Wed, 15 Feb 2017 14:06:53 GMT):
@aso When running end-to-end or endorser-tests, peer exits with code 2 running msgvalidation.go.checkSignatureFromCreator. The code that is failing is MSPConfigHandler autogenerated, so not able to add any helpful debugging. The only difference between fabric-sdk-node and fabric that I have found it that node has an identity.proto class that is missing in fabric. Even though there were many fabric proto changes recently, I did not see anything significant for mspConfig.
Getting invalid memory address or nil pointer dereference from validation.checkSignatureFromCreator: msp.(*MSPConfigHandler).DeserializeIdentity
aso (Wed, 15 Feb 2017 14:06:53 GMT):
Has joined the channel.
aso (Wed, 15 Feb 2017 14:33:57 GMT):
this is an (expected) regression that was introduced with the new config work; it will be fixed as soon as 5989 and 6021 are merged; that said, MSP should fail more gracefully, which is a separate change set that I'll push shortly
aso (Wed, 15 Feb 2017 14:33:57 GMT):
this is a (known) regression that was introduced with the new config work; it will be fixed as soon as 5989 and 6021 are merged; that said, MSP should fail more gracefully, which is a separate change set that I'll push shortly
cdaughtr (Wed, 15 Feb 2017 15:30:41 GMT):
About the transaction id... Has there been a decision about how it should be created? If so, can someone point us (sdk team) to the JIRA# or doc?
Vadim (Wed, 15 Feb 2017 15:34:46 GMT):
@cdaughtr in the end-to-end.js it's generated as `tx_id = utils.buildTransactionID({length:12});` where buildTransactionID just calls crypto.randomBytes()
cdaughtr (Wed, 15 Feb 2017 15:36:47 GMT):
@Vadim Jim told us that there was discussion on changing it to guarantee it to be more unique across channels.
Vadim (Wed, 15 Feb 2017 15:37:10 GMT):
I see that in the comment field, but so far it's like that
aso (Wed, 15 Feb 2017 15:40:54 GMT):
@adc pls describe the new way txids are generated
aso (Wed, 15 Feb 2017 15:41:01 GMT):
it has indeed changes (or will shortly)
adc (Wed, 15 Feb 2017 15:43:06 GMT):
@aso, @cdaughtr, please have a look at https://gerrit.hyperledger.org/r/#/c/5945/
cdaughtr (Wed, 15 Feb 2017 15:45:28 GMT):
@adc Thanks, that's what we were looking for.
adc (Wed, 15 Feb 2017 15:45:31 GMT):
for a code reference look at https://gerrit.hyperledger.org/r/#/c/5945/6/protos/utils/proputils.go line 504
adc (Wed, 15 Feb 2017 15:45:49 GMT):
that's the function that computes the TxID
stanliberman (Wed, 15 Feb 2017 18:09:44 GMT):
Has joined the channel.
cdaughtr (Wed, 15 Feb 2017 22:24:30 GMT):
@jimthematrix @aso With the latest fabric, end-to-end is having a problem with proposal.proto at Chain.sendTransaction, `chaincodeProposalPayloadNoTrans.transient = null;`
Error message 'Illegal value for Message.Field .protos.ChaincodeProposalPayload.transient of type bytes: object (proto3 field without field presence cannot be null)'. I don't see what changed in the endorser code to cause this. Any ideas?
xixuejia (Thu, 16 Feb 2017 02:48:26 GMT):
Has joined the channel.
wutongtree (Thu, 16 Feb 2017 09:54:02 GMT):
Has joined the channel.
salmanbaset (Thu, 16 Feb 2017 12:43:04 GMT):
Has joined the channel.
JonathanLevi (Thu, 16 Feb 2017 16:58:24 GMT):
---
JonathanLevi (Thu, 16 Feb 2017 16:58:31 GMT):
https://gerrit.hyperledger.org/r/#/c/4723
JonathanLevi (Thu, 16 Feb 2017 16:58:43 GMT):
What's going on?
aso (Thu, 16 Feb 2017 17:31:22 GMT):
hey Jonathan. Thx for the comments - like I said in the chat, I've educated myself on the subject a little bit to understand your point more correctly, and while reading, I've found the authoritative definition for "Authority Key Identifier" in the RFC https://tools.ietf.org/html/rfc3280.html#section-4.2.1.1
aso (Thu, 16 Feb 2017 17:31:31 GMT):
so I just thought I'd use that
aso (Thu, 16 Feb 2017 17:31:47 GMT):
in the comment to the function that retrieves said identifier from a CRL
ylsGit (Fri, 17 Feb 2017 02:28:08 GMT):
Has joined the channel.
RajkumarNatarajan (Fri, 17 Feb 2017 03:58:13 GMT):
Has joined the channel.
aso (Fri, 17 Feb 2017 13:19:21 GMT):
folks, please weigh in for this change set
aso (Fri, 17 Feb 2017 13:19:21 GMT):
https://gerrit.hyperledger.org/r/#/c/6149/
aso (Fri, 17 Feb 2017 13:20:03 GMT):
still WIP, but comments are appreciated
o.o. (Fri, 17 Feb 2017 14:29:23 GMT):
Has joined the channel.
kostas (Fri, 17 Feb 2017 16:00:15 GMT):
Is there a document that describes how one would go about setting up / configuring an MSP? (MSP instance? Not sure what's the right term.)
jyellick (Fri, 17 Feb 2017 17:30:48 GMT):
@adc @aso @elli-androulaki When calling `GetLocalMspConfig` there is a supplied `ID`, does this override the ID defined inside the msp configuration? Is it orthogonal to the MSP ID?
cdaughtr (Fri, 17 Feb 2017 19:56:55 GMT):
@adc In fabric-node-sdk, we are trying to implement the new TxID with nonce + creator. It is failing with
`Error: Transaction is not valid. Got [ZWY0MGRiYjM4MTJiNjMyNDQzZWE5OWViZDBhNzI2ZDdhMDE2MGZiNzRmZTRkMjU3MGQxYzk1NzVlNDRjYTJhZg==], expected [70Dbs4ErYyRD6pnr0Kcm16AWD7dP5NJXDRyVdeRMoq8=]'.
cdaughtr (Fri, 17 Feb 2017 19:56:55 GMT):
@adc In fabric-node-sdk, we are trying to implement the new TxID with nonce + creator. It is failing with
`Error: Transaction is not valid. Got [ZWY0MGRiYjM4MTJiNjMyNDQzZWE5OWViZDBhNzI2ZDdhMDE2MGZiNzRmZTRkMjU3MGQxYzk1NzVlNDRjYTJhZg==], expected [70Dbs4ErYyRD6pnr0Kcm16AWD7dP5NJXDRyVdeRMoq8=]'.
buildTransactionID(nonce, userContext) {
logger.debug('buildTransactionID - start');
var creator_bytes = userContext.getIdentity().serialize();//same as signatureHeader.Creator
var nonce_bytes = nonce;//nonce is already in bytes
var trans_bytes = Buffer.concat([nonce_bytes, creator_bytes]);
var trans_hash = this.cryptoPrimitives.hash(trans_bytes);
var transaction_id = Buffer.from(trans_hash).toString('base64');
logger.debug('buildTransactionID - transaction_id %s',transaction_id);
return transaction_id;
}
cdaughtr (Fri, 17 Feb 2017 19:56:55 GMT):
@adc In fabric-node-sdk, we are trying to implement the new TxID with nonce + creator: https://gerrit.hyperledger.org/r/#/c/5945/
It is failing with
`Error: Transaction is not valid. Got [ZWY0MGRiYjM4MTJiNjMyNDQzZWE5OWViZDBhNzI2ZDdhMDE2MGZiNzRmZTRkMjU3MGQxYzk1NzVlNDRjYTJhZg==], expected [70Dbs4ErYyRD6pnr0Kcm16AWD7dP5NJXDRyVdeRMoq8=]'.
buildTransactionID(nonce, userContext) {
logger.debug('buildTransactionID - start');
var creator_bytes = userContext.getIdentity().serialize();//same as signatureHeader.Creator
var nonce_bytes = nonce;//nonce is already in bytes
var trans_bytes = Buffer.concat([nonce_bytes, creator_bytes]);
var trans_hash = this.cryptoPrimitives.hash(trans_bytes);
var transaction_id = Buffer.from(trans_hash).toString('base64');
logger.debug('buildTransactionID - transaction_id %s',transaction_id);
return transaction_id;
}
cdaughtr (Fri, 17 Feb 2017 19:56:55 GMT):
@adc In fabric-node-sdk, we are trying to implement the new TxID with nonce + creator: https://gerrit.hyperledger.org/r/#/c/5945/
It is failing with
`Error: Transaction is not valid. Got [ZWY0MGRiYjM4MTJiNjMyNDQzZWE5OWViZDBhNzI2ZDdhMDE2MGZiNzRmZTRkMjU3MGQxYzk1NzVlNDRjYTJhZg==], expected [70Dbs4ErYyRD6pnr0Kcm16AWD7dP5NJXDRyVdeRMoq8=]'.
`buildTransactionID(nonce, userContext) {
logger.debug('buildTransactionID - start');
var creator_bytes = userContext.getIdentity().serialize();//same as signatureHeader.Creator
var nonce_bytes = nonce;//nonce is already in bytes
var trans_bytes = Buffer.concat([nonce_bytes, creator_bytes]);
var trans_hash = this.cryptoPrimitives.hash(trans_bytes);
var transaction_id = Buffer.from(trans_hash).toString('base64');
logger.debug('buildTransactionID - transaction_id %s',transaction_id);
return transaction_id;
}`
cdaughtr (Fri, 17 Feb 2017 19:56:55 GMT):
@adc In fabric-node-sdk, we are trying to implement the new TxID with nonce + creator: https://gerrit.hyperledger.org/r/#/c/5945/
It is failing with
`Error: Transaction is not valid. Got [ZWY0MGRiYjM4MTJiNjMyNDQzZWE5OWViZDBhNzI2ZDdhMDE2MGZiNzRmZTRkMjU3MGQxYzk1NzVlNDRjYTJhZg==], expected [70Dbs4ErYyRD6pnr0Kcm16AWD7dP5NJXDRyVdeRMoq8=]'.
```buildTransactionID(nonce, userContext) {
logger.debug('buildTransactionID - start');
var creator_bytes = userContext.getIdentity().serialize();//same as signatureHeader.Creator
var nonce_bytes = nonce;//nonce is already in bytes
var trans_bytes = Buffer.concat([nonce_bytes, creator_bytes]);
var trans_hash = this.cryptoPrimitives.hash(trans_bytes);
var transaction_id = Buffer.from(trans_hash).toString('base64');
logger.debug('buildTransactionID - transaction_id %s',transaction_id);
return transaction_id;
}```
mastersingh24 (Sat, 18 Feb 2017 13:12:59 GMT):
[ You probably found this yourself, but GetLocalMSPConfig simply reads the actual crypto material itself from a folder structure under the `dir` parameter. The `ID` passed in will be used to the the `Name` field of the FabricMSPConfig instance](https://chat.hyperledger.org/channel/fabric-crypto?msg=nZMG6HCyMosREDYYk) @jyellick
yacovm (Sat, 18 Feb 2017 13:13:46 GMT):
IIUC the name and ID of the MSP are actually the same thing
elli-androulaki (Sat, 18 Feb 2017 14:37:24 GMT):
Correct, "Name" in fabricMSPConfig actually represents the identifier of that MSP
kostas (Sat, 18 Feb 2017 16:49:56 GMT):
https://chat.hyperledger.org/channel/fabric-crypto?msg=u57sMP4AKCAa3sjBd
kostas (Sat, 18 Feb 2017 16:50:03 GMT):
https://chat.hyperledger.org/channel/fabric-crypto?msg=KLgXCynW6bFxP7Lwe
jyellick (Sat, 18 Feb 2017 20:54:00 GMT):
Master is currently broken
jyellick (Sat, 18 Feb 2017 20:54:14 GMT):
Because of the introduction of `CheckProposalTxID`
yacovm (Sat, 18 Feb 2017 21:02:28 GMT):
the replay attack change set?
yacovm (Sat, 18 Feb 2017 21:02:33 GMT):
@jyellick
jyellick (Sat, 18 Feb 2017 21:02:50 GMT):
Yes
jyellick (Sat, 18 Feb 2017 21:03:01 GMT):
https://gerrit.hyperledger.org/r/#/c/6225/
jyellick (Sat, 18 Feb 2017 21:03:28 GMT):
This should at least unbork CI, but we need to actually analyze how txid and config will interact
yacovm (Sat, 18 Feb 2017 22:07:26 GMT):
The merge job of the replay attack on Z succeeded though... had master been broken by it- it should had failed
yacovm (Sat, 18 Feb 2017 22:07:26 GMT):
The merge job of the replay attack on Z succeeded though... had master been broken by it- it should have failed
yacovm (Sat, 18 Feb 2017 22:07:41 GMT):
https://jenkins.hyperledger.org/job/fabric-merge-z/483/console
mastersingh24 (Sun, 19 Feb 2017 00:33:22 GMT):
I don't know why we merge change sets that are not required for the basic end to end flow. I'll leave it at that
elli-androulaki (Sun, 19 Feb 2017 08:32:22 GMT):
@kostas, for MSP description you may look this one: https://docs.google.com/document/d/1Qg7ZEccOIsrShSHSNl4kBHOFvLYRhQ3903srJ6c_AZE/edit?usp=sharing
elli-androulaki (Sun, 19 Feb 2017 08:33:35 GMT):
The way MSPs are (re)configured is not up to date given the recent changes in config mechanism, but will be sometime next week. But the logic and the parameters an MSP takes to be setup (proto messages) are up to date.
aso (Sun, 19 Feb 2017 11:40:27 GMT):
@adc @elli-androulaki @mastersingh24 please have a look - I've removed the WIP tag https://gerrit.hyperledger.org/r/#/c/6149/
mastersingh24 (Sun, 19 Feb 2017 12:15:17 GMT):
@aso - looks good - just waiting for it to pass CI again
mastersingh24 (Sun, 19 Feb 2017 12:16:33 GMT):
I agree that we might want to look at checking the CRL is signed by the CA it claims to be for, but given you'd only verify the signature if you find a matching cert in the revocation list, doing it this way should not overhead in the common path
adc (Sun, 19 Feb 2017 13:47:34 GMT):
@vpaprots bccsp/pkcs11 package needs to be refactored to leverage the existing SW implementation rather than duplicate all the functions. Otherwise, it is a mess to keep them in sync :(
adc (Sun, 19 Feb 2017 13:48:51 GMT):
@jyellick, where can I find the readers and writers policies in the channel configuration? Thanks :). @elli-androulaki
vpaprots (Sun, 19 Feb 2017 15:28:15 GMT):
@adc Actually.. the idea was to replace the other SW operations in PKCS11 BCCSP with PKCS11 operations. I will get there, but its more important now for the PKCS11 code to be used first
adc (Sun, 19 Feb 2017 15:30:44 GMT):
I see, we need to accelerate then no?
adc (Sun, 19 Feb 2017 15:33:58 GMT):
@jyellick regarding your https://gerrit.hyperledger.org/r/#/c/6225/, I would have expected a test to highlight the fact that CheckProposalTxID has to be enforced only for endorsed transactions otherwise we risk other issues in the future, no?
jyellick (Sun, 19 Feb 2017 15:36:16 GMT):
Yes, I wanted to discuss this with you. Obviously we could set the txID for config transactions, but I'm not sure that it would be useful for them
adc (Sun, 19 Feb 2017 15:40:37 GMT):
@elli-androulaki @jyellick actually, it would be nice to have txid computed in the same way for the all the transactions but I see that config is a special case
adc (Sun, 19 Feb 2017 15:40:58 GMT):
it is anyway good to have a standard for the generation of txid for configuration txs
elli-androulaki (Sun, 19 Feb 2017 16:03:49 GMT):
isnt the case config tx replays we need on the orderer side?
elli-androulaki (Sun, 19 Feb 2017 16:03:49 GMT):
isnt the case config tx replay detection we need on the orderer side?
kostas (Sun, 19 Feb 2017 16:13:30 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=qJN76MoWW7dfWycAp) @elli-androulaki Got it, thank you. FWIW, I'm offering to write this if you need an extra pair of hands, when the dust finally settles on this. What I'm personally looking for is a bare-minimum, straightforward HOWTO on creating a sample MSP.
kostas (Sun, 19 Feb 2017 16:15:28 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=r6rFrEuW7bcJXmuhv) @elli-androulaki: As for this, I've read it (see earlier comment 5-6 days ago) but there are 16 unanswered questions there (not including suggestions), 11 of which are mine.
mastersingh24 (Sun, 19 Feb 2017 16:19:33 GMT):
@kostas - uh - it's really simple and I agree with you that we should explain the basics of an X509-based MSP. There's only a few fields to populate and in the simplest case for MSPs used for organizations you should only need to provide a name and a root certificate ;)
mastersingh24 (Sun, 19 Feb 2017 16:20:03 GMT):
I've been waiting for the dust to settle so that we can get this info properly into the updated documentation
mastersingh24 (Sun, 19 Feb 2017 16:20:16 GMT):
someone we've turned something quite simple into a beast :(
mastersingh24 (Sun, 19 Feb 2017 16:22:26 GMT):
I guess there's 2 parts: populating an MSP (which is what end users will care about) and then there's using the MSP interfaces within fabric components (which fabric core developers will care about)
elli-androulaki (Sun, 19 Feb 2017 16:31:15 GMT):
Hi @kostas, thanks for the offer to help. Will get back to you this week while revising the document.
elli-androulaki (Sun, 19 Feb 2017 16:33:26 GMT):
Some of your questions have already been answered.
kostas (Sun, 19 Feb 2017 16:39:10 GMT):
The 11 ones of mine are the unanswered ones :wink:
elli-androulaki (Sun, 19 Feb 2017 16:56:01 GMT):
ok, will take a look
jyellick (Sun, 19 Feb 2017 16:58:54 GMT):
@adc @elli-androulaki Why is the `tx_id` in the header a string when it is a hash? (and not bytes)
adc (Sun, 19 Feb 2017 16:59:49 GMT):
if I remember correctly, if was bytes at the very beginning and then it was requested to change to string
adc (Sun, 19 Feb 2017 17:00:05 GMT):
I'm fine to move back to bytes
jyellick (Sun, 19 Feb 2017 17:01:40 GMT):
The fact that we are base64 encoding it is very odd to me
jyellick (Sun, 19 Feb 2017 17:01:46 GMT):
When we store all the other hash results in the protos as bytes
jyellick (Sun, 19 Feb 2017 17:02:07 GMT):
The `channel_id` used to be bytes but was changed to string, I do not know about `tx_id`
rickr (Sun, 19 Feb 2017 20:00:36 GMT):
Have to ask this ... Why is the SDKs creating the tx_ids at all ? Shouldn't when we create a proposal the proposal response has the tx_id that the fabric created for us to reference this ?
vdods (Sun, 19 Feb 2017 23:48:35 GMT):
Has joined the channel.
elli-androulaki (Mon, 20 Feb 2017 09:12:00 GMT):
@rickr, I was wondering the same thing.
yacovm (Mon, 20 Feb 2017 09:21:29 GMT):
I'm not sure from a crypto point of view, but having a txId in the client side has the following benefit:
yacovm (Mon, 20 Feb 2017 09:22:02 GMT):
In general, when you invoke an RPC call to a remote server, the call might succeed, but the server might not be able to return its "answer" to the client
yacovm (Mon, 20 Feb 2017 09:22:02 GMT):
In general, when you invoke an RPC call to a remote server, the call might succeed, but the server might not be able to return its "answer" to the client (i.e network problems)
yacovm (Mon, 20 Feb 2017 09:22:09 GMT):
in that case, the client may retry the request
yacovm (Mon, 20 Feb 2017 09:22:09 GMT):
in that case, the client may retry the request. But, if the request is not idempotent it might cause problems (i.e : increment a value twice instead of one time)
yacovm (Mon, 20 Feb 2017 09:22:37 GMT):
if the request is tagged with an ID, the server could see that this request has already been processed before and either not execute it, or return the previous computed value, etc.
mastersingh24 (Mon, 20 Feb 2017 14:13:46 GMT):
@elli-androulaki @adc - RE: https://gerrit.hyperledger.org/r/#/c/6277/ - what exactly is the `identityx` package?
adc (Mon, 20 Feb 2017 14:14:15 GMT):
it is the new name for the accesscontrol package :)
Jonas.Hedin (Mon, 20 Feb 2017 14:47:13 GMT):
Has joined the channel.
JonathanLevi (Mon, 20 Feb 2017 15:16:01 GMT):
@adc: any design doc we can look at? (I don't have a strong preference regarding the name, but now for example, the directory name does not match)
adc (Mon, 20 Feb 2017 15:23:50 GMT):
@JonathanLevi it will have the same functionalities he had in 0.6 adapted to the new infrastructure
adc (Mon, 20 Feb 2017 15:23:55 GMT):
that's it :)
JonathanLevi (Mon, 20 Feb 2017 15:24:54 GMT):
Oh, I see... more of a "re-packaging" [no pun intended ;-)]
JonathanLevi (Mon, 20 Feb 2017 15:26:11 GMT):
So the question now is, do we feel that it's more identity (of the guarding of thereof, etc.)... or really the same good ol' access control mechanism we had (adapted/updated)
JonathanLevi (Mon, 20 Feb 2017 15:27:34 GMT):
Taking another look at it (to clarify, of course we can always replace a few strings... so we not hold our breaths, either way).
JonathanLevi (Mon, 20 Feb 2017 15:29:22 GMT):
OK, another question (sorry ;-))
adc (Mon, 20 Feb 2017 15:30:09 GMT):
in fabric, it is all about identities :)
JonathanLevi (Mon, 20 Feb 2017 15:30:50 GMT):
OK, is it possible to add/remove/rename this is one changeset?
JonathanLevi (Mon, 20 Feb 2017 15:32:23 GMT):
Because *git* will not be able to correlate the changes, we may lose history/tracking, and it will be much easier to evaluate... I believe.
JonathanLevi (Mon, 20 Feb 2017 15:42:42 GMT):
@adc Am I making sense? (you can still do it in 2 steps if you really want to... starting with *git mv*, etc.)
adc (Mon, 20 Feb 2017 15:43:33 GMT):
so Jonathan, I was doing that but then I noticed that the change-set was getting too big
adc (Mon, 20 Feb 2017 15:43:44 GMT):
that's the reason why I decided to split in two
adc (Mon, 20 Feb 2017 15:44:07 GMT):
:(
yacovm (Mon, 20 Feb 2017 15:47:15 GMT):
I think the problem with change sets being too big is only when there is many code to review, not to rename
adc (Mon, 20 Feb 2017 15:50:26 GMT):
correct, so a change-set that removes accesscontrol and then add a little bit of identityx, would that buy you anything?
yacovm (Mon, 20 Feb 2017 15:51:06 GMT):
I was just pointing something out, Angelo
adc (Mon, 20 Feb 2017 15:52:09 GMT):
sorry Yacov, the question was for Jonathan building on your comment :)
JonathanLevi (Mon, 20 Feb 2017 15:57:51 GMT):
I can't assess without knowing what's in indentityx. Deleting a long list of files is not a problem.
adc (Mon, 20 Feb 2017 15:58:13 GMT):
right
JonathanLevi (Mon, 20 Feb 2017 15:58:24 GMT):
Have your rewritten everything from scratch?
adc (Mon, 20 Feb 2017 15:58:26 GMT):
I will modify the commit message
adc (Mon, 20 Feb 2017 15:58:29 GMT):
to better clarify
adc (Mon, 20 Feb 2017 15:58:34 GMT):
what will come in identityx
adc (Mon, 20 Feb 2017 15:58:40 GMT):
it will be mostly the same files
adc (Mon, 20 Feb 2017 15:58:44 GMT):
you will recognize the name
JonathanLevi (Mon, 20 Feb 2017 15:58:46 GMT):
OK hold there.
JonathanLevi (Mon, 20 Feb 2017 15:58:46 GMT):
OK hold it there.
adc (Mon, 20 Feb 2017 15:58:48 GMT):
just rearrenged
JonathanLevi (Mon, 20 Feb 2017 15:59:20 GMT):
That's what I was trying to find out. Cool. If it's the same files - then definitely let's use *git mv* commit.
JonathanLevi (Mon, 20 Feb 2017 15:59:47 GMT):
Yes, it would really help clarify.
adc (Mon, 20 Feb 2017 15:59:48 GMT):
but I need refactoring
adc (Mon, 20 Feb 2017 16:00:00 GMT):
running just git mv will not help much me
adc (Mon, 20 Feb 2017 16:00:06 GMT):
:(
adc (Mon, 20 Feb 2017 16:00:09 GMT):
how can we do that
adc (Mon, 20 Feb 2017 16:00:11 GMT):
??
JonathanLevi (Mon, 20 Feb 2017 16:05:05 GMT):
Again, I am not sure what are the exact changes that you have made (maybe it will be good to summarize actually in JIRA)...
JonathanLevi (Mon, 20 Feb 2017 16:05:22 GMT):
But, the simplest is probably to start by refactoring "in place"...
JonathanLevi (Mon, 20 Feb 2017 16:05:37 GMT):
So that we don't lose the tracking info/history.
JonathanLevi (Mon, 20 Feb 2017 16:06:53 GMT):
We can rename that updated folder with the "imports" in a separate CR
adc (Mon, 20 Feb 2017 16:11:49 GMT):
let's see. I will give a try to the refactoring in place
JonathanLevi (Mon, 20 Feb 2017 16:16:51 GMT):
Thank you. Yes, let's see. Feel free to even mark it as WIP, push to gerrit, etc. will be happy to look at things.
JonathanLevi (Mon, 20 Feb 2017 16:17:21 GMT):
The new versions of git are actually pretty smart about these (but not when it's done in isolation)
adc (Mon, 20 Feb 2017 16:23:35 GMT):
@JonathanLevi How does it look now? https://gerrit.hyperledger.org/r/#/c/6277/
JonathanLevi (Mon, 20 Feb 2017 16:33:44 GMT):
Yes, exactly. Thank you.
adc (Mon, 20 Feb 2017 16:34:09 GMT):
oh, it was easy. I though it was a nightmare
adc (Mon, 20 Feb 2017 16:34:09 GMT):
:)
JonathanLevi (Mon, 20 Feb 2017 16:34:42 GMT):
No, not. Git is "sweet" like that, when you it the *git* way. Otherwise, it is a nightmare.
JonathanLevi (Mon, 20 Feb 2017 16:35:30 GMT):
Let me know when it's ready for review.
JonathanLevi (Mon, 20 Feb 2017 16:35:30 GMT):
Let me know when it's ready for review (I appreciate that you have pushed it quickly, just that we can see if/how it works etc.)
adc (Tue, 21 Feb 2017 08:21:50 GMT):
@jyellick @binhn @muralisr @aso @elli-androulaki, the CLI needs to updated to set the /channel/Application/Writers and /channel/Application/Readers policy at channel creation time.
adc (Tue, 21 Feb 2017 08:22:17 GMT):
By default, when a policy does not exists, a reject all policy is returned. This can make the CLI failing
adc (Tue, 21 Feb 2017 12:26:51 GMT):
@JonathanLevi, https://gerrit.hyperledger.org/r/#/c/6277/ ready. May you have a look at it? Thanks :)
jyellick (Tue, 21 Feb 2017 14:09:42 GMT):
@adc The CLI does / should be setting these, the bdd does not. I have not had a chance to exhaustively test the absolute policy paths, so you may be hitting another bug
adc (Tue, 21 Feb 2017 14:33:22 GMT):
ahh, I thought it was the other way around
vpaprots (Tue, 21 Feb 2017 16:37:59 GMT):
Here is https://gerrit.hyperledger.org/r/#/c/5897/11 again.. adding yaml configuration to BCCSP (the more rebases, the more files it seems I have to touch.. )
adc (Tue, 21 Feb 2017 17:18:24 GMT):
@binhn @muralisr @elli-androulaki @aso may we assume that system chaincodes will not use CC2CC and no chainless invocation will go through a CC2CC for v1?
binhn (Tue, 21 Feb 2017 17:30:36 GMT):
i m aware of 2 scc's that are "chainless": lccc and cscc. Lccc doesn't call any other chaincodes in the sense of cc2cc. So I think we can make that assumption for these 2 unless murali has a legitimate use case.
In general (scc that instantiated on channels) should be treated the same as other cc's since they would be invoked with the same context
elli-androulaki (Tue, 21 Feb 2017 17:31:57 GMT):
maybe the query scc that @muralisr mentioned. This would need to invoke LCCC (or is part of the chainless LCCC?).
binhn (Tue, 21 Feb 2017 17:35:59 GMT):
why would we not provide the query directly from lccc?
elli-androulaki (Tue, 21 Feb 2017 17:39:47 GMT):
Here is what @wlahti mentioned: that the qscc (or extension of chainless lccc) would need to support the following queries:
1. list the installed chaincodes on a peer
2. list the instantiated chaincodes on a channel => this may require triggering the lccc of the channel the query refers to?
3. list all the channels for a given peer
wlahti (Tue, 21 Feb 2017 17:39:47 GMT):
Has joined the channel.
wlahti (Tue, 21 Feb 2017 17:48:25 GMT):
Yes, the second query is currently coded to use a state range scan on the LCCC to retrieve the instantiated chaincodes. See https://gerrit.hyperledger.org/r/#/c/6289/ , which is under code review.
binhn (Tue, 21 Feb 2017 18:02:43 GMT):
@wlahti is the code on lccc or qscc calling lccc to get the info?
muralisr (Tue, 21 Feb 2017 18:03:01 GMT):
right @wlahti ... we *are* calling LCCC from qscc for that
muralisr (Tue, 21 Feb 2017 18:03:13 GMT):
(or rather we will be )
binhn (Tue, 21 Feb 2017 18:03:30 GMT):
why wouldn't we imple on lccc?
muralisr (Tue, 21 Feb 2017 18:04:11 GMT):
oh wait
muralisr (Tue, 21 Feb 2017 18:05:07 GMT):
@wlahti that change happends to be confined to qscc
muralisr (Tue, 21 Feb 2017 18:05:14 GMT):
so its not CC-2-CC call
muralisr (Tue, 21 Feb 2017 18:05:40 GMT):
we *could* have implemented by putting that code in LCCCC and calling from qscc
muralisr (Tue, 21 Feb 2017 18:05:56 GMT):
but as implemented, there's no cc-2-cc call
muralisr (Tue, 21 Feb 2017 18:06:31 GMT):
am I missing something @wlahti ?
binhn (Tue, 21 Feb 2017 18:06:39 GMT):
`itr, err := queryExecutor.GetStateRangeScanIterator("lccc", "", "")`
binhn (Tue, 21 Feb 2017 18:06:50 GMT):
is that a backdoor?
muralisr (Tue, 21 Feb 2017 18:06:52 GMT):
thats a call to the ledger
muralisr (Tue, 21 Feb 2017 18:06:56 GMT):
not to chaincode
muralisr (Tue, 21 Feb 2017 18:06:57 GMT):
yes
wlahti (Tue, 21 Feb 2017 18:11:08 GMT):
Oh right, I forgot that we decided to use the call to the ledger entries for LCCC instead of truly using LCCC.
binhn (Tue, 21 Feb 2017 18:12:36 GMT):
so this is certainly not allowed in chaincode, but as a scc, power be with you :-) that is, a scc may poke into any cc's data ?
binhn (Tue, 21 Feb 2017 18:23:43 GMT):
#1 and 3 above should only be allowed to admins, and so it should go on lccc and cscc respectively
binhn (Tue, 21 Feb 2017 18:24:04 GMT):
though i am not sure how we control access to cscc
wlahti (Tue, 21 Feb 2017 18:52:06 GMT):
https://chat.hyperledger.org/direct/elli-androulaki?msg=Jv922rSdgh965Fhs3
wlahti (Tue, 21 Feb 2017 18:53:09 GMT):
Elli provided these thoughts on access control for these queries a few days ago:
wlahti (Tue, 21 Feb 2017 18:53:38 GMT):
"From the access perspective:
so proposal is sent to the peer for "invoking" that query scc, and let C be the creator
a simple and straight forward approach would be that the peer checks that C is among his MSP admins and rejects if C is not within that set"
wlahti (Tue, 21 Feb 2017 18:54:09 GMT):
"a more elaborate approach would be
for query of type 1:
- check that C is the peer admin and list everything if so
- check which channels C has read access for (using the instantiated chain read sets) and return the list of chaincodes that have been installed on the peer and have been available in the channels C has read access to
for query of type 2:
- check that C is the peer admin and list everything if so
- check that C has read access to the requested channel and if so, respond to C
for query of type 3:
- check that C is the peer admin and list everything if so
[ optionally: - check which channels C has read access for (using the instantiated chain read sets) and return the list of channels the peer has joined from the ones C has access to ]"
binhn (Tue, 21 Feb 2017 20:42:55 GMT):
@elli-androulaki are these check done per chaincode and by the chaincode code itself or from the peer like we do now but somehow look up the chaincode by name to apply admins or writers?
elli-androulaki (Tue, 21 Feb 2017 20:51:06 GMT):
I would say either way; perhaps inside the may have its advantages as one can substitute the policy in one without impacting the ACLs in the rest
binhn (Tue, 21 Feb 2017 20:55:21 GMT):
if inside the chaincode then we would need shim API
elli-androulaki (Tue, 21 Feb 2017 20:57:22 GMT):
I see...
elli-androulaki (Tue, 21 Feb 2017 20:58:29 GMT):
which means that the shim should be able to call and evaluate the policies on MSP
elli-androulaki (Tue, 21 Feb 2017 20:58:46 GMT):
(local MSP of peer)
binhn (Tue, 21 Feb 2017 21:00:44 GMT):
right; we don't need to in this case since they are scc, so we can just call msp validation directly, but we need to tell it to use which group (readers, writers, admins)
agaragiola (Tue, 21 Feb 2017 21:00:53 GMT):
Has joined the channel.
elli-androulaki (Tue, 21 Feb 2017 21:01:48 GMT):
ah it will only need to use a static policy that the scc would create.
elli-androulaki (Tue, 21 Feb 2017 21:02:07 GMT):
Cause readers/writers/admins are channel-scoped.
elli-androulaki (Tue, 21 Feb 2017 21:02:48 GMT):
Actually I take that back.
elli-androulaki (Tue, 21 Feb 2017 21:10:40 GMT):
Let a policy object P defining the local MSP admin. SO one MSPPrincipal that refers to the local MSP's admin.
for query of type 1:
- check that C / and its signature on proposal satisfies P and if so output the list of installed chaincodes to the peer
- if not, for each channel the peer has joined,
- retrieve channel Readers, readers
- check if C (and its proposal signature) complies with readers and if so retrieves the chaincodes the peer has installed and are on that channel
The latter may leak information on the channels a peer has joined to the readers of the channel. We may want to restrict that to members of the organization of the peer.
for query of type 2:
- check that C / and its signature on proposal satisfies P and if so output the list of chaincodes on that channel
- check that C has read access to the requested channel and if so, respond to C
for query of type 3:
- check that C / and its signature on proposal satisfies P and if so answer
v_thirugnanam (Tue, 21 Feb 2017 21:57:14 GMT):
Has joined the channel.
binhn (Wed, 22 Feb 2017 02:56:37 GMT):
I think we should simplify: anything outside of channel should only be accessible by P
elli-androulaki (Wed, 22 Feb 2017 07:05:31 GMT):
:thumbsup:
adc (Wed, 22 Feb 2017 10:09:30 GMT):
@JonathanLevi, please, may you look at https://gerrit.hyperledger.org/r/#/c/6277/ ?
psa (Wed, 22 Feb 2017 15:55:37 GMT):
Has joined the channel.
stanacton (Wed, 22 Feb 2017 17:27:36 GMT):
Has joined the channel.
elli-androulaki (Wed, 22 Feb 2017 18:13:05 GMT):
@wlahti, @muralisr, may you list existing SCCs and from these the ones that can be chainless?
elli-androulaki (Wed, 22 Feb 2017 18:14:49 GMT):
Also @wlahti, what is the full set of QSCC? Does it aim to only serve chainless proposals? @aso pointed out that things are differently in the code. May you, please, clarify? This would help us tremendously finding out what access policies one would need to apply in each case. Thanks!
wlahti (Wed, 22 Feb 2017 18:16:49 GMT):
We're switching two of the queries (the chaincode-related ones) to reside in LCCC instead of QSCC.
wlahti (Wed, 22 Feb 2017 18:17:36 GMT):
I believe the channel-related query will reside in CSCC but I haven't started on it yet so things may change.
marcusvcs (Wed, 22 Feb 2017 20:55:19 GMT):
Has joined the channel.
dbshah (Wed, 22 Feb 2017 21:29:32 GMT):
Has joined the channel.
JonathanLevi (Wed, 22 Feb 2017 22:01:34 GMT):
@adc: re: 6277, we have up'ed the score a notch, but can you please explain or point us to what the "new access control" library will do?
JonathanLevi (Wed, 22 Feb 2017 22:02:19 GMT):
@adc: re: https://gerrit.hyperledger.org/r/#/c/6277 , have up'ed the score a notch, but can you please explain or point us to what the "new access control" library will do?
JonathanLevi (Wed, 22 Feb 2017 22:03:22 GMT):
Do you think this can (or cannot) wait until after we cut an alpha... ?
bartcant (Thu, 23 Feb 2017 02:18:16 GMT):
Has joined the channel.
ibmamnt (Thu, 23 Feb 2017 05:45:33 GMT):
Has joined the channel.
kelly_ (Thu, 23 Feb 2017 07:01:17 GMT):
Has joined the channel.
RezwanKabir (Thu, 23 Feb 2017 07:21:25 GMT):
Has joined the channel.
mihai.cimpoesu (Thu, 23 Feb 2017 10:09:29 GMT):
Has joined the channel.
adc (Thu, 23 Feb 2017 12:32:52 GMT):
Hi Jonathan, as you know we removed part of the access control support from the chaincode shim
adc (Thu, 23 Feb 2017 12:33:12 GMT):
all that code has been simply moved to another package accesscontrol
adc (Thu, 23 Feb 2017 12:33:38 GMT):
that has the scope to provide, as first step, the same functionalities that were available in 0.6
adc (Thu, 23 Feb 2017 12:33:43 GMT):
no more that this
adc (Thu, 23 Feb 2017 12:35:34 GMT):
I guess, it can be merged after post-alpha. Not sure. @elli-androulaki, @binhn ?
adc (Thu, 23 Feb 2017 12:35:34 GMT):
I guess, it can be merged after post-alpha. Not sure. @mastersingh24 @elli-androulaki, @binhn ?
JonathanLevi (Thu, 23 Feb 2017 13:15:36 GMT):
Just for context: The reason I am/was asking about whether this can wait and for more details is because I am trying to follow the "6 goals" guidelines/items that we have agreed on at the time as the top priorities for the alpha.
elli-androulaki (Thu, 23 Feb 2017 14:06:23 GMT):
I think that merging this post-alpha is also consistent to what @binhn recommended earlier this week.
binhn (Thu, 23 Feb 2017 14:29:30 GMT):
@elli-androulaki @adc confirmed
aambati (Thu, 23 Feb 2017 15:14:59 GMT):
Has joined the channel.
vpaprots (Thu, 23 Feb 2017 20:57:10 GMT):
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
vpaprots (Thu, 23 Feb 2017 20:57:16 GMT):
so no SHA1 for us!!
rnair@itbit.com (Thu, 23 Feb 2017 21:49:47 GMT):
Has joined the channel.
MikeGardiner (Fri, 24 Feb 2017 17:11:00 GMT):
Has joined the channel.
MikeGardiner (Fri, 24 Feb 2017 17:12:28 GMT):
Hello fabric-crypto! is this the right place to ask questions about the HSM/PKCS#11 strategy? EG: https://jira.hyperledger.org/secure/attachment/10360/mserv-TCertOptions-v3(1).md
MikeGardiner (Fri, 24 Feb 2017 17:12:45 GMT):
I work for Gemalto (Luna brand of HSMs)
elli-androulaki (Fri, 24 Feb 2017 18:02:02 GMT):
Hi @MikeGardiner , welcome! Yes, this is the place.
gdhh (Fri, 24 Feb 2017 18:03:42 GMT):
Has joined the channel.
MikeGardiner (Fri, 24 Feb 2017 18:56:56 GMT):
Excellent! OK, so from what I read from jira the p11 bccsp is pushed out a bit, but focused on the #2 case in that document I linked to. That document seems to indicate the IBM HSM is supported for #1 - (tcert generation in the hsm) but I don't see how that was accomplished. I want to have the same support in our HSM.
MikeGardiner (Fri, 24 Feb 2017 18:58:16 GMT):
The other related thing, the .6 version used hmac key expansion similar to Bitcoin's BIP32 for tcert generation. The 1.0 release uses some rerandom function, and the crypto docs I've read so far don't explicitly say what the derivation/diversification algorithm/strategy is. So where can I get clarity?
MikeGardiner (Fri, 24 Feb 2017 18:59:23 GMT):
Normally I think of these diversification actions as something specific to public block chains. This may be a question more for another group.. but what's the use case for unique Tcerts/keys in the private hyperledger world?
JonathanLevi (Fri, 24 Feb 2017 19:29:08 GMT):
Hi Mike, by "unique TCerts/keys" -> do you mean "TCert-specific" keys?
JonathanLevi (Fri, 24 Feb 2017 19:29:08 GMT):
Hi @MikeGardiner and welcome - by "unique TCerts/keys" -> do you mean "TCert-specific" keys?
tuand (Fri, 24 Feb 2017 19:29:16 GMT):
Shouldn't `identities.proto` be in `protos/msp` rather than with the msp go files ? I ask because the SDK builds copy everything under protos/ and will miss this
ashutosh_kumar (Fri, 24 Feb 2017 19:43:04 GMT):
@MikeGardiner : TCerts are mainly for unlinkability purpose. Say Bank 1 makes 2 transactions. It'll use 2 different tcert Key/Pair to sign transaction. There TCerts belong the the member making transactions as these are derived from long term cert , named EcERT , which member own. Did I answer your q ?
ashutosh_kumar (Fri, 24 Feb 2017 19:45:09 GMT):
The rerandmization function in 1.0 is to derive another Elliptic Curve Cert from Given Elliptic Curve cert. The algorithm used is derived out from the curve that is being used.
MikeGardiner (Fri, 24 Feb 2017 20:37:48 GMT):
@ashutosh_kumar can you point to some documentation about the rerandomization function? I'd like to have it implemented in hardware and expose it over P11, but I also need to know it's not going to change again. ;)
ashutosh_kumar (Fri, 24 Feb 2017 20:41:46 GMT):
Not sure , if we have authored some doc on that.
ashutosh_kumar (Fri, 24 Feb 2017 20:41:56 GMT):
will find out and let you know.
RezwanKabir (Sun, 26 Feb 2017 08:15:08 GMT):
can anyone give an example link on how to enroll new user using grpc.
yacovm (Sun, 26 Feb 2017 10:37:14 GMT):
@jimthematrix I don't understand something regarding https://gerrit.hyperledger.org/r/#/c/6543/ ( * Hash algorithms for signing and txId * )
In https://github.com/hyperledger/fabric/blob/master/peer/core.yaml#L208 it configures the peer's hash algorithm, right?
But, if this can be changed then how does the SDK know of the hash algorithm the peer uses? Isn't it a possible problem that the peer can be configured with a custom hash algorithm and the SDK isn't aware of that?
I assume we don't have a "negotiation" phase or any discovery API that tells the SDK of the peer's hash algorithm
mastersingh24 (Sun, 26 Feb 2017 11:06:36 GMT):
@RezwanKabir - what version of fabric are you using?
RezwanKabir (Sun, 26 Feb 2017 11:07:30 GMT):
1.0 preview
mastersingh24 (Sun, 26 Feb 2017 11:22:15 GMT):
@RezwanKabir - ok. well for V1.0 we no longer use grpc for the `fabric-ca` component - all the APIs are http-based. Did you build your own images or where you following http://hyperledger-fabric.readthedocs.io/en/latest/asset_setup/ ?
RezwanKabir (Sun, 26 Feb 2017 11:52:32 GMT):
my bad. I am working on sfhackfest22017/fabric-ca: x86_64-0.7.0-snapshot-6294c57 right now. But in future I will use yeasy/hyperledger-fabric-ca:latest . It will be wonderful if I get the usage in both cases.
RezwanKabir (Sun, 26 Feb 2017 11:52:32 GMT):
my bad. I am working on sfhackfest22017/fabric-ca: x86_64-0.7.0-snapshot-6294c57 right now. But in future I will use yeasy/hyperledger-fabric-ca:latest . It will be wonderful if I get the some example for both cases.
mastersingh24 (Sun, 26 Feb 2017 12:03:42 GMT):
@RezwanKabir - the NodeJS fabric-ca-client does support register and enroll functions when working with the fabric-ca . Not sure if we have a sample yet but the APIs are available in the latest fabric-ca-client that's checked into the fabric-sdk-node repository
RezwanKabir (Sun, 26 Feb 2017 12:25:57 GMT):
Thanks. I will follow latest fabric-ca-client
jimthematrix (Sun, 26 Feb 2017 15:19:31 GMT):
@yacovm the crypto parameters (algo, hash2 vs. sha3, keysize) have always been knowledge from out-of-band sources b/w the peers/orderers and client. they are configurable on both sides (except a few cases where sha2 is always used, like generating the SKI and the txID)
jimthematrix (Sun, 26 Feb 2017 15:20:30 GMT):
CR 6543 is simply about matching the default of the app to the default of the peer and orderer
jimthematrix (Sun, 26 Feb 2017 15:24:15 GMT):
in fact there's some more work later (but not right now) to either allow the sdk to be configured to use different parameters when signing for requests to the peers vs. orderers since on the backend they are separately configured (peer/core.yaml vs. orderer/orderer.yaml), or to enforce both peers and orderers to use a common set of params. but right now the sdk is assuming they are the same
jimthematrix (Sun, 26 Feb 2017 15:25:25 GMT):
@mastersingh24 6543 should be a simple one for your judgement, so if you agree with the change can you please merge it?
jimthematrix (Sun, 26 Feb 2017 15:25:25 GMT):
@mastersingh24 @yacovm 6543 should be a simple one for your judgement, so if you agree with the change can you please merge it?
yacovm (Sun, 26 Feb 2017 15:43:21 GMT):
I wish we could have tests in CI that run the node SDK along with a peer
yacovm (Sun, 26 Feb 2017 15:43:36 GMT):
then if someone changes something in 1 of them, the tests fail
mastersingh24 (Sun, 26 Feb 2017 16:41:16 GMT):
WE NEED TO AGREE WHAT THE DEFAULT CRYPTO PARAMETERS ARE GOING TO BE ;)
mastersingh24 (Sun, 26 Feb 2017 16:41:39 GMT):
for example, not sure why we casually switch between SHA256 and SHA3-256
JonathanLevi (Sun, 26 Feb 2017 16:59:40 GMT):
Yup
JonathanLevi (Sun, 26 Feb 2017 17:00:03 GMT):
And it HAS TO BE APPLICABLE to all components.
JonathanLevi (Sun, 26 Feb 2017 17:00:32 GMT):
We are working on a modular solution... but we must be able to demonstrate a unified "front".
JonathanLevi (Sun, 26 Feb 2017 17:01:32 GMT):
What do you all think we are missing? We have a few threads on these, and I have been waiting until things stabilize.
JonathanLevi (Sun, 26 Feb 2017 17:01:54 GMT):
My vote is for more integration tests + with explicit configs.
JonathanLevi (Sun, 26 Feb 2017 17:01:54 GMT):
My vote is for more integration tests +/with explicit configs.
JonathanLevi (Sun, 26 Feb 2017 17:02:04 GMT):
Other suggestions?
jimthematrix (Sun, 26 Feb 2017 19:42:47 GMT):
btw this would have been caught by the "FIT" CI job that runs node SDK's end to end test against the latest fabric
mastersingh24 (Sun, 26 Feb 2017 21:26:27 GMT):
@jimthematrix - does the FIT job actually run on a regular basis these days?
jimthematrix (Sun, 26 Feb 2017 21:27:37 GMT):
4 times a day last time i checked
jimthematrix (Sun, 26 Feb 2017 21:28:08 GMT):
@rameshthoomu ^^^
rameshthoomu (Sun, 26 Feb 2017 21:28:08 GMT):
Has joined the channel.
silentspark (Mon, 27 Feb 2017 02:56:11 GMT):
Has joined the channel.
saifulislamsaaif (Mon, 27 Feb 2017 08:24:54 GMT):
Has joined the channel.
weeds (Mon, 27 Feb 2017 13:37:34 GMT):
@rameshthoomu does the output of the tests get posted on the fabric-quality channel? just curious
rameshthoomu (Mon, 27 Feb 2017 13:59:34 GMT):
@jimthematrix yes you are correct.. Production FIT job is a CRON job and it's run for every 6 hrs.
rameshthoomu (Mon, 27 Feb 2017 14:00:18 GMT):
@weeds: are you referring e2e tests?
weeds (Mon, 27 Feb 2017 14:01:22 GMT):
@rameshthoomu yes the e2e tests and where the new images are
weeds (Mon, 27 Feb 2017 14:01:28 GMT):
with commit levels that work together
rameshthoomu (Mon, 27 Feb 2017 14:03:22 GMT):
Yes will do that.. I am working on integrating Jenkins with Rocket.. Once this is done, will post build output along with build reference links to Rocket chat
rameshthoomu (Mon, 27 Feb 2017 14:06:04 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-quality?msg=YvNRgC89nH8fTsSap) @rameshthoomu I am sending everyday morning after images published to test dockerhub account..
bmos299 (Mon, 27 Feb 2017 19:33:00 GMT):
Has joined the channel.
bmos299 (Mon, 27 Feb 2017 19:35:38 GMT):
The images will be loaded daily at 8 am est based on a successful Function Integration Test (FIT) run for Intel, Power, System z architectures. The images will be stored at the rameshthoomu organization until we have the Nexus v3 environment running through the linux foundation. Also, release images will be published to the hyperledger organization in docker hub moving forward. Currently, FIT consists of passing the Node SDK e2e test and the cli e2e test (being added right now). The cli e2e test does not actually use an sdk or fabric-ca. FIT will continue to be enhanced as new function and SDK's become operational.
A message will be published in Rocket chat on fabric-ci channel with the following format:
```
rameshthoomu/fabric-orderer-x86_64:x86_64-0.7.0-snapshot-29d7fc0
rameshthoomu/fabric-peer-x86_64:x86_64-0.7.0-snapshot-29d7fc0
rameshthoomu/fabric-javaenv-x86_64:x86_64-0.7.0-snapshot-29d7fc0
rameshthoomu/fabric-ccenv-x86_64:x86_64-0.7.0-snapshot-29d7fc0
rameshthoomu/fabric-ca-x86_64:x86_64-0.7.0-snapshot-6dcf507
fabric-sdk-node *commit# bc36ef5*
Docker images for Power and System z are also available by modifying the last component in the repository based on the desired architecture. The above images represent the intel versions.
intel = x86_64
power = ppc64le
Sstem z = s390x
The images are also saved with the tag of : latest.
```
Build Reference# https://jenkins.hyperledger.org/sandbox/job/e2e/29 for a sample output and reference the FIT tab.
JonathanLevi (Mon, 27 Feb 2017 19:43:33 GMT):
@bmos299 Alright! Have just joined #fabric-ci !
vpaprots (Tue, 28 Feb 2017 00:01:30 GMT):
@mastersingh24 Missed the discussion about default crypto algorithms.. and you might have noticed that it kinda.. perhaps.. maybe.. well.. me who put the SHA3 in? @adc and I were talking about this.. BCCSP should not have 'Defaults' at all.. that code needs to be cleaned up. As @JonathanLevi put it, we need a unified front. have configuration in a single place, so that (for purposes of exposition) somebody could create a fabric network with MD5... with a few yaml changes
I dont think there are that many places, we just don't manage them.
- Signature algorithm MSP is to use
- Ledger Hash for merkle tree
(now I feel like I missed a few)
Rweb2 (Tue, 28 Feb 2017 01:09:27 GMT):
Has joined the channel.
vpaprots (Tue, 28 Feb 2017 02:41:23 GMT):
@yacovm @elli-androulaki @aso : https://gerrit.hyperledger.org/r/#/c/6489/2/msp/configbuilder.go
This was needed at the time for the configtx to work, but I think its relevant overall. `GetLocalMspConfig` vs `GetVerifyingMspConfig`. One is for MSPs that sign, other one is for verifying respectivelly
vpaprots (Tue, 28 Feb 2017 02:41:23 GMT):
@yacovm @elli-androulaki @aso : https://gerrit.hyperledger.org/r/#/c/6489/2/msp/configbuilder.go
This was needed at the time for the configtx to work, but I think its relevant overall. `GetLocalMspConfig` vs `GetVerifyingMspConfig`. One is for MSPs that sign, other one is for verifying only respectively
binhn (Tue, 28 Feb 2017 04:51:38 GMT):
@adc we are backing out https://gerrit.hyperledger.org/r/#/c/5897/ that @vpaprots mentioned you should be aware. This one breaks too many things that it shouldn't have been merged.
binhn (Tue, 28 Feb 2017 04:51:38 GMT):
@adc we are backing out part of https://gerrit.hyperledger.org/r/#/c/5897/ that @vpaprots mentioned you should be aware. The filename of keystore change breaks too many things that needs to revert
binhn (Tue, 28 Feb 2017 04:51:38 GMT):
@adc we are backing out and modifying part of https://gerrit.hyperledger.org/r/#/c/5897/ that @vpaprots mentioned you should be aware. The filename of keystore change breaks too many things...
vpaprots (Tue, 28 Feb 2017 04:56:57 GMT):
@adc https://gerrit.hyperledger.org/r/#/c/6601/1 change to sw.keystore to search for matching private key in all keystore directory
adc (Tue, 28 Feb 2017 12:56:21 GMT):
@vpaprots @binhn @elli-androulaki @aso it is urgent that the pkcs11 package gets refactored to not be just a copy of the sw package. I was trying to remove the defaults from bccsp and it is a real pain to refactor also pkcs11.
adc (Tue, 28 Feb 2017 12:56:42 GMT):
removing defaults means also that most of BCCSP configuration goes away
adc (Tue, 28 Feb 2017 12:57:03 GMT):
I don't really understand why we didn't remove first the defaults and then had the configuration in
adc (Tue, 28 Feb 2017 12:58:26 GMT):
This change-set https://gerrit.hyperledger.org/r/#/c/6617/ removes the usage of BCCSP defaults from MSP
adc (Tue, 28 Feb 2017 12:59:05 GMT):
the others can be removing first by hard-cording first and then see which module has to provide the configuration
adc (Tue, 28 Feb 2017 12:59:45 GMT):
@vpaprots, please refactor the pkcs11 asap
adc (Tue, 28 Feb 2017 12:59:45 GMT):
@vpaprots, please refactor the pkcs11 package asap
vpaprots (Tue, 28 Feb 2017 14:34:30 GMT):
@adc pkcs11 package is still WIP, all the copies will be removed. It is not meant to be doing SW operations (except perhaps for Hashing, which is keyless). It will be replaced by pkcs11 calls. keystore will disappear completely. rather not refactor wip code..
adc (Tue, 28 Feb 2017 14:35:00 GMT):
I know, but it has been there for a long time
vpaprots (Tue, 28 Feb 2017 14:35:13 GMT):
I havent continued that since we have a bigger problem, there is no pkcs11 use at all
adc (Tue, 28 Feb 2017 14:35:30 GMT):
indeed, I'm my last change-set on the software-based implementation I have not touched the pkcs11 package
adc (Tue, 28 Feb 2017 14:35:41 GMT):
but still, we have to remove the default opts asap
vpaprots (Tue, 28 Feb 2017 14:36:06 GMT):
agree on defaults
adc (Tue, 28 Feb 2017 14:36:17 GMT):
also, with the defaults out we will not have to worry anymore about the security level and other stuff
vpaprots (Tue, 28 Feb 2017 14:36:24 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=amTSGJKF9HA7XETaJ)
adc (Tue, 28 Feb 2017 14:36:29 GMT):
bccsp will be simplified
adc (Tue, 28 Feb 2017 14:36:54 GMT):
in this change-set https://gerrit.hyperledger.org/r/#/c/6629/
adc (Tue, 28 Feb 2017 14:37:12 GMT):
I have removed the usage of SHAOpts
adc (Tue, 28 Feb 2017 14:37:36 GMT):
but the pkcs11 is still in a very poor state, it needs to be updated asap, please
adc (Tue, 28 Feb 2017 14:37:52 GMT):
or at least, instead of cloning just forward the calls
vpaprots (Tue, 28 Feb 2017 14:39:10 GMT):
if you (and team) help me drive usage of pkcs11, I will have time to clean it up ;)
adc (Tue, 28 Feb 2017 14:40:42 GMT):
what do you need?
vpaprots (Tue, 28 Feb 2017 14:41:47 GMT):
from fabric, at this point, the most pressing is being able to run the same tests as we do with sw bccsp, with pkcs11 bccsp
vpaprots (Tue, 28 Feb 2017 14:42:23 GMT):
that means generate all the crypto material, cert signatures and so on.. through bccsp
adc (Tue, 28 Feb 2017 14:44:19 GMT):
what does that mean if we don't have a full pkcs11 bccsp implementation?
vpaprots (Tue, 28 Feb 2017 14:44:41 GMT):
its still fully a functional bccsp
vpaprots (Tue, 28 Feb 2017 14:44:58 GMT):
the impl_tests all pass and then some that I added
adc (Tue, 28 Feb 2017 14:45:09 GMT):
of course, it is a copy of SW
vpaprots (Tue, 28 Feb 2017 14:45:14 GMT):
right
adc (Tue, 28 Feb 2017 14:45:44 GMT):
that's the reason why I'm saying let's have a proper pkcs11-based bccsp and then we can see how it integrates with the fabric
adc (Tue, 28 Feb 2017 14:45:54 GMT):
I don't see how one can do the other way around
vpaprots (Tue, 28 Feb 2017 14:46:52 GMT):
dont follow. bccsp is an abstract interface. its not pkcs11 that should be integrating. its fabric that is not using bccsp properly
vpaprots (Tue, 28 Feb 2017 14:47:38 GMT):
what if someone wants to create a new bccsp? there is currently no way to plug that in, which was entire point of bccsp
adc (Tue, 28 Feb 2017 14:49:18 GMT):
before that, we need to remove the defaults
adc (Tue, 28 Feb 2017 14:49:31 GMT):
in fact you can see already the effect of not having done that before
adc (Tue, 28 Feb 2017 14:50:01 GMT):
we have in configuration something that will disappear
vpaprots (Tue, 28 Feb 2017 14:52:08 GMT):
yeah. I am all for removing defaults.. the more bccsps we got, the more defaulting code we have to dup..
vpaprots (Tue, 28 Feb 2017 14:52:08 GMT):
yeap. I am all for removing defaults.. the more bccsps we got, the more defaulting code we have to dup..
vpaprots (Tue, 28 Feb 2017 14:53:37 GMT):
that can probably fall under making the algorithms names follow a convention like OIDs..
vpaprots (Tue, 28 Feb 2017 14:53:49 GMT):
all in one swoop
adc (Tue, 28 Feb 2017 14:54:12 GMT):
when the pkcs11-based bccsp will be available?
vpaprots (Tue, 28 Feb 2017 14:54:39 GMT):
you mean when it will be finished? its available now, does only ecdsa..
vpaprots (Tue, 28 Feb 2017 14:54:39 GMT):
you mean when it will be finished? its available now, does only ecdsa through pkcs11..
adc (Tue, 28 Feb 2017 14:55:16 GMT):
the full implementation
vpaprots (Tue, 28 Feb 2017 14:55:54 GMT):
like I said, not until the fabric uses bccsp
adc (Tue, 28 Feb 2017 14:56:16 GMT):
why?
adc (Tue, 28 Feb 2017 14:56:48 GMT):
can you also point to places where the fabric is not using bccsp?
vpaprots (Tue, 28 Feb 2017 14:57:32 GMT):
I need to be able to switch bccsps to test pkcs11 code
adc (Tue, 28 Feb 2017 14:57:43 GMT):
not at all
adc (Tue, 28 Feb 2017 14:57:50 GMT):
you need first to test pkcs11 alove
adc (Tue, 28 Feb 2017 14:57:50 GMT):
you need first to test pkcs11 alone
adc (Tue, 28 Feb 2017 14:57:59 GMT):
and then we do the integration
elli-androulaki (Tue, 28 Feb 2017 15:00:06 GMT):
there are only a few places that @binhn has included in a jira item for us to take care of when polishing the code
vpaprots (Tue, 28 Feb 2017 15:00:20 GMT):
there is a reason to do integration now, while we havent arrived to v1.0, the integration task is huge (just look at my last couple of changes..). it affects all components on fabric. pkcs11 code change is small and easy to contain
elli-androulaki (Tue, 28 Feb 2017 15:00:21 GMT):
But most parts relate to TLS / X509 related management
adc (Tue, 28 Feb 2017 15:00:56 GMT):
let's do first the easy tasks
adc (Tue, 28 Feb 2017 15:01:17 GMT):
we pushed a lot of config that will now be removed
vpaprots (Tue, 28 Feb 2017 15:01:30 GMT):
I did that in 0.6 and by the time I tried to commit, it was locked down
vpaprots (Tue, 28 Feb 2017 15:01:41 GMT):
nope, the config all stayed
adc (Tue, 28 Feb 2017 15:01:51 GMT):
the has family and security level
adc (Tue, 28 Feb 2017 15:01:53 GMT):
needs to go
vpaprots (Tue, 28 Feb 2017 15:01:55 GMT):
I just changed the fileks implementation
vpaprots (Tue, 28 Feb 2017 15:02:15 GMT):
yep, the security level has to go, most definetelly
adc (Tue, 28 Feb 2017 15:02:24 GMT):
also hash family
vpaprots (Tue, 28 Feb 2017 15:02:26 GMT):
locking ourself to nist curves doesnt seem portable..
adc (Tue, 28 Feb 2017 15:02:29 GMT):
the defaults are not needed
Nishi (Tue, 28 Feb 2017 21:45:39 GMT):
Has joined the channel.
Nishi (Tue, 28 Feb 2017 21:47:11 GMT):
we are adding Kafka brokers to to test network along with an orderer, can someone confirm if we need certs for Kafka brokers, if so how can I generate them?
Nishi (Tue, 28 Feb 2017 21:47:11 GMT):
we are planning to Kafka brokers to our test network along with an orderer, can someone confirm if we need certs for Kafka brokers, if so how can I generate them?
binhn (Tue, 28 Feb 2017 22:17:49 GMT):
@kostas ^^^ @Nishi
kostas (Tue, 28 Feb 2017 22:35:50 GMT):
@Nishi Ah, in our previous conversation you referred to certs "to register on the network", which implies a connection to MSPs, which is why I referred you here. As the question stands now, I see that the focus is on Kafka brokers. The answer is that for your end-to-end tests you do _not_ need certs for the Kafka cluster.
kostas (Tue, 28 Feb 2017 22:35:50 GMT):
@Nishi Ah, in our previous conversation you referred to certs to orderers registering on the network, which implies a connection to MSPs, which is why I referred you here. As the question stands now, I see that the focus is on Kafka brokers. The answer is that for your end-to-end tests you do _not_ need certs for the Kafka cluster.
kostas (Tue, 28 Feb 2017 22:36:50 GMT):
If you wanted to try that, you would configure your ordering node by editing this file: https://github.com/hyperledger/fabric/blob/master/orderer/orderer.yaml#L133 (and following the instructions here: https://www.confluent.io/blog/apache-kafka-security-authorization-authentication-encryption/ for both your client --which is the orderer in this case-- and the Kafka brokers).
jimthematrix (Wed, 01 Mar 2017 04:46:33 GMT):
@aso @adc @elli-androulaki @mastersingh24 @JonathanLevi sorry for the spam, but I'm hitting the following error when submitting an install proposal (or any proposal):
```Error: The creator certificate is not valid, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "peerOrg0")```
jimthematrix (Wed, 01 Mar 2017 04:51:12 GMT):
I used the crypto materials generated from bdd (sent by @muralisr) to start the fabric-ca (setting --ca.certfile to ca/peerOrg0_cert.pem, --ca.keyfile to ca/peerOrg0_pk.pem), orderer and peers. so when I enroll with fabric-ca, it should have been signed with the private key in peerOrg0_pk.pem
jimthematrix (Wed, 01 Mar 2017 04:51:40 GMT):
so I'm a little puzzled by the error above
jimthematrix (Wed, 01 Mar 2017 04:56:44 GMT):
here's the enrollment cert for the creator:
```Certificate:
Data:
Version: 3 (0x2)
Serial Number:
76:c4:0f:01:21:8a:17:16:ee:ee:f0:f7:b2:30:84:fb:a4:f3:dc:e7
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=peerOrg0
Validity
Not Before: Mar 1 04:39:00 2017 GMT
Not After : Jan 28 12:39:00 2018 GMT
Subject: CN=admin
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
EC Public Key:
pub:
04:eb:18:2b:f5:2d:6f:0b:e1:e4:a4:42:56:38:77:
6c:7b:c4:a6:fb:1f:c7:14:51:da:82:72:53:07:08:
eb:e3:ac:5a:8d:82:b5:28:db:98:95:4d:7a:41:ad:
a5:65:9b:a9:8e:73:60:24:b4:d2:63:75:12:d2:13:
62:20:e2:6f:bf
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
12:56:43:1E:3C:65:16:F1:6E:55:AD:6C:55:04:B7:57:11:6D:A5:6D
Signature Algorithm: ecdsa-with-SHA256
30:45:02:20:21:bf:1b:8b:c1:24:9a:15:d7:71:8f:7a:87:0f:
aa:16:de:4a:21:dd:7a:fe:cd:b6:d1:5d:70:ef:29:c7:06:9b:
02:21:00:ee:e6:a2:55:02:9a:3c:62:f8:b8:f3:e2:b8:9c:06:
3a:14:ff:d0:c4:2f:cd:a8:42:10:68:51:18:9c:28:59:f8
```
jimthematrix (Wed, 01 Mar 2017 04:59:07 GMT):
i created the channel and join the peer
jimthematrix (Wed, 01 Mar 2017 04:59:07 GMT):
i created the channel and joined the peer
mastersingh24 (Wed, 01 Mar 2017 10:09:13 GMT):
@jimthematrix - I am pretty sure that `ca/peerOrg0_cert` and `peer/peer0/localMspConfig/cacerts/peerOrg0.pem` are different certificates
adc (Wed, 01 Mar 2017 11:07:07 GMT):
@jimthematrix, the certificate is not valid before Mar 1 04:39:00 2017 GMT, might be that?
SyneBlockChainTeam (Wed, 01 Mar 2017 11:40:38 GMT):
Has joined the channel.
jimthematrix (Wed, 01 Mar 2017 12:56:58 GMT):
@adc that timestamp is misleading, i think docker has a time skew that doesn't match the host and this has always been the case with ecerts signed by fabric-ca docker
adc (Wed, 01 Mar 2017 12:57:18 GMT):
I see
jimthematrix (Wed, 01 Mar 2017 12:57:26 GMT):
@mastersingh24 indeed they are not the same, trying to cp the cert from ca to peer...
jimthematrix (Wed, 01 Mar 2017 13:04:56 GMT):
now am getting this when running configtxgen to create orderer's genesis block:
```Setting up the MSP manager failed, err CA Certificate did not have the Subject Key Identifier extension, (SN: 1000)```
jimthematrix (Wed, 01 Mar 2017 13:05:34 GMT):
the ca certs in the "ca" folder indeed do not have the extension
jimthematrix (Wed, 01 Mar 2017 13:14:05 GMT):
@mastersingh24 do you have a more coherent set of crypto materials that i can use for sdk tests? it seems the ones being floated around don't have the proper ca certs i can use with fabric-ca. for applications the node sdk does have the ability to load ecerts from file so we can cut the fabric-ca out of the loop to make this work, but i also need a set up that has fabric-ca involved
jimthematrix (Wed, 01 Mar 2017 13:15:23 GMT):
basically what's missing are the private keys for the cacerts inside the peer orgs 'cacerts' folder
jimthematrix (Wed, 01 Mar 2017 13:16:25 GMT):
if i have those i can use them to launch fabric-ca
mastersingh24 (Wed, 01 Mar 2017 13:17:00 GMT):
I'm almost there with my little crypto generator
mastersingh24 (Wed, 01 Mar 2017 13:17:13 GMT):
just need to fix an error in the way I generate CA certificates
jimthematrix (Wed, 01 Mar 2017 13:17:15 GMT):
:clap:
mastersingh24 (Wed, 01 Mar 2017 17:16:08 GMT):
@jimthematrix - just posted an update to https://gerrit.hyperledger.org/r/#/c/6635/ - hopefully you can use this tool to create artifacts you can use with fabric and fabric-ca. The CR has details on what it generates, etc, so if you like please give it a try
jimthematrix (Wed, 01 Mar 2017 17:17:00 GMT):
cool, will give it a go. thanks!
kostas (Wed, 01 Mar 2017 19:35:03 GMT):
The `cryptogen` tool looks really nice.
kostas (Wed, 01 Mar 2017 19:35:12 GMT):
What I am looking for now is a simple doc that explains how all of these certificates and private keys are used.
kostas (Wed, 01 Mar 2017 19:35:23 GMT):
We've solved the problem of creating keys and certs, now the next questions that come to my mind are: what does every dir in there stand for, and how is it used by the system (a mid-level view of things).
kostas (Wed, 01 Mar 2017 19:35:27 GMT):
I will repeat my offer to write this document up if someone's willing to guide me through it.
jimthematrix (Wed, 01 Mar 2017 19:44:39 GMT):
i was disrupted but was finally able to run through the test:
- use 6635 cryptogen to generate a 2 peer org 4 peers 1 orderer org set
- generate orderer block
- generate channel config template
- using sdk send config template to orderer to create channel
- download the config block from orderer and send to peer to join
jimthematrix (Wed, 01 Mar 2017 19:45:07 GMT):
on that last step I'm getting the following error:
```Error: The creator certificate is not valid, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority```
jimthematrix (Wed, 01 Mar 2017 19:45:07 GMT):
on that last step I'm getting the following error:
```Transaction is not valid. Got [9868bb3b2dcab80dde37864b83fa33ab78ee1bed382c9aa750bb44f906cac857], expected [24eb2a932b92d6d34e7784dfd3144a27386f358081ae2b2f0a38da5be592155e]```
jimthematrix (Wed, 01 Mar 2017 19:55:18 GMT):
battling with various errors involving msp (mostly on the application side) but i think making progress
jimthematrix (Wed, 01 Mar 2017 19:58:00 GMT):
finally able to join channel and along the way proved that the peer's ca key and certs actually worked properly (this wasn't the case before)
jimthematrix (Wed, 01 Mar 2017 19:59:23 GMT):
@mastersingh24 so I'm moving on to test chaincode deploy and transactions against the new channel, but as far as getting the fabric-ca to work with the materials generated by the `cryptogen` tool, things are looking good :thumbsup:
mastersingh24 (Wed, 01 Mar 2017 20:00:11 GMT):
cool
ashutosh_kumar (Wed, 01 Mar 2017 20:32:39 GMT):
that looked good. @mastersingh24 , I put small comment on the change set.
ashutosh_kumar (Wed, 01 Mar 2017 20:32:39 GMT):
I put the comment based on the premise that Private Key should not be stored in memory. I understand , for that scheme to work , you need to instantiate csp , which is extra amount of work.
ashutosh_kumar (Wed, 01 Mar 2017 20:32:39 GMT):
I put the comment based on the premise that Private Key should not be stored in memory. I understand , for that scheme to work , you need to instantiate csp , which is extra amount of work.
mastersingh24 (Wed, 01 Mar 2017 20:34:49 GMT):
thx @ashutosh_kumar - it's a little tricky dealing with that stuff because it seems to me I could not set a keystore to different value due to the way the default bccsp gets loaded. I supposed I could try switching the options, but for now it seems to work ;)
jimthematrix (Wed, 01 Mar 2017 21:46:46 GMT):
so to validate my understanding of how the MSP works at various stages:
- create channel: the orderer uses the msp from the system chain's config block to validate cert, so any existing orgs can create channel
- join channel: the target peer uses the local MSP to validate, so each app can only request peers in their own org to join
- install chaincode: it looks like the peer actually uses the local msp to validate this call, so each app can only install chaincode to peers in their own org
- instantiate chaincode: peer uses the chain's msp (from the config block) to validate, so any participating org can request an instantiate
- invoke, query: same as instantiate
jimthematrix (Wed, 01 Mar 2017 21:47:09 GMT):
@aso @adc @elli-androulaki @mastersingh24 ^^^ ?
mastersingh24 (Wed, 01 Mar 2017 21:51:36 GMT):
@jimthematrix - I believe that is correct. join and install are basically "local" calls to the peer and as such the peer's local MSP is checked. instantiate,invoke,query are "channel" scoped - so the MSPs in the genesis/latest config block for the channel are used.
jimthematrix (Wed, 01 Mar 2017 21:52:07 GMT):
yep that matches my understanding of the reason as well
mastersingh24 (Wed, 01 Mar 2017 21:52:18 GMT):
for create channel, it would be orgs that are part of the orderer set
jimthematrix (Wed, 01 Mar 2017 21:52:29 GMT):
right
jimthematrix (Wed, 01 Mar 2017 21:52:55 GMT):
from the bootstrap/configtx
vpaprots (Wed, 01 Mar 2017 23:38:00 GMT):
@mastersingh24 I was talking to @jimthematrix and @smithbk today about key generation and key stores. BCCSP abstracts keystores away from us. using SW Filebased keystore directly works as a shortcut for now, but can I use your tool to generate keys with any arbitrary BCCSP?
smithbk (Wed, 01 Mar 2017 23:38:00 GMT):
Has joined the channel.
vpaprots (Thu, 02 Mar 2017 00:12:09 GMT):
@mastersingh24 configuration stuff that we were talking on crypto channel earlier..
we need a field in MSPConfig/genesis block I think to specify which algorithm each MSP (local/verifying) is using
that way we can also mix different signing algorithms..
I might choose to use SHA3-384-P256-ECDSA.. somebody else on the same network SHA2-256-P224-ECDSA..
(perhaps that already exists)
and bccsp takes its cues from that spec
same for channel create I suspect.. needs to specify the HASH of the chain
goal: bccsp has no defaults
mastersingh24 (Thu, 02 Mar 2017 00:23:42 GMT):
@vpaprots - I intentionally went down the bccsp route for just this purpose - of course for simplicity I just use basic defaults, etc, but in theory should be able to make things configurable
vpaprots (Thu, 02 Mar 2017 00:25:18 GMT):
I think @adc and I would be happier to not have concept of defaults at all inside BCCSP. It should come from outside.. i.e. based on what cert you got, bccsp defaults might make no sense
vpaprots (Thu, 02 Mar 2017 00:25:57 GMT):
thats why I was thinking it should be part of MSP?
vpaprots (Thu, 02 Mar 2017 00:26:27 GMT):
"I want all my signatures to use this cert and sha2-256"
vpaprots (Thu, 02 Mar 2017 00:26:45 GMT):
makes it into a single point of configuration
vpaprots (Thu, 02 Mar 2017 00:26:50 GMT):
@mastersingh24 ^
Donald Liu (Thu, 02 Mar 2017 01:23:01 GMT):
Has joined the channel.
Liew.SC (Thu, 02 Mar 2017 02:56:52 GMT):
Has joined the channel.
ashutosh_kumar (Thu, 02 Mar 2017 03:12:10 GMT):
One other nice feature to have is the server should broadcast its capability to the client , so that client can choose from there and Server crypto to be configurable to allow only certain security primitives to be allowed. Second requirement has real life use cases.
vpaprots (Thu, 02 Mar 2017 05:28:26 GMT):
@ashutosh_kumar that ssl-style agreement gonna get difficult fast.. they got two parties to agree and look how hard its just for two parties.. adding a few new algorithm names requires a whole new TLS spec! yikes..
vpaprots (Thu, 02 Mar 2017 05:28:53 GMT):
but perhaps something can be done at application side, the one that needs to create the genesis block..
vpaprots (Thu, 02 Mar 2017 05:31:36 GMT):
Clearly all the signatures specified by genesis block (assuming I get my config request ;) ) are to be supported by everyone on the channel. the specification on just how two orgs are to agree on this set of MSPs is currently 'out of band' but will be needed by everyone..
elli-androulaki (Thu, 02 Mar 2017 08:15:57 GMT):
Hi @jimthematrix : So,
> - create channel: the orderer uses the msp from the system chain's config block to validate cert, so any existing orgs can create channel
I believe there is to be a dedicated policy for channel creators in (orderer) system channel; but @jyellick to confirm
> - join channel: the target peer uses the local MSP to validate, so each app can only request peers in their own org to join
I would say authenticating the join channel requests against local msp admin would make sense.
> - install chaincode: it looks like the peer actually uses the local msp to validate this call, so each app can only install chaincode to peers in their own
Correct and same as join channel
> - instantiate chaincode: peer uses the chain's msp (from the config block) to validate, so any participating org can request an instantiate
There would be a chaincodeAdmins policy that the genesis of the chain should include and chaincode instantiation requests would need to run against The one we would recommend I believe is the list of participant org admins.
> - invoke, query: same as instantiate
This one is restricted to the writers of the chain, that is any member of the participant orgs.
yacovm (Thu, 02 Mar 2017 08:34:49 GMT):
> I would say authenticating the join channel requests against local msp admin would make sense.
Isn't it being done now?
yacovm (Thu, 02 Mar 2017 08:37:43 GMT):
And why is `Query` restricted to writers? Don't we have readers?
elli-androulaki (Thu, 02 Mar 2017 08:38:52 GMT):
So, we cannot distinguish invokes from queries at the moment
yacovm (Thu, 02 Mar 2017 08:39:54 GMT):
ah right because they are both "endorsements"?
elli-androulaki (Thu, 02 Mar 2017 08:42:55 GMT):
we cannot distinguish whether a call aims to also have writes but only after the execution has been completed
elli-androulaki (Thu, 02 Mar 2017 08:42:55 GMT):
we cannot distinguish whether a proposal aims to also have writes but only after the execution has been completed
elli-androulaki (Thu, 02 Mar 2017 08:43:06 GMT):
(the simulation of the execution)
elli-androulaki (Thu, 02 Mar 2017 08:45:41 GMT):
Which would on one hand offer this fine-grained access management and allow readers to query, but to some extend (not entirely) defeats the purpose of doing the access check up front to avoid doing unnecessary simulations.
elli-androulaki (Thu, 02 Mar 2017 08:46:07 GMT):
Also i believe that strong queries could need to go through the blockchain, which means write access to the chain for the queriers would be needed.
yacovm (Thu, 02 Mar 2017 08:51:55 GMT):
> strong queries could need to go through the blockchain
What do you mean by "strong queries"?
yacovm (Thu, 02 Mar 2017 08:52:51 GMT):
And I don't understand why can't a request be tagged with whether it's a write or only a read and then it can fail the simulation if it tries to mutate the state and tagged as a read?
yacovm (Thu, 02 Mar 2017 08:52:51 GMT):
And I don't understand why can't a request be tagged with whether it's a write or only a read and then it can fail the simulation if it tries to mutate the state and tagged as a read? @elli-androulaki
grapebaba (Thu, 02 Mar 2017 09:47:37 GMT):
Hi guys, we are implementing python SDK, right now we are testing install chaincode, but got invalid signature issue.
grapebaba (Thu, 02 Mar 2017 09:48:12 GMT):
could anyone help us checking the python code
elli-androulaki (Thu, 02 Mar 2017 09:50:25 GMT):
@yacovm, and who would tag the request in this case?
elli-androulaki (Thu, 02 Mar 2017 09:51:32 GMT):
@grapebaba, which hash function are you using for signing?
grapebaba (Thu, 02 Mar 2017 09:52:09 GMT):
sha256
grapebaba (Thu, 02 Mar 2017 09:57:42 GMT):
``` def sign(self, msg):
""" Sign a message
Args:
msg: message to sign
Returns: signed results
"""
digest = self._msp.crypto_suite.hash(msg)
return self.signer.sign(digest.hexdigest().encode('utf-8'))```
yacovm (Thu, 02 Mar 2017 09:59:36 GMT):
The client SDK of course, @elli-androulaki
When it submits a chaincode endorsement request that only needs to read and not to write I guess that can be tagged , no?
grapebaba (Thu, 02 Mar 2017 09:59:55 GMT):
```
class Ecies(Crypto):
""" A crypto implementation based on ECDSA and SHA. """
def __init__(self, security_level=CURVE_P_256_Size, hash_algorithm=SHA2):
""" Init curve and hash function.
:param security_level: security level
:param hash_algorithm: hash function
"""
if security_level == CURVE_P_256_Size:
order = openssl.backend._lib.BN_new()
curve = openssl.backend._lib.EC_GROUP_new_by_curve_name(
openssl.backend._lib.NID_X9_62_prime256v1)
openssl.backend._lib.EC_GROUP_get_order(
curve, order, openssl.backend._ffi.NULL)
self.order = openssl.backend._bn_to_int(order)
self.half_order = self.order / 2
self.curve = ec.SECP256R1
self.sign_hash_algorithm = hashes.SHA256()
else:
order = openssl.backend._lib.BN_new()
curve = openssl.backend._lib.EC_GROUP_new_by_curve_name(
openssl.backend._lib.NID_secp384r1)
openssl.backend._lib.EC_GROUP_get_order(
curve, order, openssl.backend._ffi.NULL)
self.order = openssl.backend._bn_to_int(order)
self.half_order = self.order / 2
self.curve = ec.SECP384R1
self.sign_hash_algorithm = hashes.SHA384()
if hash_algorithm == SHA2:
self._hash = hashlib.sha256
elif hash_algorithm == SHA3 and security_level == CURVE_P_256_Size:
self._hash = hashlib.sha3_256
else:
self._hash = hashlib.sha3_384
@property
def hash(self):
"""Get hash function
Returns: hash function
"""
return self._hash
def sign(self, private_key, message):
"""ECDSA sign message.
:param private_key: private key
:param message: message to sign
:Returns: signature
"""
signer = private_key.signer(ec.ECDSA(self.sign_hash_algorithm))
signer.update(message)
return self._prevent_malleability(signer.finalize())
def verify(self, public_key, message, signature):
"""ECDSA verify signature.
:param public_key: Signing public key
:param message: Origin message
:param signature: Signature of message
:Returns: verify result boolean, True means valid
"""
if not (self._check_malleability(signature)):
return False
verifier = public_key.verifier(signature,
ec.ECDSA(self.sign_hash_algorithm))
verifier.update(message)
try:
verifier.verify()
except InvalidSignature:
return False
except Exception as e:
raise e
return True
def _prevent_malleability(self, sig):
r, s = decode_dss_signature(sig)
if s > self.half_order:
s = self.order - s
return encode_dss_signature(r, s)
def _check_malleability(self, sig):
r, s = decode_dss_signature(sig)
if s > self.half_order:
return False
return True
def generate_private_key(self):
"""ECDSA key pair generation by current curve.
:Returns: A private key object which include public key object.
"""
return ec.generate_private_key(self.curve, default_backend())
```
grapebaba (Thu, 02 Mar 2017 10:03:38 GMT):
if anyone would like to help, can download the latest master code https://github.com/hyperledger/fabric-sdk-py, and enable test_install unittest in chaincode_test
grapebaba (Thu, 02 Mar 2017 10:04:01 GMT):
just run `make check`
elli-androulaki (Thu, 02 Mar 2017 10:21:44 GMT):
Adding @jimthematrix as there were also some signature issues with the other sdks a few days ago;
mastersingh24 (Thu, 02 Mar 2017 12:33:53 GMT):
[I'm fine with saying that we don't have "secret" embedded defaults for bccsp and that we require explicit configuration. That being said, we are absolutely crazy if we think we can support doing this via MSPs at this point. We can explicitly configure bccsp parameters within the various "*.yaml" config files (e.g. core.yaml, orderer.yaml and the fabric-ca yaml files. Might be better to actually have a separate config file for this so we could just reference it and share it with the various components. We should agree on the default settings (e.g. EC, ECDSA, p256, SHA256 or whatever )](https://chat.hyperledger.org/channel/fabric-crypto?msg=pD6JsMbbPFP48QaGi) @vpaprots
mastersingh24 (Thu, 02 Mar 2017 12:35:11 GMT):
I DO NOT support trying to do "per channel" settings for crypto at this point and don't deem it necessary for v1.0. As a matter of fact, doing so will make things even harder than they are currently
mastersingh24 (Thu, 02 Mar 2017 12:35:55 GMT):
@binhn @cbf ^^^^^
mastersingh24 (Thu, 02 Mar 2017 12:35:55 GMT):
@binhn @cbf @JonathanLevi ^^^^^
vpaprots (Thu, 02 Mar 2017 13:18:48 GMT):
@mastersingh24 "we are absolutely crazy if we think we can support doing this wia MSPs at this point". At no point I brought up schedule of when this will go in. Thats your decision. I am trying to point out a whole in our design. We have magically set {EC_ECDSA_p256_SHA256} all over the place. Usually hardcoded. Trying to change any of those defaults breaks in unexpected ways as @binhn found. Do we ever intend to allow people to use p384? SHA3? anything else at all? How will multiple algorithms co-exist?
mastersingh24 (Thu, 02 Mar 2017 13:19:19 GMT):
we should clearly externalize the settings into config
mastersingh24 (Thu, 02 Mar 2017 13:19:41 GMT):
but I'm just saying config is "global" for each component to start with
vpaprots (Thu, 02 Mar 2017 13:20:24 GMT):
Yep, I just want friendly config!
mastersingh24 (Thu, 02 Mar 2017 13:21:23 GMT):
we did this in v0.6 with a few simple parameters ;)
jimthematrix (Thu, 02 Mar 2017 21:36:32 GMT):
@yacov @aso @elli-androulaki what would cause this error during join channel?
```peer3 | 2017-03-02 21:32:18.810 UTC [gossip/service] configUpdated -> ERRO 02c Tried joining channel mychannel but our org( Org2MSP ), isn't among the orgs of the channel: [peerOrg1 peerOrg2] , aborting.```
yacovm (Thu, 02 Mar 2017 21:36:53 GMT):
* yacovm
yacovm (Thu, 02 Mar 2017 21:36:53 GMT):
* yacovm ;)
jimthematrix (Thu, 02 Mar 2017 21:37:12 GMT):
oh sorry hehe
jimthematrix (Thu, 02 Mar 2017 21:37:26 GMT):
the same error happens to both gossip leaders and non-leaders
yacovm (Thu, 02 Mar 2017 21:37:33 GMT):
it's a channel mis-config
yacovm (Thu, 02 Mar 2017 21:37:38 GMT):
I added this logic
yacovm (Thu, 02 Mar 2017 21:37:46 GMT):
to alert you you're doing something wrong :)
yacovm (Thu, 02 Mar 2017 21:38:04 GMT):
https://gerrit.hyperledger.org/r/#/c/6513/
jimthematrix (Thu, 02 Mar 2017 21:39:42 GMT):
so i guess the question is how was the "peerOrg1" and "peerOrg2" are decided, the config template file I used to create the channel clearly had the "Org2MSP" as the MSP ids
yacovm (Thu, 02 Mar 2017 21:39:52 GMT):
the ID needs to be the name
yacovm (Thu, 02 Mar 2017 21:39:52 GMT):
The ID and the name need to be identical
yacovm (Thu, 02 Mar 2017 21:41:23 GMT):
did you generate it with Gari's crypto-gen?
jimthematrix (Thu, 02 Mar 2017 21:41:32 GMT):
yes
jimthematrix (Thu, 02 Mar 2017 21:42:08 GMT):
hmm i noticed that name and ID are identical on for the peer orgs but not orderer org, in the configtx.yaml i used
jimthematrix (Thu, 02 Mar 2017 21:42:19 GMT):
but the error above was for the peers
jimthematrix (Thu, 02 Mar 2017 21:42:47 GMT):
so still puzzled... the "peerOrg1" and "peerOrg2" are not specified anywhere in the configtx.yaml
yacovm (Thu, 02 Mar 2017 21:42:56 GMT):
can you show me the part of the configtx.yaml?
yacovm (Thu, 02 Mar 2017 21:43:01 GMT):
of the orgs
jimthematrix (Thu, 02 Mar 2017 21:43:33 GMT):
```Organizations:
# SampleOrg defines an MSP using the sampleconfig. It should never be used
# in production but may be used as a template for other definitions
- &OrdererOrg
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: OrdererOrg
# ID to load the MSP definition as
ID: OrdererMSP
# MSPDir is the filesystem path which contains the MSP configuration
#########################################################################
# FIXME: this path needs to be fixed to point to the actual location of #
# the project 'fabric-sdk-node' in the file system #
#########################################################################
MSPDir: /fabric-sdk-node/test/fixtures/configtx/crypto/orderer/localMspConfig
# BCCSP (Blockchain crypto provider): Select which crypto implementation or
# library to use
BCCSP:
Default: SW
SW:
Hash: SHA2
Security: 256
# Location of Key Store. If this is unset, a location will
# be chosen using 'MSPDir'/keystore
FileKeyStore:
KeyStore:
- &Org0
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: Org0MSP
# ID to load the MSP definition as
ID: Org0MSP
# MSPDir is the filesystem path which contains the MSP configuration
#########################################################################
# FIXME: this path needs to be fixed to point to the actual location of #
# the project 'fabric-sdk-node' in the file system #
#########################################################################
MSPDir: /fabric-sdk-node/test/fixtures/configtx/crypto/peer/peer0/localMspConfig
# BCCSP (Blockchain crypto provider): Select which crypto implementation or
# library to use
BCCSP:
Default: SW
SW:
Hash: SHA2
Security: 256
# Location of Key Store. If this is unset, a location will
# be chosen using 'MSPDir'/keystore
FileKeyStore:
KeyStore:
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: localhost
Port: 7051
- &Org1
# DefaultOrg defines the organization which is used in the sampleconfig
# of the fabric.git development environment
Name: Org1MSP
# ID to load the MSP definition as
ID: Org1MSP
# MSPDir is the filesystem path which contains the MSP configuration
#########################################################################
# FIXME: this path needs to be fixed to point to the actual location of #
# the project 'fabric-sdk-node' in the file system #
#########################################################################
MSPDir: /fabric-sdk-node/test/fixtures/configtx/crypto/peer/peer2/localMspConfig
# BCCSP (Blockchain crypto provider): Select which crypto implementation or
# library to use
BCCSP:
Default: SW
SW:
Hash: SHA2
Security: 256
# Location of Key Store. If this is unset, a location will
# be chosen using 'MSPDir'/keystore
FileKeyStore:
KeyStore:
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: localhost
Port: 7056```
yacovm (Thu, 02 Mar 2017 21:43:59 GMT):
I guess the MSP-ID of the peer then
yacovm (Thu, 02 Mar 2017 21:44:06 GMT):
in the peer/core.yaml
yacovm (Thu, 02 Mar 2017 21:44:09 GMT):
is peerOrgN?
jimthematrix (Thu, 02 Mar 2017 21:46:25 GMT):
here's the config used in docker-compose.yaml for peer3:
``` peer3:
container_name: peer3
image: hyperledger/fabric-peer
environment:
- CORE_PEER_ADDRESSAUTODETECT=true
- CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
- CORE_PEER_GOSSIP_ORGLEADER=false
- CORE_PEER_NETWORKID=peer3
- CORE_NEXT=true
- CORE_PEER_ENDORSER_ENABLED=true
- CORE_PEER_ID=peer3
- CORE_PEER_PROFILE_ENABLED=true
- CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer:7050
- CORE_PEER_LOCALMSPID=Org2MSP
- CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/configtx/crypto-config/peerOrganizations/peerOrg2/peers/peerOrg2Peer2/
```
yacovm (Thu, 02 Mar 2017 21:46:34 GMT):
yep
yacovm (Thu, 02 Mar 2017 21:46:49 GMT):
Org2MSP
yacovm (Thu, 02 Mar 2017 21:46:56 GMT):
hmmmm
jimthematrix (Thu, 02 Mar 2017 21:47:17 GMT):
yes so that should be the right org name, but where did "peerOrg2" sneak in is what I'm puzzled with
yacovm (Thu, 02 Mar 2017 21:47:44 GMT):
I admit that I don't know, *but* I can give you at least a pointer
yacovm (Thu, 02 Mar 2017 21:48:04 GMT):
peerOrg1 peerOrg2 is the Name of the org
yacovm (Thu, 02 Mar 2017 21:48:06 GMT):
from the config block
yacovm (Thu, 02 Mar 2017 21:48:50 GMT):
This is very weird though, how can it be that the configtx.yaml has no such string
yacovm (Thu, 02 Mar 2017 21:48:52 GMT):
?
mastersingh24 (Thu, 02 Mar 2017 21:51:58 GMT):
@jimthematrix - are you somehow accidentially submitting one of the configtx for fixtures?
mastersingh24 (Thu, 02 Mar 2017 21:51:58 GMT):
@jimthematrix - are you somehow accidentially submitting one of the configtx from fixtures?
jimthematrix (Thu, 02 Mar 2017 21:52:44 GMT):
there's only one configtx in that folder (already deleted the other one)
jimthematrix (Thu, 02 Mar 2017 21:52:50 GMT):
but I suspect that's the source of the error
jimthematrix (Thu, 02 Mar 2017 21:52:59 GMT):
so i'm revisiting the configtx.yaml
mastersingh24 (Thu, 02 Mar 2017 21:53:06 GMT):
peerOrg1 and peerOrg2 are in those
yacovm (Thu, 02 Mar 2017 21:53:09 GMT):
maybe the docker containers need to be recreated or something?
jimthematrix (Thu, 02 Mar 2017 21:53:11 GMT):
and re-generating the configtx template
yacovm (Thu, 02 Mar 2017 21:53:14 GMT):
(just throwing an idea)
mastersingh24 (Thu, 02 Mar 2017 21:55:30 GMT):
mychannel.tx and two.org.block both have those in them
mastersingh24 (Thu, 02 Mar 2017 21:55:30 GMT):
mychannel.tx and twoorgs.orderer.block both have those in them
MikeGardiner (Fri, 03 Mar 2017 15:13:51 GMT):
Are there any upcoming meetups for fabric-crypto/BCCSP? I'm very much interested in the PKCS#11 implementation, and may be able to contribute Gemalto resources to get it done. But I probably need a bunch more information.
weeds (Fri, 03 Mar 2017 15:38:11 GMT):
@MikeGardiner They have an upcoming Hyperledger hackfest-- but you can also reach out to @elli-androulaki and @smithbk
MikeGardiner (Fri, 03 Mar 2017 15:42:07 GMT):
Yeah, I see the one in apac on the 11/12th, and another in DC on the 15/16th.
mastersingh24 (Fri, 03 Mar 2017 16:00:16 GMT):
@MikeGardiner - the PKCS11 piece is not really the "hard" part - it's really making sure that the bccsp interfaces are flexible enough and that we can easily configure various providers
mastersingh24 (Fri, 03 Mar 2017 16:00:57 GMT):
if we want to help out, I'd ping @vpaprots - he's been doing the bulk of the work making sure we can swap SW and PKCS11 providers
rahulhegde (Fri, 03 Mar 2017 16:55:13 GMT):
Has joined the channel.
fbenhamo (Sat, 04 Mar 2017 02:52:00 GMT):
Has joined the channel.
passkit (Sun, 05 Mar 2017 00:46:53 GMT):
Has joined the channel.
grapebaba (Sun, 05 Mar 2017 10:33:52 GMT):
@elli-androulaki I fixed signature issue in python. However i found a problem, the python lib I used actually underlying OpenSSL and it hasn't supported SHA3 yet
saism (Sun, 05 Mar 2017 21:01:57 GMT):
Has joined the channel.
Efdee (Mon, 06 Mar 2017 10:13:26 GMT):
Has joined the channel.
tbrooke (Tue, 07 Mar 2017 01:40:37 GMT):
Has joined the channel.
MartinMateev (Tue, 07 Mar 2017 09:08:03 GMT):
guys, if a network is encrypting transaction payload - how is the payload then stored into something like CouchDB?
CarlXK (Tue, 07 Mar 2017 12:59:16 GMT):
Has joined the channel.
SyneBlockChainTeam (Tue, 07 Mar 2017 13:04:16 GMT):
Earlier we have been using hyperledger fabric v0.5 and v0.6 with vagrant and successfully developed various sample applications. Now we want to switch to v1.0. Though we are following the steps given on "http://hyperledger-fabric.readthedocs.io/en/latest/dev-setup/devenv.html", but somehow we are facing issues while setting up development environment. Is membersrvc.yaml file replaced with fabric-cop? Thanks in advance.
Vadim (Tue, 07 Mar 2017 13:07:00 GMT):
@SyneBlockChainTeam it's now called "fabric-ca". It's a cfssl-based CA which issues certificates to registered users. Then this certificate can be used for chaincode deployment/invocation, and fabric will validate the identity based on what CAs it trusts defined in the MSP config.
Vadim (Tue, 07 Mar 2017 13:07:51 GMT):
you can get fabric-ca here: https://github.com/hyperledger/fabric-ca, you can read about MSPs here: https://docs.google.com/document/d/1Qg7ZEccOIsrShSHSNl4kBHOFvLYRhQ3903srJ6c_AZE/edit#
SyneBlockChainTeam (Tue, 07 Mar 2017 13:12:47 GMT):
@Vadim - Thank you so much
tsnyder (Tue, 07 Mar 2017 14:24:32 GMT):
Has joined the channel.
tsnyder (Tue, 07 Mar 2017 14:30:52 GMT):
Question regarding CRL usage within the Peer and Fabric SDK (Java) - In a meeting last week it was mentioned (Gari I believe) that the CRL's would need to be placed in each channel / Ledger. And that if it was there the Peer and SDK code would validate against the CRL. Is there any documentation on how this works, what type of transaction (CONFIG?), and what key(s) they need to be associated with?
weeds (Tue, 07 Mar 2017 15:29:47 GMT):
@mastersingh24 ^^ see Tim's questions Gari
mastersingh24 (Tue, 07 Mar 2017 18:54:58 GMT):
@tsnyder - from a pure format perspective, we would expect and X509 Certificate Revocation list and it should be the full list of revoked certificates each time (e.g. we don't do delta updates).
channel config transactions are a bit complicated to draw out, but essentially within each channel you'll have the "orgs" which belong to that channel defined and each of those will have a MSP config structure associated with it (https://github.com/hyperledger/fabric/blob/master/protos/msp/mspconfig.proto#L70)
mastersingh24 (Tue, 07 Mar 2017 18:56:08 GMT):
you case might be a little trickier in that you actually have the same root issuer for all orgs differentiated by OU. So in that case, we could either use the same CRL to update each org in the channel or just have separate CRLs for each org
tsnyder (Wed, 08 Mar 2017 14:10:29 GMT):
@mastersingh24 - So from the above and a review of the MSP config structure the takeaway is the if the CRL list changes for the parties associated with a channel, then the MSP structure attribute FabricMSPConfig.revocationList needs to be updated on that channel. I presume this is a CONFIG transaction but am not sure how it would be generated or rather the process to update it. Is there example code we wold follow (maybe a test case)? An additional aspect is how would the Java Fabric SDK obtain this and use it? It could be obtained via eventing but not sure what we would need to do from there. Can you delegate to someone who understands both sides?
mastersingh24 (Wed, 08 Mar 2017 14:40:32 GMT):
`I presume this is a CONFIG transaction but am not sure how it would be generated or rather the process to update it`
Currently, the only human understandable way to do this would be to use the configtx tool (located in the common/configtx package - I believe you are already using this tool to generate the blob that is used as input for create channel). The SDKs currently only take the output of the configtx tool as the input to createChannel (I don't think any of the SDKs have implemented updateChannel at this point). But basically at this point there is really no easy way to update the configuration of a channel. The core functionality to actually perform the update exists in the ordering service, but we don't yet have the end user APIs / tools to be able to do this yet
mastersingh24 (Wed, 08 Mar 2017 14:41:09 GMT):
All of this information ends up serialized in the genesis and/or latest config block for each channel.
mastersingh24 (Wed, 08 Mar 2017 14:42:02 GMT):
The SDKs can actually query a channel and get the latest config block for any given channel which will have all of the channel information embedded in it. Not sure if this is in the Java SDK yet, but it will be.
mastersingh24 (Wed, 08 Mar 2017 14:43:04 GMT):
NET-NET - we have the machinery in place to do this, but updating a channel is not ready for prime time from a consumability perspective. (first we need to make sure you can actually configure / create a channel ;) )
Suma (Wed, 08 Mar 2017 15:42:49 GMT):
Has joined the channel.
CarlXK (Thu, 09 Mar 2017 05:04:59 GMT):
Message Attachments
CarlXK (Thu, 09 Mar 2017 05:05:05 GMT):
Could peer0's certificate be signed by both root CAs (or intermediate CAs) in org1 and org2?
One organization should be all banks(bank1 bank2 bank……) or mixed business parties(bank1, corp1, corp2), or both ok?
One root CA (or intermediate CA) should be only bind with one orgnization or can cross multi orgnization?
guhaihua (Thu, 09 Mar 2017 05:39:28 GMT):
From the point of cryptographic standards, I think peer0's certificate can't be signed by both CAs.
berserkr (Thu, 09 Mar 2017 06:06:46 GMT):
Has joined the channel.
gatakka (Thu, 09 Mar 2017 12:36:18 GMT):
Has joined the channel.
K Sai Anirudh (Thu, 09 Mar 2017 12:45:13 GMT):
Has joined the channel.
K Sai Anirudh (Thu, 09 Mar 2017 13:00:33 GMT):
Hello,
I have basic knowledge of PKI. Can anybody confirm if my understanding is correct? When a single peer with ca is started, the peer generates it key pair and registers it public key to the certificate. So whoever need to send this peer a message they sign it with the public key(they acquire the public key from CA). For checking that the peer is legitimate, it checks the ACA. These ecerts and tcerts will be only given to client and not the peer(Is it correct?) Are ecerts and tcerts like public key used to sign transcations? If somebody captures these ecert and tcert while giving it client, is the client compromised?
aberfou (Thu, 09 Mar 2017 13:49:22 GMT):
Has joined the channel.
gatakka (Thu, 09 Mar 2017 13:49:39 GMT):
No, it will not be compromised because you sign message using private key and verify using public key (Ecert, Tcert). So if you keep private key private you can even print your Ecert on fliers and give it to random peoples and nobady will be able to sign a message. They will be able to verify that some message is signed with this certificate private key, but only this. And yes, they can get data stored in Ecert like enrollment ID
gatakka (Thu, 09 Mar 2017 13:49:39 GMT):
@K Sai Anirudh No, it will not be compromised because you sign message using private key and verify using public key (Ecert, Tcert). So if you keep private key private you can even print your Ecert on fliers and give it to random peoples and nobady will be able to sign a message. They will be able to verify that some message is signed with this certificate private key, but only this. And yes, they can get data stored in Ecert like enrollment ID
gatakka (Thu, 09 Mar 2017 13:49:39 GMT):
@K Sai Anirudh No, it will they will not be compromised because you sign message using private key and verify using public key (Ecert, Tcert). So if you keep private key private you can even print your Ecert on fliers and give it to random peoples and nobady will be able to sign a message. They will be able to verify that some message is signed with this certificate private key, but only this. And yes, they can get data stored in Ecert like enrollment ID
gatakka (Thu, 09 Mar 2017 13:50:47 GMT):
Golden rule in PKI is keep private key as private as possible!
kostas (Thu, 09 Mar 2017 17:48:46 GMT):
In `mspconfig.proto`:
kostas (Thu, 09 Mar 2017 17:48:48 GMT):
``` // OrganizationalUnitIdentifiers holds one or more
// fabric organizational unit identifiers that belong to
// this MSP configuration
repeated FabricOUIdentifier organizational_unit_identifiers = 7;```
kostas (Thu, 09 Mar 2017 17:49:51 GMT):
@aso @adc: What is a very simple explanation on why this is needed?
ashutosh_kumar (Thu, 09 Mar 2017 17:51:23 GMT):
@kostas , pls have a look at fabric-ca channel. Elli has explained it there.
kostas (Thu, 09 Mar 2017 17:52:10 GMT):
@ashutosh_kumar: Will do, thx.
ruslan.kryukov (Fri, 10 Mar 2017 04:07:21 GMT):
Has joined the channel.
AlanLee (Fri, 10 Mar 2017 04:17:30 GMT):
Has joined the channel.
WeiHu (Fri, 10 Mar 2017 04:51:26 GMT):
Has joined the channel.
joshuajeeson (Fri, 10 Mar 2017 14:01:41 GMT):
Has joined the channel.
JatinderBali (Fri, 10 Mar 2017 15:43:28 GMT):
Has joined the channel.
binhn (Fri, 10 Mar 2017 15:49:02 GMT):
@mastersingh24 @yacovm @C0rWin @jeffgarratt I'd like to discuss how to get TLS test going as some told me all ready but other said more work needed. What else do we need?
yacovm (Fri, 10 Mar 2017 15:50:28 GMT):
I thought we need some more commit(s) from Gari
binhn (Fri, 10 Mar 2017 15:50:40 GMT):
@bmos299
binhn (Fri, 10 Mar 2017 15:51:38 GMT):
@yacovm what else do we need? we tested from node and cli yesterday to a peer. Does gossip need something else?
binhn (Fri, 10 Mar 2017 15:51:55 GMT):
@jimthematrix
yacovm (Fri, 10 Mar 2017 15:53:16 GMT):
Sorry i'm driving. Will be back 30 min or so. Explained to jeff a few mim ago
yacovm (Fri, 10 Mar 2017 16:44:54 GMT):
Gossip needs to be able to extract the tls cert from the grpc stream
binhn (Fri, 10 Mar 2017 17:23:09 GMT):
is that specific to gossip layer or other components peer/orderer would need the same code?
yacovm (Fri, 10 Mar 2017 17:38:33 GMT):
It is specific for gossip, because we do a special handshake based on that ability (the code already exists, and is exercised in our tests, you just need to "enable" it in production)
yacovm (Fri, 10 Mar 2017 17:38:33 GMT):
It is specific for gossip, because we do a special handshake based on that ability (the code already exists, and is exercised in our tests, you just need to "enable" it in production via the TLS configuration)
mastersingh24 (Fri, 10 Mar 2017 18:46:07 GMT):
oops - sorry @binhn
mastersingh24 (Fri, 10 Mar 2017 18:46:11 GMT):
missed this earlier
jeffgarratt (Fri, 10 Mar 2017 20:47:57 GMT):
@jimthematrix any progress?
jojocheung (Sun, 12 Mar 2017 02:29:29 GMT):
Has joined the channel.
jjohnst (Mon, 13 Mar 2017 12:36:01 GMT):
Has joined the channel.
amilazzo (Mon, 13 Mar 2017 15:54:03 GMT):
Has joined the channel.
wwendy (Tue, 14 Mar 2017 13:56:14 GMT):
Has joined the channel.
lignyxg (Tue, 14 Mar 2017 17:28:07 GMT):
Has joined the channel.
karysto (Tue, 14 Mar 2017 20:48:27 GMT):
Has joined the channel.
dhuseby (Tue, 14 Mar 2017 22:53:53 GMT):
Has joined the channel.
vdods (Tue, 14 Mar 2017 23:50:16 GMT):
Hi all, what is the planned (and current) concept for use of transaction certificates (or enrollment certs if transaction certs aren't used) -- is it that the transaction parameters are encrypted using the key corresponding to the cert? Or something else?
ashutosh_kumar (Wed, 15 Mar 2017 01:00:35 GMT):
@vdods : You are talking about 2 distinct entities : Transaction Certificate and Encryption. Which one you are interested to know ?
ashutosh_kumar (Wed, 15 Mar 2017 01:00:35 GMT):
@vdods : You are talking about 2 distinct entities : Transaction Certificate and Encryption. Which one you are interested to know about?
rickr (Wed, 15 Mar 2017 01:13:59 GMT):
Question on the MSPID for the the user (not peers, orderers) Currently we've used for that just "DEFAULT" . So if I wanted to test with users that have different MSPIDs where on the Fabric side would that have to be configured?
rickr (Wed, 15 Mar 2017 01:13:59 GMT):
Question on the MSPID for the the user (not peers, orderers) Currently for the SDK used for that just "DEFAULT" . So if I wanted to test with users that have different MSPIDs where on the Fabric side would that have to be configured?
rickr (Wed, 15 Mar 2017 01:13:59 GMT):
Question on the MSPID for the the user (not peers, orderers) Currently for the SDK we've userd for that just "DEFAULT" . So if I wanted to test with users that have different MSPIDs where on the Fabric side would that have to be configured?
mastersingh24 (Wed, 15 Mar 2017 09:05:55 GMT):
@rickr - so you want to have the SDK tests use different users with different MSPIDs? This is all going to start with generating the right config for a channel so that it contains multiple organzations (each with their own different MSPID). You might want to ping @jimthematrix because he has a nice set of artifacts for this
rickr (Wed, 15 Mar 2017 10:55:23 GMT):
Last I looked the Node SDK does use mullit orgs but using a single user for all interaction. So unless each org was defined to use the same user with same MSPID I don't catch the connection. I didn't even think the organization of Peer/Order definitions were tied (bound) to local users MSPID/Org . I thought the only requirement was a trusted root signing authority
rickr (Wed, 15 Mar 2017 10:56:26 GMT):
@jimthematrix ^^^
mastersingh24 (Wed, 15 Mar 2017 11:18:42 GMT):
in order for things to work, the peers must be aware of multiple MSPs. The only way they get that information is via joining channels (via the genesis/config blocks). So you'd need to use configtxgen to actually create channels which have multiple orgs (each with it's own MSP) in them. You'd then also need to generate users for each of those MSPs.
mastersingh24 (Wed, 15 Mar 2017 11:19:16 GMT):
I am actually about to modify the cryptogen tool to produce all the crypto and MSP stuff needed for this to work as well
jimthematrix (Wed, 15 Mar 2017 12:21:49 GMT):
@rickr the updated e2e in node sdk already started using two different users in separate orgs (Org1MSP and Org2MSP) each enrolled with their own fabric-ca
jimthematrix (Wed, 15 Mar 2017 12:26:40 GMT):
if you look closely you see that:
- the admin in Org1 did the create channel
- admin of Org1 joins peer0 and peer1 in Org1
- admin of Org2 joins peer2 and peer3 in Org2
- admin of Org1 installs chaincode in peer0 and peer1 in org1
- admin of Org2 installs chaincode in peer2 and peer3 in org2
- admin of Org1 instantiates the chaincode for the new channel
- admin of Org2 invokes a transaction in the channel
- admin of Org1 queries for information in the channel
mychewcents (Wed, 15 Mar 2017 12:28:02 GMT):
Has joined the channel.
jimthematrix (Wed, 15 Mar 2017 12:29:21 GMT):
some operations can only be done by users in their own org (join peer, install chaincode) so those must be performed twice, one for each org. for other operations users from either org can call (create channel, instantiate, invoke or query), so I try to mix up the org
balashevich (Wed, 15 Mar 2017 12:35:31 GMT):
Has joined the channel.
rickr (Wed, 15 Mar 2017 13:17:33 GMT):
Great!, Is the MSPID of all the users still something that is only known by each user through _out of band_ means? Can you _divulge_ how the Fabric matches each user independent MSPID/Cert ?
vdods (Thu, 16 Mar 2017 00:39:21 GMT):
@ashutosh_kumar Both, really.
ashutosh_kumar (Thu, 16 Mar 2017 00:43:15 GMT):
We definitely has plans for TCerts. Encryption is kind of tricky topic. For attributes that you want to pass along in TCert , those are encrypted using symmetric key , we support TLS for link encryption and data encryption responsibility lies with application.
berserkr (Thu, 16 Mar 2017 00:51:35 GMT):
there is no at-rest encryption right?
berserkr (Thu, 16 Mar 2017 00:51:50 GMT):
for the world state nor for the channel data
Rymd (Thu, 16 Mar 2017 09:19:35 GMT):
Has joined the channel.
mastersingh24 (Thu, 16 Mar 2017 09:56:52 GMT):
@berserkr - no. but of course you can simply encrypt the file system
farhan3 (Thu, 16 Mar 2017 16:49:08 GMT):
Has joined the channel.
farhan3 (Thu, 16 Mar 2017 16:52:03 GMT):
Hi - not sure if this is the correct place to ask this, but how can a peer be configured to use a different MSP at the moment? Or is it hardcoded to use the Fabric MSP under the fabric/msp dir for now?
tuand (Thu, 16 Mar 2017 17:21:14 GMT):
hi gang, I'm getting this error `Extensions not allowed in v2 certificate` when loading cert from the genesis block from the e2e scenario ?
tuand (Thu, 16 Mar 2017 17:21:45 GMT):
I looked at some of the certs and there is one with this : ``` openssl x509 -text -noout -in peerOrg1.pem
Certificate:
Data:
Version: 4 (0x3)
Serial Number: 1000 (0x3e8)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN=peerOrg1
Validity
```
RahulBagaria (Fri, 17 Mar 2017 04:02:10 GMT):
Has joined the channel.
Rymd (Fri, 17 Mar 2017 09:42:21 GMT):
If i generate the genesis block and the channel configuration transaction with profile: SampleInsecureSolo in configtx.yaml, i don't need any MSP certificates right?
But i get this error: ```Error: Error endorsing chaincode: rpc error: code = 2 desc = The creator certificate is not valid, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority``` when i try to install my chaincode
Rymd (Fri, 17 Mar 2017 09:42:21 GMT):
If i generate the genesis block and the channel configuration transaction with profile: SampleInsecureSolo in configtx.yaml, i don't need any MSP certificates right?
But i get this error: ```Error: Error endorsing chaincode: rpc error: code = 2 desc = The creator certificate is not valid, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority```
when i try to install my chaincode
Rymd (Fri, 17 Mar 2017 09:42:21 GMT):
If i generate the genesis block and the channel configuration transaction with profile: SampleInsecureSolo in configtx.yaml, i don't need any MSP certificates right?
But i get this error: `Error: Error endorsing chaincode: rpc error: code = 2 desc = The creator certificate is not valid, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority`
when i try to install my chaincode
mastersingh24 (Fri, 17 Mar 2017 11:19:23 GMT):
@Rymd - installing chaincode on the peer is actually orthogonal to joining channels. when you install chaincode on a peer, the peer checks to make sure that the submitter of the install command / API belongs to the same MSP as the peer (the local MSP for the peer)
mastersingh24 (Fri, 17 Mar 2017 11:19:35 GMT):
how are you installing the chaincode? from the CLI?
Rymd (Fri, 17 Mar 2017 11:21:58 GMT):
yea
mastersingh24 (Fri, 17 Mar 2017 11:35:19 GMT):
if you are using the CLI and the default peer setup, this should just work
Rymd (Fri, 17 Mar 2017 12:41:37 GMT):
it does work if i use the channel: testchainid, but if i use my generated channel with `peer channel create -o $ORDERER_IP:7050 -c mychannel0 -f crypto/orderer/channel0.tx` but when i try to join now i get `Tried joining channel mychannel0 but our org( DEFAULT ), isn't among the orgs of the channel: [] , aborting.`
yacovm (Fri, 17 Mar 2017 14:02:41 GMT):
That's a gossip logging, isn't it?
It says that the list of channel members it got from the genesis block is an empty list
yacovm (Fri, 17 Mar 2017 14:03:06 GMT):
So it detects a "bad configuration" and decides to ignore the channel joining.
Rymd (Fri, 17 Mar 2017 14:49:22 GMT):
Is there any guide to setup your own network configuration and how the MSP and configtx are involved?
yacovm (Fri, 17 Mar 2017 15:29:04 GMT):
What is the MSP-id in the peer/core.yaml or if you're using docker then in the dokcer-compose file?
Rymd (Fri, 17 Mar 2017 16:45:05 GMT):
if i define my org in configtx, what do i set as MSPDir? can i use the sample config?
yacovm (Fri, 17 Mar 2017 16:51:59 GMT):
You need to set your MSP as it was in the configtx...
samwood (Sat, 18 Mar 2017 01:30:44 GMT):
Has joined the channel.
rickr (Sat, 18 Mar 2017 21:47:00 GMT):
Hi @mastersingh24 @jimthematrix Still not seeing any love from the Fabric with TLS
`vp0_1 | 2017-03-18 21:27:23.349 UTC [deliveryClient] NewDeliverService -> ERRO 453 Cannot dial to orderer:7050, because of grpc: timed out when dialing`
I changed my certs for CN to be orderer and vp0 to match DC.yml tags
rickr (Sat, 18 Mar 2017 21:47:27 GMT):
Best I can tell client to fabric is communicating ok
rickr (Sat, 18 Mar 2017 22:37:31 GMT):
@mastersingh24 @jimthematrix @ashutosh_kumar https://jira.hyperledger.org/browse/FAB-2827 opened a JIRA to capture info .. probably just needs more experienced eyes to spot the user error.
mastersingh24 (Sun, 19 Mar 2017 10:23:07 GMT):
@rickr - what do you see in the orderer logs? Maybe some type of "EOF"? In that case it is typically a hostname mismatch
GeorgeSamman (Mon, 20 Mar 2017 03:49:48 GMT):
Has joined the channel.
Xiao (Mon, 20 Mar 2017 07:09:38 GMT):
Has joined the channel.
dorrakhribi (Mon, 20 Mar 2017 10:24:09 GMT):
Has joined the channel.
ruslan.kryukov (Mon, 20 Mar 2017 16:38:00 GMT):
Hi, what difference between SW and PKCS11 in settings?
ruslan.kryukov (Mon, 20 Mar 2017 16:41:16 GMT):
@rickr recently I've managed to start fabric with enabled tls successfuly
ruslan.kryukov (Mon, 20 Mar 2017 16:41:39 GMT):
Day ago
farhan3 (Mon, 20 Mar 2017 19:36:17 GMT):
Hi - I'm just wondering how Admins/Readers/Writers are suppose to be set for an MSP instance.
bh4rtp (Tue, 21 Mar 2017 00:57:01 GMT):
Has joined the channel.
bkvellanki (Tue, 21 Mar 2017 13:56:05 GMT):
Has joined the channel.
shanlusun (Wed, 22 Mar 2017 01:31:46 GMT):
Has joined the channel.
rickr (Wed, 22 Mar 2017 23:23:08 GMT):
I'm seeing the following from my chaincode DC
```
Orgs/tls/orderer$ docker logs dev-peer0-example_cc.go-1.0
2017/03/22 23:12:50 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: x509: certificate signed by unknown authority"; Reconnecting to {"peer0:7051"
rickr (Wed, 22 Mar 2017 23:23:42 GMT):
I signed them with a common ca
rickr (Wed, 22 Mar 2017 23:25:35 GMT):
and that's pointed to by
CORE_PEER_TLS_ROOTCERT_FILE on the peer
rickr (Wed, 22 Mar 2017 23:42:19 GMT):
think i found it :)
Shadow-Hawk (Thu, 23 Mar 2017 05:16:47 GMT):
Has joined the channel.
Shadow-Hawk (Thu, 23 Mar 2017 05:22:43 GMT):
Hi！ I don't quite understand Transaction.ToValidators in fabric0.6, could anyone please explain? Thank you
xuzhao103389 (Thu, 23 Mar 2017 10:37:29 GMT):
Has joined the channel.
matanyahu (Thu, 23 Mar 2017 10:54:00 GMT):
Has joined the channel.
WaleIBM (Fri, 24 Mar 2017 00:26:23 GMT):
Has joined the channel.
AbhilekhSingh (Sun, 26 Mar 2017 06:12:54 GMT):
Has joined the channel.
AbhilekhSingh (Sun, 26 Mar 2017 06:14:02 GMT):
ert, _ := stub.GetCreator() giving same value
I'm invoking the chaincode from different users
I'm trying e2e_cli example and check both user has different keystore/key.pem
How can I check whether from which private key it is signed
I'm getting this output -----BEGIN -----\nMIIBYzCCAQmgAwIBAwICA+gwCgYIKoZIzj0EAwIwEzERMA8GA1UEAwwIcGVlck9y\nZzAwHhcNMTcwMjIwMTkwNjExWhcNMTgwMjIwMTkwNjExWjAQMQ4wDAYDVQQDDAVw\nZWVyMDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEF6dfqjqfbIgZuOR+dgoJMl\n/FaUlGI70A/ixmVUY83Yp4YtV3FDBSOPiO5O+s8pHnpbwB1LqhrxAx1Plr0M/UWj\nUDBOMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFBY2bc84vLEwkX1fSAER2p48jJXw\nMB8GA1UdIwQYMBaAFFQzuQR1RZP/Qn/BNDtGSa8n4eN/MAoGCCqGSM49BAMCA0gA\nMEUCIQDeDZ71L+OTYcbbqiDNRf0L8OExO59mH1O3xpdwMAM0MgIgXySG4sv9yV31\nWcWRFfRFyu7o3T72kqiLZ1nkDuJ8jWI=\n-----END -----
Can you help me in this?
which certificate used by peer in cli container for signing transaction ? (e2e_cli example)
AbhilekhSingh (Sun, 26 Mar 2017 06:14:22 GMT):
Also how to parse this certificate I got from GetCreator()
conor (Mon, 27 Mar 2017 00:39:02 GMT):
Has joined the channel.
AbhilekhSingh (Mon, 27 Mar 2017 12:48:14 GMT):
Can anyone please answer this?
AbhilekhSingh (Mon, 27 Mar 2017 12:48:14 GMT):
Can anyone please answer the above question?
MikeGardiner (Mon, 27 Mar 2017 12:51:30 GMT):
So I'm trying to run fabric-ca-server using p11.. after correcting the yaml file to be "csp" rather than "crypto" and changing "software" to "pkcs11" then adding the p11 stuff.. I get an error: Hash Family not supported [] while initializing the BCCSP PKCS11. SHA2 seems like it should be the valid option for hash_family.
mastersingh24 (Mon, 27 Mar 2017 12:56:38 GMT):
@AbhilekhSingh - if GetCreator is returning the same value, then you are definitely calling the chaincode using the same user
mastersingh24 (Mon, 27 Mar 2017 12:56:56 GMT):
how exactly are you calling / invoking the chaincode?
AbhilekhSingh (Mon, 27 Mar 2017 12:57:15 GMT):
peer chaincode invoke -o orderer0:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/orderer/localMspConfig/cacerts/ordererOrg0.pem -C mychannel -n $CODEID -c '{"Args":["addSigner", "boardAdmin", "sudh"]}'
AbhilekhSingh (Mon, 27 Mar 2017 12:57:20 GMT):
That I got it
AbhilekhSingh (Mon, 27 Mar 2017 12:57:48 GMT):
but from which folder it taking the certificate and which one it's taking it
mastersingh24 (Mon, 27 Mar 2017 12:58:09 GMT):
are you in the CLI container?
AbhilekhSingh (Mon, 27 Mar 2017 12:58:12 GMT):
yes
AbhilekhSingh (Mon, 27 Mar 2017 12:58:46 GMT):
I enrolled the user from CA which stores the certificate in msp folder
AbhilekhSingh (Mon, 27 Mar 2017 12:59:01 GMT):
the I figured out /etc/hyperledger/fabric/msp which has certs
AbhilekhSingh (Mon, 27 Mar 2017 12:59:12 GMT):
but replacing this certs also didn't help
AbhilekhSingh (Mon, 27 Mar 2017 12:59:31 GMT):
Also the cert I got in GetCreator() I don't see it in a filesystem
AbhilekhSingh (Mon, 27 Mar 2017 12:59:58 GMT):
is It dynamically generating in e2e_cli example?
mastersingh24 (Mon, 27 Mar 2017 13:00:43 GMT):
you need to set the `CORE_PEER_MSPCONFIGPATH` environment variable - https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/scripts/script.sh#L23
AbhilekhSingh (Mon, 27 Mar 2017 13:01:15 GMT):
thanks let me try that
mastersingh24 (Mon, 27 Mar 2017 13:01:24 GMT):
that's the "identity" the peer cli will use to sign transactions
AbhilekhSingh (Mon, 27 Mar 2017 13:01:39 GMT):
but this is Peer certs
AbhilekhSingh (Mon, 27 Mar 2017 13:01:48 GMT):
I want user certs or Peer on cli is user
mastersingh24 (Mon, 27 Mar 2017 13:02:32 GMT):
where are you getting the user certs from?
AbhilekhSingh (Mon, 27 Mar 2017 13:02:40 GMT):
CA server
AbhilekhSingh (Mon, 27 Mar 2017 13:02:51 GMT):
fabric-ca-client enroll --config /opt/gopath/src/github.com/hyperledger/fabric/peer/fabric-ca-server-config.yaml -u http://admin:adminpw@localhost:7054
mastersingh24 (Mon, 27 Mar 2017 13:03:26 GMT):
ok - and you have access to those from the CLI container?
AbhilekhSingh (Mon, 27 Mar 2017 13:03:33 GMT):
yes
AbhilekhSingh (Mon, 27 Mar 2017 13:04:05 GMT):
CORE_PEER_MSPCONFIGPATH will be different if I run transaction on different peer
AbhilekhSingh (Mon, 27 Mar 2017 13:04:16 GMT):
it should be same
mastersingh24 (Mon, 27 Mar 2017 13:05:27 GMT):
`peer chaincode invoke ...` is using the peer cli as a client. When run in this mode, it still gets its identity from `CORE_PEER_MSPCONFIGPATH`
mastersingh24 (Mon, 27 Mar 2017 13:06:03 GMT):
which needs to point to a folder with the same structure as the peer MSP folders
AbhilekhSingh (Mon, 27 Mar 2017 13:06:41 GMT):
Let me try out changing it
AbhilekhSingh (Mon, 27 Mar 2017 13:06:41 GMT):
Let me try to change it
AbhilekhSingh (Mon, 27 Mar 2017 13:07:03 GMT):
thanks a lot
nhrishi (Mon, 27 Mar 2017 13:07:18 GMT):
Has joined the channel.
mastersingh24 (Mon, 27 Mar 2017 13:07:33 GMT):
you can actually generate this structure with the fabric-ca-client as well:
```
fabric-ca-client enroll --config /opt/gopath/src/github.com/hyperledger/fabric/peer/fabric-ca-server-config.yaml -u http://admin:adminpw@localhost:7054 -M ${pick some directory}
```
mastersingh24 (Mon, 27 Mar 2017 13:08:20 GMT):
if you add the -M option to the fabric-ca-client, it will create an MSP folder structure which you can then point to with CORE_PEER_MSPCONFIGPATH
AbhilekhSingh (Mon, 27 Mar 2017 13:10:23 GMT):
yes that's what I tried
AbhilekhSingh (Mon, 27 Mar 2017 13:10:40 GMT):
but didn't know that it's using it's own cert for transaction
AbhilekhSingh (Mon, 27 Mar 2017 13:11:50 GMT):
I have enrollmentId and certs
AbhilekhSingh (Mon, 27 Mar 2017 13:12:04 GMT):
Can I verify that cert is belong to this enrollmentId?
AbhilekhSingh (Mon, 27 Mar 2017 13:12:10 GMT):
in a chaincode
AbhilekhSingh (Mon, 27 Mar 2017 13:17:28 GMT):
How does it creates the cert I got in GetCreator? Is there any doc/code I can have a look at?
AbhilekhSingh (Mon, 27 Mar 2017 13:19:54 GMT):
@mastersingh24 yes CORE_PEER_MSPCONFIGPATH is the one I had to change. Thanks a lot
passkit (Tue, 28 Mar 2017 17:56:23 GMT):
Getting the following errors when using `peer channel`
Peer:
```Error connecting: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure
Error: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure```
passkit (Tue, 28 Mar 2017 17:56:45 GMT):
Orderer:
```grpc: Server.Serve failed to complete security handshake from "42.98.162.199:59137": tls: client didn't provide a certificate```
passkit (Tue, 28 Mar 2017 17:56:45 GMT):
Orderer:
```grpc: Server.Serve failed to complete security handshake from "42.98.123.234:59137": tls: client didn't provide a certificate```
passkit (Tue, 28 Mar 2017 17:58:49 GMT):
How to specify a peer cliet cert? Env variables `CORE_PEER_TLS_CERT_FILE` and `CORE_PEER_TLS_KEY_FILE` are ignored, and I only see flags for --tls and --caroot
passkit (Tue, 28 Mar 2017 18:00:10 GMT):
Values in core.yaml and the configuration block are also ignored.
passkit (Tue, 28 Mar 2017 18:07:09 GMT):
`CORE_PEER_GOSSIP_SKIPHANDSHAKE=true` also has no effect
passkit (Tue, 28 Mar 2017 18:20:48 GMT):
@mastersingh24 - looked through the work you did and I can see that client certificates are ignored throughout the CLI. How are you disabling the handshake on the orderers in your tests?
mastersingh24 (Tue, 28 Mar 2017 19:12:19 GMT):
@passkit - https://github.com/hyperledger/fabric/blob/master/orderer/orderer.yaml#L31 - should disable client certificates
yacovm (Tue, 28 Mar 2017 20:19:12 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=Z3NTjHu6QYKqtxNLM)
If gossip would've complained it would've printed `Remote peer 42.98.123.234:59137 didn't send TLS certificate"`
yacovm (Tue, 28 Mar 2017 20:19:46 GMT):
And you're doing "peer channel" so the gossip code has no effect
yacovm (Tue, 28 Mar 2017 20:19:46 GMT):
And you're doing `peer channel` so the gossip code has no effect
dorrakhribi (Tue, 28 Mar 2017 20:51:31 GMT):
hi everybody, is it true that v 0.6 does not support security and certificates . and in this case how can i decrypt the blocks of my blockchain to display the history of transactions done in my network
passkit (Tue, 28 Mar 2017 21:22:38 GMT):
Also gossip between peers seems to be failing because client TLS certificates are not being sent.
```2017-03-28 21:14:45.477 UTC [gossip/comm#-1] authenticateRemotePeer -> WARN 42a Remote peer 10.22.73.173:7051 didn't send TLS certificate
2017-03-28 21:14:45.477 UTC [gossip/comm#-1] createConnection -> DEBU 42b Exiting
2017-03-28 21:14:45.477 UTC [gossip/comm#-1] sendToEndpoint -> WARN 42c Failed obtaining connection for 10.22.73.173:7051, PKIid:[] reason: Remote peer 10.22.73.173:7051 didn't send TLS certificate```
yacovm (Tue, 28 Mar 2017 21:40:35 GMT):
Is the skip handshake flag on?
yacovm (Tue, 28 Mar 2017 21:41:14 GMT):
wait, @passkit that's not because the client isn't sending certificate, but rather because the server isn't sending. 7051 is a server port
yacovm (Tue, 28 Mar 2017 21:42:11 GMT):
the TLS isn't configured correctly and the server-side peer from some reason doesn't have the certificate.
scottz (Tue, 28 Mar 2017 21:59:55 GMT):
Has joined the channel.
passkit (Wed, 29 Mar 2017 01:51:34 GMT):
Makes sense - had to turn off TLS on the orderer temporarily to be able to use the CLI. Peer TLS seems to still need some work outside of the node function - and also for consistency across commands. Seems strange to have to specify explicitly in a flag for channel and chaincode, but utilise code.yaml and environment variables elsewhere.
passkit (Wed, 29 Mar 2017 09:31:55 GMT):
@yacovm - which certificates are used as TLS client certificates? Peers act as both servers and clients, but the config files, environment variables and command line do not have any options to specify client certs. I had previously assumed that the MSP certs would be used to identify the client. If that was the case, I would not expect to see issues with peer to peer over TLS. What am I missing?
Vadim (Wed, 29 Mar 2017 09:33:43 GMT):
@passkit I think there is no mutual auth between peers so far
passkit (Wed, 29 Mar 2017 09:34:53 GMT):
`2017-03-29 09:24:06.024 UTC [gossip/comm#-1] sendToEndpoint -> WARN 336 Failed obtaining connection for peer-10.22.34.113:7051, PKIid:[] reason: Remote peer 10.22.34.113:7051 didn't send TLS certificate`
passkit (Wed, 29 Mar 2017 09:35:16 GMT):
This is from my peer log, trying to connect to one of the other anchor peers over TLS
passkit (Wed, 29 Mar 2017 09:35:35 GMT):
If there is no mutual auth - how to configure around this?
yacovm (Wed, 29 Mar 2017 09:35:35 GMT):
take a look at `core/peer/config.go` line 183 `GetSecureConfig`
yacovm (Wed, 29 Mar 2017 09:35:57 GMT):
again- the error you see doesn't stem from the lack of mutual auth.
passkit (Wed, 29 Mar 2017 09:41:01 GMT):
`peer.tls.key.file` refers to a Server key. But a should a peer connecting to another peer not use a Client key?
yacovm (Wed, 29 Mar 2017 09:41:58 GMT):
From what I know- there is no use of mutual auth just yet.
passkit (Wed, 29 Mar 2017 09:44:20 GMT):
I just want to run everything over TLS - I'm not specifically looking for mutual auth, but it seems to be being enforced and I cannot see how o disable it/
yacovm (Wed, 29 Mar 2017 09:45:34 GMT):
It is not enforced.
Can you take a look at `examples/e2e_cli/docker-compose.yml` ?
mastersingh24 (Wed, 29 Mar 2017 10:50:04 GMT):
[https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/docker-compose.yaml ](https://chat.hyperledger.org/channel/fabric-crypto?msg=2Di4BoEzx72ogSsv9) @passkit
mastersingh24 (Wed, 29 Mar 2017 10:50:15 GMT):
that has TLS enabled end to end
mastersingh24 (Wed, 29 Mar 2017 10:50:41 GMT):
https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/peer-base/peer-base.yaml#L21
mastersingh24 (Wed, 29 Mar 2017 10:50:50 GMT):
should get rid of the warning you saw above
passkit (Wed, 29 Mar 2017 11:44:52 GMT):
With that set I get:
`NewDeliverService -> ERRO 34c Cannot dial to orderer:7050, because of grpc: timed out when dialing`
on the peer, and
` grpc: Server.Serve failed to complete security handshake from "172.17.0.1:53494": tls: client didn't provide a certificate`
on the orderer
passkit (Wed, 29 Mar 2017 11:52:39 GMT):
@mastersingh24 Seems as if the orderer is still expecting a handshake. Was the `ORDERER_GOSSIP_IGNORE_SECURITY` (deprecated in fe8c021bd) the orderer equivalent of `CORE_PEER_GOSSIP_SKIPHANDSHAKE`
mastersingh24 (Wed, 29 Mar 2017 12:22:49 GMT):
unless you have https://github.com/hyperledger/fabric/blob/master/orderer/orderer.yaml#L31 set to true, client certs should not be required
passkit (Wed, 29 Mar 2017 16:00:33 GMT):
I think you mean set to false. My config was set to true.
passkit (Wed, 29 Mar 2017 16:51:23 GMT):
Confirmed all working if `CORE_PEER_GOSSIP_SKIPHANDSHAKE=true` is set and `ORDERER_GOSSIP_TLS_CLIENTAUTHENABLED=false`. To ease the pain on others, may be worthwhile removing the clientauthenabled paramater from orderer.yaml (or at least commenting as unsupported) and maybe flipping the default of CORE_PEER_GOSSIP_SKIPHANDSHAKE to true until such time as client is available.
roadcrypto (Fri, 31 Mar 2017 10:12:26 GMT):
Has joined the channel.
o.o. (Fri, 31 Mar 2017 14:12:52 GMT):
Perhaps someone here knows the answer to: https://chat.hyperledger.org/channel/fabric-sdk-java?msg=YHMdQ9Z4kSmC5PhAY
Vadim (Fri, 31 Mar 2017 15:00:06 GMT):
@o.o. in my setup, I used cryptogen to generate the certs and then took the peer CA cert&key and used it in the fabric-ca-server
o.o. (Fri, 31 Mar 2017 16:08:08 GMT):
Ok; so you need to move them there also. I'll let him know!
I assume you had _volumes_ move them and some _environment_ variable set the home to find them then; as set up in a docker-compose.yml.
And perhaps _--ca.certfile/keyfile_ as arguments to the fabric-ca-server start command.
Thanks Vadim!
bh4rtp (Sat, 01 Apr 2017 08:04:19 GMT):
hi, in the end-to-end examples such as java and node sdk, there is a crypto-config directory which contains orderer, ca, msp, peer key-pairs under ordererOrganizations and peerOrganizations sub-directories. i wonder how to generate our organizations and roles like the example?
bh4rtp (Sat, 01 Apr 2017 08:04:19 GMT):
hi, in the end-to-end examples such as java and node sdk, there is a crypto-config directory which contains orderer, ca, msp, peer certs and key-pairs under ordererOrganizations and peerOrganizations sub-directories. i wonder how to generate the certs and key-pairs for our organizations like e2e example?
saism (Sun, 02 Apr 2017 10:50:46 GMT):
Hello, am I right assuming that fabric-ca is not required for running the network and I can use any other compatible cert for my peers/orderer?
yacovm (Sun, 02 Apr 2017 13:12:42 GMT):
@saism correct
suganuma (Sun, 02 Apr 2017 15:11:51 GMT):
Has joined the channel.
farhan3 (Mon, 03 Apr 2017 15:49:54 GMT):
Hi - Does Fabric provide any way of encrypting/securing the content stored in the ledger/world state?
The case I'm interested in is that if Peer A is part of Chain A and Chain B, it is storing the ledger and world state of both chains in the same database, just different directories (in the case of LevelDB). If an application on Chain A is storing confidential information in the chain, is there any built-in way to secure/encrypt the data so that there is more security than just "the data is in a different directory".
From the docs I've read, I don't see something like this. If that is the case, then one solution would be that the application should encrypt the data before writing it to the chain. However, the chaincode may need to decrypt the data in order to perform some business logic. If that is the case, then does Fabric provide some key management that is available to both the application and the chaincode where they could retrieve keys for encrypting/decrypting confidential data. Or are there plans for such a key management feature for the future.
Vadim (Tue, 04 Apr 2017 06:55:10 GMT):
@farhan3 https://github.com/hyperledger/fabric/blob/master/docs/source/FAQ/architecture_FAQ.rst
xuzhao103389 (Tue, 04 Apr 2017 13:26:02 GMT):
@Vadim what is the " visibility setting" ?
xuzhao103389 (Tue, 04 Apr 2017 13:26:06 GMT):
which parameter?
Vadim (Tue, 04 Apr 2017 13:26:50 GMT):
@xuzhao103389 I'm not sure this is implemented yet
xuzhao103389 (Tue, 04 Apr 2017 13:26:59 GMT):
ok thanks:)
xuzhao103389 (Tue, 04 Apr 2017 13:28:25 GMT):
I find that ,
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0362b5844bef dev-peer0-mycc-1.0 "chaincode -peer.a..." 7 seconds ago Up 7 seconds dev-peer0-mycc-1.0
5987694ee42d dev-peer2-mycc-1.0 "chaincode -peer.a..." 11 seconds ago Up 10 seconds dev-peer2-mycc-1.0
xuzhao103389 (Tue, 04 Apr 2017 13:28:57 GMT):
those 2 containers are created by "installChaincode () {
PEER=$1
setGlobals $PEER
peer chaincode install -n mycc -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 >&log.txt
res=$?
cat log.txt
verifyResult $res "Chaincode installation on remote peer PEER$PEER has Failed"
echo "===================== Chaincode is installed on remote peer PEER$PEER ===================== "
echo
}
"
xuzhao103389 (Tue, 04 Apr 2017 13:29:23 GMT):
but I am not sure, how the "peer chaincode install" creates the containers?
Vadim (Tue, 04 Apr 2017 13:29:40 GMT):
@xuzhao103389 it's created by instantiate, invoke or query, install just copied the code onto the file system of a peer
xuzhao103389 (Tue, 04 Apr 2017 13:29:54 GMT):
ok
xuzhao103389 (Tue, 04 Apr 2017 13:29:56 GMT):
thanks
xuzhao103389 (Tue, 04 Apr 2017 13:30:27 GMT):
so each " instantiate, invoke or query" will create a container?
Vadim (Tue, 04 Apr 2017 13:30:41 GMT):
if it has not been running before
xuzhao103389 (Tue, 04 Apr 2017 13:30:47 GMT):
ok
xuzhao103389 (Tue, 04 Apr 2017 13:30:48 GMT):
thanks
farhan3 (Tue, 04 Apr 2017 14:30:55 GMT):
@Vadim Thanks for the reply. I've already read that doc, and that was the one I was referring to. It mentions that _"Third, you can hash or encrypt the data before calling chaincode. [...]. If you encrypt the data then you will need a way to share the decryption keys outside of fabric. "_ Are there any plans to provide a service to share these keys? Or maybe some recommendations on how this should work (maybe using the existing MSP or something)
Vadim (Tue, 04 Apr 2017 14:32:05 GMT):
@farhan3 so far you just store it outside of fabric, whether anything is planned to store it securely in the fabric, I don't know
farhan3 (Tue, 04 Apr 2017 14:32:28 GMT):
ok, sounds good!
AmberZhang (Wed, 05 Apr 2017 02:45:04 GMT):
Has joined the channel.
LordGoodman (Wed, 05 Apr 2017 06:02:36 GMT):
Has joined the channel.
LordGoodman (Wed, 05 Apr 2017 06:02:39 GMT):
could anybody tell me where can i find more detail about msp(membership service provider)
Vadim (Wed, 05 Apr 2017 07:04:46 GMT):
@LordGoodman https://docs.google.com/document/d/1Qg7ZEccOIsrShSHSNl4kBHOFvLYRhQ3903srJ6c_AZE/edit#
LordGoodman (Wed, 05 Apr 2017 07:21:30 GMT):
@Vadim Thanks~
LordGoodman (Fri, 07 Apr 2017 10:30:30 GMT):
Could somebody tell me how to discover other peers in the same channel
yacovm (Fri, 07 Apr 2017 10:44:21 GMT):
What is the need, @LordGoodman ?
LordGoodman (Fri, 07 Apr 2017 10:54:31 GMT):
I am curious about whether or not can I find out other members under the same organization
LordGoodman (Fri, 07 Apr 2017 10:56:20 GMT):
or say can I find out other members under the same organization
LordGoodman (Fri, 07 Apr 2017 10:56:35 GMT):
@yacovm just curiousity
yacovm (Fri, 07 Apr 2017 11:02:27 GMT):
This information exists but isn't exposed to clients currently
LordGoodman (Fri, 07 Apr 2017 11:07:13 GMT):
@yacovm Ok,Thanks
SyneBlockChainTeam (Fri, 07 Apr 2017 14:09:06 GMT):
@muralisr:
We are referring instructions given in github.com/hyperledger/fabric/examples/e2e_cli/end-to-end.rst file, but getting following error:
root@7899e896ea03:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer channel create -o orderer0:7050 -c mychannel -f crypto/orderer/channel.tx --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/orderer/localMspConfig/cacerts/ordererOrg0.pem
2017-04-07 14:03:14.106 UTC [logging] InitFromViper -> DEBU 001 Setting default logging level to DEBUG for command 'channel'
2017-04-07 14:03:14.106 UTC [msp] GetLocalMSP -> DEBU 002 Returning existing local MSP
2017-04-07 14:03:14.106 UTC [msp] GetDefaultSigningIdentity -> DEBU 003 Obtaining default signing identity
Error connecting: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure
Error: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure
Usage:
peer channel create [flags]
Global Flags:
-b, --blockpath string Path to file containing genesis block
--cafile string Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint
-c, --chain string In case of a newChain command, the chain ID to create.
-f, --file string Configuration transaction file generated by a tool such as configtxgen for submitting to orderer
--logging-level string Default logging level and overrides, see core.yaml for full syntax
-o, --orderer string Ordering service endpoint
--test.coverprofile string Done (default "coverage.cov")
--tls Use TLS when communicating with the orderer endpoint
-v, --version Display current version of fabric peer server
Please suggest if we are missing something...
Thanks
mychewcents (Sun, 09 Apr 2017 12:08:56 GMT):
Has left the channel.
hcsatish (Sun, 09 Apr 2017 15:52:55 GMT):
Has joined the channel.
subbu165 (Sun, 09 Apr 2017 17:33:52 GMT):
Has joined the channel.
zian (Mon, 10 Apr 2017 13:58:10 GMT):
Has joined the channel.
Lin-YiTang (Tue, 11 Apr 2017 21:11:42 GMT):
Has joined the channel.
snakejerusalem (Wed, 12 Apr 2017 15:46:32 GMT):
Has joined the channel.
snakejerusalem (Wed, 12 Apr 2017 15:53:04 GMT):
Greetings everyone. My name is João Sousa, a phD student from the university of Lisbon. I am developing a new consenter type based on the BFT-SMaRt java library. This consenter will need to have their consensus nodes written in java. I am already at a stage where I supply the rest of the golang codebase with a signed block generated at those nodes, using Bouncy Castle to generate that signature. However, I am unable to make the rest of the golang codebase to sucessfully verify the signature that was produced in java.
snakejerusalem (Wed, 12 Apr 2017 15:55:03 GMT):
The code I am using to generate the signatures is something like this: '''Signature signEngine = Signature.getInstance("ECDSA", BouncyCastleProvider.PROVIDER_NAME);
signEngine.initSign(privKey);
signEngine.update(text);
return signEngine.sign()'''
snakejerusalem (Wed, 12 Apr 2017 15:55:37 GMT):
while the code I use to verify the signatures is something lie:
snakejerusalem (Wed, 12 Apr 2017 15:56:23 GMT):
des := mspmgmt.GetIdentityDeserializer("")
snakejerusalem (Wed, 12 Apr 2017 15:56:44 GMT):
ident, err := des.DeserializeIdentity(sigHeader.Creator)
snakejerusalem (Wed, 12 Apr 2017 15:57:07 GMT):
err = ident.Verify(bytes, sig.Signature)
snakejerusalem (Wed, 12 Apr 2017 15:58:06 GMT):
I also tryed to verify the signature by directly invoking golang's native ecdsa functions, but the results were the same
SyneBlockChainTeam (Thu, 13 Apr 2017 14:05:02 GMT):
To setup fabric-CA (server and client ), we executed following commands with the help of online documentation but faced error which setting up CLIENT:
DOCKER build:
$ cd /path/to/fabric-ca; make docker
(worked fine)
username3@ubuntu:~/work/src/github.com/hyperledger/fabric-ca/docker/examples/client-server-flow$ docker-compose up
WARNING: The CSR_CONFIG variable is not set. Defaulting to a blank string.
WARNING: The CA_CERTIFICATE variable is not set. Defaulting to a blank string.
WARNING: The CA_KEY_CERTIFICATE variable is not set. Defaulting to a blank string.
WARNING: The FABRIC_CA_CONFIG variable is not set. Defaulting to a blank string.
Starting fabric-ca
ERROR: for fabric-ca Cannot start service fabric-ca: driver failed programming external connectivity on endpoint fabric-ca (3e522e034edae4bc16be10ff96cea589090eb464354af5408b2a8721f4654414): Bind for 0.0.0.0:7054 failed: port is already allocated
ERROR: Encountered errors while bringing up the project.
SyneBlockChainTeam (Thu, 13 Apr 2017 14:11:46 GMT):
To setup fabric-CA (server and client ), we executed following commands with the help of online documentation but faced error which setting up CLIENT:
DOCKER build:
$ cd ~/work/src/github.com/hyperledger/fabric-ca
$ make docker
(worked fine)
Terminal 1
$ cd ~/work/src/github.com/hyperledger/fabric-ca/docker/server
$ docker-compose up
(worked file)
Terminal 2
$ cd ~/work/src/github.com/hyperledger/fabric-ca/docker/examples/client-server-flow
$ docker-compose up
(failed)
WARNING: The CSR_CONFIG variable is not set. Defaulting to a blank string.
WARNING: The CA_CERTIFICATE variable is not set. Defaulting to a blank string.
WARNING: The CA_KEY_CERTIFICATE variable is not set. Defaulting to a blank string.
WARNING: The FABRIC_CA_CONFIG variable is not set. Defaulting to a blank string.
Starting fabric-ca
ERROR: for fabric-ca Cannot start service fabric-ca: driver failed programming external connectivity on endpoint fabric-ca (3e522e034edae4bc16be10ff96cea589090eb464354af5408b2a8721f4654414): Bind for 0.0.0.0:7054 failed: port is already allocated
ERROR: Encountered errors while bringing up the project.
Please give us clue to resolve this issue.
Regards.
mastersingh24 (Thu, 13 Apr 2017 14:47:41 GMT):
Hi @snakejerusalem - Welcome to the project. I'd suggest you take a look at the Java SDK - https://github.com/hyperledger/fabric-sdk-java - and/or post to the #fabric-sdk-java channel as the Java SDK is currently able to provide valid signatures for Fabric peers / orderers.
mastersingh24 (Thu, 13 Apr 2017 14:47:51 GMT):
Is your code posted anywhere yet?
snakejerusalem (Thu, 13 Apr 2017 14:48:55 GMT):
Hi there @mastersingh24 . Nop, I didn't post it anywhere yet because I didn't start to conduct performance tests yet
mastersingh24 (Thu, 13 Apr 2017 14:57:41 GMT):
one quick thing to check, what curve are you using and what signing algorithm? I believe the default for Fabric is SHA256 with a p256 curve. So you might need to change `Signature.getInstance("ECDSA", BouncyCastleProvider.PROVIDER_NAME)` to `Signature.getInstance("SHA256withECDSA", BouncyCastleProvider.PROVIDER_NAME)` and make sure that you generated a p256 key , e.g.
```
KeyPairGenerator g = KeyPairGenerator.getInstance("EC");
ECGenParameterSpec kpgparams = new ECGenParameterSpec("secp256r1");
g.initialize(kpgparams);
KeyPair pair = g.generateKeyPair()
```
snakejerusalem (Thu, 13 Apr 2017 14:58:57 GMT):
Even though I wasn't explicitly setting the signature engine to use sha256, I was passing the plaintext already has a sha256 digest
snakejerusalem (Thu, 13 Apr 2017 14:59:55 GMT):
As for the curve, I am not generating any keypair; I am using the keys that already come with fabric, for the DEFAULT MSPID
snakejerusalem (Thu, 13 Apr 2017 15:00:55 GMT):
I am also making sure that I am serializing everything the same way fabric does
snakejerusalem (Thu, 13 Apr 2017 15:02:00 GMT):
could it be due to how I initialize the Signature engine?
mastersingh24 (Thu, 13 Apr 2017 15:15:10 GMT):
`Even though I wasn't explicitly setting the signature engine to use sha256, I was passing the plaintext already has a sha256 digest` - I am pretty sure you don't want to do that because I believe that the combination of update/sign actually hashes whatever you pass to the update function
snakejerusalem (Thu, 13 Apr 2017 15:23:06 GMT):
hmmm
snakejerusalem (Thu, 13 Apr 2017 15:23:39 GMT):
I will try them to change it to the way it is usually done with sha256withecdsa
snakejerusalem (Thu, 13 Apr 2017 15:35:25 GMT):
oh boy, you were correct. Once I changed `Signature.getInstance("ECDSA", BouncyCastleProvider.PROVIDER_NAME)` to `Signature.getInstance("SHA256withECDSA", BouncyCastleProvider.PROVIDER_NAME)` it solved a lot of problems
snakejerusalem (Thu, 13 Apr 2017 15:35:48 GMT):
however, I still have one last little problem
snakejerusalem (Thu, 13 Apr 2017 15:36:20 GMT):
for some signatures, I get this error: Could not determine the validity of the signature, err Invalid S. Must be smaller than half the order [88928327662531495998636124320422696545791494049447600416237270171581801383589][57896044605178124381348723474703786764998477612067880171211129530534256022184].
snakejerusalem (Thu, 13 Apr 2017 15:36:54 GMT):
From what I can tell, this is a verification done by the fabric codebase, not the golang native code
snakejerusalem (Thu, 13 Apr 2017 15:37:51 GMT):
should I just import the cryptosuite available in the java sdk, or should I add one more minor tweek isntead?
mastersingh24 (Thu, 13 Apr 2017 15:48:18 GMT):
ah - right - this was for ECDSA signature malleability
mastersingh24 (Thu, 13 Apr 2017 15:53:59 GMT):
https://github.com/hyperledger/fabric-sdk-java/blob/master/src/main/java/org/hyperledger/fabric/sdk/security/CryptoPrimitives.java#L678
snakejerusalem (Thu, 13 Apr 2017 15:59:28 GMT):
yeah, that was the class I was looking into
snakejerusalem (Thu, 13 Apr 2017 15:59:44 GMT):
I just finised importing it and testing it
snakejerusalem (Thu, 13 Apr 2017 15:59:48 GMT):
it worked perfectly!
snakejerusalem (Thu, 13 Apr 2017 16:00:24 GMT):
thank you very much for your help!
mastersingh24 (Thu, 13 Apr 2017 16:01:26 GMT):
Sure thing. Let me know when you want to showcase what you are doing. Definitely interested. Are you working Marko
mastersingh24 (Thu, 13 Apr 2017 16:01:26 GMT):
Sure thing. Let me know when you want to showcase what you are doing. Definitely interested. Are you working Marko?
snakejerusalem (Thu, 13 Apr 2017 16:02:28 GMT):
Not directly. It is my phD advisor, Professor Alysson Bessani, who collaborates mostly with Marko.
mastersingh24 (Thu, 13 Apr 2017 16:03:03 GMT):
Ah - so they collaborate and you do the work ;)
mastersingh24 (Thu, 13 Apr 2017 16:03:07 GMT):
haha
mastersingh24 (Thu, 13 Apr 2017 16:03:09 GMT):
just kidding
snakejerusalem (Thu, 13 Apr 2017 16:03:42 GMT):
I would say everybody works, but given that I am the one doing the phD, it is me who ends up creating code
mastersingh24 (Thu, 13 Apr 2017 16:05:02 GMT):
You are wise in your choice of words!
snakejerusalem (Thu, 13 Apr 2017 16:06:04 GMT):
I dont' really feel that wise at the moment, given that I was missing something pretty obvious with that parameters in the signature engine
snakejerusalem (Thu, 13 Apr 2017 16:06:47 GMT):
I did stumble upon many examples that used sha256withECDSA, but it didnt' occur to me that it could be the problem
snakejerusalem (Thu, 13 Apr 2017 16:06:54 GMT):
isntead I was trying to check everythng else
snakejerusalem (Thu, 13 Apr 2017 16:07:02 GMT):
XD
snakejerusalem (Thu, 13 Apr 2017 16:57:17 GMT):
eh, I just noticed that the java sdk already comes with the protobuf data structures. I can ditch the ones I compiled myself from the golang code and use those instead
kostas (Thu, 13 Apr 2017 19:13:49 GMT):
I have MSP certs and MSP/BCCSP configuration settings and I want to end up with an object that implements `msp.SigningIdentity`. How would I go about doing this?
kostas (Thu, 13 Apr 2017 19:13:55 GMT):
I thought I could use `msp.GetVerifyingMspConfig()` to get an `msp.MSPConfig` object, then`msp.NewBccspMsp()` to get an `MSP` object, then run the `Setup(mspConfigObject) on it. But that wouldn't work cause cause the `GetVerifyingMspConfig()` call sets the `SigningIdentity` field of the `msp.FabricMSPConfig` object to nil.
kostas (Thu, 13 Apr 2017 19:13:55 GMT):
I thought I could use `msp.GetVerifyingMspConfig()` to get an `msp.MSPConfig` object, then call `msp.NewBccspMsp()` to get an `MSP` object, then run the `Setup(mspConfigObject) on it. But that wouldn't work cause cause the `GetVerifyingMspConfig()` call sets the `SigningIdentity` field of the `msp.FabricMSPConfig` object to nil.
kostas (Thu, 13 Apr 2017 19:13:55 GMT):
I thought I could use `msp.GetVerifyingMspConfig()` to get an `msp.MSPConfig` object, then call `msp.NewBccspMsp()` to get an `MSP` object, then run the `Setup(mspConfigObject)` method on it. But that wouldn't work cause cause the `GetVerifyingMspConfig()` call sets the `SigningIdentity` field of the `msp.FabricMSPConfig` object to nil.
kostas (Thu, 13 Apr 2017 19:14:06 GMT):
So, we're back to square one.
kostas (Fri, 14 Apr 2017 06:29:50 GMT):
^^ @adc @aso
mastersingh24 (Fri, 14 Apr 2017 10:31:33 GMT):
@kostas - https://github.com/hyperledger/fabric/blob/master/common/tools/cryptogen/msp/msp_test.go#L60-L64
kostas (Fri, 14 Apr 2017 15:03:04 GMT):
@mastersingh24 Hm, this seems to be identical to the steps outlined above, and thus suffers from the same issue no?
kostas (Fri, 14 Apr 2017 15:03:09 GMT):
(Namely that you don't end up with a `SigningIdentity`.)
kostas (Fri, 14 Apr 2017 15:03:18 GMT):
If you extend that test with:
kostas (Fri, 14 Apr 2017 15:03:26 GMT):
```_, err = testMSP.GetDefaultSigningIdentity()
assert.NoError(t, err, "Error getting default signing identity")```
kostas (Fri, 14 Apr 2017 15:03:26 GMT):
```_, err = testMSP.GetDefaultSigningIdentity()
assert.NoError(t, err, "Error getting default signing identity")```
kostas (Fri, 14 Apr 2017 15:03:48 GMT):
You'll get:
kostas (Fri, 14 Apr 2017 15:03:51 GMT):
```--- FAIL: TestGenerateVerifyingMSP (0.02s)
Error Trace: msp_test.go:99
Error: Received unexpected error "This MSP does not possess a valid default signing identity"
Messages: Error getting default signing identity```
kostas (Fri, 14 Apr 2017 15:04:21 GMT):
Perhaps I'm missing something though?
mastersingh24 (Fri, 14 Apr 2017 15:06:21 GMT):
@kostas - Looks like you changed the code in the TestGenerateVerifyingMSP rather than TestGenerateLocalMSP
kostas (Fri, 14 Apr 2017 15:06:34 GMT):
Arghhh
mastersingh24 (Fri, 14 Apr 2017 15:06:36 GMT):
or maybe I am missing something - you'll never be able to sign with a verifying MSP
kostas (Fri, 14 Apr 2017 15:06:52 GMT):
Well, that's embarassing
kostas (Fri, 14 Apr 2017 15:06:58 GMT):
Let me retry that
mastersingh24 (Fri, 14 Apr 2017 15:07:17 GMT):
not as embarrassing as it was when I suffered this same experience ;)
mastersingh24 (Fri, 14 Apr 2017 15:07:28 GMT):
that's how I ended up with two test functions ;)
mastersingh24 (Fri, 14 Apr 2017 15:07:54 GMT):
I hope it works - I think I used to have that in there at one point
kostas (Fri, 14 Apr 2017 15:08:24 GMT):
Oh nice, it works. Thanks Gari. Will study how you did it now.
kostas (Fri, 14 Apr 2017 15:11:45 GMT):
Alright, so for everyone wondering the key is in calling `GetLocalMspConfig` versus `GetVerifyingMspConfig`. Seems obvious in hindsight.
elli-androulaki (Mon, 17 Apr 2017 14:57:53 GMT):
Hi, I have a question on what you think needs to be included in v1 regarding support for endorsement policies that allow for OU-based endorser classification:
a) Option 1: no support for classification of identities w.r.t. OU using MSP principals in v1 (guide people through setting up a separate MSP , e.g., different intermediate CA per otherwise defined as OU).
b) Option 2: extend the MSP definition to allow for inclusion of OUs (FAB-2400)
c) Option 3: extend the endorsement policy language to be able to recognise and trigger the creation of OU-based policies (the rest is already there). However this is not recommended in cases where organisation-scoped gossip messages should not be allowed to be propagated via gossip among peers of different OUs.
Adding @mastersingh24 , @smithbk , @binhn, @jimthematrix .
JonathanLevi (Mon, 17 Apr 2017 17:41:36 GMT):
BTW: Is there an a time estimate for FAB-2400 ?
JonathanLevi (Mon, 17 Apr 2017 17:41:36 GMT):
BTW: Is there a time estimate for FAB-2400 ?
mastersingh24 (Mon, 17 Apr 2017 18:12:11 GMT):
FAB-2400 has always been my opinion of what people want and makes things more consumable in terms of being able to use a single CA
smithbk (Mon, 17 Apr 2017 18:12:28 GMT):
@elli-androulaki IIUC, option 2 would be used with a single OU in each MSP, thus allowing gossip to restrict routing to a group of MSPs/OUs.
mastersingh24 (Mon, 17 Apr 2017 18:12:44 GMT):
option 2 works
ashutosh_kumar (Mon, 17 Apr 2017 23:39:17 GMT):
@elli-androulaki : Sorry , I am kind of behind in my understanding. So , you are going to retrieve OU from Certificate , compute certchain and compare it against the hashed chain value in the validation process ?
divyank (Tue, 18 Apr 2017 01:59:20 GMT):
Has joined the channel.
elli-androulaki (Tue, 18 Apr 2017 12:51:28 GMT):
@jimthematrix @mastersingh24 @binhn @smithbk @Clayton Sims FAB-2400 is now part of Sprint16, @aso said is a few hours of work to have it in.
elli-androulaki (Tue, 18 Apr 2017 12:51:28 GMT):
@jimthematrix @mastersingh24 @binhn @smithbk @Clayton Sims FAB-2400 (option 2) is now part of Sprint16, @aso said is a few hours of work to have it in.
elli-androulaki (Tue, 18 Apr 2017 12:51:28 GMT):
@jimthematrix @mastersingh24 @binhn @smithbk @Clayton Sims FAB-2400 (option 2) is now part of Sprint16. @JonathanLevi @aso said is a few hours of work to have it in, so I guess sometime this week it should be available.
jimthematrix (Tue, 18 Apr 2017 13:09:37 GMT):
@elli-androulaki so with option 2 the MSPs configured with OUs will need additional fields to identity, instead of the simple "mspid" that's been used everywhere so far right? the impact of this seems to be far reaching, basically anywhere "mspid" is used right now, for instance the endorsement policy.
elli-androulaki (Tue, 18 Apr 2017 13:16:04 GMT):
@jimthematrix, OUs is already included as part of the X.509 cert structure.
smithbk (Tue, 18 Apr 2017 13:37:16 GMT):
@elli-androulaki IIUC, option 2 simply adds another condition to the validation of a signature. In addition to checking the cert chain with root and intermediate certs of the MSP, it also checks that one of the cert's subject OU entries is also one of the OU entries of the MSP. If there are no OU entries in the MSP, then there is no change and is sort of a wild-card OU match. If there is one OU entry, then only certs with that OU match. Elli, is this correct?
jimthematrix (Tue, 18 Apr 2017 14:00:14 GMT):
@elli-androulaki to use an example to illustrate my question, when the app submits a transaction it needs to specify the mspid as part of the Creator field in the proposal, is that mspid still the simple org ID (an arbitrary name decided for that org's msp) or should it use the OU value, or a combination of mspid (for the top org) + OU (sub org)? based on your explanation it seems just the simple "mspid" is enough because the issuer value in the client cert will be inspected and expected to match the target MSP's OU?
jimthematrix (Tue, 18 Apr 2017 14:04:02 GMT):
@smithbk is it the OU portion of the cert's own DN or the cert's Issuer?
o.o. (Tue, 18 Apr 2017 14:30:54 GMT):
https://chat.hyperledger.org/channel/fabric-questions?msg=qbZ9KT47TMjBXMYZ9
Got directed here.
Does the sending user have some keys corresponding to the creator certificate that could be used for signing the proposal is what I'm asking I guess?
elli-androulaki (Tue, 18 Apr 2017 14:56:54 GMT):
@smithbk
> @elli-androulaki IIUC, option 2 simply adds another condition to the validation of a signature. In addition to checking the cert chain with root and intermediate certs of the MSP, it also checks that one of the cert's subject OU entries is also one of the OU entries of the MSP. If there are no OU entries in the MSP, then there is no change and is sort of a wild-card OU match. If there is one OU entry, then only certs with that OU match. Elli, is this correct?
Yes, this is correct.
elli-androulaki (Tue, 18 Apr 2017 14:58:47 GMT):
@jimthematrix
> to use an example to illustrate my question, when the app submits a transaction it needs to specify the mspid as part of the Creator field in the proposal, is that mspid still the simple org ID (an arbitrary name decided for that org's msp) or should it use the OU value, or a combination of mspid (for the top org) + OU (sub org)? based on your explanation it seems just the simple "mspid" is enough because the issuer value in the client cert will be inspected and expected to match the target MSP's OU?
Correct. Indeed, the MSP-id is still the simple org ID chosen for that org's msp.
ashutosh_kumar (Tue, 18 Apr 2017 15:50:06 GMT):
@elli-androulaki , based on your explanation for issuer OU , looks like the design is forcing to have another in-house CA for each OU whose certs are being signed by some intermediate CA , like Verisign. Did it sound right ?
ashutosh_kumar (Tue, 18 Apr 2017 15:52:59 GMT):
so , in most cases using fabric-ca as OU CA will be required , IMO.
elli-androulaki (Tue, 18 Apr 2017 16:05:37 GMT):
@ashutosh_kumar , if we extend the MSP config to include also OUs, it will not be necessary to have different intermediate CA per OU.
ashutosh_kumar (Tue, 18 Apr 2017 16:28:27 GMT):
thanks @elli-androulaki
farhan3 (Tue, 18 Apr 2017 17:07:09 GMT):
Hi - I have the e2e_cli example working and now I'm trying to modify it but I'm having issues. I'm trying to use my own certs for the orderer, these certs are created via the cryptogen tool. But when I use these new certs for the orderer the TLS handshake fails. Is this a known issue?
farhan3 (Tue, 18 Apr 2017 17:12:16 GMT):
I just replaced the files under
```
e2e_cli/crypto/orderer/localMspConfig/
├── admincerts
│ └── ordererOrg0.pem
├── cacerts
│ └── ordererOrg0.pem
├── keystore
│ └── ordererSigner.pem
└── signcerts
└── orderer0Signer.pem
```
With those from
```
crypto-config/ordererOrganizations/ordererOrg1/orderers/ordererOrg1Orderer1/
├── admincerts
│ └── ordererOrg1-cert.pem
├── cacerts
│ └── ordererOrg1-cert.pem
├── keystore
│ └── 816c13d250633c5cb21d4018c34dbf3e90ba2824a944211a5209f5932e605fef_sk
└── signcerts
└── ordererOrg1Orderer1-cert.pem
```
farhan3 (Tue, 18 Apr 2017 17:12:16 GMT):
I just replaced the files under
```
e2e_cli/crypto/orderer/localMspConfig/
├── admincerts
│ └── ordererOrg0.pem
├── cacerts
│ └── ordererOrg0.pem
├── keystore
│ └── ordererSigner.pem
└── signcerts
└── orderer0Signer.pem
```
With those from
```
crypto-config/ordererOrganizations/ordererOrg1/orderers/ordererOrg1Orderer1/
├── admincerts
│ └── ordererOrg1-cert.pem
├── cacerts
│ └── ordererOrg1-cert.pem
├── keystore
│ └── 816c13d250633c5cb21d4018c34dbf3e90ba2824a944211a5209f5932e605fef_sk
└── signcerts
└── ordererOrg1Orderer1-cert.pem
```
I renamed the files from the cryptogen tool to match the original names in the e2e_cli orderer.
yacovm (Tue, 18 Apr 2017 17:39:43 GMT):
@farhan3 are your certs signed by the root CA of the orgs of the peer organizations?
yacovm (Tue, 18 Apr 2017 17:39:49 GMT):
or by different root CAs?
farhan3 (Tue, 18 Apr 2017 18:21:18 GMT):
@yacovm Based on the cryptogen tool, each org has an independent root, so ordererOrg0.pem is the self-signed root:
```
$ cert-info ./cacerts/ordererOrg0.pem
{
"subject": {
"common_name": "ordererOrg1",
"country": "US",
"organization": "ordererOrg1",
"locality": "San Francisco",
"province": "California",
"names": [
"US",
"California",
"San Francisco",
"ordererOrg1",
"ordererOrg1"
]
},
"issuer": {
"common_name": "ordererOrg1",
"country": "US",
"organization": "ordererOrg1",
"locality": "San Francisco",
"province": "California",
"names": [
"US",
"California",
"San Francisco",
"ordererOrg1",
"ordererOrg1"
]
},
"serial_number": "96244212470314033781153611403716357527",
"not_before": "2017-04-18T16:51:02Z",
"not_after": "2027-04-16T16:51:02Z",
"sigalg": "ECDSAWithSHA256",
"authority_key_id": "",
"subject_key_id": "F1:8F:38:BC:DF:D8:47:F8:BE:E3:D7:34:76:AC:97:67:3F:6E:69:CF:CE:1C:DE:82:C4:60:2:BB:6C:DF:72:EE",
"pem": "-----BEGIN CERTIFICATE-----\nMIICMzCCAdmgAwIBAgIQSGf2CSVWG3p5nMInyKptlzAKBggqhkjOPQQDAjBmMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEUMBIGA1UEChMLb3JkZXJlck9yZzExFDASBgNVBAMTC29yZGVyZXJP\ncmcxMB4XDTE3MDQxODE2NTEwMloXDTI3MDQxNjE2NTEwMlowZjELMAkGA1UEBhMC\nVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28x\nFDASBgNVBAoTC29yZGVyZXJPcmcxMRQwEgYDVQQDEwtvcmRlcmVyT3JnMTBZMBMG\nByqGSM49AgEGCCqGSM49AwEHA0IABCMdmIGVRRILihlocJ2UzBT9pll5SGqZjuiW\nTPObCF1a9hWgsg06zVVjwQUPZNxZb6GN/psH1iiX4KK2yh843CWjaTBnMA4GA1Ud\nDwEB/wQEAwIBpjAZBgNVHSUEEjAQBgRVHSUABggrBgEFBQcDATAPBgNVHRMBAf8E\nBTADAQH/MCkGA1UdDgQiBCDxjzi839hH+L7j1zR2rJdnP25pz84c3oLEYAK7bN9y\n7jAKBggqhkjOPQQDAgNIADBFAiEArb1mDQzymCzdywbFBfOHMgeGoXLCdEnnva/D\n69M2JYgCIBmd0E/7lWr11fn2UYVDl2CZfdCnjA9nX3yxFug4AU2i\n-----END CERTIFICATE-----\n"
}
```
And then `signcerts/orderer0Signer.pem` is signed by that root:
```
$ cert-info ./signcerts/orderer0Signer.pem
{
"subject": {
"common_name": "ordererOrg1Orderer1",
"country": "US",
"locality": "San Francisco",
"province": "California",
"names": [
"US",
"California",
"San Francisco",
"ordererOrg1Orderer1"
]
},
"issuer": {
"common_name": "ordererOrg1",
"country": "US",
"organization": "ordererOrg1",
"locality": "San Francisco",
"province": "California",
"names": [
"US",
"California",
"San Francisco",
"ordererOrg1",
"ordererOrg1"
]
},
"serial_number": "199552051525213525810868349245186920720",
"not_before": "2017-04-18T16:51:02Z",
"not_after": "2027-04-16T16:51:02Z",
"sigalg": "ECDSAWithSHA256",
"authority_key_id": "F1:8F:38:BC:DF:D8:47:F8:BE:E3:D7:34:76:AC:97:67:3F:6E:69:CF:CE:1C:DE:82:C4:60:2:BB:6C:DF:72:EE",
"subject_key_id": "",
"pem": "-----BEGIN CERTIFICATE-----\nMIICHjCCAcWgAwIBAgIRAJYgU8AUB3b771BJjFngURAwCgYIKoZIzj0EAwIwZjEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xFDASBgNVBAoTC29yZGVyZXJPcmcxMRQwEgYDVQQDEwtvcmRlcmVy\nT3JnMTAeFw0xNzA0MTgxNjUxMDJaFw0yNzA0MTYxNjUxMDJaMFgxCzAJBgNVBAYT\nAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2Nv\nMRwwGgYDVQQDExNvcmRlcmVyT3JnMU9yZGVyZXIxMFkwEwYHKoZIzj0CAQYIKoZI\nzj0DAQcDQgAEfj+7CooBbDeO+cHNVgXxIpptkfpGGPLhU31BPZBe6zcvfE9sx5TP\np2OchXLrRsgCaDArZT8ZbcIKaEPIEVxIn6NiMGAwDgYDVR0PAQH/BAQDAgWgMBMG\nA1UdJQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAg8Y84\nvN/YR/i+49c0dqyXZz9uac/OHN6CxGACu2zfcu4wCgYIKoZIzj0EAwIDRwAwRAIg\nGooOykNcgtlA9Rl1ks3tewYksUNdKFZREOTnF7/8IykCIDp0GPXB1NiPq+Z9pIoS\nG73tD3NqYpfbgrX8im9cTrKg\n-----END CERTIFICATE-----\n"
}
```
farhan3 (Tue, 18 Apr 2017 18:21:18 GMT):
@yacovm Based on the cryptogen tool, each org has an independent root, so ordererOrg0.pem is the self-signed root: https://pastebin.com/hFxjrxDr
And then `signcerts/orderer0Signer.pem` is signed by that root: https://pastebin.com/zjyrP7iZ
yacovm (Tue, 18 Apr 2017 18:21:58 GMT):
oh no, what have I done...
Can you please upload this data to pastebin.com or a similar site?
farhan3 (Tue, 18 Apr 2017 18:22:10 GMT):
Sure
yacovm (Tue, 18 Apr 2017 18:23:39 GMT):
and of course delete the text above
farhan3 (Tue, 18 Apr 2017 18:24:46 GMT):
Updated the message
yacovm (Tue, 18 Apr 2017 18:26:23 GMT):
ok, now - you say you have a TLS problem right? I guess you mean that the peers cannot connect to the orderer.
right?
So, the peers - need to trust the CA of the orderer. I think that since you just replaced the certs of the orderers, and didn't update the peers, that's where the problem lies.
yacovm (Tue, 18 Apr 2017 18:26:23 GMT):
ok, now - you say you have a TLS problem right? I guess you mean that the peers cannot connect to the orderer.
right?
So, the peers - need to trust the CA of the orderer. I think that since you just replaced the certs of the orderer org, and didn't update the peers, that's where the problem lies.
farhan3 (Tue, 18 Apr 2017 18:28:57 GMT):
No, it's not the peer. The TLS error occurs during channel creation.
farhan3 (Tue, 18 Apr 2017 18:29:20 GMT):
Also, I don't see the Orderer's root cert anywhere in under e2e_cli/crypto/peer
yacovm (Tue, 18 Apr 2017 18:29:37 GMT):
ah but the channel creation- uses the peer binary
farhan3 (Tue, 18 Apr 2017 18:30:53 GMT):
So the binary needs to be recompiled? Or the peer binary uses a default location to pick up the orderer root
farhan3 (Tue, 18 Apr 2017 18:31:04 GMT):
And I'm not updating that location
farhan3 (Tue, 18 Apr 2017 18:31:33 GMT):
Because the peers only know about each other's roots
farhan3 (Tue, 18 Apr 2017 18:31:59 GMT):
```
├── peer0
│ └── localMspConfig
│ ├── admincerts
│ │ ├── peerOrg0.pem
│ │ ├── peerOrg1.pem
│ │ └── peerOrg2.pem
│ ├── cacerts
│ │ ├── peerOrg0.pem
│ │ ├── peerOrg1.pem
│ │ └── peerOrg2.pem
│ ├── keystore
│ │ └── peer0Signer.pem
│ └── signcerts
│ └── peer0Signer.pem
```
yacovm (Tue, 18 Apr 2017 18:32:09 GMT):
no no no
yacovm (Tue, 18 Apr 2017 18:32:15 GMT):
it uses the file system
yacovm (Tue, 18 Apr 2017 18:32:39 GMT):
look at the code in `scripts/script.sh` under `examples/e2e_cli`
yacovm (Tue, 18 Apr 2017 18:32:59 GMT):
there are environment variables there that control the certificates that are related to TLS
farhan3 (Tue, 18 Apr 2017 18:33:37 GMT):
`ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/orderer/localMspConfig/cacerts/ordererOrg0.pem`
farhan3 (Tue, 18 Apr 2017 18:33:57 GMT):
This would still point to my new root because I keep the same file name
yacovm (Tue, 18 Apr 2017 18:34:56 GMT):
look at https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/scripts/script.sh#L21-L35
farhan3 (Tue, 18 Apr 2017 18:38:29 GMT):
This is for the peers themselves, there is no mention of the orderer CA
yacovm (Tue, 18 Apr 2017 18:39:48 GMT):
ah yeah you're right - ` peer channel create -o orderer0:7050 -c $CHANNEL_NAME -f crypto/orderer/channel.tx --tls $CORE_PEER_TLS_ENABLED --cafile $ORDERER_CA >&log.txt`
yacovm (Tue, 18 Apr 2017 18:40:13 GMT):
so you set the ORDERER_CA to be the new CA that signed the orderer's certs and it doesn't work?
farhan3 (Tue, 18 Apr 2017 18:40:22 GMT):
Right
farhan3 (Tue, 18 Apr 2017 18:40:29 GMT):
Kept the same file name, just changed the cert itself
yacovm (Tue, 18 Apr 2017 18:41:08 GMT):
:thinking: Sorry I don't have any idea why that doesn't work for you
farhan3 (Tue, 18 Apr 2017 18:44:54 GMT):
ok, hmm, thank you for trying :)
farhan3 (Tue, 18 Apr 2017 18:55:38 GMT):
Hmm, I think it might have to do with the common_name in the cert. The example cert has common_name set to "orderer0", which matches the hostname given to the orderer container. While the cert generated by cryptogen has common_name of "ordererOrg1Orderer1"
farhan3 (Tue, 18 Apr 2017 18:55:46 GMT):
Trying that now
farhan3 (Tue, 18 Apr 2017 18:59:14 GMT):
@yacovm Yep! That was it, the common_name in the cert needs to match the container name/hostname.
yacovm (Tue, 18 Apr 2017 19:00:20 GMT):
cool
yacovm (Tue, 18 Apr 2017 19:00:24 GMT):
glad I could help ;)
JonathanLevi (Tue, 18 Apr 2017 19:03:25 GMT):
@elli-androulaki, @mastersingh24: Do we have a(ny) time estimate regarding FAB-2400? [ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=b32pYYzJ6fGRa8fXS)
JonathanLevi (Tue, 18 Apr 2017 19:03:49 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=nyzyeRS8L7Pury7FG)
JonathanLevi (Tue, 18 Apr 2017 19:04:52 GMT):
I agree that it is the preferred option in terms of functionality... wanting to check if should allocate/plan accordingly should this affect the release plan/milestones/freeze/testing/etc.?
JonathanLevi (Tue, 18 Apr 2017 19:05:26 GMT):
To be clear, I'm not saying "let's not have it" - I'm trying to quantify and just plan accordingly.
JonathanLevi (Tue, 18 Apr 2017 19:09:07 GMT):
I agree that it is the preferred option in terms of functionality... wanting to check if we should allocate/plan accordingly should this affect the release plan/milestones/freeze/testing/etc.?
elli-androulaki (Tue, 18 Apr 2017 19:17:33 GMT):
@JonathanLevi, i thought i pasted up there somewhere :) It is only a few hours of work, therefore the expected time of arrival is sometime this week.
elli-androulaki (Tue, 18 Apr 2017 19:17:53 GMT):
Would this work for you?
JonathanLevi (Tue, 18 Apr 2017 19:18:08 GMT):
Oh, then definitely option 2. Hands down - sure.
JonathanLevi (Tue, 18 Apr 2017 19:18:23 GMT):
(thanks for this)
JonathanLevi (Tue, 18 Apr 2017 19:19:05 GMT):
BTW: Even 2-3 days would be fine, in case we need to iterate over these, etc.
nickgaski (Tue, 18 Apr 2017 19:23:04 GMT):
Has joined the channel.
bkvellanki (Tue, 18 Apr 2017 19:30:57 GMT):
@here..After going through the Fabric chain Membership access Control.. am trying to create new Orgs and Partners, once I use the cryptogen I see the ca's, admincerts, signers, etc are created..there are 4 folders (ca,msp,orderer/peer, users) --> For configuring peer, orderer, --> Under organizations --> we have ca, msp, orderder/peer we have all four certs (ca, admin, keystore,sign). We just need to select the certs from peers and orderer folder...So, ca's are mainly for ca-server, users are for user config, what are msp's certs used for? Does the MSP's folder need to be configured in BCCSP?
bkvellanki (Tue, 18 Apr 2017 19:35:50 GMT):
i am trying to understand the configuration..
bkvellanki (Tue, 18 Apr 2017 19:36:30 GMT):
In my example is use OrgA, OrgB, OrgC as MSPId's to govern the chain.
farhan3 (Tue, 18 Apr 2017 19:39:24 GMT):
Take a look at `fabric/examples/e2e_cli/configtx.yaml`. You would define your organizations there, and each would have an MSP (membership service provider). The enrolling peer would then need to have certs that match the MSP certs.
bkvellanki (Tue, 18 Apr 2017 19:52:34 GMT):
@farhan3 thanks for the response..I understood that piece that each org will have an MSP. But if you look at the directory structure created by the cryptogen tool as attached below..What would be you localMSPConfig directory --> Ia ssusme it is under peerOrganizations-->peers-->PeerOrg1Peer1. If so, what are peerOrganizations -->peerOrg1-->msp folder used for? I can think ca's are for ca server?
bkvellanki (Tue, 18 Apr 2017 19:52:39 GMT):
Message Attachments
farhan3 (Tue, 18 Apr 2017 19:59:59 GMT):
Right, that's what I understood as well, peers/peerOrg1Peer1 would be the "msp" config for the peer. But not sure about the root msp directory, seems incomplete as well since i'ts missing the key under keystore.
bkvellanki (Tue, 18 Apr 2017 20:00:55 GMT):
yep..you are absolutely right..That is what i understood too..can @JonathanLevi or @elli-androulaki please clarigy
bkvellanki (Tue, 18 Apr 2017 20:00:59 GMT):
clarify
bkvellanki (Tue, 18 Apr 2017 20:16:43 GMT):
@farhan3 is the common name issue for orderer solved. Did you change the code in cryptogen to match that?
farhan3 (Tue, 18 Apr 2017 20:23:44 GMT):
I changed the container's name instead
farhan3 (Tue, 18 Apr 2017 20:24:04 GMT):
In docker-compose.yaml and script.sh
bkvellanki (Tue, 18 Apr 2017 20:24:09 GMT):
:-) thinking of that too..got it
bkvellanki (Tue, 18 Apr 2017 20:24:36 GMT):
@farhan3 thanks
farhan3 (Tue, 18 Apr 2017 20:24:58 GMT):
But... I'm having another issue. Now I can create channel, and peers can join, etc. But when a peer queries, it fails, saying "mycc" chaincode was not found.
farhan3 (Tue, 18 Apr 2017 20:25:14 GMT):
Literally the only thing I change is the msp certs of the orderer -_-
farhan3 (Tue, 18 Apr 2017 20:25:28 GMT):
They're not even related.
bkvellanki (Tue, 18 Apr 2017 20:26:50 GMT):
hmmm..what do the orderer logs say
farhan3 (Tue, 18 Apr 2017 20:33:46 GMT):
So many logs... looking for anything interesting
farhan3 (Tue, 18 Apr 2017 20:38:42 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=3vft94vzK8k782M9y) @bkvellanki add configtx.yaml to that list...
farhan3 (Tue, 18 Apr 2017 20:39:37 GMT):
e2e works after that
bkvellanki (Tue, 18 Apr 2017 20:42:30 GMT):
@farhan3 you mean that change of orderer0 in configtx.yaml, docker-compose, and scritps right?
farhan3 (Tue, 18 Apr 2017 20:43:10 GMT):
Yes, change orderer0 to the new hostname, which by default would be ordererOrg1Orderer1
bkvellanki (Tue, 18 Apr 2017 20:43:22 GMT):
yep got it
bobbiejc (Tue, 18 Apr 2017 22:23:54 GMT):
Has joined the channel.
silentspark (Wed, 19 Apr 2017 10:03:27 GMT):
@here Seems currently sdk has not supported getting tcert from fabric-ca and using it to sign transaction. May I know when this feature will be available?
davidkel (Wed, 19 Apr 2017 14:40:16 GMT):
Has joined the channel.
pmullaney (Wed, 19 Apr 2017 18:30:57 GMT):
Has joined the channel.
JohnWhitton (Wed, 19 Apr 2017 19:10:25 GMT):
Has joined the channel.
vdods (Wed, 19 Apr 2017 21:20:02 GMT):
Yeah, I'm also very interested in that
mastersingh24 (Thu, 20 Apr 2017 13:28:00 GMT):
[based on the interest from the community, it's definitely a high priority item in the backlog. Some changes might be needed in the fabric-ca although hopefully not. It's probably a couple week effort to develop and test. There's some existing code which should help. If you are interested in helping out, heres a link to the main JIRA ticket: https://jira.hyperledger.org/browse/FAB-865 . It would be great if you would also hit the vote for this issue button as well](https://chat.hyperledger.org/channel/fabric-crypto?msg=BttbcunNTW5bbELzf) @silentspark
dorrakhribi (Thu, 20 Apr 2017 13:41:46 GMT):
hello everybody, does anyone know how to decrypt the transaction stored in the ledger using users certificates?
silentspark (Thu, 20 Apr 2017 15:49:25 GMT):
@mastersingh24 Thx for your reply!
jimthematrix (Thu, 20 Apr 2017 18:30:51 GMT):
@elli-androulaki @mastersingh24 @binhn @JonathanLevi want to ask your opinion about something, so the node SDK's MSP implementation always returns `true` from the `validate` call (java does validate certificate properly). this means it doesn't properly validate the certs before checking signatures (https://jira.hyperledger.org/browse/FAB-3202)
it's a result of the node.js community not having good cert chain validators in general. pki.js v2.0 provides a CertificateChainValidationEngine that has good support for that but it's built with ES6 language features that are not supported by our current node.js version (6.9.x). if we upgraded our required node.js version then we'll have some struggle with grpc
I'm thinking, for v1.0 can we keep it this way without fixing it? it's meant to validate Endorser identity from proposal responses but those are received on a TLS connection so there's no danger of anyone messing with it. but there might be other concerns so want to ask you guys for input.
jimthematrix (Thu, 20 Apr 2017 18:30:51 GMT):
@elli-androulaki @mastersingh24 @binhn @JonathanLevi want to ask your opinion about something, so the node SDK's MSP implementation always returns `true` from the `validate` call (java SDK does validate certificate properly). this means it doesn't properly validate the certs before checking signatures (https://jira.hyperledger.org/browse/FAB-3202)
it's a result of the node.js community not having good cert chain validators in general. pki.js v2.0 provides a CertificateChainValidationEngine that has good support for that but it's built with ES6 language features that are not supported by our current node.js version (6.9.x). if we upgraded our required node.js version then we'll have some struggle with grpc
I'm thinking, for v1.0 can we keep it this way without fixing it? it's meant to validate Endorser identity from proposal responses but those are received on a TLS connection so there's no danger of anyone messing with it. but there might be other concerns so want to ask you guys for input.
mastersingh24 (Thu, 20 Apr 2017 18:55:37 GMT):
@jimthematrix - in the end, it does not really impact the security in terms of the transaction path through the orderer and peers but just means that it is possible for the client may pass on a endorsement that is not actually "valid". BTW - why doesn't pki.js v2.x work with Node 6.9.x? I know that there are incompatibilities between the pki.js v1.x and v2.x APIs
jimthematrix (Thu, 20 Apr 2017 18:59:32 GMT):
@mastersingh24 when i tried running pki.js v2.0.55 in node 6.9.4 it complained not able to parse the `import` statement that replaces the require() calls
elli-androulaki (Thu, 20 Apr 2017 19:02:19 GMT):
@jimthematrix, I agree with @mastersingh24 . The only concern i would have is the following: if the client cannot check signature validity, isnt the case that the endorser could simply pass arbitrary data there that would ultimately be signed by the client?
jimthematrix (Thu, 20 Apr 2017 19:02:29 GMT):
_"it is possible for the client may pass on a endorsement that is not actually "valid""_ - right, which then will be caught by VSCC anyway. maybe the endorser's org has been kicked out of the channel for instance. or the proposal was sent to the wrong peers who are not part fo the channel
jimthematrix (Thu, 20 Apr 2017 19:02:56 GMT):
still it won't affect the overall security posture...
jimthematrix (Thu, 20 Apr 2017 19:04:00 GMT):
@elli-androulaki see my comment above, yes the endorser could do that, but that will get rooted out by VSCC
jimthematrix (Thu, 20 Apr 2017 19:04:00 GMT):
@elli-androulaki see my comment above, yes the endorser could do that, but that will get rooted out by VSCC (assuming VSCC checks each endorsement's Endorser identity before validating signature which I think it does)
elli-androulaki (Thu, 20 Apr 2017 19:04:34 GMT):
But I guess if we assume that peers are generally trusted to "do the right thing" w.r.t., the clients, this should not be an issue. @adc, @aso, @eug what do you guys think ? :)
jimthematrix (Thu, 20 Apr 2017 19:05:12 GMT):
no the peers don't have to be trusted because of the checks at VSCC
elli-androulaki (Thu, 20 Apr 2017 19:05:23 GMT):
> @elli-androulaki see my comment above, yes the endorser could do that, but that will get rooted out by VSCC (assuming VSCC checks each endorsement's Endorser identity before validating signature which I think it does)
Correct; it will not harm the chain, in that sense. But the signature the client produced could be used elsewhere(?)
jimthematrix (Thu, 20 Apr 2017 19:05:34 GMT):
or the committer, not sure which does the cert validation
jimthematrix (Thu, 20 Apr 2017 19:07:29 GMT):
I assume you are referring to the client signing the transaction that contains the endorsements. how would that be taken advantage of?
jimthematrix (Thu, 20 Apr 2017 19:07:29 GMT):
I assume you are referring to the client signing the transaction that contains the endorsements before sending it to the orderer. how would that be taken advantage of?
elli-androulaki (Thu, 20 Apr 2017 19:10:23 GMT):
I mean if i am a malicious endorser i can send to the client "valid simulation result computed correctly" || "I store 100 $ from the account of Alice"
elli-androulaki (Thu, 20 Apr 2017 19:10:23 GMT):
I mean if i am a malicious endorser i can send to the client "valid simulation result computed correctly" || "I stole 100 $ from the account of Alice
elli-androulaki (Thu, 20 Apr 2017 19:11:27 GMT):
of course it is sort of restricted to a few bytes that cannot be a big message, but the endorser can trick the client to sign data that the client did not intend on singing
elli-androulaki (Thu, 20 Apr 2017 19:11:27 GMT):
of course it is sort of restricted to a few bytes that cannot be a big message, but the endorser can trick the client to sign data that the client did not intend on singing
elli-androulaki (Thu, 20 Apr 2017 19:12:11 GMT):
but from what you are saying not much can be done at this point right? so we can just add it in the listed assumptions?
elli-androulaki (Thu, 20 Apr 2017 19:12:11 GMT):
but from what you are saying not much can be done at this point right? so we can just add it in the "admitted issues"? If we check the rest, proposal header and payload it could potentially invalidate the rest of message
elli-androulaki (Thu, 20 Apr 2017 19:12:11 GMT):
but from what you are saying not much can be done at this point right? so we can just add it in the "admitted issues"? If we check the rest, proposal header and payload it could potentially invalidate the rest of message (in case malicious)
jimthematrix (Thu, 20 Apr 2017 19:28:05 GMT):
If I understand you correctly, you are interpreting the client's signing as an endorsement on the ProposalResponse. but i don't think it's interpreted that way: the only function the client signature serves is for the orderer to check for ACL on the request. i don't think the client's signature gets preserved beyond the orderer's grpc request handler
jimthematrix (Thu, 20 Apr 2017 19:50:19 GMT):
@adc @elli-androulaki with https://gerrit.hyperledger.org/r/#/c/7651/ we now need to get an admin identity to sign the join channel request in the SDK's end to end test
jimthematrix (Thu, 20 Apr 2017 19:51:18 GMT):
I'm wondering how is that admin identity set up
jimthematrix (Thu, 20 Apr 2017 19:56:00 GMT):
the app will have to pre-provision this identity so that the private key and cert are loaded into the app for a special admin user
jimthematrix (Thu, 20 Apr 2017 19:56:00 GMT):
the app will have to pre-provision this identity so that the private key and cert are loaded into the app for a special admin user that matches the `admincerts` under the peer's local MSP dir
mastersingh24 (Thu, 20 Apr 2017 20:00:33 GMT):
you'll notice that I added a feature to cryptogen to anticipate these for being able to generate test / sample artifacts ;)
jimthematrix (Thu, 20 Apr 2017 20:02:31 GMT):
so it'll provide the private key for the admin right? that's the main thing i need
elli-androulaki (Thu, 20 Apr 2017 20:03:39 GMT):
ha! admin is the owner of one of the certificates listed in the mspconfig as admin!
mastersingh24 (Thu, 20 Apr 2017 20:06:11 GMT):
yep - private key for the admin issued by the peer's localmsp
jimthematrix (Thu, 20 Apr 2017 20:15:59 GMT):
@mastersingh24 when I `go install` and `cryptogen` it immediately returns with `Killed: 9`?
jimthematrix (Thu, 20 Apr 2017 20:17:17 GMT):
upgrade to 1.8.1? currently 1.8
jimthematrix (Thu, 20 Apr 2017 20:20:40 GMT):
works better after upgrading to 1.8.1
binhn (Thu, 20 Apr 2017 20:23:01 GMT):
@jimthematrix the client sig on the tx remains with the tx, but you are correct that we don't assume the client would validate the proposal responses in the tx and why vscc does that prior to commit -- we might end up with more invalid tx's on the ledger, but that's part of the design
elli-androulaki (Thu, 20 Apr 2017 21:18:34 GMT):
Hi, some of the CRs we ( @adc , @aso , @mne , and myself) are working on and their status:
CRs that aim for v1:
[FAB-2969] Access control at LSCC (https://gerrit.hyperledger.org/r/#/c/8229/)
[FAB-3156] ensure cc ver match on invocation (https://gerrit.hyperledger.org/r/#/c/8313/)
[FAB-2931] CC instantiation tx validation (https://gerrit.hyperledger.org/r/#/c/8141/)
[FAB-3272] Only allow 1 action per tx (https://gerrit.hyperledger.org/r/#/c/8309/)
[FAB-3155] LSCC security checks at validation time (https://gerrit.hyperledger.org/r/#/c/8253/,
https://gerrit.hyperledger.org/r/#/c/8299/, https://gerrit.hyperledger.org/r/#/c/8305/)
[FAB-2362] Customizable Hash at MSP (https://gerrit.hyperledger.org/r/#/c/8301/)
[FAB-2103] Adding ACL enforcement for CC2CC (https://gerrit.hyperledger.org/r/#/c/6279/)
[FAB-2094] Documenting MSP Setup & Best Practices (https://gerrit.hyperledger.org/r/#/c/8273/)
Work in progress for an item that was moved to post v1:
https://gerrit.hyperledger.org/r/#/c/7691/
elli-androulaki (Thu, 20 Apr 2017 21:18:34 GMT):
Hi, some of the CRs we ( @adc , @aso , @mne , and myself) are working on and their target fix-version:
CRs that aim for v1:
[FAB-2969] Access control at LSCC (https://gerrit.hyperledger.org/r/#/c/8229/)
[FAB-3156] ensure cc ver match on invocation (https://gerrit.hyperledger.org/r/#/c/8313/)
[FAB-2931] CC instantiation tx validation (https://gerrit.hyperledger.org/r/#/c/8141/)
[FAB-3272] Only allow 1 action per tx (https://gerrit.hyperledger.org/r/#/c/8309/)
[FAB-3155] LSCC security checks at validation time (https://gerrit.hyperledger.org/r/#/c/8253/,
https://gerrit.hyperledger.org/r/#/c/8299/, https://gerrit.hyperledger.org/r/#/c/8305/)
[FAB-2362] Customizable Hash at MSP (https://gerrit.hyperledger.org/r/#/c/8301/)
[FAB-2103] Adding ACL enforcement for CC2CC (https://gerrit.hyperledger.org/r/#/c/6279/)
[FAB-2094] Documenting MSP Setup & Best Practices (https://gerrit.hyperledger.org/r/#/c/8273/)
Work in progress for an item that was moved to post v1:
https://gerrit.hyperledger.org/r/#/c/7691/
mne (Thu, 20 Apr 2017 21:18:34 GMT):
Has joined the channel.
yacovm (Thu, 20 Apr 2017 21:20:30 GMT):
is *[FAB-2094] Documenting MSP Setup & Best Practices* a WIP or not?
elli-androulaki (Thu, 20 Apr 2017 21:26:20 GMT):
There are some sections that are to be added. But the ones i have already included are ready from my perspective.
elli-androulaki (Thu, 20 Apr 2017 21:26:20 GMT):
@yacovm There are some sections that are to be added. But the ones i have already included are ready from my perspective.
yacovm (Thu, 20 Apr 2017 21:30:27 GMT):
but there is a [WIP] inside the document. Shouldn't it be removed?
elli-androulaki (Thu, 20 Apr 2017 21:47:49 GMT):
well i was planning to add two more sections
elli-androulaki (Thu, 20 Apr 2017 21:48:24 GMT):
(i will remove the WIP on my next revision yes, was just trying to collect feedback on the exiting sections)
jimthematrix (Fri, 21 Apr 2017 06:51:03 GMT):
@mastersingh24 @adc the private key PEMs generated and persisted by cryptogen (really the `bccsp/utils/PrivateKeyToPEM()`) won't load in openssl or node.js jsrsasign (which expects plain PKCS#8 format)
jimthematrix (Fri, 21 Apr 2017 06:51:03 GMT):
@mastersingh24 @adc the private key PEMs generated and persisted by cryptogen (really the `bccsp/utils/PrivateKeyToPEM()`) won't load in openssl or node.js jsrsasign (which expects plain PKCS#8 format). I have a need to do this in order to create a signing identity for the channel admin
jimthematrix (Fri, 21 Apr 2017 06:51:57 GMT):
@jeffgarratt do you still generate everything in BDD with openssl?
adc (Fri, 21 Apr 2017 06:52:48 GMT):
Hi Jim, what if you rename in the file 'ECDSA PRIVATE KEY' to 'EC PRIVATE KEY'
adc (Fri, 21 Apr 2017 06:52:52 GMT):
does it work?
adc (Fri, 21 Apr 2017 06:53:13 GMT):
looked at this page https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations, it might be that
jimthematrix (Fri, 21 Apr 2017 06:53:28 GMT):
hmm let me try that, did try renaming to "BEGIN PRIVATE KEY" (removing ECDSA)
adc (Fri, 21 Apr 2017 06:53:39 GMT):
replacing ECDSA with EC
adc (Fri, 21 Apr 2017 06:53:54 GMT):
if that work, I can submit quickly a patch
adc (Fri, 21 Apr 2017 06:53:54 GMT):
if that works, I can submit quickly a patch
jimthematrix (Fri, 21 Apr 2017 07:00:19 GMT):
jsrsasign still complains "not supported argument"
jimthematrix (Fri, 21 Apr 2017 07:00:30 GMT):
that's typically about the wrong header and footer
jimthematrix (Fri, 21 Apr 2017 07:00:49 GMT):
had to change to "BEGIN PRIVATE KEY" and "END PRIVATE KEY" to get past that
jimthematrix (Fri, 21 Apr 2017 07:01:12 GMT):
but then gets "malformed plain pkcs8 content"
jimthematrix (Fri, 21 Apr 2017 07:01:23 GMT):
oh wait
jimthematrix (Fri, 21 Apr 2017 07:03:50 GMT):
changed to "BEGIN EC PRIVATE KEY" and "END EC PRIVATE KEY", still "not supported argument"
jimthematrix (Fri, 21 Apr 2017 07:04:39 GMT):
error from openssl:
```jimzhang:fabric-sdk-node jimzhang$ openssl ec -in test/fixtures/channel/crypto-config/peerOrganizations/peerOrg1/peers/peerOrg1Peer1/keystore/5e67f35124df6a9124bf3659365b8476af4090f73c82c9b626efc15f12739d5d_sk -noout -text
read EC key
unable to load Key
140736884941832:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:707:Expecting: ANY PRIVATE KEY
jimthematrix (Fri, 21 Apr 2017 07:07:08 GMT):
but openssl can display that (ECDSA->EC)
jimthematrix (Fri, 21 Apr 2017 07:10:29 GMT):
so "BEGIN EC PRIVATE KEY" is not PKCS#8, I may have to manually parse it, would this look right to you:
- strip out header and footer
- base64 decode to byte array
- encode to hex
- load as DER
jimthematrix (Fri, 21 Apr 2017 07:12:16 GMT):
(Gari has written a pemToDER() utility for fabric-ca that does the same)
adc (Fri, 21 Apr 2017 07:47:26 GMT):
yes, it should be fine then
adc (Fri, 21 Apr 2017 07:47:43 GMT):
at this point I will submit a change-set to fix the header and footer anyway
smallant (Fri, 21 Apr 2017 10:40:34 GMT):
Has joined the channel.
mastersingh24 (Fri, 21 Apr 2017 11:00:10 GMT):
@jimthematrix @adc https://gerrit.hyperledger.org/r/#/c/8349/
mastersingh24 (Fri, 21 Apr 2017 11:00:17 GMT):
hopefully this will work
mastersingh24 (Fri, 21 Apr 2017 11:25:12 GMT):
actually - sorry - I missed something so this actually does not work
yacovm (Fri, 21 Apr 2017 11:51:34 GMT):
what did you miss?
yacovm (Fri, 21 Apr 2017 11:51:50 GMT):
(I guess you missed something that isn't highlighted in green/red)
mastersingh24 (Fri, 21 Apr 2017 11:57:57 GMT):
well it turns out that the I'm not actually marshalling to PKCS8 format :(
ashutosh_kumar (Fri, 21 Apr 2017 12:51:21 GMT):
AFAIK , golang does not support marshalling PKCS8 private key out of the box ,whereas it supports encrypted PEM block. Although it supports Parsing of PKCS8.
ashutosh_kumar (Fri, 21 Apr 2017 12:51:21 GMT):
AFAIK , golang does not support marshalling PKCS8 private key out of the box ,whereas it supports encrypted PEM block. Although it supports Parsing of PKCS8. I might be wrong.
jimthematrix (Fri, 21 Apr 2017 13:20:13 GMT):
hi @mastersingh24, thanks, yeah i think marshaling to PKCS#8 format will give them better compatibility among key parsers
jeffgarratt (Fri, 21 Apr 2017 14:09:38 GMT):
@jimthematrix yes, openssl still used in BDD
ashutosh_kumar (Fri, 21 Apr 2017 16:17:16 GMT):
after googling , I found this golang package for pkcs8 : https://gowalker.org/github.com/youmark/pkcs8. This might help marshalling.
jimthematrix (Fri, 21 Apr 2017 16:21:37 GMT):
yeah i saw that earlier, definitely easier to do the converting to pkcs8 on the golang side than trying to parse the private key PEM with ASN.1 and OID in node.js
JonathanLevi (Fri, 21 Apr 2017 18:56:26 GMT):
Let's not use an "unknown"/unofficial user's implementation for this.
ashutosh_kumar (Fri, 21 Apr 2017 18:58:18 GMT):
that can be used as guidance for implementation as most of the constructs are implemented there.
JonathanLevi (Fri, 21 Apr 2017 18:59:37 GMT):
Sure. By the way, to be more precise... it's not just the un/marshalling that's not there. Effectively, Golang does not have the support for parsing encrypted PKCS#8 private keys.
JonathanLevi (Fri, 21 Apr 2017 19:00:09 GMT):
So "by design", they chose not to implement this, back in 2013 (IIRC)...
JonathanLevi (Fri, 21 Apr 2017 19:00:32 GMT):
---
JonathanLevi (Fri, 21 Apr 2017 19:00:46 GMT):
Also, have I mentioned (enough) that I don't like ASN.1 ;-)
JonathanLevi (Fri, 21 Apr 2017 19:01:01 GMT):
I know, I know...
ashutosh_kumar (Fri, 21 Apr 2017 19:01:22 GMT):
what was the reason for them not implementing PKCS8 ?
ashutosh_kumar (Fri, 21 Apr 2017 19:01:47 GMT):
I am curious like curious Geroge.
jimthematrix (Fri, 21 Apr 2017 21:41:16 GMT):
BTW I am using openSSL pkcs8 command to rewrite the ec key PEM to PKCS8 format
jimthematrix (Fri, 21 Apr 2017 21:43:18 GMT):
works like a charm, I just need them to be right for the setup before running the e2e tests
ashutosh_kumar (Sat, 22 Apr 2017 00:18:11 GMT):
I was thinking along the same line @jimthematrix. Glad that you got it figured out.
ashutosh_kumar (Sat, 22 Apr 2017 00:18:51 GMT):
should have clicked to my mind before.
mastersingh24 (Sat, 22 Apr 2017 11:59:27 GMT):
[ https://gerrit.hyperledger.org/r/#/c/8349/](https://chat.hyperledger.org/channel/fabric-crypto?msg=iiT7JGFe4bsHb4XY8) @jimthematrix
mastersingh24 (Sat, 22 Apr 2017 11:59:48 GMT):
[https://gerrit.hyperledger.org/r/#/c/8349/ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=iiT7JGFe4bsHb4XY8) @jimthematrix
mastersingh24 (Sat, 22 Apr 2017 12:00:20 GMT):
I tested with jsrsasign
jimthematrix (Sat, 22 Apr 2017 12:00:24 GMT):
thanks Gari, reviewed and trying it locally
jimthematrix (Sat, 22 Apr 2017 12:00:35 GMT):
ah ok, KEYUTIL.getKey()?
jimthematrix (Sat, 22 Apr 2017 12:00:40 GMT):
that's the main one
jimthematrix (Sat, 22 Apr 2017 12:00:40 GMT):
that's the main one I'm using in node SDK
mastersingh24 (Sat, 22 Apr 2017 12:01:00 GMT):
```
var jsrsa = require('jsrsasign');
var KEYUTIL = jsrsa.KEYUTIL;
var fs = require('fs');
var pemFile = "ec-key.pem";
var raw = fs.readFileSync(pemFile);
pemString = Buffer.from(raw).toString();
console.log(pemString);
var key = KEYUTIL.getKey(pemString);
```
mastersingh24 (Sat, 22 Apr 2017 12:01:37 GMT):
hopefully this is not a "it works on my machine" ;)
jimthematrix (Sat, 22 Apr 2017 12:06:22 GMT):
on my machine:
```jimzhang:fabric-sdk-node jimzhang$ node
> var ku = require('jsrsasign').KEYUTIL
undefined
> var fs = require('fs')
undefined
> var data = fs.readFileSync('./9022d671ceedbb24af3ea69b5a8136cc64203df6b9920e26f48123fcfcb1d2e9_sk')
undefined
> Buffer.from(data).toString()
'-----BEGIN PRIVATE KEY-----\nMIGHAgEBMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgS0L+WeTBa4vdUW4j\nrogLu8JmLSjda0YcA2TWOfaR+8yhRANCAAQO41JsWQE2pt2UZ/DBdIcpa/inDZ4U\n54P5VcIdXgISsEqdRcGLBz+cvvrpTNedaeyNRSndk5LMIJ/npw2Qua/p\n-----END PRIVATE KEY-----\n'
> ku.getKey(Buffer.from(data).toString())
{ type: 'EC',
getBigRandom: [Function],
setNamedCurve: [Function],
setPrivateKeyHex: [Function],
setPublicKeyHex: [Function],
getPublicKeyXYHex: [Function],
getShortNISTPCurveName: [Function],
generateKeyPairHex: [Function],
jimthematrix (Sat, 22 Apr 2017 12:06:42 GMT):
8349 is a go for me ;-)
mastersingh24 (Sat, 22 Apr 2017 12:07:28 GMT):
I do what I can ;)
ioctl (Sat, 22 Apr 2017 16:34:04 GMT):
Has joined the channel.
LordGoodman (Mon, 24 Apr 2017 11:03:56 GMT):
How to generate certificates like those under e2e_cli/crypto
ashutosh_kumar (Mon, 24 Apr 2017 13:40:03 GMT):
for Elliptic curve , I would suggest cfssl. For RSA , openssl.
LordGoodman (Mon, 24 Apr 2017 13:48:23 GMT):
@ashutosh_kumar thank you
nya1 (Mon, 24 Apr 2017 15:00:16 GMT):
Has joined the channel.
nya1 (Mon, 24 Apr 2017 15:06:02 GMT):
Hi, I'm trying to run the block-listener example (to listen on a particular chaincode event), but I keep getting errors related to the signing identity:
```
error on Register send could not obtain the default signing identity, err This MSP does not possess a valid default signing identity
could not start chat could not obtain the default signing identity, err This MSP does not possess a valid default signing identity
Error creating event client
```
padmaja (Tue, 25 Apr 2017 10:15:31 GMT):
Has joined the channel.
glotov (Tue, 25 Apr 2017 14:24:53 GMT):
Has joined the channel.
HubertYoung (Tue, 25 Apr 2017 15:03:37 GMT):
Has joined the channel.
haiderny (Tue, 25 Apr 2017 15:16:55 GMT):
Has joined the channel.
rmohta (Tue, 25 Apr 2017 15:22:22 GMT):
Has joined the channel.
rangak (Wed, 26 Apr 2017 04:06:47 GMT):
Has joined the channel.
prashiyn (Wed, 26 Apr 2017 08:58:47 GMT):
Has joined the channel.
ansonlau3 (Thu, 27 Apr 2017 06:41:35 GMT):
Has joined the channel.
marek.dapps (Thu, 27 Apr 2017 10:17:43 GMT):
Has joined the channel.
adc (Thu, 27 Apr 2017 16:35:19 GMT):
Hi All, please, have a your say on this FAB https://jira.hyperledger.org/browse/FAB-3465 on how to restructure the bccsp to improve test coverage and more
adc (Thu, 27 Apr 2017 16:35:19 GMT):
Hi All, please, have a your say on this FAB https://jira.hyperledger.org/browse/FAB-3465 on how to restructure the bccsp to improve test coverage and more. Thanks :)
adc (Thu, 27 Apr 2017 16:35:19 GMT):
Hi All, please, have your say on this FAB https://jira.hyperledger.org/browse/FAB-3465 on how to restructure the bccsp to improve test coverage and more. Thanks :)
wsh_bob (Fri, 28 Apr 2017 08:11:29 GMT):
Has joined the channel.
jkirke (Fri, 28 Apr 2017 15:04:22 GMT):
Has left the channel.
npnjuguna (Sat, 29 Apr 2017 05:02:47 GMT):
Has joined the channel.
svasilyev (Sat, 29 Apr 2017 14:27:20 GMT):
Has joined the channel.
rickr (Mon, 01 May 2017 13:33:36 GMT):
In mspimpl.go around line 117 I think what this does is generate a hash for the certificate which is later printed out in logs that show the identity being dealt with. I'd like to match that in SDK but had no luck so far. Is that cert.Raw the entities certificate as a pem file in bytes ? and what hashing is being used ? Is there any way the client/sdk can know that and be in sync?
adc (Mon, 01 May 2017 13:38:13 GMT):
@rickr, cert.Raw is just the DER representation of certificate
rickr (Mon, 01 May 2017 13:44:00 GMT):
ok --- thx how about the hashing being used ? Would it match the hashing that' used to sign proposals
adc (Mon, 01 May 2017 13:52:49 GMT):
so, by default, SHA256 is used. In theory, the hash function used there can be different from the one used for signatures
jimthematrix (Mon, 01 May 2017 16:42:16 GMT):
@elli-androulaki @adc quick question: is the Policy.PolicyType.MSP supposed to work? I can't seem to find an example using it or tests that uses it. and https://github.com/hyperledger/fabric/blob/master/common/configtx/initializer.go#L80 seems to indicate this is not really supported
jimthematrix (Mon, 01 May 2017 16:42:51 GMT):
did I understand it right? should we remove the handling of this policy type in the client (like when decoding the config block)
mastersingh24 (Mon, 01 May 2017 19:51:02 GMT):
@jimthematrix - there's no support for PolicyType.MSP
Lakshmipadmaja (Tue, 02 May 2017 04:59:57 GMT):
Has joined the channel.
William.Z (Thu, 04 May 2017 13:04:56 GMT):
Has joined the channel.
davidkel (Thu, 04 May 2017 13:29:14 GMT):
Reading the docs on endorsement policies regarding the policy if one is not specified, the docs say
```
NOTE - the default policy requires one signature from a member of the DEFAULT MSP
```
I can't find any description of what the default MSP is and how a proposal could be signed by this MSP. Anyone point me to some information ?
jeffgarratt (Thu, 04 May 2017 15:37:32 GMT):
@davidkel the default MSP is the local msp configuration. I showed you some of the folders in our discussions yesterday if you recall
jeffgarratt (Thu, 04 May 2017 15:38:42 GMT):
the path to this folder is configured here in the peers core.yaml file https://github.com/hyperledger/fabric/blob/master/sampleconfig/core.yaml#L200
jeffgarratt (Thu, 04 May 2017 15:39:23 GMT):
```a sample folder output is as shown here...
jeffgarratt (Thu, 04 May 2017 15:41:22 GMT):
Message Attachments
jeffgarratt (Thu, 04 May 2017 15:42:19 GMT):
@davidkel so any one with a cert signed by one of the orgs in the cacerts folder can sign for the endorsment.
davidkel (Thu, 04 May 2017 17:20:50 GMT):
@jeffgarratt Thanks Jeff, I figured as much. It was the use of the word default which implies to me that it was built in with alternatives being available
jeffgarratt (Thu, 04 May 2017 17:21:43 GMT):
yw
ishan.gulhane (Thu, 04 May 2017 17:57:42 GMT):
Has joined the channel.
tom.appleyard (Fri, 05 May 2017 09:54:50 GMT):
Has joined the channel.
elli-androulaki (Fri, 05 May 2017 14:00:27 GMT):
Hi all! Your opinion on this issue would be greatly appreciated! https://jira.hyperledger.org/browse/FAB-3678
yacovm (Fri, 05 May 2017 14:13:43 GMT):
I don't understand the "number of blocks" approach.
If there is no "action" in the channel, a block isn't created AFAIK. How does that solve the underlying problem that the certificate expiration is supposed to solve?
elli-androulaki (Fri, 05 May 2017 14:40:33 GMT):
@yacovm, are you referring to option 1 from the ones mentioned in the FAB-3678?
yacovm (Fri, 05 May 2017 14:40:55 GMT):
that too
yacovm (Fri, 05 May 2017 14:41:32 GMT):
I also commented in the FAB
elli-androulaki (Fri, 05 May 2017 14:52:07 GMT):
I answered there, thanks!
ashutosh_kumar (Fri, 05 May 2017 20:22:39 GMT):
@elli-androulaki , it seems over engineering. I put my comments in the fabric.
passkit (Sat, 06 May 2017 12:14:35 GMT):
How does the new MSA OrganisationalUnit config help prevent imposters. Is it not superfluous to the certificate entry? The certificate can only contain one OU so why explicitly state it in the config. Indeed why the need forthe config at all?
passkit (Sat, 06 May 2017 12:14:35 GMT):
How does the new MSA OrganisationalUnit config help prevent imposters. Is it not superfluous to the certificate entry? The certificate can only contain one OU so why explicitly state it in the config. Indeed why the need for the config file at all?
passkit (Sat, 06 May 2017 12:23:51 GMT):
I worry about cases of just checking the OU string, which could be spoofed by anybody
passkit (Sat, 06 May 2017 12:25:02 GMT):
If it is not explicitly required, then perhaps it should be removed although open to accept justifications.
mastersingh24 (Sat, 06 May 2017 12:55:30 GMT):
[ A few things which are probably not as clear as they should be:
1) Each organization has an MSP
2) The default MSP implementation is X509-based and in a typical setup each MSP would contain a different root certificates / set of intermediate certificates
3) 2) implies that each organization would have it's own CA / Intermediate CAs which avoids central control of a single CA
4) There are some use cases where where there is actually the desire / requirement to have a single CA (i.e a CA controlled by the founder of the network or perhaps a 3rd party CA mutually trusted by all participants)
5) If you go with 4), then there is an issue in that the root CA for the MSP for each organization would actually be the same and that means that if you know the MSPID for an organization you'd be able to spoof it since your certs are signed by the same CA
6) So in order to meet the requirements of 4) and avoid the vulnerability stated in 5), we added the option to include OU(s) in the MSP. The allows all orgs to share the same root CA but now we can distinguish them based on the combination of the root cert and OU. This does of course imply that the central CA has controls in place to ensure that it does not issue certificates for one org with the OU intended to represent another org
7) Recall that for all of this to work, the orgs must be included in the configuration transactions submitted to the ordering service and that there are policies which define how may signatures are require for the configuration transaction to be valid (which in turn means that multiple organizations will inspect the config transaction before signing it)
](https://chat.hyperledger.org/channel/fabric-crypto?msg=P3d2pxqq5DBJcF5a4) @passkit
passkit (Sat, 06 May 2017 13:00:11 GMT):
#mastersingh24 Nailed it!
jimthematrix (Sat, 06 May 2017 22:24:48 GMT):
@elli-androulaki @adc (would include Matthias but couldn't find his ID) the node and java SDK e2e tests are both failing due to the following error. So I went back to review the instantiation policy added by https://gerrit.hyperledger.org/r/#/c/8667/. if the chaincode itself does not include an instantiation policy (the chaincode package currently installed by both SDKs don't include one), it uses the local MSP to enforce the policy. what I don't understand is how would this work in a transaction cycle when org1's admin sends the proposal to peers in org2 (along with peers in org1), which would reject it?
```error: [Chain.js]: Chain-sendPeersProposal - Promise is rejected: Error: chaincode instantiation policy violated
jimthematrix (Sat, 06 May 2017 22:24:59 GMT):
@rickr ^^^
rickr (Sat, 06 May 2017 22:25:14 GMT):
Hi Jim
rickr (Sat, 06 May 2017 22:25:24 GMT):
It's all broken again :)
jimthematrix (Sat, 06 May 2017 22:27:13 GMT):
at the time when this was discussed i thought it was pretty simple (the required change in the tests would be a single switch in the SDK API call)
jimthematrix (Sat, 06 May 2017 22:28:10 GMT):
but when I reviewed the CR above, it did not make sense to me. and the `instantiation policy included in the chaincode package` took my by surprise, I had no idea there was such a thing
rickr (Sat, 06 May 2017 22:30:43 GMT):
Both @muralisr and @jeffgarratt were working on it this morning. Let them figure it out and I'll follow suit. Got a deck of other things that need attention besides that.
rickr (Sat, 06 May 2017 22:31:58 GMT):
I figured out may hang this morning .. that was a weird one. Give you the details on Monday
rickr (Sat, 06 May 2017 22:31:58 GMT):
I figured out my hang this morning .. that was a weird one. Give you the details on Monday
jimthematrix (Sat, 06 May 2017 22:43:09 GMT):
crypto random in java hanging ;-) that's pretty awesome
muralisr (Sat, 06 May 2017 22:44:16 GMT):
@jimthematrix - `what I don't understand is how would this work in a transaction cycle when org1's admin sends the proposal to peers in org2 (along with peers in org1), which would reject it?` that's correct, this will work only for 1 org scenario..... since using CDSPackage is meant to be temporary anyway (we should move to SignedCDSPackage as soon as we can) we should relax this constraint to me more workable default @elli-androulaki
muralisr (Sat, 06 May 2017 22:44:16 GMT):
@jimthematrix - `what I don't understand is how would this work in a transaction cycle when org1's admin sends the proposal to peers in org2 (along with peers in org1), which would reject it?` that's correct, this will work only for 1 org scenario..... since using CDSPackage is meant to be temporary anyway (we should move to SignedCDSPackage which allows user to specify policy as soon as we can) we should relax this constraint to me more workable default @elli-androulaki
muralisr (Sat, 06 May 2017 22:44:16 GMT):
@jimthematrix - `what I don't understand is how would this work in a transaction cycle when org1's admin sends the proposal to peers in org2 (along with peers in org1), which would reject it?` that's correct, this will work only for 1 org scenario..... since using CDSPackage is meant to be temporary anyway (we should move to SignedCDSPackage which allows user to specify policy as soon as we can) we should relax this constraint to a more workable default @elli-androulaki
jimthematrix (Sat, 06 May 2017 22:45:06 GMT):
@muralisr i think that it shouldn't have been enforced at all, just doesn't make sense
jimthematrix (Sat, 06 May 2017 22:45:42 GMT):
instantiation is a transaction so should use verifying MSPs in the channel config to check instead of local MSP
muralisr (Sat, 06 May 2017 22:45:53 GMT):
@jimthematrix if we cannot get a decent default ( "should be some admin" ?), yes
jimthematrix (Sat, 06 May 2017 22:46:29 GMT):
no the default policy is fine, but what I'm saying is the enforcing code doesn't seem right to me
muralisr (Sat, 06 May 2017 22:46:52 GMT):
the enforcing code is using a default policy that's not workable
jimthematrix (Sat, 06 May 2017 22:47:40 GMT):
actually you are right
jimthematrix (Sat, 06 May 2017 22:47:50 GMT):
https://github.com/hyperledger/fabric/blob/master/core/scc/lscc/lscc.go#L494
jimthematrix (Sat, 06 May 2017 22:47:58 GMT):
is returning the default policy
muralisr (Sat, 06 May 2017 22:48:00 GMT):
from comment ` the default instantiation policy requires the peer's msp admin` ... this will change for each peer and lead to each peer's ProposalResponse being different
muralisr (Sat, 06 May 2017 22:48:03 GMT):
right
muralisr (Sat, 06 May 2017 22:48:19 GMT):
(btw, the above is what @jeffgarratt found)
muralisr (Sat, 06 May 2017 22:50:08 GMT):
and I should have caught this when reviewing... but the successful 1 endorser CLI test passing fooled me
muralisr (Sat, 06 May 2017 22:51:50 GMT):
on a related topic.... the right thing would be to use SignedCDSPackage and move away from the old and tired CDS package
jimthematrix (Sat, 06 May 2017 22:52:01 GMT):
i would return something like this as the default:
```ONE_OF_TWO_ORG_ADMIN = {
identities: [{role: {
name: 'admin',
mspId: 'org1'
}
}, {
role: {
name: 'admin',
mspId: 'org2'
}
}],
policy: {
'1-of': [{ 'signed-by': 0 }, { 'signed-by': 1 }]
}
jimthematrix (Sat, 06 May 2017 22:53:03 GMT):
i'm not sure there's anything wrong with the CDSPackage
muralisr (Sat, 06 May 2017 22:53:07 GMT):
yes, if we did some more work and found all the orgs in the channel)
muralisr (Sat, 06 May 2017 22:53:58 GMT):
CDSPackage cannot specify policy - ie, you have to go with default
muralisr (Sat, 06 May 2017 22:54:14 GMT):
SignedCDSPackage allows policy
muralisr (Sat, 06 May 2017 22:54:14 GMT):
SignedCDSPackage allows user policy
muralisr (Sat, 06 May 2017 22:54:36 GMT):
and users to sign the package
jimthematrix (Sat, 06 May 2017 22:54:46 GMT):
using the signed cds package will make the instantiate process that much more complex just like creating channel
muralisr (Sat, 06 May 2017 22:55:04 GMT):
right
muralisr (Sat, 06 May 2017 22:55:39 GMT):
it brings in the notion of "ownership" of chaincode like channel
jimthematrix (Sat, 06 May 2017 22:55:43 GMT):
for for creating channel you have no choice but to embed the signatures before the transaction gets sent to the orderer, but here we can actually take advantage of the endorsement process to collect the signatures
muralisr (Sat, 06 May 2017 22:57:42 GMT):
it does give you more option...however, the chaincode being outside of channels, there's value in specifying ownership
muralisr (Sat, 06 May 2017 22:59:07 GMT):
in any case, we do have to solve the current problem for CDSPackage with right default policy regardless... not saying we should move to SignedCDSPackage right away
jimthematrix (Sat, 06 May 2017 22:59:27 GMT):
are you guys working on patch this code so the default policy looks like something I pasted above? I think that should be the right fix
jimthematrix (Sat, 06 May 2017 22:59:38 GMT):
or you have another solution?
muralisr (Sat, 06 May 2017 23:01:17 GMT):
need to check with @elli-androulaki .... we could try something like what you have if we can get the list of MSPIDs for the channel from the peer
muralisr (Sat, 06 May 2017 23:01:30 GMT):
it does look like a possibility
muralisr (Sat, 06 May 2017 23:02:06 GMT):
I can investigate while we wait...
jimthematrix (Sat, 06 May 2017 23:03:29 GMT):
should be pretty easy, already have the channel ID, can ask the peer for the channel's MSP manager
jimthematrix (Sat, 06 May 2017 23:03:33 GMT):
which has all the MSPs
muralisr (Sat, 06 May 2017 23:03:59 GMT):
right... that's what I was going to check
muralisr (Sat, 06 May 2017 23:04:10 GMT):
but not sure what the actual apis were
muralisr (Sat, 06 May 2017 23:11:04 GMT):
how about this
muralisr (Sat, 06 May 2017 23:11:09 GMT):
``` } else {
// the default instantiation policy requires any of the peer's msp admin
mspids := peer.GetMSPIDs(channel)
ipEnvelope := cauthdsl.SignedByAnyMember(mspids)
ip, err := proto.Marshal(ipEnvelope)
if err != nil {
return nil, fmt.Errorf("Marshalling instantiation policy failed: [%s]", err)
}
}```
jimthematrix (Sat, 06 May 2017 23:11:47 GMT):
can be `SignedByAnyAdmin` to be more stringent
jimthematrix (Sat, 06 May 2017 23:12:20 GMT):
and that'd match what we had expected ;-)
muralisr (Sat, 06 May 2017 23:12:44 GMT):
:-)
muralisr (Sat, 06 May 2017 23:12:45 GMT):
ok
muralisr (Sat, 06 May 2017 23:13:31 GMT):
need to a bit of refactor for common code and add that method I think... or is it there already ?
jimthematrix (Sat, 06 May 2017 23:19:41 GMT):
not seeing it there, but should be trivial to add by refactoring the existing SignedByAnyMember to a common local func that takes an arg to decide whether it's any member or any admin
muralisr (Sat, 06 May 2017 23:21:05 GMT):
right
jimthematrix (Sat, 06 May 2017 23:21:08 GMT):
only cauthdsl_builder.go:128 `Role: msp.MSPRole_MEMBER` needs to be different b/w the two
muralisr (Sat, 06 May 2017 23:21:24 GMT):
can I give you the files to check with ?
jimthematrix (Sat, 06 May 2017 23:21:30 GMT):
thanks for taking care of it man
jimthematrix (Sat, 06 May 2017 23:21:33 GMT):
yes sure
muralisr (Sat, 06 May 2017 23:24:21 GMT):
sure (and thanks) .... let me run a bit of UT and send them over ASAP ?
mastersingh24 (Sun, 07 May 2017 09:10:23 GMT):
@jimthematrix @muralisr - I am a bit confused as to what you decided the solution should be here. I thought that the plan was to keep the "old" CDSPackage around (especially for development purposes) so that we could avoid all of the complexities of instantiation policy.
It looks like that's what you decided? I would also go with SignedByAnyMember rather than SignedByAnyAdmin
muralisr (Sun, 07 May 2017 11:06:27 GMT):
@mastersingh24 right re CDSPackage
muralisr (Sun, 07 May 2017 11:07:07 GMT):
that was just an observation that with SignedCDSPackage we don't have have to rely on fabric generated default policy
muralisr (Sun, 07 May 2017 11:08:01 GMT):
easy to pick either Member or Admin
muralisr (Sun, 07 May 2017 11:08:01 GMT):
about whether to use SignedByAnyMember rather than SignedByAnyAdmin.... easy to pick either
muralisr (Sun, 07 May 2017 11:09:10 GMT):
But I'd have thought for instantiate an "Admin" role is more appropriate @mastersingh24 ?
muralisr (Sun, 07 May 2017 11:12:37 GMT):
@mastersingh24 testing a fix by the way (more work was needed to get the UT happy)
jimthematrix (Sun, 07 May 2017 13:31:36 GMT):
@mastersingh24 so the error is due to something more than using AnyAdmin vs. AnyMember. to be honest at this point I don't think it's a big difference because to install chaincode you already have to use a peer org admin. that's why I suggested AnyAdmin to preserve the original spirit of https://gerrit.hyperledger.org/r/#/c/8667
jimthematrix (Sun, 07 May 2017 13:33:09 GMT):
in node SDK e2e both peers rejected the instantiate endorsement proposal, and in @rickr 's case his channel only has one org and that org's peer rejected the proposal too. so there must be issues with the policy evaluation logic or something.
jimthematrix (Sun, 07 May 2017 13:33:53 GMT):
just tried @muralisr 's patch that defined SignedByAnyAdmin as the default but still getting the error. investigating
jimthematrix (Sun, 07 May 2017 14:47:55 GMT):
@muralisr and I found two problems:
- using local MSP as the default chaincode instantiation will prevent any channel with more than one org to successfully instantiate chaincode
jimthematrix (Sun, 07 May 2017 14:47:55 GMT):
@muralisr and I found two problems:
- using local MSP as the default chaincode instantiation will prevent any channel with more than one org to successfully instantiate chaincode
- 2nd argument in the LSCC `instantiate` call is supposed to be the chainId, but node SDK and java SDK are both setting it to `default` because since long time ago this has worked. chainId is set in the proposal header as with any other proposals. Murali will later see if this can be eliminated
jimthematrix (Sun, 07 May 2017 14:51:05 GMT):
@rickr see above 2nd item
muralisr (Sun, 07 May 2017 14:53:16 GMT):
@jimthematrix will do another round of tests (also want to see if I can make the mock cleaner ... but that's a secondary at this point so I can get the fix in)
rickr (Sun, 07 May 2017 14:54:03 GMT):
thx jim I'll jump on this tomorrow ... went back a build and working on TLS enablement
jimthematrix (Sun, 07 May 2017 15:04:53 GMT):
http://gerrit.hyperledger.org/r/9059 for node SDK fix (won't pass until after @muralisr 's fix is merged)
jimthematrix (Sun, 07 May 2017 15:05:08 GMT):
@muralisr @rickr @mastersingh24 ^^^
jimthematrix (Sun, 07 May 2017 15:06:27 GMT):
thanks Murali for the investigation. @elli-androulaki please let us know if you have any concerns regarding the discussions and decisions above
muralisr (Sun, 07 May 2017 16:01:09 GMT):
@jimthematrix SignedByXXX was using MarshalOrPanic ... to be safe decided to do a bit more work to return the proto message and use error or panic on case by case basis
muralisr (Sun, 07 May 2017 16:01:42 GMT):
will run UTs and push as soon as done.
muralisr (Sun, 07 May 2017 16:01:46 GMT):
within the hour for sure
elli-androulaki (Sun, 07 May 2017 16:38:38 GMT):
@jimthematrix, regarding this:
> - using local MSP as the default chaincode instantiation will prevent any channel with more than one org to successfully instantiate chaincode
Are you considering a chaincodes that are installed on the peers of more than one organisations? If so, indeed default instantiation policy would not work, as it would result into two or more (depending on how many organisations are on the channel and have the chaincode instlaled) installation entries for the same chaincode across the peers i.e.,
elli-androulaki (Sun, 07 May 2017 16:42:24 GMT):
@jimthematrix , @muralisr, are you suggesting that the defaul instantiation policy would be set to the members of the org of the peer that receives the cc installation request.
elli-androulaki (Sun, 07 May 2017 16:42:24 GMT):
@jimthematrix , @muralisr, are you suggesting that the defaul instantiation policy would be set to the members of the org of the peer that receives the cc installation request?
muralisr (Sun, 07 May 2017 16:43:20 GMT):
@elli-androulaki admins in the orgs for channel to be specific
muralisr (Sun, 07 May 2017 16:44:44 GMT):
currently each endorser will have its own msp based instantiation policy
elli-androulaki (Sun, 07 May 2017 16:44:58 GMT):
(as default yes)
elli-androulaki (Sun, 07 May 2017 16:44:58 GMT):
(as default, yes)
muralisr (Sun, 07 May 2017 16:45:01 GMT):
two endorsers will come up with two different instantiation policies
muralisr (Sun, 07 May 2017 16:45:15 GMT):
so if you are collecting endorsements, this won't work
elli-androulaki (Sun, 07 May 2017 16:45:17 GMT):
if they are members ofdifferent orgs
elli-androulaki (Sun, 07 May 2017 16:45:42 GMT):
but we dont need to collect endorsements
elli-androulaki (Sun, 07 May 2017 16:45:42 GMT):
Hi everyone! Your feedback on this would be much helpful!
elli-androulaki (Sun, 07 May 2017 16:45:46 GMT):
we only need one, no?
yacovm (Sun, 07 May 2017 17:35:43 GMT):
Correct me if I'm wrong, but - shouldn't we try to have instantiation policies that for every given principal, they evaluate (accepted/denied) in the same way across all peers in the org?
yacovm (Sun, 07 May 2017 17:35:43 GMT):
Correct me if I'm wrong, but - shouldn't we try to have instantiation policies that for every given principal, they evaluate (accept/deny the proposal) in the same way across all peers in the org?
yacovm (Sun, 07 May 2017 17:35:43 GMT):
Correct me if I'm wrong, but - shouldn't we try to have instantiation policies that for every given principal, they evaluate (accept/deny the proposal) in the same way across all peers in all orgs in the channel?
yacovm (Sun, 07 May 2017 17:48:20 GMT):
Otherwise we might run into inconsistencies.
muralisr (Sun, 07 May 2017 18:13:12 GMT):
@yacovm really what we need to do is allow user to specify policy which we can do with the SignedCDSPackage (just ChaincodeDeploymentSpec + instantiation policy ... we can ignore the "owner signatures" for future implementation)
muralisr (Sun, 07 May 2017 18:13:40 GMT):
so basically we can allow users to specify policies
yacovm (Sun, 07 May 2017 18:14:35 GMT):
I'm trying to grasp the big picture behind the problem you and Jim are describing
muralisr (Sun, 07 May 2017 18:16:17 GMT):
the instantiation policy ties the local MSP of the peer ... which works if you are using only one peer for instantation
yacovm (Sun, 07 May 2017 18:16:48 GMT):
Yeah I understood this.
muralisr (Sun, 07 May 2017 18:17:20 GMT):
(as an aside @jimthematrix other UTs are failing due to the change ...working on getting them to work as well)
yacovm (Sun, 07 May 2017 18:17:58 GMT):
Anyway, I don't want to divert the flow of the discussion from what you and @elli-androulaki were talking about - carry on.
muralisr (Sun, 07 May 2017 18:18:33 GMT):
no worries, yacov :-)
muralisr (Sun, 07 May 2017 18:18:49 GMT):
(and thanks for chiming in!!)
yacovm (Sun, 07 May 2017 18:22:07 GMT):
I am worried though - fixing a problem with regard to the "default policy" is closing the hole in a leaking pipe, and you might have other holes which you do not know about.
That's why I was trying to think - what principal can be adopted so we will not run into such problems.
Users define instantiation policies themselves, right?
Isn't it a problem with regard to what I said a few comments before? Shouldn't we be able to restrict the expressions they can have in order for them not to make the channel reach a diverged state?
yacovm (Sun, 07 May 2017 18:22:07 GMT):
I am worried though - fixing a problem with regard to the "default policy" is closing the hole in a leaking pipe, and you might have other holes which you do not know about.
That's why I was trying to think - what principal can be adopted so we will not run into such problems.
Users define instantiation policies themselves, right?
Isn't it a problem with regard to what I said a few comments before? Shouldn't we be able to restrict the expressions they can have in order for them not to make the channel reach a diverged state?
- Again, if I'm missing something please correct me
yacovm (Sun, 07 May 2017 18:22:07 GMT):
I am worried though - fixing a problem with regard to the "default policy" is closing the hole in a leaking pipe, but how do we know that we don't have other problems around the corner?
That's why I was trying to think - what principal can be adopted so we will not run into such problems.
Users define instantiation policies themselves, right?
Isn't it a problem with regard to what I said a few comments before? Shouldn't we be able to restrict the expressions they can have in order for them not to make the channel reach a diverged state?
- Again, if I'm missing something please correct me
yacovm (Sun, 07 May 2017 18:22:07 GMT):
I am worried though - fixing a problem with regard to the "default policy" is closing the hole in a leaking pipe, but how do we know that we don't have other problems around the corner?
That's why I was trying to think - what principal can be adopted so we will not run into such problems.
Users can define any instantiation policies themselves, right?
Isn't it a problem with regard to what I said a few comments before? Shouldn't we be able to restrict the expressions they can have in order for them not to make the channel reach a diverged state?
- Again, if I'm missing something please correct me
muralisr (Sun, 07 May 2017 18:36:57 GMT):
` in order for them not to make the channel reach a diverged state?` - how can they do that ?
muralisr (Sun, 07 May 2017 18:37:50 GMT):
as in non-deterministic ledger ?
yacovm (Sun, 07 May 2017 18:45:36 GMT):
So maybe my understanding is lacking
yacovm (Sun, 07 May 2017 18:45:36 GMT):
So maybe my understanding is lacking, @muralisr
yacovm (Sun, 07 May 2017 18:45:55 GMT):
but you define an instantiation policy with installation of a chaincode right?
yacovm (Sun, 07 May 2017 18:46:22 GMT):
But you can install the chaincode on peers from different orgs with different instantiation polices, can you not?
yacovm (Sun, 07 May 2017 19:08:13 GMT):
Ah- so what I was missing is that the validation of the instantiation is via the endorsement policy, not the instantiation policy.
yacovm (Sun, 07 May 2017 19:08:13 GMT):
@muralisr when a peer receives an `instantiate` update from a block - it uses the endorsement policy to validate it? or the instantiation policy?
yacovm (Sun, 07 May 2017 19:08:13 GMT):
@muralisr when a peer receives an `instantiate` update from a block - it uses the endorsement policy to validate it? or the instantiation policy? (I guess they do `ValidateLSCCInvocation` ? )
yacovm (Sun, 07 May 2017 19:13:55 GMT):
@muralisr when a peer receives an `instantiate` update from a block - it uses the endorsement policy to validate it? or the instantiation policy? (I guess they do `ValidateLSCCInvocation` ? )
mastersingh24 (Sun, 07 May 2017 20:16:57 GMT):
I am again confused. I thought that "instantiation policy" was supposed to be analogous to "endorsement policy". Here's what I mean:
For user chaincode, the endorsement policy is "attached" at instantiate time and then at validate / commit time the each transaction is evaluated against the endorsement policy
But chaincode lifecylce actions (e.g. instantiate) are invoked against lifecycle system chaincode and therefore this would mean that you'd have to have endorsement policies attached to LCCC which is a checking and egg problem.
So I thought that the policy which is attached to chaincode at install time would effectively be evaluated like endorsement policy during the commit of the lifecycle chaincode instantiate function / transaction.
Now we also said that you don't need to specify an instantiation policy in order to make things more consumable and definitely more friendly at development time. So I guess that's where the default instantiation policy comes in.
I think we all agree that a the simplest policy would be to require a signature from a single organization which belongs to the channel in which the chaincode is being instantiated.
So for this, as I see it, we would have two options: Any member or any admin
mastersingh24 (Sun, 07 May 2017 20:16:57 GMT):
I am again confused. I thought that "instantiation policy" was supposed to be analogous to "endorsement policy". Here's what I mean:
For user chaincode, the endorsement policy is "attached" at instantiate time and then at validate / commit time the each transaction is evaluated against the endorsement policy
But chaincode lifecylce actions (e.g. instantiate) are invoked against lifecycle system chaincode and therefore this would mean that you'd have to have endorsement policies attached to LCCC which is a checking and egg problem.
So I thought that the policy which is attached to chaincode at install time would effectively be evaluated like endorsement policy during the commit of the lifecycle chaincode instantiate function / transaction.
Now we also said that you don't need to specify an instantiation policy in order to make things more consumable and definitely more friendly at development time. So I guess that's where the default instantiation policy comes in.
I think we all agree that a the simplest policy would be to require a signature from a single organization which belongs to the channel in which the chaincode is being instantiated.
yacovm (Sun, 07 May 2017 20:33:05 GMT):
> So I thought that the policy which is attached to chaincode at install time would effectively be evaluated like endorsement policy during the commit of the lifecycle chaincode instantiate function / transaction.
That is what happens as far as I know
yacovm (Sun, 07 May 2017 20:33:05 GMT):
> So I thought that the policy which is attached to chaincode at install time would effectively be evaluated like endorsement policy during the commit of the lifecycle chaincode instantiate function / transaction.
That is what happens as far as I know
> I think we all agree that a the simplest policy would be to require a signature from a single organization which belongs to the channel in which the chaincode is being instantiated.
+1
jimthematrix (Sun, 07 May 2017 20:46:32 GMT):
@mastersingh24 good question, and that got me confused now ;-) I had thought the instantiation policy is simply for access control, not as the policy to check by the validators like the endorsement policies
jimthematrix (Sun, 07 May 2017 20:46:53 GMT):
@muralisr @elli-androulaki @binhn can we get clarification on this point?
jimthematrix (Sun, 07 May 2017 20:47:26 GMT):
i'm pretty sure based on how I read the code it's meant to be an ACL policy
jimthematrix (Sun, 07 May 2017 20:47:58 GMT):
that's why I was suggestion SignedByAnyAdmin instead of SignedByAnyMember being the default
jimthematrix (Sun, 07 May 2017 20:47:58 GMT):
that's why I was suggesting SignedByAnyAdmin instead of SignedByAnyMember being the default
mastersingh24 (Sun, 07 May 2017 20:56:32 GMT):
Yeah - I am confusing myself as well here :(
yacovm (Sun, 07 May 2017 20:59:25 GMT):
Does anyone know what happens if you have 2 peers in different orgs and with different instantiation policies passed in install time?
mastersingh24 (Sun, 07 May 2017 21:02:04 GMT):
The eventual instantiation would fail because lccc actually checks a hash of the signed chaincode package which includes the instantiation policy
muralisr (Sun, 07 May 2017 21:04:44 GMT):
sorry... just got back and see all the above. let me pick what I think are main questions and try to respond ?
muralisr (Sun, 07 May 2017 21:05:21 GMT):
@mastersingh24 @jimthematrix `So I thought that the policy which is attached to chaincode at install time would effectively be evaluated like endorsement policy during the commit of the lifecycle chaincode instantiate function / transaction.`
yacovm (Sun, 07 May 2017 21:05:43 GMT):
Hmm what do you mean eventual instantiation @mastersingh24 ? Isn't the "eventual" done in the VSCC?
jimthematrix (Sun, 07 May 2017 21:05:52 GMT):
... that only or for other purposes as well like ACL?
mastersingh24 (Sun, 07 May 2017 21:06:00 GMT):
Let's take 10 steps back
jimthematrix (Sun, 07 May 2017 21:06:06 GMT):
i think the code points to using the same policy for both
yacovm (Sun, 07 May 2017 21:06:11 GMT):
I have this https://jira.hyperledger.org/browse/FAB-2859
yacovm (Sun, 07 May 2017 21:06:11 GMT):
I have this https://jira.hyperledger.org/browse/FAB-2859 *Chaincode Install Packaging with Security enablement*
mastersingh24 (Sun, 07 May 2017 21:06:14 GMT):
@muralisr - let me try to ask some basic questions in order
muralisr (Sun, 07 May 2017 21:06:24 GMT):
ok
mastersingh24 (Sun, 07 May 2017 21:07:05 GMT):
Let's forget about policies altogether for a moment ...... since at least I think I confused myself ;)
mastersingh24 (Sun, 07 May 2017 21:08:19 GMT):
1) Instantiate - A client sends a proposal to a peer targeting LCCC on a channel and calling the instantiate function
mastersingh24 (Sun, 07 May 2017 21:08:23 GMT):
Is that correct?
muralisr (Sun, 07 May 2017 21:08:33 GMT):
yes
mastersingh24 (Sun, 07 May 2017 21:09:33 GMT):
2) Assuming the peer was able to find the package, things checked out, etc, the peer will respond back with a signed proposal response?
muralisr (Sun, 07 May 2017 21:09:44 GMT):
yes
mastersingh24 (Sun, 07 May 2017 21:10:16 GMT):
3) The proposal response actually contains a RWSet which updates the LCCC "state"? (could be wrong here)
muralisr (Sun, 07 May 2017 21:10:30 GMT):
absoluteluy correct
muralisr (Sun, 07 May 2017 21:10:57 GMT):
contains both LSCC and the actual chaincodes (from calling the Init method) RW States
yacovm (Sun, 07 May 2017 21:12:01 GMT):
Is the instantiation policy serialized to (3) @muralisr ?
yacovm (Sun, 07 May 2017 21:12:01 GMT):
Is the instantiation policy serialized into (3) @muralisr ?
yacovm (Sun, 07 May 2017 21:12:01 GMT):
Is the instantiation policy also serialized into (3) @muralisr ?
mastersingh24 (Sun, 07 May 2017 21:12:19 GMT):
4) Client gets back the proposal response, packs it up in a transaction, signs it and sends to the ordering service
5) Here's where I think I get confused - committing peers on the channel now get a block which contains the LCCC instantiate transaction .....
muralisr (Sun, 07 May 2017 21:12:33 GMT):
(hang on on that please @yacovm ... that's part of the key thing will get to that)
muralisr (Sun, 07 May 2017 21:12:40 GMT):
4) yes
muralisr (Sun, 07 May 2017 21:13:34 GMT):
5) that's quite correct @mastersingh24 ..not sure what the confusion is ?
mastersingh24 (Sun, 07 May 2017 21:14:14 GMT):
So normally at this point, the peer will run the validation, endorsement check and commit logic
muralisr (Sun, 07 May 2017 21:14:24 GMT):
right...
mastersingh24 (Sun, 07 May 2017 21:14:47 GMT):
so what's the actual endorsement policy for LCCC?
muralisr (Sun, 07 May 2017 21:14:56 GMT):
right
mastersingh24 (Sun, 07 May 2017 21:15:39 GMT):
Is it just a single endorsement from any member of the channel?
muralisr (Sun, 07 May 2017 21:16:15 GMT):
right
muralisr (Sun, 07 May 2017 21:16:39 GMT):
hich is different from the "instantiation policy" we have been talking about
mastersingh24 (Sun, 07 May 2017 21:16:52 GMT):
right
muralisr (Sun, 07 May 2017 21:17:54 GMT):
the only thing I'll add to that list is this... the *install* package should ideally contain the "instanttiaion policy" specified by the user as to who can do the *instantiation*
muralisr (Sun, 07 May 2017 21:18:57 GMT):
and this is checked by LSCC on the endorsement side when a proposal is recieved
muralisr (Sun, 07 May 2017 21:19:07 GMT):
the big elephant in the room is this
mastersingh24 (Sun, 07 May 2017 21:19:33 GMT):
so at the end of the day, you still only need a single endorsement to instantiate chaincode
muralisr (Sun, 07 May 2017 21:19:41 GMT):
right
mastersingh24 (Sun, 07 May 2017 21:20:23 GMT):
but peers should only endorse if the proposal is in line with the instantiation policy embedded in the package at time of deploy
muralisr (Sun, 07 May 2017 21:21:02 GMT):
right..basically if lscc OK's the instantiation
muralisr (Sun, 07 May 2017 21:21:29 GMT):
let me get to the elephant :-)
mastersingh24 (Sun, 07 May 2017 21:21:35 GMT):
But - then does that mean that instantiation policies can really only be one of the form "one of ..."
mastersingh24 (Sun, 07 May 2017 21:21:41 GMT):
OK
jimthematrix (Sun, 07 May 2017 21:22:29 GMT):
i'm hearing the elephant stumping now ;-)
muralisr (Sun, 07 May 2017 21:22:35 GMT):
:-)
muralisr (Sun, 07 May 2017 21:22:51 GMT):
but let me answer the above question first - very relevant
muralisr (Sun, 07 May 2017 21:25:21 GMT):
since we are basing the evaliation on the prposal, yes, the policy has to be something like "does this proposal creator satisfy the policy in the install package for instantiating this CC ?"
muralisr (Sun, 07 May 2017 21:25:42 GMT):
not "do we have n signatures for instantiating this CC"
muralisr (Sun, 07 May 2017 21:26:07 GMT):
did I understand / answer appr. @mastersingh24 ?
mastersingh24 (Sun, 07 May 2017 21:26:36 GMT):
yep
muralisr (Sun, 07 May 2017 21:26:54 GMT):
ok. ...now for the elephant :-)
muralisr (Sun, 07 May 2017 21:27:44 GMT):
all the current problems are because we don't have the user defined policy - which is in SignedCDSPackage - as we are using CDSPackage which does not have a "policy"...
muralisr (Sun, 07 May 2017 21:27:47 GMT):
```message SignedChaincodeDeploymentSpec {
// This is the bytes of the ChaincodeDeploymentSpec
bytes chaincode_deployment_spec = 1;
// This is the instantiation policy which is identical in structure
// to endorsement policy. This policy is checked by the VSCC at commit
// time on the instantiation (all peers will get the same policy as it
// will be part of the LSCC instantation record and will be part of the
// hash as well)
bytes instantiation_policy = 2;
// The endorsements of the above deployment spec, the owner's signature over
// chaincode_deployment_spec and Endorsement.endorser.
repeated Endorsement owner_endorsements = 3;
}```
muralisr (Sun, 07 May 2017 21:28:04 GMT):
ignoring `owner_endorsements` which is not required
muralisr (Sun, 07 May 2017 21:28:36 GMT):
if we use SignedChaincodeDeploymentSpec, we can set `instantiation_policy` and we won
muralisr (Sun, 07 May 2017 21:28:36 GMT):
if we use SignedChaincodeDeploymentSpec, we can set `instantiation_policy` and we won't get into the "default policy" path
yacovm (Sun, 07 May 2017 21:29:03 GMT):
Can you explain please what is going on here?
https://github.com/hyperledger/fabric/blob/master/core/scc/vscc/validator_onevalidsignature.go#L343-L351
mastersingh24 (Sun, 07 May 2017 21:29:35 GMT):
```
// This is the instantiation policy which is identical in structure
// to endorsement policy. This policy is checked by the VSCC at commit
// time on the instantiation (all peers will get the same policy as it
// will be part of the LSCC instantation record and will be part of the
// hash as well)
```
mastersingh24 (Sun, 07 May 2017 21:29:41 GMT):
That's not correct though
muralisr (Sun, 07 May 2017 21:29:52 GMT):
sorry
muralisr (Sun, 07 May 2017 21:29:53 GMT):
right
muralisr (Sun, 07 May 2017 21:29:56 GMT):
that's not correct
muralisr (Sun, 07 May 2017 21:30:01 GMT):
need to change that
mastersingh24 (Sun, 07 May 2017 21:30:06 GMT):
instantiation policy seems to only be checked during invoke
himansri (Sun, 07 May 2017 21:30:16 GMT):
Has joined the channel.
muralisr (Sun, 07 May 2017 21:30:24 GMT):
invoke on the LSCC
mastersingh24 (Sun, 07 May 2017 21:30:25 GMT):
OK
muralisr (Sun, 07 May 2017 21:31:04 GMT):
the reason why we are using CDSPackage is so we can continue to send raw ChaincodeDeploymentSpect for installing
mastersingh24 (Sun, 07 May 2017 21:31:14 GMT):
right
mastersingh24 (Sun, 07 May 2017 21:31:39 GMT):
and I would think that we only care about instantiate policy if using the secure cds
muralisr (Sun, 07 May 2017 21:31:55 GMT):
my suggestion - move to SiignedCDSPackage, just specify a reasonable default instantiation policy so we don't have to rely so heavily on default policy
muralisr (Sun, 07 May 2017 21:32:08 GMT):
in fact we can nuke that path and error out
muralisr (Sun, 07 May 2017 21:33:40 GMT):
yea.. the idea was the "SignedChaincodeDeploymentSpec" is the future with the policy (and the "owner endorsements" if we care)
muralisr (Sun, 07 May 2017 21:34:18 GMT):
`in fact we can nuke that path and error out` - I mean not even have an artificial "default policy" in the LSCC
jimthematrix (Sun, 07 May 2017 21:35:30 GMT):
let's not introduce another big change like this at this point unless it's absolutely necessary
mastersingh24 (Sun, 07 May 2017 21:35:36 GMT):
Agree
muralisr (Sun, 07 May 2017 21:35:43 GMT):
it shouldn't be a big change
jimthematrix (Sun, 07 May 2017 21:35:43 GMT):
i still think this could work out with CDSPackage
jimthematrix (Sun, 07 May 2017 21:36:05 GMT):
well, it is if you consider all the other components like SDKs
muralisr (Sun, 07 May 2017 21:36:13 GMT):
insteadn of sending ChaincodeDeploymentSpec, you'd send SignedChaincodeDeploymentSpec
mastersingh24 (Sun, 07 May 2017 21:36:19 GMT):
yeah - we can't change this right now
mastersingh24 (Sun, 07 May 2017 21:36:30 GMT):
WELL - hang on
mastersingh24 (Sun, 07 May 2017 21:36:54 GMT):
So what is the problem? We are currently sending CDSPackage and it's no longer working?
muralisr (Sun, 07 May 2017 21:37:28 GMT):
nope... we are currently sending ChaincodeDeploymentSpec (which is what we have always been sending)
jimthematrix (Sun, 07 May 2017 21:37:35 GMT):
so what's wrong with each peer building the default policy exactly the same way for a CDSPackage?
jimthematrix (Sun, 07 May 2017 21:37:57 GMT):
if we use something you included in your fix
mastersingh24 (Sun, 07 May 2017 21:38:00 GMT):
I guess what broke?
mastersingh24 (Sun, 07 May 2017 21:38:28 GMT):
I thought policy would only apply to SignedCDSPackage
jimthematrix (Sun, 07 May 2017 21:38:33 GMT):
all peers would arrive at exactly the same default policy, so 1) no API changes needed and 2) determinism is preserved
mastersingh24 (Sun, 07 May 2017 21:39:03 GMT):
I am confused
jimthematrix (Sun, 07 May 2017 21:39:09 GMT):
```func (lscc *LifeCycleSysCC) getInstantiationPolicy(channel string, ccpack ccprovider.CCPackage) ([]byte, error) {
var ip []byte
// if ccpack is a SignedCDSPackage, return its IP, otherwise use a default IP
sccpack, isSccpack := ccpack.(*ccprovider.SignedCDSPackage)
if isSccpack {
logger.Info("Found signed CDSPackage")
ip = sccpack.GetInstantiationPolicy()
if ip == nil {
return nil, fmt.Errorf("Instantiation policy cannot be null for a SignedCCDeploymentSpec")
}
} else {
// the default instantiation policy requires any of the peer's msp admin
mspids := lscc.getChannelMSPIDs(channel)
logger.Infof("Found MSPIDs for channel %s: %s", channel, mspids)
//NOTE this uses MarshalOrPanic which needs to be modified to return err
ip = cauthdsl.SignedByAnyAdmin(mspids)
}
return ip, nil
}
jimthematrix (Sun, 07 May 2017 21:39:25 GMT):
@mastersingh24 a policy is needed for either
muralisr (Sun, 07 May 2017 21:39:26 GMT):
give me few mins, @jimthematrix :-)
mastersingh24 (Sun, 07 May 2017 21:39:37 GMT):
yes
jimthematrix (Sun, 07 May 2017 21:39:45 GMT):
just that when it's not Signed CDS then it's calculated
mastersingh24 (Sun, 07 May 2017 21:39:53 GMT):
But you only need to ever send to 1 peer
mastersingh24 (Sun, 07 May 2017 21:40:02 GMT):
what is this about multiple peers?
mastersingh24 (Sun, 07 May 2017 21:40:27 GMT):
also - all peers in a channel should have the MSPs for all other peer orgs including their admins
muralisr (Sun, 07 May 2017 21:40:29 GMT):
so @mastersingh24 the above is with the fix in progress
mastersingh24 (Sun, 07 May 2017 21:40:50 GMT):
And install already requires admin as well
muralisr (Sun, 07 May 2017 21:40:52 GMT):
the previous code was using local MSP admin (each peer would have its own local MSP Admin)
jimthematrix (Sun, 07 May 2017 21:41:21 GMT):
Oops i forgot to mention the above is after Murali's fix (had thought it was the original code)
muralisr (Sun, 07 May 2017 21:41:48 GMT):
so... here's the deal ..promise just a few more sentences
muralisr (Sun, 07 May 2017 21:42:43 GMT):
(1) we are not sending CDSPackage from SDK but sending ChaincodeDeploymentSpec (ie no change from pre-package days)
muralisr (Sun, 07 May 2017 21:43:02 GMT):
(2) so we don't have a instantiationPolicy in the install package
muralisr (Sun, 07 May 2017 21:43:51 GMT):
(3) so to make up for that a "default" instantiation policy was attahced (in the "else" part above ...)
muralisr (Sun, 07 May 2017 21:44:46 GMT):
we could go ahead and keep that same flow with the right default in the "else" .. or we can send SignedChaincodeDeploymentSpec with a policy
mastersingh24 (Sun, 07 May 2017 21:44:51 GMT):
OK - but I'm still missing something:
1) To install chaincode, you need to be part of the peer's localMSP admins, correct?
muralisr (Sun, 07 May 2017 21:45:01 GMT):
correct
muralisr (Sun, 07 May 2017 21:45:15 GMT):
well...sorry, let me check that
mastersingh24 (Sun, 07 May 2017 21:45:16 GMT):
So we have that identity in the SDK already to make that work
muralisr (Sun, 07 May 2017 21:45:22 GMT):
I know you need to be some admin...
muralisr (Sun, 07 May 2017 21:45:28 GMT):
assume that for now though
mastersingh24 (Sun, 07 May 2017 21:45:38 GMT):
So why not just sign the instantiate proposal with the same admin user?
mastersingh24 (Sun, 07 May 2017 21:45:41 GMT):
and we are done
mastersingh24 (Sun, 07 May 2017 21:46:14 GMT):
Instantiate only needs to be called on a single peer - so it can be your peer ;)
mastersingh24 (Sun, 07 May 2017 21:46:35 GMT):
;)
mastersingh24 (Sun, 07 May 2017 21:46:49 GMT):
of course I like the new code better - any admin
mastersingh24 (Sun, 07 May 2017 21:47:12 GMT):
I feel like I am being dense or missing something here
muralisr (Sun, 07 May 2017 21:48:52 GMT):
we could and maybe that's the right thing to do ... but in the general case (SignedChaincodeDeplouymentSpec) the instantiation policy is also maintained as part of the LSCC's data for the chaincode so VSCCs can do the same check
muralisr (Sun, 07 May 2017 21:49:13 GMT):
( @yacovm this is probably what you were asking about )
muralisr (Sun, 07 May 2017 21:50:12 GMT):
as all peers may not have chaincode installed, sending the policy for validation ensures everyone can validate it - even those that don't have the chaincode installed
yacovm (Sun, 07 May 2017 21:51:59 GMT):
Well this is precisely what I don't understand
yacovm (Sun, 07 May 2017 21:52:12 GMT):
```
pol := cdRWSet.InstantiationPolicy
if pol == nil {
return fmt.Errorf("No installation policy was specified")
}
// FIXME: could we actually pull the cds package from the
// file system to verify whether the policy that is specified
// here is the same as the one on disk?
// PROS: we prevent attacks where the policy is replaced
// CONS: this would be a point of non-determinism
err = vscc.checkInstantiationPolicy(chid, env, pol, payl)
```
yacovm (Sun, 07 May 2017 21:53:27 GMT):
This is the step where we take the *instantiation policy* from the block, right?
muralisr (Sun, 07 May 2017 21:54:14 GMT):
yes.. this is where peers that don't have the chaincode installed could also verify the instantiation using the policy in the TX
yacovm (Sun, 07 May 2017 21:54:41 GMT):
Great, but isn't it a problem?
muralisr (Sun, 07 May 2017 21:54:51 GMT):
why ?
yacovm (Sun, 07 May 2017 21:54:57 GMT):
It means that a single peer enforces its instantiation policy over all peers in the channel
yacovm (Sun, 07 May 2017 21:55:13 GMT):
even though instantiation policy is a thing that can have different inputs for different peers
yacovm (Sun, 07 May 2017 21:55:17 GMT):
(in diff. orgs)
muralisr (Sun, 07 May 2017 21:56:20 GMT):
hmmm as we talked (I think it was @mastersingh24 ... ) we are not talking about multiple orgs "signing off" on a instantiation with multiple singatures
muralisr (Sun, 07 May 2017 21:57:03 GMT):
in fact this is an additional sanity check for those peers that don't have chaincode installed but can still validate the same policy
yacovm (Sun, 07 May 2017 21:58:07 GMT):
> we are not talking about multiple orgs "signing off" on a instantiation with multiple singatures
I'm just saying- we can have different instantiation policies configured
yacovm (Sun, 07 May 2017 21:58:12 GMT):
but in the end, only 1 prevails
yacovm (Sun, 07 May 2017 21:58:23 GMT):
isn't that a bit.... bizzare?
muralisr (Sun, 07 May 2017 21:58:35 GMT):
in any case... with the original default policy created on the fly of " *MY* local MSP admin" (the code in the original "else" ) everyone will create their own little policy - and here's the problem @mastersingh24 - if we send the instantiation to > 1 peer we'll have different ProposalResponses... and SDK won't be happy. which is what @jeffgarratt ran into with BDD
muralisr (Sun, 07 May 2017 21:59:05 GMT):
if we say we HAVE to send instantiation to one peer only, then we don't have a problem
muralisr (Sun, 07 May 2017 21:59:15 GMT):
so
muralisr (Sun, 07 May 2017 22:00:05 GMT):
one simple solution... keep the code as is and as long as we send ChaincodeDeploymentSpec, tell users to send to 1 user only
muralisr (Sun, 07 May 2017 22:00:05 GMT):
one simple solution... keep the code as is and as long as we send ChaincodeDeploymentSpec, tell users to send to 1 endorser only
muralisr (Sun, 07 May 2017 22:00:58 GMT):
when we get to specify our own policy with SDK sending SignedChaincodeDeploymentSpec, we can just remove the "else" code and error if there's no policy specified
muralisr (Sun, 07 May 2017 22:01:09 GMT):
or
jimthematrix (Sun, 07 May 2017 22:01:45 GMT):
@mastersingh24 i think we should bring in Murali's fix to create a SignedByAnyAdmin default policy
mastersingh24 (Sun, 07 May 2017 22:01:59 GMT):
yes - it needs to be that
jimthematrix (Sun, 07 May 2017 22:02:08 GMT):
this allows the instantiate proposal call to be sent to all peers in the channle
jimthematrix (Sun, 07 May 2017 22:02:14 GMT):
just like any other transactions
mastersingh24 (Sun, 07 May 2017 22:02:21 GMT):
that matches the current design
jimthematrix (Sun, 07 May 2017 22:02:27 GMT):
yes
muralisr (Sun, 07 May 2017 22:02:45 GMT):
or that
muralisr (Sun, 07 May 2017 22:03:10 GMT):
so today SDK sends instantiate proposal to multiple endorsers ?
jimthematrix (Sun, 07 May 2017 22:03:30 GMT):
yes
jimthematrix (Sun, 07 May 2017 22:03:42 GMT):
because it's a channel-aware transaction
jimthematrix (Sun, 07 May 2017 22:04:01 GMT):
we'd like to emulate an app that gives all peers a chance to endorse that
muralisr (Sun, 07 May 2017 22:04:09 GMT):
ok
mastersingh24 (Sun, 07 May 2017 22:04:22 GMT):
But - even if you just sent it to one, it would still fail today during vscc
jimthematrix (Sun, 07 May 2017 22:04:37 GMT):
right
mastersingh24 (Sun, 07 May 2017 22:04:55 GMT):
so that's the real need for any admin
jimthematrix (Sun, 07 May 2017 22:04:58 GMT):
all other peers vscc except for the own orgs will mark it invalid
jimthematrix (Sun, 07 May 2017 22:05:17 GMT):
ok
muralisr (Sun, 07 May 2017 22:05:29 GMT):
wait... are we talking about the above code that @jimthematrix pasted ?
muralisr (Sun, 07 May 2017 22:05:36 GMT):
that should go through...
muralisr (Sun, 07 May 2017 22:05:40 GMT):
I think
jimthematrix (Sun, 07 May 2017 22:05:52 GMT):
it does, i've tested it
mastersingh24 (Sun, 07 May 2017 22:06:09 GMT):
ip = cauthdsl.SignedByAnyAdmin(mspids)
jimthematrix (Sun, 07 May 2017 22:06:11 GMT):
but Gari is say something different
muralisr (Sun, 07 May 2017 22:06:18 GMT):
`even if you just sent it to one, it would still fail today during vscc` - so I don't get that...
mastersingh24 (Sun, 07 May 2017 22:06:20 GMT):
no - that's what I'm saying
mastersingh24 (Sun, 07 May 2017 22:06:29 GMT):
without your change
muralisr (Sun, 07 May 2017 22:06:34 GMT):
ah
jimthematrix (Sun, 07 May 2017 22:06:36 GMT):
right
mastersingh24 (Sun, 07 May 2017 22:06:58 GMT):
I don't care about multiple endorsements - but validation can't fail
mastersingh24 (Sun, 07 May 2017 22:07:43 GMT):
Even of we don't agree with the current design, I think the change above is valid as it is what should have been there
jimthematrix (Sun, 07 May 2017 22:07:57 GMT):
agree
muralisr (Sun, 07 May 2017 22:08:20 GMT):
would also note this... with the policy in the installed package, one policy will apply across all channels.
muralisr (Sun, 07 May 2017 22:08:37 GMT):
with the "default" as above, we make one for each channel
muralisr (Sun, 07 May 2017 22:08:59 GMT):
as a point in time "default" statement this may be ok...but calling it out
muralisr (Sun, 07 May 2017 22:09:53 GMT):
(I don't think we have a choice ... )
jimthematrix (Sun, 07 May 2017 22:09:56 GMT):
well, i think just like any other transactions, you don't have to specify an endorsement policy
jimthematrix (Sun, 07 May 2017 22:10:12 GMT):
LSCC should also in the same way have a default endorsement policy
muralisr (Sun, 07 May 2017 22:10:13 GMT):
the difference is in the scope
muralisr (Sun, 07 May 2017 22:10:28 GMT):
policy per channel vs across channels
jimthematrix (Sun, 07 May 2017 22:10:59 GMT):
the LSCC's default channel is also cross channels
jimthematrix (Sun, 07 May 2017 22:11:08 GMT):
it just needs to be expressed in a channel-specific way
jimthematrix (Sun, 07 May 2017 22:11:44 GMT):
default policy = "any admin of the channel"
muralisr (Sun, 07 May 2017 22:13:18 GMT):
the intent is to use install package dicatate policy across channels. ..so one may not even be allowed to install a chaincode on a channel
muralisr (Sun, 07 May 2017 22:14:06 GMT):
but if we make a default policy we change that intent from "can you instantiation on this channel" to "only admins of this channel can instantiate"
muralisr (Sun, 07 May 2017 22:15:39 GMT):
that's ok as a "default" policy ..perhaps just evolve as we move to using user specified policy
jimthematrix (Sun, 07 May 2017 22:17:06 GMT):
i think that's ok as default, if more control is needed like disallowing instantiates, then use a custom policy in the package. which by the way none of the SDKs support
jimthematrix (Sun, 07 May 2017 22:17:06 GMT):
i think that's ok as default, if more control is needed like disallowing instantiates, then use a custom policy in the package. but note that none of the SDKs support this
muralisr (Sun, 07 May 2017 22:18:25 GMT):
so I'll continue getting the UTs to run and try to put out a CR as soon as I can (the hiccups to UTs across a few packages are the hold up)
jimthematrix (Sun, 07 May 2017 22:18:48 GMT):
thanks!
muralisr (Sun, 07 May 2017 22:19:17 GMT):
need to make mock MSPIDs available to keep the LSCC "else" happy
muralisr (Sun, 07 May 2017 22:19:21 GMT):
sure
muralisr (Sun, 07 May 2017 22:19:49 GMT):
first to hit the stores before they close :-)
jimthematrix (Sun, 07 May 2017 22:20:04 GMT):
go for it
jimthematrix (Sun, 07 May 2017 22:20:07 GMT):
;-)
rickr (Mon, 08 May 2017 01:56:23 GMT):
So have you guys taught the elephant to dance yet ?
muralisr (Mon, 08 May 2017 11:30:40 GMT):
https://gerrit.hyperledger.org/r/#/c/9073 - looks like it did :-)
elli-androulaki (Mon, 08 May 2017 16:36:25 GMT):
Hi everyone, your feedback here would be very helpful ! https://jira.hyperledger.org/browse/FAB-3678
elli-androulaki (Mon, 08 May 2017 16:37:15 GMT):
@binhn, @yacovm, @adc, @aso ,@muralisr, @mastersingh24 , @jimthematrix
elli-androulaki (Mon, 08 May 2017 16:37:15 GMT):
@binhn, @yacovm, @adc, @aso ,@muralisr , @mastersingh24 , @jimthematrix , @JonathanLevi
elli-androulaki (Mon, 08 May 2017 17:31:16 GMT):
@muralisr
jpatchell (Mon, 08 May 2017 20:39:01 GMT):
Has joined the channel.
amber-zhang (Tue, 09 May 2017 00:55:03 GMT):
Has joined the channel.
bmkor (Tue, 09 May 2017 01:47:58 GMT):
Has joined the channel.
greg.haskins (Tue, 09 May 2017 01:55:12 GMT):
Has joined the channel.
Ying (Tue, 09 May 2017 04:34:47 GMT):
Has joined the channel.
mutexing (Tue, 09 May 2017 04:36:36 GMT):
Has joined the channel.
tom.appleyard (Tue, 09 May 2017 10:50:27 GMT):
Can someone explain to me how cryptogen is working? - basically how does it make certificates that the MSP can use?
yacovm (Tue, 09 May 2017 10:56:05 GMT):
I guess it just randomly generates a private-public key pairs for CA, peers, orderes, signs the certs of the orderers and peers with the private key of the CA
yacovm (Tue, 09 May 2017 10:56:05 GMT):
I guess it just randomly generates private-public key pairs for CA, peers, orderes, signs the certs of the orderers and peers with the private key of the CA
yacovm (Tue, 09 May 2017 10:56:36 GMT):
the MSP uses just normal x509 certifiactes
yacovm (Tue, 09 May 2017 11:33:56 GMT):
@tom.appleyard ^
tom.appleyard (Tue, 09 May 2017 11:36:07 GMT):
ok cool - so I'm not seeing an MSP or CA docker container when I fire up the network
tom.appleyard (Tue, 09 May 2017 11:36:10 GMT):
where is all of this handled?
yacovm (Tue, 09 May 2017 11:37:46 GMT):
you don't need the CA to be alive
yacovm (Tue, 09 May 2017 11:38:22 GMT):
w.r.t the MSP - it's a logical entity that is constructed from all the PEM material + the MSP-ID (in the `core.yaml` )
tom.appleyard (Tue, 09 May 2017 12:11:04 GMT):
I see - sorry, could you explain to me exactly what an MSP is in this context and how it relates to a CA?
tom.appleyard (Tue, 09 May 2017 12:11:43 GMT):
I'm launching my network by using some docker images so I don't know what is in core.yaml
yacovm (Tue, 09 May 2017 12:25:08 GMT):
ah so there is an excellent document on that actually
yacovm (Tue, 09 May 2017 12:25:31 GMT):
https://github.com/hyperledger/fabric/blob/master/docs/source/msp.rst
yacovm (Tue, 09 May 2017 12:25:36 GMT):
Enjoy the read
ashutosh_kumar (Tue, 09 May 2017 14:32:41 GMT):
I have one question on the doc : Should not the CRL be read from cert itself instead of having the CRL folder ? How the content of CRL folder be synched with the CRL ?
yacovm (Tue, 09 May 2017 14:40:51 GMT):
> Should not the CRL be read from cert itself instead of having the CRL folder ?
How can a cert have a CRL though? I don't think the x509.Certificate supports this
> How the content of CRL folder be synched with the CRL ?
so from my (limited understanding) the CRLs contains SNs and when the MSP checks if an identity is valid it looks for the CRL that matches the right CA of the identity and that the CRL contains a SN for the identity's certificate.
yacovm (Tue, 09 May 2017 14:40:51 GMT):
> Should not the CRL be read from cert itself instead of having the CRL folder ?
How can a cert have a CRL though? I don't think the x509.Certificate supports this
> How the content of CRL folder be synched with the CRL ?
so from my (limited) understanding the CRLs contains SNs and when the MSP checks if an identity is valid it looks for the CRL that matches the right CA of the identity and that the CRL contains a SN for the identity's certificate.
ashutosh_kumar (Tue, 09 May 2017 14:44:01 GMT):
If you look at gloang X509 cert structure https://golang.org/pkg/crypto/x509/#Certificate , you'll see 3 fields : CRLDistributionPoints and OCSPServer []string
IssuingCertificateURL []string
ashutosh_kumar (Tue, 09 May 2017 14:44:30 GMT):
So , x509 cert contains CRL info.
ashutosh_kumar (Tue, 09 May 2017 14:45:39 GMT):
your second statement seems correct. MSP should check for CRL in OCSP server.
yacovm (Tue, 09 May 2017 14:51:34 GMT):
ah you're saying the MSP can contact the CA to obtain the CRLs at runtime?
yacovm (Tue, 09 May 2017 14:51:34 GMT):
ah you're saying the MSP should contact the CA to obtain the CRLs at runtime?
ashutosh_kumar (Tue, 09 May 2017 14:52:09 GMT):
yup.
ashutosh_kumar (Tue, 09 May 2017 14:52:17 GMT):
ocsp server.
yacovm (Tue, 09 May 2017 14:52:19 GMT):
I don't think it's a good idea.
ashutosh_kumar (Tue, 09 May 2017 14:52:40 GMT):
it is not CA , it is OCSP server.
yacovm (Tue, 09 May 2017 14:53:05 GMT):
well we an OCSP server as part of the fabric distribution and also that's in the critical path (validation)
yacovm (Tue, 09 May 2017 14:53:05 GMT):
well we don't have an OCSP server as part of the fabric distribution and also that's in the critical path (validation)
yacovm (Tue, 09 May 2017 14:53:54 GMT):
Anyway I was only trying to answer questions, not to argue on what we should or should not do
ashutosh_kumar (Tue, 09 May 2017 14:53:56 GMT):
you have to contact OCSP regardless for synching purposes
ashutosh_kumar (Tue, 09 May 2017 14:54:07 GMT):
ok.
ashutosh_kumar (Tue, 09 May 2017 14:54:32 GMT):
the doc is good. Thanks for pointing out.
yacovm (Tue, 09 May 2017 14:57:20 GMT):
sure thing!
jojialex2 (Wed, 10 May 2017 03:57:20 GMT):
Has joined the channel.
joshuajeeson (Wed, 10 May 2017 14:16:12 GMT):
I am going through the pkcs11_test.go and it says cannot find package : github.com/stretchr/testify/assert
jtrayfield (Wed, 10 May 2017 18:28:33 GMT):
Has joined the channel.
jtrayfield (Wed, 10 May 2017 18:41:22 GMT):
I am trying to create my own certificates, but I get this error when the orderer starts up:
2017-05-09 17:49:32.961 UTC [msp] getSigningIdentityFromConf -> DEBU 013 Could not find SKI [95365419d849c389bae6e6519a1ad1358c9cc5415fe2f988d6d940821c692c0d], trying KeyMaterial field: Key type not recognized
jtrayfield (Wed, 10 May 2017 18:42:03 GMT):
I read https://github.com/hyperledger/fabric/blob/master/docs/source/msp.rst but couldn't find anything that helped
yacovm (Wed, 10 May 2017 19:09:50 GMT):
@jtrayfield how are you creating them?
yacovm (Wed, 10 May 2017 19:09:52 GMT):
`openssl`?
jtrayfield (Wed, 10 May 2017 19:10:06 GMT):
yes, openssl
yacovm (Wed, 10 May 2017 19:10:16 GMT):
use cryptogen
jtrayfield (Wed, 10 May 2017 19:14:44 GMT):
fabric/common/tools/cryptogen ?
yacovm (Wed, 10 May 2017 19:16:07 GMT):
indeed
jtrayfield (Wed, 10 May 2017 19:16:50 GMT):
I'll give it a try, thanks
ashutosh_kumar (Wed, 10 May 2017 19:37:09 GMT):
alternatively , you can use cfssl.
jtrayfield (Wed, 10 May 2017 20:15:53 GMT):
@yacovm ok, the problem is that they key generated by "openssl ecparam -genkey -name secp256r1 > keyfile" has an extra header on it:
-----BEGIN EC PARAMETERS-----
BggqhkjOPQMBBw==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIKrVDCWVg7v4f2+2uNqZgHfACXOJCpTD1FUFL/vIUn8soAoGCCqGSM49
AwEHoUQDQgAElsv+o3/i3scyR8lHicR3DoMfH2l1RuXpoKS7+JfWBXTjKyuvdBYT
6nNtBNUBulLrtgIDK6xbdptZX4mnz6WEEQ==
-----END EC PRIVATE KEY-----
jtrayfield (Wed, 10 May 2017 20:16:24 GMT):
this removes the header:
openssl ec -in ../orderer0key.pem.bad -out orderer0key.pem
jtrayfield (Wed, 10 May 2017 20:19:43 GMT):
or you can remove it with emacs cause the PRIVATE KEY part looks the same as before
yacovm (Wed, 10 May 2017 20:21:01 GMT):
Interesting. I wonder maybe we should make it work? @adc @mastersingh24 what do you think?
yacovm (Wed, 10 May 2017 20:21:01 GMT):
Interesting. I wonder maybe we should make it work? @adc @mastersingh24 what do you think?
This remind me of https://gerrit.hyperledger.org/r/#/c/8349/3/bccsp/utils/keys.go
yacovm (Wed, 10 May 2017 20:21:01 GMT):
Interesting. I wonder what is the "right" thing to do - make such keys be supported or not? @adc @mastersingh24 what do you think?
This remind me of https://gerrit.hyperledger.org/r/#/c/8349/3/bccsp/utils/keys.go
ashutosh_kumar (Wed, 10 May 2017 21:48:21 GMT):
@jtrayfield : you can ignore EC Parameters.
ashutosh_kumar (Wed, 10 May 2017 21:48:43 GMT):
the key format seems right.
ashutosh_kumar (Wed, 10 May 2017 21:50:13 GMT):
@yacom , I do not see any problem either with openssl or bccsp/util/keys.go. openssl has more information.
ashutosh_kumar (Wed, 10 May 2017 21:50:13 GMT):
@yacovm , I do not see any problem either with openssl generated key or bccsp/util/keys.go. openssl generated key has more information.
yacovm (Wed, 10 May 2017 23:34:16 GMT):
But why didnt it work for him then?
ashutosh_kumar (Thu, 11 May 2017 01:55:02 GMT):
BEGIN EC Paramter and END EC Parameter section might be the reason.
ashutosh_kumar (Thu, 11 May 2017 01:55:22 GMT):
If you remove them , it should work.
ashutosh_kumar (Thu, 11 May 2017 01:56:17 GMT):
Again , this is implementation mismatch issue.
muralisr (Thu, 11 May 2017 12:11:03 GMT):
@jtrayfield did @ashutosh_kumar suggestion above work for you ?
FenglianXu (Thu, 11 May 2017 14:29:00 GMT):
Has joined the channel.
FenglianXu (Thu, 11 May 2017 14:31:06 GMT):
I am using peer query to run below a command from peer0 and I got below error. Can anyone help on this issue?
FenglianXu (Thu, 11 May 2017 14:32:59 GMT):
peer chaincode query -C mychannel -n vehicle-lifecycle-network -u admin -c '{"Args":["query","{\"selector\":{\"data.owner\":\"resource:org.acme.vehicle.lifecycle.PrivateOwner#dan\"}}"]}'
Error: Error endorsing query: rpc error: code = 2 desc = Error: Could not determine the participant for identity 'peerOrg1Peer1'. The identity may be invalid or may have been revoked.
Usage:
peer chaincode query [flags]
peer chaincode query -C mychannel -n vehicle-lifecycle-network -u admin -c '{"Args":["query","{\"selector\":{\"data.owner\":\"resource:org.acme.vehicle.lifecycle.PrivateOwner#dan\"}}"]}'
Error: Error endorsing query: rpc error: code = 2 desc = Error: Could not determine the participant for identity 'peerOrg1Peer1'. The identity may be invalid or may have been revoked.
Usage:
peer chaincode query [flags]
peer chaincode query -C mychannel -n vehicle-lifecycle-network -u admin -c '{"Args":["query","{\"selector\":{\"data.owner\":\"resource:org.acme.vehicle.lifecycle.PrivateOwner#dan\"}}"]}'
Error: Error endorsing query: rpc error: code = 2 desc = Error: Could not determine the participant for identity 'peerOrg1Peer1'. The identity may be invalid or may have been revoked.
Usage:
peer chaincode query [flags]
peer chaincode query -C mychannel -n vehicle-lifecycle-network -u admin -c '{"Args":["query","{\"selector\":{\"data.owner\":\"resource:org.acme.vehicle.lifecycle.PrivateOwner#dan\"}}"]}'
Error: Error endorsing query: rpc error: code = 2 desc = Error: Could not determine the participant for identity 'peerOrg1Peer1'. The identity may be invalid or may have been revoked.
Usage:
peer chaincode query [flags]
FenglianXu (Thu, 11 May 2017 14:33:38 GMT):
sorry to paste many repeat ones
FenglianXu (Thu, 11 May 2017 14:34:35 GMT):
I can run transaction and the data is already created in state couchDB
jtrayfield (Thu, 11 May 2017 14:40:26 GMT):
@muralisr yes removing the EC PARAMETERS section with emacs worked
muralisr (Thu, 11 May 2017 14:40:52 GMT):
Thanks @jtrayfield (thanks @ashutosh_kumar )
joshuajeeson (Thu, 11 May 2017 16:24:02 GMT):
The pkcs11_test is failing. Is anyone looking at that ? PS: Is anyone testing it with an actual HSM ?
joshuajeeson (Thu, 11 May 2017 16:24:02 GMT):
The pkcs11_test is failing. Is anyone looking at that ? PS: Is anyone working with an actual HSM ?
joshuajeeson (Thu, 11 May 2017 17:31:18 GMT):
How about using: Openssl req -new -out alice.csr -keyout alice.key -nodes -newkey ec:<(openssl ecparam -name secp384r1) –subj "/CN=Alice/O=Hyperledger org/OU=Dept /emailAddress=alice.gmail.com" [ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=eLgFjsExjfi3ovZxi)
ashutosh_kumar (Thu, 11 May 2017 17:39:55 GMT):
The key mismatch issue between openssl and golang will be there , I think.
ashutosh_kumar (Thu, 11 May 2017 17:40:15 GMT):
For that reason , I suggest to use cfssl.
dave.enyeart (Thu, 11 May 2017 19:36:53 GMT):
Re-posting question from @bkvellanki :
>Do we have a function in the shim to get the user attributes like similar to getUserAffiliates() in 0.6. The key reason for this is to restrict the user to perform only reads or writes based on the Role. Is see that we have them hfc sdk (getAffiliates, getSigningEntity, etc) and i think HFC fabric communicates with the Fabric CA to get the details. Is there any way to restrict the user in the chaincode to perforn only certian operations
jtrayfield (Thu, 11 May 2017 21:30:14 GMT):
what keys do the peers use to sign the proposal responses?
jtrayfield (Thu, 11 May 2017 21:31:43 GMT):
is it this key? - CORE_PEER_TLS_KEY_FILE=/var/hyperledger/peer/keystore/peer1Signer.pem
rmohta (Fri, 12 May 2017 04:56:51 GMT):
@here I had few questions related to configtx.yaml and crypto-config.yaml. 1. How do we define entries for a member and an admin in the config file for a given Organization? 2. When we define that role and that org has couple of peer - are those roles common to both the peer nodes?
chunhui (Fri, 12 May 2017 08:49:18 GMT):
Has joined the channel.
yacovm (Fri, 12 May 2017 08:52:45 GMT):
@rmohta what's crypto-config.yaml?
yacovm (Fri, 12 May 2017 08:52:51 GMT):
https://chat.hyperledger.org/channel/fabric?msg=mYwA6bJrFoYNqC6uJ
chunhui (Fri, 12 May 2017 08:53:33 GMT):
hi, hope someone can answer a quick question:
can a peer-org have multiple MSP definitions / point to multiple MSP?
yacovm (Fri, 12 May 2017 08:54:35 GMT):
> I am wondering why we don't leverage the existing metadata carrier we already have: x509
> e.g. Why do we need to supply mspid when we could utilize the Subject::Organization
@greg.haskins This question is more suitable to this channel than #fabric
I think it's because: (1) not every MSP may use x509 certificates, and (2) to make it more flexible
yacovm (Fri, 12 May 2017 08:54:35 GMT):
> I am wondering why we don't leverage the existing metadata carrier we already have: x509
> e.g. Why do we need to supply mspid when we could utilize the Subject::Organization
This question is more suitable to this channel than #fabric
I think it's because: (1) not every MSP may use x509 certificates, and (2) to make it more flexible
@greg.haskins
yacovm (Fri, 12 May 2017 08:54:35 GMT):
> I am wondering why we don't leverage the existing metadata carrier we already have: x509
> e.g. Why do we need to supply mspid when we could utilize the Subject::Organization
This question is more suitable to this channel than #fabric
I think it's because: (1) not every MSP may use x509 certificates, and (2) to make it more flexible
@greg.haskins
https://chat.hyperledger.org/channel/fabric?msg=mYwA6bJrFoYNqC6uJ
yacovm (Fri, 12 May 2017 08:55:53 GMT):
https://chat.hyperledger.org/channel/fabric-crypto?msg=9T8su4bSMfvcZ4DYc
So in general, an organization can have multiple MSPs, for example- they will be separated by the OU
yacovm (Fri, 12 May 2017 08:56:20 GMT):
@chunhui for further read: https://github.com/hyperledger/fabric/blob/master/docs/source/msp.rst
chunhui (Fri, 12 May 2017 09:07:04 GMT):
@yacovm we are thinking, if we implement an alternative fabric-ca implementation, can a single peer-organization(as defined in `configtx.yaml) be tied to more than 1 MSP implementations, possibly in a prioritized manner?
chunhui (Fri, 12 May 2017 09:07:38 GMT):
i'm wondering if this is already possible in current fabric v1, or it requires some re-working?
yacovm (Fri, 12 May 2017 09:08:24 GMT):
@elli-androulaki the stage is all yours ^
yacovm (Fri, 12 May 2017 09:08:24 GMT):
@elli-androulaki the stage is all yours :arrow_up:
elli-androulaki (Fri, 12 May 2017 09:17:19 GMT):
@chunhui what do you mean by multiple "MSP implementations"? Have multiple MSP per organisation is possible as long as the organisation is fine with the limitations described in /docs/source/msp.rst (which are considerable). Prioritisation across these MSPs is not supported.
If i understood your question / need though properly you may need to build your own MSP (different type of MSP that considers multiple sub-msps with some prioritisation among them), and a different object in place of FabricMSPConfig.
elli-androulaki (Fri, 12 May 2017 09:17:19 GMT):
@chunhui what do you mean by "multiple MSP implementations"? Have multiple MSP per organisation is possible as long as the organisation is fine with the limitations described in /docs/source/msp.rst (which are considerable). Prioritisation across these MSPs is not supported.
If i understood your question / need though properly you may need to build your own MSP (different type of MSP that considers multiple sub-msps with some prioritisation among them), and a different object in place of FabricMSPConfig.
tomconte (Fri, 12 May 2017 09:45:28 GMT):
Has joined the channel.
alesebi91 (Fri, 12 May 2017 13:48:21 GMT):
Has joined the channel.
alesebi91 (Fri, 12 May 2017 13:50:51 GMT):
Hi, what is the purpose of Users Count configuration in the PeerOrgs section inside crypto-config.yaml?
rmohta (Fri, 12 May 2017 18:16:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=KeQwevydDQxo924p4) @yacovm File that can help us generate private keys for test purpose. See github.com/hyperledger/fabric/examples/e2e_cli/crypto-config.yaml
rmohta (Fri, 12 May 2017 18:16:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=KeQwevydDQxo924p4) @yacovm File that can help us generate private keys and signed certs. Bascially what we'll need for localMSP and other for test purpose. See github.com/hyperledger/fabric/examples/e2e_cli/crypto-config.yaml
rmohta (Fri, 12 May 2017 18:18:05 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=GpZ7kobS7HRaKQJob) @alesebi91 How many users do you want to create - is basically asking how many SDK apps are you going to have for that org (MSP ID).
rmohta (Fri, 12 May 2017 18:18:05 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=GpZ7kobS7HRaKQJob) @alesebi91 How many users do you want to create - is basically asking how many SDK apps are you going to have for that org (MSP ID). And then, you can use that in your app and perform operation on your org's peer.
yacovm (Fri, 12 May 2017 18:18:06 GMT):
Is that simply the ouput of cryptogen when you print the template?
rmohta (Fri, 12 May 2017 18:19:57 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=SxkFd8zMMMuTsj6vF) @yacovm No. It generates private keys, folder structure to be configured in peer etc.
yacovm (Fri, 12 May 2017 18:20:50 GMT):
Yeah thats the goal but it can also print a tenplate to standard oytput
rmohta (Fri, 12 May 2017 18:24:24 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=qXErkgTimTGvQaZae) @yacovm Hmm, I'm confused. I thought we have two separate utilities. cryptogen and configtxgen. cryptogen generates all the cryptographic keys (for end to end test now) even today. Did I misunderstand the concept?
yacovm (Fri, 12 May 2017 18:25:56 GMT):
Yeah they are
yacovm (Fri, 12 May 2017 18:27:07 GMT):
But if you run cryptogen with "showtemplate"
michele (Fri, 12 May 2017 20:40:38 GMT):
Has joined the channel.
chunhui (Sat, 13 May 2017 02:01:50 GMT):
@elli-androulaki thanks for the answer :smile:
so having multiple MSP defined as their individual intermediatecerts is possible, as long as they are all PKI x509 based MSP,
and having multiple MSP implementation with prioritized sub-MSPs is something different.
chunhui (Sat, 13 May 2017 02:02:16 GMT):
right?
elli-androulaki (Sat, 13 May 2017 18:02:04 GMT):
@chunhui sure! So, I am not clear where you consider the MSP prioritisation for. In Fabric v1 we allow for instantiation of membership service providers that follow standard PKI certificate hierarchy. That is, each MSP would consider a set of root CAs, and (optionally) intermediate CAs to validate MSP members (certificates) against. Ideally each MSP would correspond to the membership rules of a certain organisation. More details on the MSPs and their use you may find in /docs/source/msp.rst.
Now to have more sophisticated logic implemented within an MSP (e.g., certain prioritisation among CAs) you may need to implement it yourself complying with the interface of the MSP.
chunhui (Mon, 15 May 2017 07:48:57 GMT):
@elli-androulaki i'm thinking of an alternate MSP implementation and considering if it can still co-exist with the default MSP. but since it will still have a root key, i guess they can be integrated by having 2 intermediate certs for the default and new MSP. thanks :smile:
alesebi91 (Mon, 15 May 2017 14:11:05 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=k8sCaW2DSNYhMShxB) @rmohta Thank you! Another question... I've set 4 but i see only the Admin@example.com user (crypto-config/ordererOrganizations/example.com/users).. Who creates Users? Can you change the number of users at a later time?
chrisconway (Mon, 15 May 2017 15:21:50 GMT):
Has joined the channel.
vdods (Mon, 15 May 2017 20:51:52 GMT):
Hi all, I used transaction certificate attributes in v0.6 to do basic authorization, but it would seem that the relevant golang modules are missing in fabric 1.0 (I'm referring specifically to what was found in github.com/hyperledger/fabric/core/chaincode/shim/crypto/attr in v0.6). How would I go about porting that capability to v1.0 chaincode? Assuming that capability is even still there.
rangak (Tue, 16 May 2017 02:21:33 GMT):
Has left the channel.
Senthil1 (Tue, 16 May 2017 06:38:26 GMT):
Has joined the channel.
oooo (Tue, 16 May 2017 08:48:49 GMT):
Has joined the channel.
MichaelOsborne (Tue, 16 May 2017 12:01:20 GMT):
Has joined the channel.
rmohta (Tue, 16 May 2017 16:44:43 GMT):
@here Do we have a list of all the supported algorithms for message signing? LIke ECDSA secp256r1, secp384r1 etc somewhere?
rmohta (Tue, 16 May 2017 16:44:43 GMT):
@here Do we have a list of all the supported algorithms for ecerts? LIke ECDSA secp256r1, secp384r1 etc somewhere?
yacovm (Tue, 16 May 2017 16:50:07 GMT):
Start from here https://github.com/hyperledger/fabric/blob/master/bccsp/sw/impl.go
yacovm (Tue, 16 May 2017 16:50:11 GMT):
@rmohta
ymchee (Tue, 16 May 2017 19:30:22 GMT):
Has joined the channel.
gormand (Wed, 17 May 2017 13:50:34 GMT):
Can I double check TCerts won't be in V1 until after V1 GA?
srss (Wed, 17 May 2017 14:49:09 GMT):
Has joined the channel.
mastersingh24 (Wed, 17 May 2017 16:48:21 GMT):
@gormand - correct
vdods (Wed, 17 May 2017 22:15:05 GMT):
I'm trying to use cryptogen in and against v1.0.0-alpha2, and orderer is complaining about a missing intermediatecerts dir -- cryptogen makes no such directory. Is this an omission, or a configuration issue? Perhaps I need to add something to my crypto-config.yaml?
vdods (Wed, 17 May 2017 22:15:21 GMT):
I'm using something equivalent to the default cryptogen config template
vdods (Wed, 17 May 2017 22:16:00 GMT):
same with the `crls` dir
vdods (Thu, 18 May 2017 00:51:55 GMT):
Looks like one can create empty dirs at crypto-config/ordererOrganizations/example.com/msp/intermediatecerts and crypto-config/ordererOrganizations/example.com/msp/crls to shut these error messages up
RistoAlas (Thu, 18 May 2017 09:40:25 GMT):
Has joined the channel.
passkit (Thu, 18 May 2017 10:19:08 GMT):
I think I have found a bug in setting up OUs. When checking the OU certificate against the intermediates and roots, the OU certificate is extracted using `x509.ParseCertificate` whereas the intermediates and roots are sanitised then reimported through `msp.bccsp.KeyImport`. The reimporting has the potential to change the signature algorithm which in turn results in certificates not marching, even though they are the same.
passkit (Thu, 18 May 2017 10:19:08 GMT):
I think I have found a bug in setting up OUs. When checking the OU certificate against the intermediates and roots, the OU certificate is extracted using `x509.ParseCertificate` whereas the intermediates and roots are sanitised then reimported through `msp.bccsp.KeyImport`. The reimporting has the potential to change the signature algorithm which in turn results in certificates not matching, even though they are the same.
passkit (Thu, 18 May 2017 10:24:46 GMT):
Will post a Jira issue and a patch.
passkit (Thu, 18 May 2017 10:24:46 GMT):
http://gerrit.hyperledger.org/r/9519 [FAB-4003] OU certificates fail to match
passkit (Thu, 18 May 2017 10:28:12 GMT):
This is particularly relevant for entities using certificates that have been generated independently of fabric
bmkor (Thu, 18 May 2017 10:34:53 GMT):
Not sure if I should ask here. Mutual TLS can be enabled in the orderer but wondering if mutual TLS could also be enabled in peer as well? In peer channel cmd, I can see grpc can enable with TLS by supplying CA cert to verify the orderer but would the peer need to supply its own cert for the orderer's verification? Have I missed something? Thanks for help.
passkit (Thu, 18 May 2017 10:39:58 GMT):
http://gerrit.hyperledger.org/r/9519 [FAB-4003] OU certificates fail to match
yacovm (Thu, 18 May 2017 10:43:21 GMT):
@bmkor there is no mutual TLS between the peers and the orderer but there will be (I hope) mutual TLS between the peers when https://gerrit.hyperledger.org/r/#/c/9119/ is merged
rickr (Thu, 18 May 2017 13:20:35 GMT):
Hi @muralisr @binhn the hashing algorithm SHA3/SHA2 that is used to calculate the blocks hash from the blocks number previous hash and dataHash is that always *guaranteed* the same as hash algorithm that is being used by Peer / Orderer in signing proposals ?
If not, is there some means for the client to determine this ?
rickr (Thu, 18 May 2017 13:20:35 GMT):
Hi @muralisr @binhn the hashing algorithm SHA3/SHA2 that is used to calculate the blocks hash from the blocks number previous hash and dataHash is that always *guaranteed* the same as hash algorithm that is being used by Peer / Orderer in signing proposals ? I'm actually guessing not.
If not, is there some means for the client to determine this ?
passkit (Thu, 18 May 2017 15:44:53 GMT):
Above bug also seems to extend to the peer via `validateIdentityOUs` - you are not comparing apples with apples!
passkit (Thu, 18 May 2017 15:51:14 GMT):
`if bytes.Equal(certificationID, OU.CertifiersIdentifier)` These hashes are of certificate objects that have been processed differently. The default signature method used by bccsp may not match what is in the original pem file, therefore comparing a hash of the object is not a valid way of determining equality.
passkit (Thu, 18 May 2017 15:51:14 GMT):
`if bytes.Equal(certificationID, OU.CertifiersIdentifier)` These hashes of certificate objects that have been processed differently. The default signature method used by bccsp may not match what is in the original pem file, therefore comparing a hash of the object is not a valid way of determining equality.
passkit (Thu, 18 May 2017 15:51:14 GMT):
`if bytes.Equal(certificationID, OU.CertifiersIdentifier)` These hashes of certificate object have been processed differently. The default signature method used by bccsp may not match what is in the original pem file, therefore comparing a hash of the object is not a valid way of determining equality.
passkit (Thu, 18 May 2017 15:51:14 GMT):
`if bytes.Equal(certificationID, OU.CertifiersIdentifier)` These hashes of certificate object have been processed differently. The default signature method used by bccsp may not match what is in the original pem file. Therefore comparing a hash of the object is not a valid way of determining equality.
passkit (Thu, 18 May 2017 15:51:14 GMT):
`if bytes.Equal(certificationID, OU.CertifiersIdentifier)` These hashes of certificate objects have been processed differently. The default signature method used by bccsp may not match what is in the original pem file. Therefore comparing a hash of the object is not a valid way of determining equality.
passkit (Thu, 18 May 2017 15:51:14 GMT):
`if bytes.Equal(certificationID, OU.CertifiersIdentifier)` This compares hashes of certificate objects that have been processed differently. The default signature method used by bccsp may not match what is in the original pem file. Therefore comparing a hash of the object is not a valid way of determining equality.
passkit (Thu, 18 May 2017 15:53:44 GMT):
I have posted a certificate chain in FAB-4003 that can trigger this error
passkit (Thu, 18 May 2017 16:14:39 GMT):
From initial analysis, seems like OU.CertifiersIdentifier is a hash of the chain, and certificationID is just a hash of the certificate. Have you ran tests using with intermediate certificates?
passkit (Thu, 18 May 2017 17:16:55 GMT):
so, `OU.CertifiersIdentifier` contains a hash of the whole chain, whereas `certificationID` contains only a hash of the first certificate in the chain
passkit (Thu, 18 May 2017 17:17:51 GMT):
So this means that alpha2 does not work with intermediate certificates, or with certificates generated outside of the fabric ecosystem. Would be helpful to update the docs to that effect.
passkit (Thu, 18 May 2017 17:17:51 GMT):
So this means that alpha2 does not work with intermediate certificates (stored in the intermediate certificates folder), or with certificates generated outside of the fabric ecosystem. Would be helpful to update the docs to that effect.
passkit (Thu, 18 May 2017 17:38:15 GMT):
A quick hacky fix is to change line 734 of mspimpl.go to `return msp.getCertificationChainIdentifierFromChain([]*x509.Certificate{chain[1]})` to only return the intermediate cert (not the chain). The rabbit hole on how the `msp.ouIdentifiers` is a little too deep for me to look at right now.
passkit (Thu, 18 May 2017 17:38:15 GMT):
A quick hacky fix is to change line 734 of mspimpl.go to `return msp.getCertificationChainIdentifierFromChain([]*x509.Certificate{chain[1]})` to only return the intermediate cert (not the chain). The rabbit hole on how the `msp.ouIdentifiers` is a little too deep for me to look at right now. But for some reason, these are not processing the root when the peer certificate is signed by an intermediate.
yacovm (Thu, 18 May 2017 17:47:58 GMT):
Passkit
yacovm (Thu, 18 May 2017 17:48:03 GMT):
What's the issue
yacovm (Thu, 18 May 2017 17:48:12 GMT):
Can you open a jira and sesribe it there
yacovm (Thu, 18 May 2017 17:48:17 GMT):
*describe
yacovm (Thu, 18 May 2017 17:48:25 GMT):
In an elaborate way?
yacovm (Thu, 18 May 2017 18:01:51 GMT):
@passkit
passkit (Thu, 18 May 2017 18:29:10 GMT):
@yacovm See FAB-4003. I am trying to enroll peers with certs issued from the chain attached to that issue. Put simply, you are trying to determine certificate equality by comparing objects that have been prepared from the MSP files using different methods that yield different results. In particular, where a peer cert is signed by and intermediate certificate, one method hashed the intermediate and the root, while the other just hashes the intermediate - resulting in a false mismatch and a panic.
passkit (Thu, 18 May 2017 18:29:10 GMT):
@yacovm See FAB-4003. I am trying to start peers with certs issued from the chain attached to that issue. Put simply, you are trying to determine certificate equality by comparing objects that have been prepared from the MSP files using different methods that yield different results. In particular, where a peer cert is signed by and intermediate certificate, one method hashed the intermediate and the root, while the other just hashes the intermediate - resulting in a false mismatch and a panic.
passkit (Thu, 18 May 2017 18:29:10 GMT):
@yacovm See FAB-4003. I am trying to start peers with certs issued from the chain attached to that issue. Put simply, the MSP checks are trying to determine certificate equality by comparing objects that have been prepared from the MSP files using different methods that yield different results. In particular, where a peer cert is signed by and intermediate certificate, one method hashed the intermediate and the root, while the other just hashes the intermediate - resulting in a false mismatch and a panic.
passkit (Thu, 18 May 2017 18:29:10 GMT):
@yacovm See FAB-4003. I am trying to start peers with certs issued from the chain attached to that issue. Put simply, the MSP checks are trying to determine certificate chain equality by comparing objects that have been prepared from the MSP files using different methods that yield different results. In particular, where a peer cert is signed by and intermediate certificate, one method hashed the intermediate and the root, while the other just hashes the intermediate - resulting in a false mismatch and a panic.
passkit (Thu, 18 May 2017 18:29:10 GMT):
@yacovm See FAB-4003. I am trying to start peers with certs issued from the chain attached to that issue. Put simply, the MSP checks are trying to determine certificate chain equality by comparing objects that have been prepared from the MSP files using different methods that yield different results. In particular, where a peer cert is signed by an intermediate certificate, one method hashed the intermediate and the root, while the other just hashes the intermediate - resulting in a false mismatch and a panic.
passkit (Thu, 18 May 2017 18:29:10 GMT):
@yacovm See FAB-4003. I am trying to start peers with certs issued from the chain attached to that issue. Put simply, the MSP checks are trying to determine certificate chain equality by comparing objects that have been prepared from the MSP files using different methods that yield different results. In particular, where a peer cert is signed by an intermediate certificate, one method hashes the intermediate and the root, while the other just hashes the intermediate - resulting in a false mismatch and a panic.
passkit (Thu, 18 May 2017 18:30:21 GMT):
I would prepare a separate issue but it is 2:30am here now. If needbe, I will submit one tomorrow afternoon.
yacovm (Thu, 18 May 2017 18:34:50 GMT):
wait wait
yacovm (Thu, 18 May 2017 18:34:57 GMT):
Nick Murray is you?
passkit (Thu, 18 May 2017 18:35:30 GMT):
Yes
passkit (Thu, 18 May 2017 18:43:47 GMT):
@yacovm - I thought about making a test - if I have time tomorrow or over the weekend, I will do.
yacovm (Thu, 18 May 2017 19:03:59 GMT):
@passkit I don't understand why in your fix you go through the `newIdentity`, can' you just call `msp.sanitizeCert(cert)`?
yacovm (Thu, 18 May 2017 19:03:59 GMT):
@passkit I don't understand why in your fix you go through the `newIdentity`, can't you just call `msp.sanitizeCert(cert)`?
yacovm (Thu, 18 May 2017 19:03:59 GMT):
@passkit I don't understand why in your fix you go through the `newIdentity`, can't you just call `msp.sanitizeCert(cert)`?
```
cert, err := msp.getCertFromPem(ou.Certificate)
if err != nil {
return fmt.Errorf("Failed getting certificate for [%v]: [%s]", ou, err)
}
cert, err = msp.sanitizeCert(cert)
if err != nil {
return fmt.Errorf("Failed sanitizing cert for [%v]: [%s]", ou, err)
}
```
yacovm (Thu, 18 May 2017 19:05:25 GMT):
> I thought about making a test - if I have time tomorrow or over the weekend, I will do.
A test would be very helpful here, and also - a directory structure of msp config that allows to reproduce a problem
passkit (Thu, 18 May 2017 22:38:10 GMT):
Probably can - was in a rush to get something working for a client today. Will take a proper look later and also try to tackle the peer issue. Reproducing in a test should be possible.
saptarshee (Fri, 19 May 2017 10:42:05 GMT):
Has joined the channel.
rickr (Sat, 20 May 2017 13:03:00 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=o8z5LsiJGKreew3e5) ?
yacovm (Sat, 20 May 2017 13:09:57 GMT):
I don't think the structure has the hash algorithm inside the block
yacovm (Sat, 20 May 2017 13:10:21 GMT):
therefore I don't think there is a way of the client to know which hash was used to produce the block.
yacovm (Sat, 20 May 2017 13:10:50 GMT):
https://github.com/hyperledger/fabric/blob/master/protos/common/common.proto
rickr (Sat, 20 May 2017 18:20:31 GMT):
So if a user wants to verify the blocks hash it'll be solely _out of band_ information :(
yacovm (Sat, 20 May 2017 18:36:16 GMT):
We have so many out of band stuff going on that this is the least of our worries.
Why would a user want to verify himself the block hash? The infrastructure does it for him.
rickr (Sat, 20 May 2017 19:11:35 GMT):
Some are just paranoid
rickr (Sat, 20 May 2017 19:11:35 GMT):
Some are just paranoid Seems like this should have been in the config block or maybe some other api.
yacovm (Sat, 20 May 2017 19:15:33 GMT):
> Seems like this should have been in the config block
I agree
> Some are just paranoid
Why are they paranoid though? Hash based validation only works backwords...
rickr (Sat, 20 May 2017 19:20:18 GMT):
Well I've already had someone for the Java SDK doing the work to calculate this and asking to commit so apparently it's wanted. My concern is at the moment its assuming the hashing is the same as the peer/orderer signing. My concern is that's not true and how it might be discovered
anik (Tue, 23 May 2017 11:57:11 GMT):
Has joined the channel.
jeffgarratt (Tue, 23 May 2017 22:24:35 GMT):
@rickr @yau
jeffgarratt (Tue, 23 May 2017 22:24:35 GMT):
@rickr @yacovm I believe the hashing algorithm is in the config_update key == "HashingAlgorithm"
jeffgarratt (Tue, 23 May 2017 22:25:39 GMT):
example....
jeffgarratt (Tue, 23 May 2017 22:25:43 GMT):
```values {
key: "HashingAlgorithm"
value {
value: "\n\006SHA256"
mod_policy: "Admins"
}
}
rickr (Tue, 23 May 2017 23:06:16 GMT):
Thanks @jeffgarratt good to know !
jeffgarratt (Tue, 23 May 2017 23:06:44 GMT):
yw
SandySun2000 (Wed, 24 May 2017 16:39:14 GMT):
Has joined the channel.
AndresGaragiola (Wed, 24 May 2017 16:59:23 GMT):
Has joined the channel.
spipes (Thu, 25 May 2017 20:43:24 GMT):
Has joined the channel.
elli-androulaki (Fri, 26 May 2017 18:01:17 GMT):
Hi, for work-items pending for v1 i created this epic https://jira.hyperledger.org/browse/FAB-4179. Here you can see these items classified into "bugs urgent to be fixed", "enhancements important to be done", "documentation", "needs review".
elli-androulaki (Fri, 26 May 2017 18:01:17 GMT):
Hi, for work-items pending for v1 we created this epic https://jira.hyperledger.org/browse/FAB-4179. Here you can see these items classified into "bugs urgent to be fixed", "enhancements important to be done", "documentation", "needs review".
bmalavan (Sat, 27 May 2017 15:38:03 GMT):
Has joined the channel.
C0rWin (Sun, 28 May 2017 20:53:49 GMT):
@elli-androulaki in order to help to classify list of items, I've added review-needed label, so maintainers will able to vote and weight on tasks listed
elli-androulaki (Mon, 29 May 2017 07:15:39 GMT):
@C0rWin thanks much!
farhan3 (Mon, 29 May 2017 22:06:55 GMT):
Hi - I have a question about revoking certificates.
I'm using the cryptogen to generate my certs. And I'm trying to understand how each of certs can possibly be revoked or updated.
First, if a Peer/Orderer MSP signcert needs to be revoked, it can be done by sending an updated channel tx that blacklists the cert. The other Peers, will then no longer accept communications from the blacklisted Peer.
Second, if the Admin cert needs to be revoked, the MSPs of the Peers using that Admin cert will need to be updated. This will be done by removing the admin cert from the admincerts dir in the MSPs. How would this be accomplished for "normal" user certs since they are not copied into the MSP dirs?
Next comes TLS certs - here is where I don't have the answer. If a TLS cert needs to be revoked, how will this be done? I've read around a bit and normally this would be done through Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP). But I don't think fabric supports either (please correct me if I'm wrong).
yacovm (Mon, 29 May 2017 22:41:24 GMT):
> First, if a Peer/Orderer MSP signcert needs to be revoked, it can be done by sending an updated channel tx that blacklists the cert.
That's correct
> The other Peers, will then no longer accept communications from the blacklisted Peer.
That's also correct, and they will also close connection to these peers.
> How would this be accomplished for "normal" user certs since they are not copied into the MSP dirs?
You need to create a CRL and have the CA sign it.
> Next comes TLS certs - here is where I don't have the answer.
You were OK so far
> If a TLS cert needs to be revoked, how will this be done?
Can't imagine a way of doing it in fabric at the moment.
> But I don't think fabric supports either (please correct me if I'm wrong).
I think you're correct. However - we have additional authentication layers that are built on top of TLS so you should be safe in any case.
@mastersingh24 is there any planning on supporting TLS cert revocation, or did I miss something and we already support it somehow?
yacovm (Mon, 29 May 2017 22:41:24 GMT):
@farhan3
> First, if a Peer/Orderer MSP signcert needs to be revoked, it can be done by sending an updated channel tx that blacklists the cert.
That's correct
> The other Peers, will then no longer accept communications from the blacklisted Peer.
That's also correct, and they will also close connection to these peers.
> How would this be accomplished for "normal" user certs since they are not copied into the MSP dirs?
You need to create a CRL and have the CA sign it.
> Next comes TLS certs - here is where I don't have the answer.
You were OK so far
> If a TLS cert needs to be revoked, how will this be done?
Can't imagine a way of doing it in fabric at the moment.
> But I don't think fabric supports either (please correct me if I'm wrong).
I think you're correct. However - we have additional authentication layers that are built on top of TLS so you should be safe in any case.
@mastersingh24 is there any planning on supporting TLS cert revocation, or did I miss something and we already support it somehow?
farhan3 (Mon, 29 May 2017 22:45:59 GMT):
@yacovm Thank you for the quick reply!
> You need to create a CRL and have the CA sign it.
Who would this CRL go to? Would it a part of the updated channel configtx?
yacovm (Mon, 29 May 2017 22:46:21 GMT):
No
yacovm (Mon, 29 May 2017 22:46:26 GMT):
you are talking about a local MSP no?
farhan3 (Mon, 29 May 2017 22:50:54 GMT):
I'm talking about the user certs that are generated by the cryptogen tool. My understanding is that those user certs are to be used by the fabric-client to sign transactions.
yacovm (Mon, 29 May 2017 22:59:00 GMT):
ah
yacovm (Mon, 29 May 2017 22:59:11 GMT):
hmm so yeah you're right about the channel one
farhan3 (Mon, 29 May 2017 23:03:58 GMT):
Awesome, thanks!
rasmustrew (Tue, 30 May 2017 12:53:56 GMT):
Has joined the channel.
rasmustrew (Tue, 30 May 2017 12:55:37 GMT):
Hi there! I have a question about using the cryptogen tool. Is it recommended to use it in a production environment? How does it work together with the CA? What are their roles in relation to eachother?
JonathanLevi (Tue, 30 May 2017 16:14:53 GMT):
Hello @rasmustrew - while I am not sure what you are referring to as a "production" environment... in the sense of a "server" or "real data" or "mission critical" stuff, etc., I'll just mention that the latest "cut" of fabric was announced the Friday before last, which is `v1.0.0-alpha2`, and that we are working towards a `v1.0.0-beta` release soon.
mat0pad (Tue, 30 May 2017 16:45:33 GMT):
Has joined the channel.
mat0pad (Tue, 30 May 2017 16:50:42 GMT):
Hey @JonathanLevi when would "expect" the `v1.0.0-beta` to be released? Is it in a few weeks or longer?
JonathanLevi (Tue, 30 May 2017 16:51:36 GMT):
At it stands now, about a week (say, or two).
JonathanLevi (Tue, 30 May 2017 16:52:32 GMT):
Should not be longer. We are mostly waiting for some work on tooling with channel configurations, so we are holding on cutting a "beta", just in case it would require some API changes.
JonathanLevi (Tue, 30 May 2017 16:54:25 GMT):
Other than that, I don't envision us accepting any API changes beyond that point for 1.0 (unless a real show-stopper is found, which really requires us changing the API for 1.0).
mat0pad (Tue, 30 May 2017 16:55:08 GMT):
Thanks! Sounds good :thumbsup:
rmohta (Tue, 30 May 2017 21:21:18 GMT):
@here Using `cryptogen` we can generate keystore and signed certs. I was hoping to generate the CSR too, so that the tool can be used to generate pk and csr, and an offline CA signing could be done. Does anyone know if it's been done?
troyronda (Wed, 31 May 2017 00:18:09 GMT):
re: https://jira.hyperledger.org/browse/FAB-3678. What's the solution in 1.0 for enforcing key management policies?
troyronda (Wed, 31 May 2017 00:18:09 GMT):
re: https://jira.hyperledger.org/browse/FAB-3678. What's the recommended mechanism in 1.0 for enforcing key management policies?
troyronda (Wed, 31 May 2017 00:39:41 GMT):
(I'm guessing that currently an administrator needs to manually revoke and upload a new CRL whenever a cert expires)... (not exactly enforced).
troyronda (Wed, 31 May 2017 00:39:41 GMT):
I'm guessing that currently an administrator needs to manually revoke and upload a new CRL whenever a cert expires... (not that this implies enforced).
JonathanLevi (Wed, 31 May 2017 05:54:52 GMT):
@rmohta: please stop using the @ here, at least not on the first attempt to ask a question.
E.g., [ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=Yer8TgdfG8LEMMsr6)
JonathanLevi (Wed, 31 May 2017 05:55:48 GMT):
Give us at least 24 hours, before you wake people up ;-)
rasmustrew (Wed, 31 May 2017 08:08:43 GMT):
@JonathanLevi Production environment as opposed to a test environment like the e2e scenario. Would you mind giving a further explanation, if possible, on the purpose of the cryptogen tool, in relation to the CA. Is the cryptogen tool mostly created for testing purposes? If not, should it be used to create just the admin certs or more? When should the CA be used instead of the cryptogen tool? These are mostly "best practice" questions i suppose.
Willson (Wed, 31 May 2017 08:32:07 GMT):
Has joined the channel.
jimthematrix (Wed, 31 May 2017 16:04:14 GMT):
@adc @elli-androulaki can you take a look bug https://jira.hyperledger.org/browse/FAB-4248? I added some details of what I think is the policy checker's logic flaw
jimthematrix (Wed, 31 May 2017 16:04:14 GMT):
@adc @elli-androulaki can you take a look bug https://jira.hyperledger.org/browse/FAB-4248? I added some details of what I think is a flow in the policy checker's logic
jimthematrix (Wed, 31 May 2017 16:04:14 GMT):
@adc @elli-androulaki @aso can you take a look bug https://jira.hyperledger.org/browse/FAB-4248? I added some details of what I think is a flow in the policy checker's logic
jimthematrix (Wed, 31 May 2017 16:04:14 GMT):
@adc @elli-androulaki @aso can you take a look bug https://jira.hyperledger.org/browse/FAB-4248? I added some details of what I think is a flaw in the policy checker's logic
jimthematrix (Wed, 31 May 2017 16:07:33 GMT):
@xixuejia @Nishi ^^^
guillermo.correa (Wed, 31 May 2017 22:33:03 GMT):
Has joined the channel.
adc (Thu, 01 Jun 2017 13:38:24 GMT):
Hi @jimthematrix, thanks. I put some additional comment there
jimthematrix (Thu, 01 Jun 2017 13:42:36 GMT):
got it thanks @adc. i agree with your assessment. will continue the discussion in the JIRA. @aso @jyellick can one of you check out https://jira.hyperledger.org/browse/FAB-4248 and decide on a fix?
jyellick (Thu, 01 Jun 2017 13:50:56 GMT):
Thanks for the heads up @jimthematrix , this very issue was actually discussed with @aso during implementation, will update the issue.
vdods (Thu, 01 Jun 2017 22:47:41 GMT):
Hi all, as far as I can tell from searching Jira for 'tcert', tcerts are not going to be supported in v1.0.. is that correct? Is there an estimated release that they will be supported? This ticket indicates perhaps that is v1.1 -- https://jira.hyperledger.org/browse/FAB-2441?jql=text%20~%20%22tcert%22 -- but other relevant tickets show "future" for the fix version(s).
tom.appleyard (Fri, 02 Jun 2017 12:51:10 GMT):
Would someone be able to field some questions about what cryptogen creates?
jeffgarratt (Fri, 02 Jun 2017 16:23:23 GMT):
@tom.appleyard think @mastersingh24 may be able to help
mastersingh24 (Fri, 02 Jun 2017 16:25:21 GMT):
@vdods - given the desire for tcerts, it seemed to make send to have them on the initial list of features for the next version. Ones that are not so clear are marked "FUTURE"
vdods (Fri, 02 Jun 2017 16:27:07 GMT):
@mastersingh24 is there a single Jira ticket or list somewhere that enumerates the features going into the next version? I assume you're talking about v1.1, not e.g. alpha3 or whatever the next release is.
mastersingh24 (Fri, 02 Jun 2017 16:30:20 GMT):
sorry - yes - I meant next MINOR release - e.g. 1.1
There's no JIRA ticket for v1.1 and there has not (yet) been any formal planning
vdods (Fri, 02 Jun 2017 19:00:25 GMT):
Thanks
vdods (Fri, 02 Jun 2017 19:01:07 GMT):
Does v1.1 have an approximate release schedule, and if so, what is it?
vdods (Fri, 02 Jun 2017 19:21:38 GMT):
Also, is there a document describing all the files generated by cryptogen and their relationships? I'm trying to figure it out by reading tools/cryptogen/main.go and friends but it's not too clear. My main goal is to figure out which keys/certs do what, and which ones are needed for the various actions, such as user creation (client.createUser in fabric-sdk-node) and channel creation (client.createChannel)
vdods (Fri, 02 Jun 2017 19:22:27 GMT):
There are so many files to pick from and there's no clear correct choice, and the lack of specifics in the API docs for e.g. fabric-sdk-node isn't helping (e.g. use this key+cert here)
vdods (Fri, 02 Jun 2017 20:18:07 GMT):
This command is illuminating -- `find crypto-config -type f -exec sha512sum {} \; | sort` -- in that it shows which files are the same, but there are still mysteries, such as why peerOrganizations/org0.example.com/msp/admincerts/Admin@org0.example.com-cert.pem and peerOrganizations/org0.example.com/users/Admin@org0.example.com/tls/server.crt are the same file.
vdods (Fri, 02 Jun 2017 20:58:55 GMT):
A few other questions I have about the crypto materials: Which directories are meant to go to which entities? E.g. peers, orderers, SDK-using web server, etc. So far my dockerized peer network (which is analogous to other working examples) works fine using only about half the materials
vdods (Sat, 03 Jun 2017 00:19:28 GMT):
@here Anyone have a word on this?
vdods (Sat, 03 Jun 2017 21:14:24 GMT):
Also, related question: Is it just for convenience that the `tls` and `msp` materials are shared per entity in the output of cryptogen? For example, the following pairs of files are identical (sha512sums truncated for readability):
```
a4c98e4a ./ordererOrganizations/example.com/orderers/orderer.example.com/msp/cacerts/ca.example.com-cert.pem
a4c98e4a ./ordererOrganizations/example.com/orderers/orderer.example.com/tls/ca.crt
0ed1c43e ./ordererOrganizations/example.com/orderers/orderer.example.com/msp/keystore/be56864ade899cb8ac04b2cb442a37779b1040c5927fe7e850333fff34cbc321_sk
0ed1c43e ./ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.key
81c287a3 ./ordererOrganizations/example.com/orderers/orderer.example.com/msp/signcerts/orderer.example.com-cert.pem
81c287a3 ./ordererOrganizations/example.com/orderers/orderer.example.com/tls/server.crt
```
vdods (Sat, 03 Jun 2017 21:15:06 GMT):
There's no reason why the `tls` and `msp` files need to be the same though? Since they should be independent considerations+
vdods (Sat, 03 Jun 2017 21:15:06 GMT):
There's no reason why the `tls` and `msp` files need to be the same though? Since they should be independent considerations?
yacovm (Sat, 03 Jun 2017 21:30:51 GMT):
There is no reason @vdods .
yacovm (Sat, 03 Jun 2017 21:31:29 GMT):
But they need to be signed by the same root CA
vdods (Sat, 03 Jun 2017 21:37:37 GMT):
@yacovm Ok, thanks. And just to make sure I'm straight on this -- these files produced by cryptogen are the same for purposes of convenience?
yacovm (Sat, 03 Jun 2017 21:39:20 GMT):
Don't know, I didn't write cryptogen.
vdods (Sat, 03 Jun 2017 21:42:27 GMT):
:)
rickr (Sun, 04 Jun 2017 22:08:41 GMT):
I think I asked this a while back but never got an answer :( Do we see in the *future* the need to support peers with a mix of different hashing/crypto strengths ?
bh4rtp (Mon, 05 Jun 2017 00:30:19 GMT):
@vdods you can ask @mastersingh24 .
LordGoodman (Mon, 05 Jun 2017 06:57:21 GMT):
Hello I trying to separate the orderer service of e2e examples to another vm, however it didn't and the error like this ```2017-06-05 06:43:51.649 UTC [grpc] Printf -> DEBU 0df grpc: Server.Serve failed to complete security handshake from "10.112.122.8:64943": EOF
2017-06-05 06:45:57.225 UTC [grpc] Printf -> DEBU 0e0 grpc: Server.Serve failed to complete security handshake from "10.112.122.8:65036": EOF
```
LordGoodman (Mon, 05 Jun 2017 06:58:52 GMT):
the orderer vm use the crypto-config dir which generated on the former vm
guruce (Mon, 05 Jun 2017 07:27:33 GMT):
Has joined the channel.
LordGoodman (Mon, 05 Jun 2017 07:57:18 GMT):
everything is good when I disable the TLS
LordGoodman (Mon, 05 Jun 2017 09:55:02 GMT):
somebody help???:joy:
dklesev (Mon, 05 Jun 2017 10:09:59 GMT):
Has joined the channel.
mastersingh24 (Mon, 05 Jun 2017 10:30:42 GMT):
@LordGoodman - there was a thread about this on the mailing list as well -
```
The underlying issue is that hostname verification is failing when communicating with the orderer.
The reason for this is due to the fact that the CN/SAN in the TLS certificate used by the orderer is "orderer.example.com" and not the ip address / host you are now assigning to the orderer.
You could attempt to regenerate all of the crypto material and start from the beginning, but a simpler solution might be ti simply add a hosts entry for orderer.example.com in the hosts file (/etc/hosts) on the host where you are running the peers and the CLI. Just map orderer.example.com to the IP address of the host it is running on
```
LordGoodman (Mon, 05 Jun 2017 10:33:02 GMT):
@mastersingh24 Thank you ! I just find out I can't use the "peer channel create -o 127.0.0.1:7050" to create channel , thanks for your suggestion.
bh4rtp (Mon, 05 Jun 2017 11:03:10 GMT):
@here is it possible to control proposal invoke right for different peers by endorsing policy?
levinkwong (Mon, 05 Jun 2017 11:03:18 GMT):
Has joined the channel.
adc (Mon, 05 Jun 2017 11:04:15 GMT):
@bh4rtp may you be more precise, please? maybe an example
bh4rtp (Mon, 05 Jun 2017 11:07:07 GMT):
@adc for example, in a market, there are seller, purchaser, trader and regulator. the quoted price should keep secret to other sellers or purchasers, and only can be accessed by trader and regulator.
bh4rtp (Mon, 05 Jun 2017 11:07:07 GMT):
@adc for example, in a market, there are seller, purchaser, trader and regulator. the quoted price declared by a seller or a purchaser should keep secret to other ones, and only can be accessed by trader and regulator.
adc (Mon, 05 Jun 2017 11:09:00 GMT):
may you expand more, please
adc (Mon, 05 Jun 2017 11:09:19 GMT):
it looks like you want to achieve some kind of access control
bh4rtp (Mon, 05 Jun 2017 11:10:46 GMT):
yes. in the blockchain network, some invoke methods are not open to all peers.
adc (Mon, 05 Jun 2017 11:11:48 GMT):
so, the chaincode needs to be programmed to perform access control
adc (Mon, 05 Jun 2017 11:12:19 GMT):
what you can do at the current stage is the leverage the shim's GetCreator method
bh4rtp (Mon, 05 Jun 2017 11:12:27 GMT):
@yacovm said it can be done using endorsement policy.
adc (Mon, 05 Jun 2017 11:13:01 GMT):
he probably had another picture in mind
adc (Mon, 05 Jun 2017 11:13:01 GMT):
he probably had another picture in mind then
bh4rtp (Mon, 05 Jun 2017 11:13:15 GMT):
@adc thanks. maybe the GetCreator method does work.
yacovm (Mon, 05 Jun 2017 11:13:23 GMT):
can't you specify a specific identity in the endorsement policy, Angelo?
yacovm (Mon, 05 Jun 2017 11:13:45 GMT):
No, the get creator has nothing to do with that.
yacovm (Mon, 05 Jun 2017 11:13:56 GMT):
it's the certificate of the client SDK
yacovm (Mon, 05 Jun 2017 11:13:58 GMT):
that send the proposal
adc (Mon, 05 Jun 2017 11:14:46 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=LGytXbaaDvKgEnTpJ) @yacovm you can, sure!
adc (Mon, 05 Jun 2017 11:14:58 GMT):
it all depends what is the goal one wants to achieve
adc (Mon, 05 Jun 2017 11:14:58 GMT):
it all depends on what is the goal one wants to achieve
bh4rtp (Mon, 05 Jun 2017 11:16:07 GMT):
maybe access control is beyond the fabric, but it should provide the identity interface. am i right?
yacovm (Mon, 05 Jun 2017 11:17:29 GMT):
from what I understood from @bh4rtp he/she wants to deny certain peers from endorsing chaincode
bh4rtp (Mon, 05 Jun 2017 11:17:33 GMT):
espeically, from the chaincode side, i know who is calling.
yacovm (Mon, 05 Jun 2017 11:17:39 GMT):
right?
adc (Mon, 05 Jun 2017 11:18:04 GMT):
if that is the case, then you can just declare who should endorse, no?
adc (Mon, 05 Jun 2017 11:18:38 GMT):
an endorsement policy is just a formula over MSP Principals
yacovm (Mon, 05 Jun 2017 11:18:51 GMT):
wow formula
adc (Mon, 05 Jun 2017 11:18:59 GMT):
a possible MSP Principal is that identify a precise identity in the fabric network
yacovm (Mon, 05 Jun 2017 11:19:05 GMT):
I'd say it's a predicate over MSP principals
adc (Mon, 05 Jun 2017 11:20:11 GMT):
if you just say predicate then one might image that can point to a function that returns true/false
adc (Mon, 05 Jun 2017 11:20:27 GMT):
you actually specify a formula and evaluate its satisfiability
adc (Mon, 05 Jun 2017 11:20:30 GMT):
but anyway
adc (Mon, 05 Jun 2017 11:20:34 GMT):
it is a predicate :)
adc (Mon, 05 Jun 2017 11:20:34 GMT):
it is a predicate too :)
adc (Mon, 05 Jun 2017 11:20:59 GMT):
@bh4rtp what do you want to achieve then?
bh4rtp (Mon, 05 Jun 2017 11:30:25 GMT):
@adc i think it should be the best to achieve through endorsement policy. otherwise, the accesses cannot be strictly controlled.
bh4rtp (Mon, 05 Jun 2017 11:30:47 GMT):
that is under the fabric lower layer.
bh4rtp (Mon, 05 Jun 2017 11:32:51 GMT):
if it is implemented above chaincode, then someone can bypass the access control.
yacovm (Mon, 05 Jun 2017 12:51:12 GMT):
@mastersingh24 Why not add support for IP SANs in cryptogen? it only supports dns names
This code snippet fixes this:
```
for _, s := range sans {
ip := net.ParseIP(s)
if ip == nil {
continue
}
template.IPAddresses = append(template.IPAddresses, ip)
}
```
Should we try to add it, or is it too late at this point?
yacovm (Mon, 05 Jun 2017 12:51:12 GMT):
@mastersingh24 Why not add support for IP SANs in cryptogen? it only supports dns names
This code snippet fixes this (obviously this is not the change we would want to have but I needed an ad-hoc solution):
```
for _, s := range sans {
ip := net.ParseIP(s)
if ip == nil {
continue
}
template.IPAddresses = append(template.IPAddresses, ip)
}
```
Should we try to add it, or is it too late at this point?
mastersingh24 (Mon, 05 Jun 2017 13:02:00 GMT):
Should not be an issue to do this - let's create a JIRA and if we can get to it we can do it
yacovm (Mon, 05 Jun 2017 13:06:00 GMT):
https://jira.hyperledger.org/browse/FAB-4364
muralisr (Mon, 05 Jun 2017 14:30:16 GMT):
https://chat.hyperledger.org/channel/fabric-crypto?msg=ShvSMMuAkMG8cQniP
muralisr (Mon, 05 Jun 2017 14:30:45 GMT):
https://chat.hyperledger.org/channel/fabric-crypto?msg=kGe8J5yXkXeyC4Jqm
muralisr (Mon, 05 Jun 2017 14:31:23 GMT):
putting those together, what we are saying is your endorsement policy needs to be different for different invokes
muralisr (Mon, 05 Jun 2017 14:31:27 GMT):
correct ?
muralisr (Mon, 05 Jun 2017 14:31:27 GMT):
correct @bh4rtp
muralisr (Mon, 05 Jun 2017 14:31:27 GMT):
correct @bh4rtp ?
adc (Mon, 05 Jun 2017 14:39:35 GMT):
it would be interesting to have an endorsement policy per function, actually
bh4rtp (Mon, 05 Jun 2017 14:52:14 GMT):
@muralisr yes. i had thought be different for different invoke. for example there are queryPrice, declarePrice, i want queryPrice only invoked by the seller or purchaser who declared price, the trader and regulator. while declarePrice can only be invoked by the seller and the purchaser.
yacovm (Mon, 05 Jun 2017 14:53:18 GMT):
It makes no sense to prohibit invocations.
What you really want to do, is prohibit endorsements by these peers
bh4rtp (Mon, 05 Jun 2017 14:54:43 GMT):
@yacovm yes. the proposal response should not send to these peers.
adc (Mon, 05 Jun 2017 15:12:48 GMT):
but do you need queryPrice to be endorsed?
bh4rtp (Mon, 05 Jun 2017 15:17:15 GMT):
@adc should be endorsed, but you remind me that it is just a query.
adc (Mon, 05 Jun 2017 15:17:35 GMT):
a query needs to be endorsed only you want a strong query
adc (Mon, 05 Jun 2017 15:17:35 GMT):
a query needs to be endorsed only if you want a strong query
adc (Mon, 05 Jun 2017 15:17:50 GMT):
meaning that the result will appear on the ledger
adc (Mon, 05 Jun 2017 15:18:16 GMT):
so, if it does not need to be endorsed then you need to enforce access control at the chaincode
adc (Mon, 05 Jun 2017 15:18:41 GMT):
so, it looks to me you are kind of implementing an auction, no?
muralisr (Mon, 05 Jun 2017 15:24:30 GMT):
@bh4rtp @adc @yacovm just wanted to make sure we are not steering in a wrong direction.. or applying the wrong tools for the job. Lets put down what we *really* want to do and then workaround if that's not possible
bh4rtp (Mon, 05 Jun 2017 15:24:31 GMT):
@adc yes. a trade example.
muralisr (Mon, 05 Jun 2017 15:25:29 GMT):
to me what @bh4rtp really wants is ACL mechanisms in the chaincode where the chaincode can decide if something invoke should go through or not
adc (Mon, 05 Jun 2017 15:25:32 GMT):
@muralisr +1
bh4rtp (Mon, 05 Jun 2017 15:26:54 GMT):
@muralisr but in the chaincode, how to check the identity of invoke peer?
muralisr (Mon, 05 Jun 2017 15:27:08 GMT):
that is the crucial question
adc (Mon, 05 Jun 2017 15:27:38 GMT):
I have an educated answer :)
yacovm (Mon, 05 Jun 2017 15:27:53 GMT):
This doesn't make sense though, why would you want the chaincode to do that?
If the request reached the chaincode, you are already invoking it
yacovm (Mon, 05 Jun 2017 15:28:01 GMT):
you need just not to send the request to the peer
muralisr (Mon, 05 Jun 2017 15:28:04 GMT):
(@adc correct if Im wrong) .. the GetCreator is the only mechanism currently which gives some idea of "who is calling me"
muralisr (Mon, 05 Jun 2017 15:28:15 GMT):
will yield to @adc ;-) now
yacovm (Mon, 05 Jun 2017 15:28:16 GMT):
the peer that invokes a Txn, does it via its chaincode
adc (Mon, 05 Jun 2017 15:29:28 GMT):
@muralisr, you are right. The shim exposes the GetCreator method that returns the byte representation of the MSP identity of the signer of the proposal
adc (Mon, 05 Jun 2017 15:30:17 GMT):
so, for example, the chaincode might associate, in some way, to an asset a list of serialized MSP identities
adc (Mon, 05 Jun 2017 15:30:17 GMT):
so, for example, the chaincode might associate, in some way, to an asset (might be any resource the querier wants to access) a list of serialized MSP identities
adc (Mon, 05 Jun 2017 15:30:44 GMT):
and then the chaincode can checks if the creator of the proposal is in the list
adc (Mon, 05 Jun 2017 15:30:44 GMT):
and then the chaincode can check if the creator of the proposal is in the list
adc (Mon, 05 Jun 2017 15:31:05 GMT):
if yes, the chaincode grants access, otherwise it returns an error
adc (Mon, 05 Jun 2017 15:33:27 GMT):
let me also notice that access control is orthogonal to confidentiality
bh4rtp (Mon, 05 Jun 2017 15:33:44 GMT):
in the sense of security, i think it is not useful to implement in chaincode. firstly chaincode is source code and secondly the peer controls its access, doesn't it?
adc (Mon, 05 Jun 2017 15:33:53 GMT):
if the chaincode exposes a query function and the ledger is not encrypted then any reader of the ledger can derive directly that information
adc (Mon, 05 Jun 2017 15:34:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=nK4zYA8ykgG58wTD8) @bh4rtp not sure I got what you meant
bh4rtp (Mon, 05 Jun 2017 15:35:54 GMT):
@adc yes. that is the second question. how to encrypt the trade secret data? :grinning:
adc (Mon, 05 Jun 2017 15:36:00 GMT):
it makes very sense to perform access control at the chaincode, the peer only check that the creator of the proposal is a writer of the channel the chaincode is running into
adc (Mon, 05 Jun 2017 15:36:17 GMT):
aha, encryption is another beautiful story :)
adc (Mon, 05 Jun 2017 15:36:56 GMT):
for that I would need to know more about your setting
adc (Mon, 05 Jun 2017 15:37:13 GMT):
encryption can be performed at the client side and/or at the chaincode side
adc (Mon, 05 Jun 2017 15:37:23 GMT):
each solution has different trade-off to consider
adc (Mon, 05 Jun 2017 15:37:34 GMT):
in terms of key distribution and so on
jimthematrix (Mon, 05 Jun 2017 15:38:46 GMT):
@adc @elli-androulaki @mastersingh24 @vpaprots can I ask the configurability of the BCCSP settings throughout the fabric? at this point, where and how do they get configured, if configurable at all? I see BCCSP sections in both core.yaml and orderer.yaml. I see that `SHA2` is not recommended to be changed since it's hardcoded in multiple places (according to the comment). I know `sw` vs. `pkcs#11` can be configured. what about security level `256/384/512`? if I change the security level, that must be done everywhere (sdk/peer/orderer) otherwise validating signatures will fail right?
adc (Mon, 05 Jun 2017 15:39:45 GMT):
@jimthematrix that section is useless at the current stage
adc (Mon, 05 Jun 2017 15:40:12 GMT):
also the security level is meaningless because, if we consider MSP, it comes from the signing identity directly
adc (Mon, 05 Jun 2017 15:40:34 GMT):
meaning that the crypto material a peer is loaded with implicitly induce the security level
adc (Mon, 05 Jun 2017 15:40:34 GMT):
meaning that the crypto material a peer is loaded with implicitly induces the security level
adc (Mon, 05 Jun 2017 15:40:54 GMT):
now, we have the hash function configured at configuration transaction
adc (Mon, 05 Jun 2017 15:41:02 GMT):
but that is not use everywhere
adc (Mon, 05 Jun 2017 15:41:02 GMT):
but that is not use everywhere, yet
jimthematrix (Mon, 05 Jun 2017 15:41:31 GMT):
but the signer (say SDK when submitting a request) and the validator (say the peer when validating the request) must coordinate out-of-band on the MSP settings correct?
adc (Mon, 05 Jun 2017 15:41:50 GMT):
yes
jimthematrix (Mon, 05 Jun 2017 15:42:02 GMT):
so that given an "MSPId" it's clear what settings to use
jimthematrix (Mon, 05 Jun 2017 15:42:04 GMT):
ok
adc (Mon, 05 Jun 2017 15:42:14 GMT):
in particular for signature verification, the coordination needs to be on the which hash function to use for computing the digest
adc (Mon, 05 Jun 2017 15:42:16 GMT):
nothing else
adc (Mon, 05 Jun 2017 15:42:23 GMT):
yes
jimthematrix (Mon, 05 Jun 2017 15:45:04 GMT):
on _which hash function to use_, so given a security level, I thought the hashing function must use the same length, so you'd only have SHA2 vs. SHA3 to choose from (since the length is dictated by the key algo's security level). is that understanding correct?
adc (Mon, 05 Jun 2017 15:45:23 GMT):
very much :)
jimthematrix (Mon, 05 Jun 2017 15:45:34 GMT):
ok
jimthematrix (Mon, 05 Jun 2017 15:46:06 GMT):
thanks Angelo, much clearer now
adc (Mon, 05 Jun 2017 15:46:11 GMT):
:)
SriramaSharma (Mon, 05 Jun 2017 23:36:47 GMT):
Has joined the channel.
rmohta (Tue, 06 Jun 2017 22:59:25 GMT):
Guys, does orderer need to have ca for peer nodes? I was hoping to get a better understanding on how the keys/certs have to be distributed?
bernardo9999 (Wed, 07 Jun 2017 05:16:18 GMT):
Has joined the channel.
bh4rtp (Wed, 07 Jun 2017 07:38:10 GMT):
@here does sha256 encoding result change with calculating host and time?
yacovm (Wed, 07 Jun 2017 08:14:40 GMT):
why would the encoding be affected by host or time?
bh4rtp (Wed, 07 Jun 2017 08:40:17 GMT):
@yacovm i found the encoded values are different from yesterday. but i am not sure about whether the hash input was changed?
bh4rtp (Wed, 07 Jun 2017 08:40:17 GMT):
@yacovm i found the encoded values are different from yesterday. but i am not sure whether the hash input was changed?
bh4rtp (Wed, 07 Jun 2017 08:40:17 GMT):
@yacovm i found the encoded values are different from yesterday. but i am not sure whether the hash input was changed.
bh4rtp (Wed, 07 Jun 2017 08:40:17 GMT):
@yacovm i found the encoded values are different from yesterday. but i am not sure whether the hash input was changed. the input is typed by myself in a script file.
bh4rtp (Wed, 07 Jun 2017 08:40:17 GMT):
@yacovm i found the encoded values are different from yesterday. but i am not sure whether the hash input was changed. the input was typed by myself in a script file. so i am doubted that.
bh4rtp (Wed, 07 Jun 2017 08:54:20 GMT):
i will check tomorrow.
farhan3 (Wed, 07 Jun 2017 19:25:57 GMT):
Hi - does anyone know how the Peers decide on whether to use TLS or not when talking to the Orderer? I don't see that option anywhere on the Peer side, however, on the Orderer side, you can enable/disable TLS.
farhan3 (Wed, 07 Jun 2017 19:26:42 GMT):
Reason I'm asking is, because I'm trying to use a different CA for my TLS certs, but then the Peer-Orderer handshake fails after the Peer joins the channel.
farhan3 (Wed, 07 Jun 2017 19:27:37 GMT):
```peer0.org0 | 2017-06-07 19:09:22.823 UTC [ConnProducer] NewConnection -> ERRO 2ed Failed connecting to orderer.org0:7050 , error: grpc: timed out when dialing
peer0.org0 | 2017-06-07 19:09:22.823 UTC [deliveryClient] connect -> ERRO 2ee Failed obtaining connection: Could not connect to any of the endpoints: [orderer.org0:7050]
```
farhan3 (Wed, 07 Jun 2017 19:28:05 GMT):
```orderer.org0 | 2017-06-07 19:09:19.831 UTC [grpc] Printf -> DEBU 7fa grpc: Server.Serve failed to complete security handshake from "172.26.0.1:48008": EOF
orderer.org0 | 2017-06-07 19:09:19.861 UTC [grpc] Printf -> DEBU 7fb grpc: Server.Serve failed to complete security handshake from "172.26.0.1:48010": EOF
```
farhan3 (Wed, 07 Jun 2017 19:28:45 GMT):
How does the Peer determine what TLS cert to use during the handshake with the Orderer
yacovm (Wed, 07 Jun 2017 19:37:21 GMT):
in the core.yaml there is a tls section
farhan3 (Wed, 07 Jun 2017 19:53:11 GMT):
Right, to set the TLS crt and key for the Peer. There is also a place to provide a root crt.
farhan3 (Wed, 07 Jun 2017 19:53:24 GMT):
Is that the Root crt used during the handshake with the Orderer?
yacovm (Wed, 07 Jun 2017 20:09:43 GMT):
no. There is no mutual TLS with the orderer
yacovm (Wed, 07 Jun 2017 20:09:48 GMT):
Only mutual TLS with peers
yacovm (Wed, 07 Jun 2017 20:09:54 GMT):
and the certificate that is used is the one listed there
yacovm (Wed, 07 Jun 2017 20:09:58 GMT):
as the server certificate
farhan3 (Wed, 07 Jun 2017 20:16:35 GMT):
Right, no mutual TLS. But when you try to do a TLS handshake, you still need to trust the Root cert who has signed the cert of the server you're connecting to.
farhan3 (Wed, 07 Jun 2017 20:17:26 GMT):
So when the Peer is connecting to the Orderer. The Orderer will send it's cert to the Peer, the Peer then needs to trust the Root who signed the Orderer's cert.
farhan3 (Wed, 07 Jun 2017 20:18:20 GMT):
Where is that Root cert specified?
yacovm (Wed, 07 Jun 2017 20:19:56 GMT):
ah
yacovm (Wed, 07 Jun 2017 20:20:06 GMT):
it's in the config block of the channel
yacovm (Wed, 07 Jun 2017 20:20:08 GMT):
i.e the genesis block
yacovm (Wed, 07 Jun 2017 20:20:24 GMT):
basically we have some dynamically updating root CA pool
yacovm (Wed, 07 Jun 2017 20:20:35 GMT):
that as you join channels, it is updated
farhan3 (Wed, 07 Jun 2017 20:20:52 GMT):
Ah, I see
farhan3 (Wed, 07 Jun 2017 20:21:42 GMT):
So if I want to use an external CA to sign my TLS cert of Orderer. I would need to add that TLS Root under the Orderer's MSP?
yacovm (Wed, 07 Jun 2017 20:22:01 GMT):
yeah
farhan3 (Wed, 07 Jun 2017 20:22:16 GMT):
Under cacerts I presume
yacovm (Wed, 07 Jun 2017 20:22:26 GMT):
ah no
yacovm (Wed, 07 Jun 2017 20:22:35 GMT):
you need to make that information
yacovm (Wed, 07 Jun 2017 20:22:38 GMT):
get into the genesis block
yacovm (Wed, 07 Jun 2017 20:22:49 GMT):
so not the local MSP
yacovm (Wed, 07 Jun 2017 20:22:52 GMT):
of the orderer
yacovm (Wed, 07 Jun 2017 20:23:03 GMT):
but into that folder that is consumed by the `configtxgen`
farhan3 (Wed, 07 Jun 2017 20:23:19 GMT):
Right, I'll put it in the Orderer's MSP and then generate the genesis block using configtxgen
yacovm (Wed, 07 Jun 2017 20:23:29 GMT):
https://github.com/hyperledger/fabric/blob/master/sampleconfig/configtx.yaml#L90
yacovm (Wed, 07 Jun 2017 20:23:33 GMT):
This one
farhan3 (Wed, 07 Jun 2017 20:24:09 GMT):
Ah, right. The Orderer's Org's MSP. Not the Orderer's MSP.
yacovm (Wed, 07 Jun 2017 20:24:17 GMT):
yeah
farhan3 (Wed, 07 Jun 2017 20:24:25 GMT):
ok, cool. Let me give that a try.
farhan3 (Wed, 07 Jun 2017 20:24:27 GMT):
Thank you :D
yacovm (Wed, 07 Jun 2017 20:24:29 GMT):
sure
farhan3 (Wed, 07 Jun 2017 20:42:07 GMT):
@yacovm worked!
yacovm (Wed, 07 Jun 2017 20:42:57 GMT):
cool
farhan3 (Wed, 07 Jun 2017 20:44:19 GMT):
Just to summarize for everyone else: `The Root CA cert that signs the Orderer's TLS cert must be added to the Orderer Org's msp/cacerts dir before the genesis block is created via configtxgen.`
wyanglau (Thu, 08 Jun 2017 16:00:06 GMT):
Has joined the channel.
wyanglau (Thu, 08 Jun 2017 16:04:20 GMT):
Hi - does anyone know how to make the orderer/peers trust the intermediate CA? While the user has been enrol in the intermediate CA, the peers seems to be not trusting the intermediate CA, throwing 'X509 signed by unknown authority' error. Also I tried to put the intermediate CA cert under the `msp/intermediatecerts` of the orderer, but it thrown `CRIT 08e Error creating configtx manager and handlers: Setting up the MSP manager failed, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority` when starting up the orderer.
wyanglau (Thu, 08 Jun 2017 16:04:20 GMT):
Thanks in advance
wyanglau (Thu, 08 Jun 2017 16:04:20 GMT):
Hi - does anyone know how to make the orderer/peers trust the intermediate CA? While the user has been enrol in the intermediate CA, the peers seems to be not trusting the intermediate CA, throwing 'X509 signed by unknown authority' error. Also I tried to put the intermediate CA cert under the `msp/intermediatecerts` of the orderer, but it thrown `CRIT 08e Error creating configtx manager and handlers: Setting up the MSP manager failed, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority` when starting up the orderer. Thanks in advance
wyanglau (Thu, 08 Jun 2017 16:04:20 GMT):
Hi - does anyone know how to make the orderer/peers trust the intermediate CA? While the user has been enrol in the intermediate CA, the peers seems to be not trusting the intermediate CA, throwing 'X509 signed by unknown authority' error. Also I tried to put the intermediate CA cert under the `msp/intermediatecerts` of the orderer, but it thrown ```CRIT 08e Error creating configtx manager and handlers: Setting up the MSP manager failed, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority``` when starting up the orderer. Thanks in advance
mastersingh24 (Thu, 08 Jun 2017 16:54:18 GMT):
@wyanglau - you need to put the root cert in the `msp/cacerts` directory and the intermediate cert in the `msp/intermediatecerts` directory
wyanglau (Thu, 08 Jun 2017 17:04:13 GMT):
@mastersingh24 Hi, I have put the root cert in `msp/cacerts` and intermediate cert in `msp/intermediatecerts`. The orderer can start with the root cert only, and the intermediate cert has been signed by the root CA; but still this problem is appearing
wyanglau (Thu, 08 Jun 2017 17:04:13 GMT):
@mastersingh24 Hi, I have put the root cert in `msp/cacerts` and intermediate cert in `msp/intermediatecerts` ; but still this problem is appearing . The orderer can start with the root cert only. The intermediate cert has been signed by the root CA btw
wyanglau (Thu, 08 Jun 2017 17:08:27 GMT):
Do I need to configure anything else to make the orderer trust the intermediate CA?
berestet (Thu, 08 Jun 2017 20:13:41 GMT):
Has joined the channel.
wyanglau (Thu, 08 Jun 2017 21:49:46 GMT):
btw while I generated a cert and signed it, then put it in `msp/intermediatecerts` , now the orderer/peer thrown ```panic: Error creating configtx manager and handlers: Setting up the MSP manager failed, err The supplied identity is not valid, Verify() returned x509: certificate has expired or is not yet valid```
wyanglau (Thu, 08 Jun 2017 21:49:58 GMT):
I am using the beta version
wyanglau (Thu, 08 Jun 2017 21:49:58 GMT):
just update to the beta version
kelvinzhong (Fri, 09 Jun 2017 03:43:11 GMT):
Has joined the channel.
kelvinzhong (Fri, 09 Jun 2017 03:47:21 GMT):
hi, i have read the docs of the configtxgen tool. Is that currently the configtxgen tool could only initialize the genesis block but could not add a new Org to the orderer and update the config right?
mastersingh24 (Fri, 09 Jun 2017 12:40:10 GMT):
[so this is happening when you first start the orderer? ](https://chat.hyperledger.org/channel/fabric-crypto?msg=YER3J537DMcNjb3m4) @wyanglau
mastersingh24 (Fri, 09 Jun 2017 13:01:20 GMT):
Message Attachments
mastersingh24 (Fri, 09 Jun 2017 13:01:20 GMT):
Message Attachments
mastersingh24 (Fri, 09 Jun 2017 13:01:20 GMT):
Message Attachments
dhwang (Fri, 09 Jun 2017 14:44:37 GMT):
Has joined the channel.
wyanglau (Fri, 09 Jun 2017 15:11:24 GMT):
Yes it is happening when first start the orderer. And the MSP you gave us is working. [ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=iCL7ETqoEskvkMjzG) @mastersingh24
wyanglau (Fri, 09 Jun 2017 15:13:34 GMT):
```debug: true
ca:
name: int-ca.org0
db:
type: mysql
datasource: 'root:password@tcp(mariadb:3306)/fabricca?parseTime=true&tls=custom'
tls:
enabled: true
certfiles: [/etc/hyperledger/fabric-ca-server-tls/ca-cert.pem]
client:
certfile: /etc/hyperledger/fabric-ca-server-tls/client-cert.pem
keyfile: /etc/hyperledger/fabric-ca-server-tls/client-key.pem
# Enable TLS
tls:
enabled: true
certfile: /etc/hyperledger/fabric-ca/ca/INT_CA_TLS_CERT.pem
keyfile: /etc/hyperledger/fabric-ca/ca/INT_CA_TLS_KEY.pem
intermediate:
tls:
enabled: true
certfiles: [/etc/hyperledger/fabric-ca/root-ca-tls-cert/ROOT_CA_TLS_CERT.pem]
registry:
# Maximum number of times a password/secret can be reused for enrollment
# (default: 0, which means there is no limit)
maxEnrollments: 0
# Contains user information which is used when LDAP is disabled
identities:
- name: admin
pass: password
type: client
affiliation: ""
attrs:
hf.Registrar.Roles: "client,user,peer,validator,auditor,ca"
hf.Registrar.DelegateRoles: "client,user,validator,auditor"
hf.Revoker: true
hf.IntermediateCA: true
ldap:
# Enables or disables the LDAP client (default: false). This is not used but we still need this section here
enabled: false
tls:
certfiles:
- ldap-server-cert.pem
client:
certfile: ldap-client-cert.pem
keyfile: ldap-client-key.pem
csr:
hosts:
- int-ca.org0
affiliations:
org0:
- department1```
wyanglau (Fri, 09 Jun 2017 15:14:21 GMT):
this is the config file we used to sign the intermediate CA. Do you mind sharing yours with us so that we can compare what is the difference ?
wyanglau (Fri, 09 Jun 2017 15:15:23 GMT):
< some thing/>
wyanglau (Fri, 09 Jun 2017 15:24:40 GMT):
btw with the cert generated by the above config, it thrown ```peer0.org0 | panic: Failed putting our own identity into the identity mapper: Could not obtain certification chain, err Invalid validation chain. Parent certificate should be a leaf of the certification tree``` when starting the peer
laliux (Fri, 09 Jun 2017 16:15:53 GMT):
Has joined the channel.
wyanglau (Fri, 09 Jun 2017 19:22:42 GMT):
@mastersingh24 Thanks we finally found the issue. It turns out that the peers are needed to be signed by intermediate CA instead of the root, which will make the trust chain works.
mastersingh24 (Fri, 09 Jun 2017 19:24:42 GMT):
Ah - great news
jrezwan (Sun, 11 Jun 2017 16:16:33 GMT):
Has joined the channel.
CedricHumbert (Mon, 12 Jun 2017 12:52:53 GMT):
Has joined the channel.
lm_nop (Mon, 12 Jun 2017 23:14:24 GMT):
Has joined the channel.
pvrbharg (Tue, 13 Jun 2017 16:45:26 GMT):
Has joined the channel.
pvrbharg (Tue, 13 Jun 2017 16:50:56 GMT):
@mastersingh24 We need to know how to run crypto-gen tool to use a customer provisioned root, intermediate (chained) and customer server provisioned certificates - so that we can setup a QA node instance that uses cryptographic material (x509 certs) for our various network entities with the certs are parked in the folder titled ``crypto-config``. We just want to use the same tool to generate crypto artifacts in the same manner - however we want to pass in the root and intermediate pem/key artifacts to the tool (parameterized). We do not mind some other way to generate these artifacts automatically (versus manually). At this point - we have customer generated key file, cert file and chain file running on a customer QA server. We want to run e2e sample on this server - with custom configurations. Thanks.
jtrayfield (Tue, 13 Jun 2017 19:35:09 GMT):
emdall:fabricv1beta jtray$ ./configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./channel-artifacts/orderer.genesis.block
2017-06-13 15:34:23.506 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-06-13 15:34:23.510 EDT [common/configtx/tool/localconfig] Load -> CRIT 002 Error unmarshaling config into struct: 8 error(s) decoding:
* 'Organizations[0]' has invalid keys: BCCSP
* 'Organizations[1]' has invalid keys: BCCSP
* 'Organizations[2]' has invalid keys: BCCSP
jtrayfield (Tue, 13 Jun 2017 19:35:18 GMT):
what am I doing wrong?
jtrayfield (Tue, 13 Jun 2017 19:36:30 GMT):
emdall:fabricv1beta jtray$ echo $FABRIC_CFG_PATH
/Users/jtray/git/fabricv1beta
jtrayfield (Tue, 13 Jun 2017 19:42:23 GMT):
ah, configtx.yaml changed from alpha2
farhan3 (Tue, 13 Jun 2017 20:01:51 GMT):
Hi - I have some certs that I generated for the peer msp using fabric-ca. In alpha2, these certs worked fine with the MSP lib. However, in beta, I get an MSP error when I start the peer:
```
peer-1_7051 | 2017-06-13 19:36:52.394 UTC [msp] getMspConfig -> INFO 001 crls folder not found at [/var/hyperledger/peer/config/msp/intermediatecerts]. Skipping
.: [stat /var/hyperledger/peer/config/msp/crls: no such file or directory]
peer-1_7051 | 2017-06-13 19:36:52.394 UTC [msp] getMspConfig -> INFO 002 MSP configuration file not found at [/var/hyperledger/peer/config/msp/config.yaml]: [st
at /var/hyperledger/peer/config/msp/config.yaml: no such file or directory]
peer-1_7051 | panic: Error when setting up MSP from directory /var/hyperledger/peer/config/msp: err The supplied identity is not valid, Verify() returned x509:
certificate has expired or is not yet valid
peer-1_7051 |
peer-1_7051 | goroutine 1 [running]:
peer-1_7051 | panic(0xc4d6c0, 0xc42026b040)
peer-1_7051 | /opt/go/src/runtime/panic.go:500 +0x1a1
peer-1_7051 | main.main()
peer-1_7051 | /opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:113 +0x69b
peer-1_7051 exited with code 2
```
Have some additional checks been added to the MSP lib? For example, I noticed that in the certs generated by the cryptogen tool, there is a `X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication` setting, but certs generated via fabric-ca don't have this.
farhan3 (Tue, 13 Jun 2017 20:11:46 GMT):
I have verified that the certs aren't expired. Basically, I have the alpha2 and beta images for the peer. Using the same msp dir, I can start the peer when using the alpha2 tag, but not when using the beta tag.
farhan3 (Tue, 13 Jun 2017 20:21:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=iCL7ETqoEskvkMjzG) @mastersingh24 How did you generate these certs? I tried using these and they work with alpha2 and beta. I looked at the int ca that you use vs the one generated via fabric-ca and yours has the `X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication` flag.
farhan3 (Tue, 13 Jun 2017 20:21:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=iCL7ETqoEskvkMjzG) @mastersingh24 How did you generate these certs? I tried using these and they work with alpha2 and beta.
farhan3 (Tue, 13 Jun 2017 21:56:39 GMT):
The issue has something to do with this commit: https://github.com/hyperledger/fabric/commit/7ca901e5964e32184db24912bb8859b785b6c012
The commit was for *FAB-3678 Bind blockchain time to real-world time (e.g., used for standard X.509 certificates expiration)*
yacovm (Tue, 13 Jun 2017 22:03:51 GMT):
why do you think so?
farhan3 (Tue, 13 Jun 2017 22:04:12 GMT):
In `fabric/msp/mspimpl.go`, if I change `line 692` from
```
validationChains, err := cert.Verify(msp.getValidityOptsForCert(cert))
```
Back to:
```
validationChains, err := cert.Verify(*(msp.opts))
```
It works
yacovm (Tue, 13 Jun 2017 22:05:04 GMT):
oh that's interesting
farhan3 (Tue, 13 Jun 2017 22:05:07 GMT):
And all msp.getValidityOptsForCert(cert) does is update the time
```
+func (msp *bccspmsp) getValidityOptsForCert(cert *x509.Certificate) x509.VerifyOptions {
+ // First copy the opts to override the CurrentTime field
+ // in order to make the certificate passing the expiration test
+ // independently from the real local current time.
+ // This is a temporary workaround for FAB-3678
+
+ var tempOpts x509.VerifyOptions
+ tempOpts.Roots = msp.opts.Roots
+ tempOpts.DNSName = msp.opts.DNSName
+ tempOpts.Intermediates = msp.opts.Intermediates
+ tempOpts.KeyUsages = msp.opts.KeyUsages
+ tempOpts.CurrentTime = cert.NotBefore.Add(time.Second)
+
+ return tempOpts
+}
```
yacovm (Tue, 13 Jun 2017 22:05:18 GMT):
well yeah I remember that change set
yacovm (Tue, 13 Jun 2017 22:05:35 GMT):
hmmm
yacovm (Tue, 13 Jun 2017 22:06:12 GMT):
ok let's do an experiment
yacovm (Tue, 13 Jun 2017 22:06:16 GMT):
can you put prints
yacovm (Tue, 13 Jun 2017 22:06:29 GMT):
to print the not before
yacovm (Tue, 13 Jun 2017 22:06:31 GMT):
and not after fields
yacovm (Tue, 13 Jun 2017 22:06:33 GMT):
of your cert?
farhan3 (Tue, 13 Jun 2017 22:07:19 GMT):
Sure, gimme a few minutes, I was cleaning my environment
yacovm (Tue, 13 Jun 2017 22:15:08 GMT):
@farhan3
yacovm (Tue, 13 Jun 2017 22:15:13 GMT):
you can also paste the PEM here
yacovm (Tue, 13 Jun 2017 22:15:24 GMT):
...
yacovm (Tue, 13 Jun 2017 22:15:29 GMT):
while you're cleaning
farhan3 (Tue, 13 Jun 2017 22:15:59 GMT):
ok, I don't know exactly which cert it is, I'll send you the entire msp dir.
yacovm (Tue, 13 Jun 2017 22:16:08 GMT):
sure
yacovm (Tue, 13 Jun 2017 22:16:16 GMT):
that'll work too...
farhan3 (Tue, 13 Jun 2017 22:19:22 GMT):
Message Attachments
farhan3 (Tue, 13 Jun 2017 22:19:36 GMT):
@yacovm
yacovm (Tue, 13 Jun 2017 22:19:43 GMT):
yeah I got that
farhan3 (Tue, 13 Jun 2017 22:19:53 GMT):
Wait sorry, wrong one...
farhan3 (Tue, 13 Jun 2017 22:19:56 GMT):
It was a tar.gz
yacovm (Tue, 13 Jun 2017 22:20:08 GMT):
ah damn
farhan3 (Tue, 13 Jun 2017 22:22:52 GMT):
Let me make a zip... tar.gz isn't allowed
yacovm (Tue, 13 Jun 2017 22:22:57 GMT):
ah
yacovm (Tue, 13 Jun 2017 22:22:59 GMT):
no
yacovm (Tue, 13 Jun 2017 22:23:03 GMT):
change it to
yacovm (Tue, 13 Jun 2017 22:23:05 GMT):
tar.gz.txt
yacovm (Tue, 13 Jun 2017 22:23:31 GMT):
you can send anything you want this way, rocket chat is superficial ;)
farhan3 (Tue, 13 Jun 2017 22:23:50 GMT):
Message Attachments
farhan3 (Tue, 13 Jun 2017 22:24:04 GMT):
Hah, worked
farhan3 (Tue, 13 Jun 2017 22:24:21 GMT):
I was wondering why msp.tar.gz wasn't even showing up in the list
yacovm (Tue, 13 Jun 2017 22:45:05 GMT):
ok
yacovm (Tue, 13 Jun 2017 22:45:09 GMT):
so... from some reason
yacovm (Tue, 13 Jun 2017 22:45:14 GMT):
adding 1 second isn't enough :O
yacovm (Tue, 13 Jun 2017 22:45:24 GMT):
I tried adding a day
yacovm (Tue, 13 Jun 2017 22:45:26 GMT):
for your certs
yacovm (Tue, 13 Jun 2017 22:45:28 GMT):
and it worked
farhan3 (Tue, 13 Jun 2017 22:45:45 GMT):
Oh, hmm
farhan3 (Tue, 13 Jun 2017 22:46:20 GMT):
These were generated via fabric-ca - if that matters
yacovm (Tue, 13 Jun 2017 22:49:18 GMT):
let me take a look at them
yacovm (Tue, 13 Jun 2017 22:50:27 GMT):
ahhhhhh
yacovm (Tue, 13 Jun 2017 22:50:34 GMT):
maybe it's because: `Not Before: Jun 13 18:50:00 2017 GMT`
farhan3 (Tue, 13 Jun 2017 22:50:40 GMT):
GMT?
yacovm (Tue, 13 Jun 2017 22:50:40 GMT):
isn't that... um
yacovm (Tue, 13 Jun 2017 22:50:45 GMT):
heh
yacovm (Tue, 13 Jun 2017 22:50:47 GMT):
wait a sec
yacovm (Tue, 13 Jun 2017 22:51:44 GMT):
hmmm so when did you generate
yacovm (Tue, 13 Jun 2017 22:51:47 GMT):
these certificates
yacovm (Tue, 13 Jun 2017 22:51:52 GMT):
did fabric-CA generate all of them?
farhan3 (Tue, 13 Jun 2017 22:52:04 GMT):
Yes
farhan3 (Tue, 13 Jun 2017 22:52:32 GMT):
I just generated another batch, let me check the time in the cert vs time on my machine
yacovm (Tue, 13 Jun 2017 22:52:45 GMT):
ah ok
yacovm (Tue, 13 Jun 2017 22:52:47 GMT):
I have an idea
yacovm (Tue, 13 Jun 2017 22:52:50 GMT):
why it doesn't work ;)
yacovm (Tue, 13 Jun 2017 22:52:52 GMT):
want to hear?
farhan3 (Tue, 13 Jun 2017 22:52:58 GMT):
Sure
yacovm (Tue, 13 Jun 2017 22:53:01 GMT):
so the verification options
farhan3 (Tue, 13 Jun 2017 22:53:04 GMT):
I'm thinking it's time zone related..
yacovm (Tue, 13 Jun 2017 22:53:06 GMT):
are computed for your certificate right?
yacovm (Tue, 13 Jun 2017 22:53:08 GMT):
nope
yacovm (Tue, 13 Jun 2017 22:53:11 GMT):
I think it's something else
farhan3 (Tue, 13 Jun 2017 22:53:23 GMT):
ok, right
yacovm (Tue, 13 Jun 2017 22:54:52 GMT):
ahh wait
yacovm (Tue, 13 Jun 2017 22:54:55 GMT):
you have 2 certificates
yacovm (Tue, 13 Jun 2017 22:55:12 GMT):
in the signcerts!
yacovm (Tue, 13 Jun 2017 22:55:15 GMT):
peer.pem and another one
yacovm (Tue, 13 Jun 2017 22:55:18 GMT):
why do you have 2?
farhan3 (Tue, 13 Jun 2017 22:55:37 GMT):
No I don't :/
yacovm (Tue, 13 Jun 2017 22:55:38 GMT):
so peer.pem ruins it all
yacovm (Tue, 13 Jun 2017 22:55:45 GMT):
wait
yacovm (Tue, 13 Jun 2017 22:56:04 GMT):
ah right
yacovm (Tue, 13 Jun 2017 22:56:06 GMT):
sorry my mistake
yacovm (Tue, 13 Jun 2017 22:56:09 GMT):
1 sec then
yacovm (Tue, 13 Jun 2017 22:58:16 GMT):
ok
yacovm (Tue, 13 Jun 2017 22:58:18 GMT):
solved it!
yacovm (Tue, 13 Jun 2017 22:58:24 GMT):
```
Not Before: Jun 13 18:51:00 2017 GMT
Not After : Jun 13 18:51:00 2018 GMT
```
this is the signing cert
yacovm (Tue, 13 Jun 2017 22:58:38 GMT):
this is the intermediate cert
```
Not Before: Jun 13 18:54:19 2017 GMT
Not After : Jun 11 18:54:19 2027 GMT
```
farhan3 (Tue, 13 Jun 2017 22:58:49 GMT):
Oh...
yacovm (Tue, 13 Jun 2017 22:58:49 GMT):
```
Not Before: Jun 13 18:50:00 2017 GMT
Not After : Jun 12 18:50:00 2022 GMT
```
yacovm (Tue, 13 Jun 2017 22:58:53 GMT):
this is the root ca cert
yacovm (Tue, 13 Jun 2017 22:59:00 GMT):
so when the cert is validated
yacovm (Tue, 13 Jun 2017 22:59:07 GMT):
the whole chain (I think) is validated
yacovm (Tue, 13 Jun 2017 22:59:14 GMT):
but the options are for the cert only
yacovm (Tue, 13 Jun 2017 22:59:24 GMT):
so 1 second + `18:51:00`
yacovm (Tue, 13 Jun 2017 22:59:32 GMT):
is less than the intermediate cert
yacovm (Tue, 13 Jun 2017 22:59:37 GMT):
I think that's the issue....
yacovm (Tue, 13 Jun 2017 22:59:51 GMT):
let me try to make it 5 min + the time and see
farhan3 (Tue, 13 Jun 2017 23:00:56 GMT):
5 min works
yacovm (Tue, 13 Jun 2017 23:02:04 GMT):
ah you tried?
farhan3 (Tue, 13 Jun 2017 23:02:05 GMT):
So somehow my int cert has a Not Before time that is after the Not Before time of the cert it signs...
yacovm (Tue, 13 Jun 2017 23:02:36 GMT):
I wonder how to fix this bug though.... I think maybe we should do something more smart than 1 second
yacovm (Tue, 13 Jun 2017 23:02:41 GMT):
maybe for example iterate over the chain
yacovm (Tue, 13 Jun 2017 23:02:45 GMT):
and compute the minimum
yacovm (Tue, 13 Jun 2017 23:02:51 GMT):
to be the max of not before
yacovm (Tue, 13 Jun 2017 23:03:00 GMT):
and the maximum to be the minimum of not after
farhan3 (Tue, 13 Jun 2017 23:03:43 GMT):
That would do it
farhan3 (Tue, 13 Jun 2017 23:03:55 GMT):
I'll add 5 minutes for now though :D
yacovm (Tue, 13 Jun 2017 23:04:14 GMT):
haha
yacovm (Tue, 13 Jun 2017 23:04:38 GMT):
I'll open a JIRA and we'll fix it
yacovm (Tue, 13 Jun 2017 23:04:41 GMT):
thanks a lot for the find
farhan3 (Tue, 13 Jun 2017 23:04:55 GMT):
Noo, thank you for the help :)
yacovm (Tue, 13 Jun 2017 23:07:51 GMT):
@farhan3
yacovm (Tue, 13 Jun 2017 23:07:57 GMT):
can I use your msp.tar.gz in the JIRA?
farhan3 (Tue, 13 Jun 2017 23:08:01 GMT):
Sure
yacovm (Tue, 13 Jun 2017 23:08:02 GMT):
as an example
yacovm (Tue, 13 Jun 2017 23:08:05 GMT):
ok just making sure
farhan3 (Tue, 13 Jun 2017 23:08:16 GMT):
Thanks for checking
farhan3 (Tue, 13 Jun 2017 23:09:57 GMT):
Can you let me know the JIRA id when you file it, so I can make a reference to it in my temporary fix
yacovm (Tue, 13 Jun 2017 23:16:55 GMT):
1 sec
yacovm (Tue, 13 Jun 2017 23:19:46 GMT):
https://jira.hyperledger.org/browse/FAB-4617
farhan3 (Tue, 13 Jun 2017 23:21:04 GMT):
Great, thank you!
alain2sf (Wed, 14 Jun 2017 07:48:10 GMT):
Has joined the channel.
reubent 1 (Wed, 14 Jun 2017 10:36:37 GMT):
Has joined the channel.
naolduga (Wed, 14 Jun 2017 17:18:33 GMT):
Has joined the channel.
shad0wpin9 (Thu, 15 Jun 2017 07:43:48 GMT):
Has joined the channel.
shad0wpin9 (Thu, 15 Jun 2017 07:44:44 GMT):
Hi，everyone
I read the source code of fabric and found that every connection can use SSL/TLS. Suppose that in situations where security requirement is high, all connections are configured to use SSL/TLS. Is it too “heavy” for the network of a lot of peers？ Or is there any solution for both performance and communication confidentiality？
yacovm (Thu, 15 Jun 2017 08:05:10 GMT):
Well since fabric, in contrast to web servers , use long-lasting TLS connections there isn't much performance penalty
yacovm (Thu, 15 Jun 2017 08:05:20 GMT):
because the expensive crypto stuff are in the handshake
yacovm (Thu, 15 Jun 2017 08:05:27 GMT):
after that you have symmetric encryption and decryption
yacovm (Thu, 15 Jun 2017 08:17:34 GMT):
I think the right model to compare the performance overhead of TLS in fabric is not to web servers but to stuff like MQTT over TLS, there are reviews / studies on the internet
yacovm (Thu, 15 Jun 2017 08:17:37 GMT):
@shad0wpin9
shad0wpin9 (Thu, 15 Jun 2017 08:20:04 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=uLCSBgsBLSGv8ziQG) @yacovm Thank you very much!
simsc (Thu, 15 Jun 2017 13:49:23 GMT):
Has joined the channel.
mastersingh24 (Thu, 15 Jun 2017 14:01:32 GMT):
@nhrishi - what's your environment? e.g. Linux, Windows, macOS, Vagrant?
(https://chat.hyperledger.org/channel/fabric-ca?msg=hvimTPy8CFQQK4ZAP)
SotirisAlfonsos (Thu, 15 Jun 2017 14:25:38 GMT):
Has joined the channel.
ecn (Thu, 15 Jun 2017 15:19:29 GMT):
Has joined the channel.
s.narayanan (Thu, 15 Jun 2017 16:31:58 GMT):
Is transient field supported in Alpha 1? We are looking to use the transient field in transaction proposal to pass in user role information for access control checks that chaincode needs to perform. Since Tcerts are not supported, this was the work around. If transient field is not supported, we may have to just pass in the role information in the operation signature (not ideal but again as a workaround for now).
guillermo.correa (Thu, 15 Jun 2017 22:12:09 GMT):
Hello,
I am trying to use an external certificate. This PoC y use an OpenSSL server and I generate the intermediate cert and a cert.
In the msp, I put the intermediate cert in intermediatecerts folder and the device certificate in the cacerts folder.
When I excecute the configtxgen tool, I get this error message:
"2017-06-15 19:07:12.881 CLT [configvalues/msp] TemplateGroupMSPWithAdminRolePrincipal -> CRIT 004 Setting up the MSP manager failed, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority
panic: Setting up the MSP manager failed, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority" and the intermediatecerts folder not found.
Please, someone can help me o suggest me something.
By the way, I am using OpenSuSe and the fabric beta version.
Thanks
guillermo.correa (Thu, 15 Jun 2017 22:13:45 GMT):
Message Attachments
mastersingh24 (Thu, 15 Jun 2017 22:14:45 GMT):
@guillermo.correa - you need to have the whole chain (i.e. both the root certificate as well as the intermediate root certificate) in the MSP. The root certificate should go in `cacerts` and the intermediate should go in `intermediatecerts` . If you want the signed certificate to be in the admin group, then add that to the `admincerts` folder
gauravgiri (Fri, 16 Jun 2017 05:46:26 GMT):
Has joined the channel.
nhrishi (Fri, 16 Jun 2017 06:54:01 GMT):
@mastersingh24 I'm running it on AWS RHEL instance. This is what i observed. The issue only when you bring up the network and try to connect and invoke a chaincode. I dont get the error after few mins. This may be due to some network is still running processes (some one mentioned clock synchronization related issue).
akdj (Fri, 16 Jun 2017 08:12:31 GMT):
Has joined the channel.
mastersingh24 (Fri, 16 Jun 2017 08:31:55 GMT):
@nhrishi - it's possible that it's a time sync error - that is what I was thinking as well
CodeReaper (Fri, 16 Jun 2017 09:57:45 GMT):
Has joined the channel.
CodeReaper (Fri, 16 Jun 2017 10:06:40 GMT):
Hey Ive done some changes in the crypto-config file and configtx file for customizing my own environment and organizations, Orderer genesis block, channel cofiguration(channel.tx) and anchor peer generation is correctly done, but at the beginning it threw a few warming/errors for certificate generations. I checked the folder I do see some pem files and certs if not all. What is it Im seeing and what couldve caused it?? Any help would be appreciated thanks.
CodeReaper (Fri, 16 Jun 2017 10:06:50 GMT):
Message Attachments
ericmvaughn (Fri, 16 Jun 2017 14:05:46 GMT):
@nhrishi @mastersingh24 I hit a a problem that sounds the same. What I found is that if the user is registered and enrolled within the first 4 minutes after building the network then I see the certificate error. Waiting 5 minutes or more before registering/enrolling the user and the invoke works. I created jira FAB-4825 for it.
husky-parul (Fri, 16 Jun 2017 14:39:14 GMT):
Has joined the channel.
husky-parul (Fri, 16 Jun 2017 14:40:38 GMT):
Hi
I am following the get started tutorial of Hyperledger
I am running the scripts manually instead of using network.sh up
However in the create & join the channel , while running the script to get channel-id.block I am getting the below error.
2017-06-15 20:18:45.664 UTC [grpc] Printf -> DEBU 006 Failed to dial orderer.example.com:7050: connection error: desc = "transport: authentication handshake failed: x509: certificate has expired or is not yet valid"; please retry.Error: Error connecting due to rpc error: code = Internal desc = connection error: desc = "transport: authentication handshake failed: x509: certificate has expired or is not yet valid"
Can someone please help to resolve this?
husky-parul (Fri, 16 Jun 2017 14:41:37 GMT):
Message Attachments
scm197 (Fri, 16 Jun 2017 16:50:28 GMT):
Has joined the channel.
jtrayfield (Fri, 16 Jun 2017 17:23:22 GMT):
is this still accurate re the nonce? https://hyperledger-fabric.readthedocs.io/en/stable/protocol-spec/#4-security_1
jtrayfield (Fri, 16 Jun 2017 17:23:51 GMT):
In the fabric, replay attack protection uses a hybrid approach. That is, users add in the transaction a nonce that is generated in a different manner depending on whether the transaction is anonymous (followed and signed by a transaction certificate) or not (followed and signed by a long term enrollment certificate). More specifically:
Users submitting a transaction with their enrollment certificate should include in that transaction a nonce that is a function of the nonce they used in the previous transaction they issued with the same certificate (e.g., a counter function or a hash).
jtrayfield (Fri, 16 Jun 2017 17:24:26 GMT):
the nonce in TransactionID seems to be generated at random each time
guillermo.correa (Fri, 16 Jun 2017 19:32:39 GMT):
t [ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=r3iDGaK629uL4CCAE) @mastersingh24 thanks.
snowy13 (Sat, 17 Jun 2017 05:28:49 GMT):
Has joined the channel.
nhrishi (Sun, 18 Jun 2017 04:18:38 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=d93tDydb4w9hYG9pu) @ericmvaughn [ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=d93tDydb4w9hYG9pu) @ericmvaughn Thats correct. my observation is also the same.
SotirisAlfonsos (Sun, 18 Jun 2017 15:17:45 GMT):
Hello, what is the correct way to create certificates for 4 orderers that belong in a kafka cluster?
SotirisAlfonsos (Sun, 18 Jun 2017 15:17:45 GMT):
Hello, what is the correct way to create certificates for 4 orderers that will be part of a kafka cluster?
jeffgarratt (Sun, 18 Jun 2017 15:40:04 GMT):
@SotirisAlfonsos if the orderers all belong to the same organization, you can generate them by having the Orderers CA (from the MSP config) sign the certs for each orderer.
SotirisAlfonsos (Sun, 18 Jun 2017 15:53:10 GMT):
@jeffgarratt hmm i was trying to work without an Orderer CA. I will try this approach. thanks
sfukazu (Mon, 19 Jun 2017 06:34:30 GMT):
Has joined the channel.
mariogemoll (Mon, 19 Jun 2017 13:14:27 GMT):
Has joined the channel.
praveennagpal (Mon, 19 Jun 2017 16:54:53 GMT):
Has joined the channel.
bh4rtp (Tue, 20 Jun 2017 00:16:40 GMT):
hi, what is the cause of below error reported during peer starting.
```2017-06-19 19:42:40.160 CST [gossip/discovery] handleAliveMessage -> ERRO 1ce Bad configuration detected: Received AliveMessage from a peer with the same PKI-ID as myself: tag:EMPTY alive_msg:
bh4rtp (Tue, 20 Jun 2017 00:18:04 GMT):
the message seems to say that `peer0.org1.example.com` and `peer1.org1.example.com` have the same PKI-ID.
yacovm (Tue, 20 Jun 2017 04:48:38 GMT):
Thats probably because they have the same certificate @bh4rtp
yacovm (Tue, 20 Jun 2017 04:48:50 GMT):
And this has nothing to do with fabric-crypto
yacovm (Tue, 20 Jun 2017 04:48:59 GMT):
Pleasr move this to ghe gossip channel
bh4rtp (Tue, 20 Jun 2017 05:44:45 GMT):
ok
dongqi (Tue, 20 Jun 2017 08:35:16 GMT):
Has joined the channel.
roj (Tue, 20 Jun 2017 08:38:54 GMT):
Has joined the channel.
zemtsov (Wed, 21 Jun 2017 13:27:48 GMT):
Has joined the channel.
SotirisAlfonsos (Thu, 22 Jun 2017 08:23:39 GMT):
Hello. I would like to ask how the cryptogen.yaml file should be structured to create certs for multiple orderers (lets say 4). How could it be done without a ca?
yacovm (Thu, 22 Jun 2017 08:25:22 GMT):
@SotirisAlfonsos there is a command
yacovm (Thu, 22 Jun 2017 08:25:31 GMT):
cryptogen showtemplate
SotirisAlfonsos (Thu, 22 Jun 2017 08:30:32 GMT):
@yacovm Thank you i am aware of this template. However no matter what approach it try i can not manage to work with more than one orderers. I have narrowed it down to a cert fault probably, that is why i wanted to know if there is an example somewhere.
SotirisAlfonsos (Thu, 22 Jun 2017 08:30:32 GMT):
@yacovm Thank you i am aware of this template. However no matter what approach i try i can not manage to work with more than one orderers. I have narrowed it down to a cert fault probably, that is why i wanted to know if there is an example somewhere.
yacovm (Thu, 22 Jun 2017 08:31:00 GMT):
ah I didn't read the last half of your question
yacovm (Thu, 22 Jun 2017 08:31:39 GMT):
but why can't you just expand the array of `- Hostname:`
yacovm (Thu, 22 Jun 2017 08:31:42 GMT):
won't that work?
SotirisAlfonsos (Thu, 22 Jun 2017 08:36:19 GMT):
@yacovm No it did not work. But in that approach wouldn't we need a ca to validate the certs?
yacovm (Thu, 22 Jun 2017 08:36:51 GMT):
well cryptogen generates certs that are signed by the CA certs
SotirisAlfonsos (Thu, 22 Jun 2017 08:38:10 GMT):
Hm ok that makes sense
mastersingh24 (Thu, 22 Jun 2017 10:45:11 GMT):
@SotirisAlfonsos - exactly what issue are you having? Are you trying to create multiple orderer nodes for a single orderer organization or multiple orderer organizations?
mastersingh24 (Thu, 22 Jun 2017 10:45:18 GMT):
```
# ---------------------------------------------------------------------------
# "OrdererOrgs" - Definition of organizations managing orderer nodes
# ---------------------------------------------------------------------------
OrdererOrgs:
# ---------------------------------------------------------------------------
# Orderer
# ---------------------------------------------------------------------------
- Name: Orderer
Domain: example.com
# ---------------------------------------------------------------------------
# "Specs" - See PeerOrgs below for complete description
# ---------------------------------------------------------------------------
Template:
Count: 5
```
mastersingh24 (Thu, 22 Jun 2017 10:45:47 GMT):
The above will create the crypto material for 5 orderer nodes that belong to the same organization
SotirisAlfonsos (Thu, 22 Jun 2017 10:46:27 GMT):
@mastersingh24 Yes that is what i wanted to do. Thank you.
mastersingh24 (Thu, 22 Jun 2017 10:46:55 GMT):
sure thing
ThePleasurable (Sat, 24 Jun 2017 12:29:09 GMT):
Has joined the channel.
rickr (Mon, 26 Jun 2017 22:00:07 GMT):
@ashutosh_kumar and other crypto experts here. Is there a way simple way to verify a private key matches the public key in a certificate ? Other then signing and verifying something ? The JSDK get's this from the end user and I'm looking for something that's computationally inexpensive when lets say in debug mode that the SDK will do this verification to assure that the user has not in some way messed that those parings up.
rickr (Mon, 26 Jun 2017 22:00:07 GMT):
@ashutosh_kumar and other crypto experts here. Is there a way simple way to verify a private key matches the public key in a certificate ? Other then signing and verifying something ? The JSDK get's this from the end user and I'm looking for something that's computationally inexpensive when lets say in debug mode that the SDK will do this verification to assure that the user has not in some way messed those pair up.
berserkr (Mon, 26 Jun 2017 22:22:28 GMT):
@rickr do you have access to the private key?
berserkr (Mon, 26 Jun 2017 22:22:32 GMT):
and the pub key?
jeffgarratt (Mon, 26 Jun 2017 23:26:41 GMT):
@rickr hey rick. You can get the public key from the cert and create a verifying key. Then sign a message with the private key, then ask the verffying key to verify the sig and data
rickr (Mon, 26 Jun 2017 23:35:35 GMT):
Jeff thanks, but was hoping for something less computationally expensive. Like getting the d value for the private key if that's even possible and comparing that with some values obtainable from the public key.
Yes, @berserkr have certificate thus public and private key.
berserkr (Tue, 27 Jun 2017 00:05:35 GMT):
@rickr For RSA-based keys it is easier than ECDSA, follow the steps here for rsa: https://security.stackexchange.com/questions/56697/determine-if-private-key-belongs-to-certificate, ecdsa: https://security.stackexchange.com/questions/73127/how-can-you-check-if-a-private-key-and-certificate-match-in-openssl-with-ecdsa --- if within your code, you can use openssl bindings perhaps
shanlusun (Tue, 27 Jun 2017 03:58:38 GMT):
Hello， anyone knows in chaincode how to unmarshal the Signature bytes inside SignedProposal？ I tried to import "github.com/golang/protobuf/proto", but this is not provided by peer image by default.
dave.enyeart (Tue, 27 Jun 2017 12:08:31 GMT):
@rezamt, I'm posting your question here:
rezamt (Tue, 27 Jun 2017 12:08:32 GMT):
Has joined the channel.
dave.enyeart (Tue, 27 Jun 2017 12:08:35 GMT):
>Hi guys, I have a question regarding to the user accounts admin1 and user1 in fabric crypto-config.
a) Why do we need o create them ?
b) Is there any role / definition of permission between these two user accounts?
c) How can I use them ? the application of them.
dave.enyeart (Tue, 27 Jun 2017 12:08:35 GMT):
>Hi guys, I have a question regarding to the user accounts admin1 and user1 in fabric crypto-config.
>a) Why do we need o create them ?
>b) Is there any role / definition of permission between these two user accounts?
>c) How can I use them ? the application of them.
rezamt (Tue, 27 Jun 2017 12:09:08 GMT):
thank you dave. I wasn't sure to post it here
dave.enyeart (Tue, 27 Jun 2017 13:35:43 GMT):
@rezamt Your questions are partially answered in a mailing list posting today:
dave.enyeart (Tue, 27 Jun 2017 13:35:46 GMT):
1) Chaincode must be installed on each individual peer. Only an administrator from peer's organization can install chaincode. An administrator is defined as the holder of a certificate which is part of the admincerts for the peer's local MSP
You can find more details at http://hyperledger-fabric.readthedocs.io/en/latest/chaincode4noah.html#installing-chaincode although it looks like the note in the last line about needing to be an admin should be highlighted
2) In order to instantiate chaincode on a channel, the submitter of the transaction must be a member of an organization which is part of the channel (and have write access) and if you don't attach an instantiation policy must also again be an administrator for it's organization. You can find more details at http://hyperledger-fabric.readthedocs.io/en/latest/chaincode4noah.html#instantiate
rezamt (Tue, 27 Jun 2017 13:37:29 GMT):
@dave.enyeart I am looking at sample https://github.com/hyperledger/fabric-samples/tree/master/balance-transfer
rezamt (Tue, 27 Jun 2017 13:37:37 GMT):
and I am going to read the links above
rezamt (Tue, 27 Jun 2017 13:37:40 GMT):
thanks
ashutosh_kumar (Tue, 27 Jun 2017 14:08:40 GMT):
@rickr : For elliptic curve , the D value of Private Key is unique and the public key is being computed by doing Group mathematics operation using Cuve base point and D. For that reason , in Go , Private Key object contains public key also.
ashutosh_kumar (Tue, 27 Jun 2017 14:09:19 GMT):
Same kind of implementation must exist on Bouncy Castle or Java Crypto.
ashutosh_kumar (Tue, 27 Jun 2017 14:10:48 GMT):
So , get public key from cert and compare it with Public Key field of Private Key object.
rickr (Tue, 27 Jun 2017 14:11:18 GMT):
k will look closer into it.
ashutosh_kumar (Tue, 27 Jun 2017 14:11:48 GMT):
ok.
rickr (Tue, 27 Jun 2017 14:15:32 GMT):
The Java PrivateKey does not have a means to get the public key ...
webdaford (Tue, 27 Jun 2017 18:46:16 GMT):
Has joined the channel.
jeroiraz (Wed, 28 Jun 2017 14:41:52 GMT):
Has joined the channel.
sandroku63 (Mon, 03 Jul 2017 03:14:45 GMT):
Has joined the channel.
awattez (Mon, 03 Jul 2017 16:01:27 GMT):
Has joined the channel.
jaswanth (Tue, 04 Jul 2017 06:14:30 GMT):
Has joined the channel.
zaishengming (Tue, 04 Jul 2017 07:02:25 GMT):
Has joined the channel.
nhrishi (Tue, 04 Jul 2017 09:54:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=d93tDydb4w9hYG9pu) @ericmvaughn Thanks !!
tennenjl (Wed, 05 Jul 2017 16:55:14 GMT):
Has joined the channel.
tennenjl (Wed, 05 Jul 2017 16:55:20 GMT):
Hi Team, has anyone done any sort of integration between MSP and OAuth, or has there been any thought around OAuth authentication? Thanks!
Tigermisu (Wed, 05 Jul 2017 19:38:34 GMT):
Has joined the channel.
guoger (Thu, 06 Jul 2017 00:04:47 GMT):
Has joined the channel.
moulali308 (Thu, 06 Jul 2017 04:18:26 GMT):
Has joined the channel.
VamsiKrishnak (Thu, 06 Jul 2017 14:35:00 GMT):
Has joined the channel.
jarroyer (Thu, 06 Jul 2017 14:39:51 GMT):
Has joined the channel.
smithbk (Fri, 07 Jul 2017 13:11:12 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=C9MgEzD5PbLnizbyB) @tennenjl I've thought about supporting Open ID Connect for authenticating an enrollment request to the fabric CA.
jmcnevin (Fri, 07 Jul 2017 16:25:51 GMT):
Has joined the channel.
ashutosh_kumar (Fri, 07 Jul 2017 18:26:50 GMT):
@tennenjl , can you please highlight your use case for MSP-oAuth integration ? oAuth is one kind of authorization mechanism of we need to first determine whether it fits fabric model.
ashutosh_kumar (Fri, 07 Jul 2017 18:26:50 GMT):
@tennenjl , can you please highlight your use case for MSP-oAuth integration ? oAuth is one kind of authorization mechanism and we need to first determine whether it fits fabric model.
tennenjl (Sat, 08 Jul 2017 01:39:57 GMT):
@ashutosh_kumar I have been working with a partner on an opportunity where there was a stated requirement to integrate with an existing PKI solution, where I was told that the existing solution supported OAuth as the authentication mechanism. Thanks.
ashutosh_kumar (Sat, 08 Jul 2017 02:17:14 GMT):
@tennenjl , oAuth is for authorization. OpenId connect uses openId for authentication and oAuth for authorization. Based on what you described , looks like MSP or elements that comprise MSP is going to be used as resource to be protected by oAuth.
ashutosh_kumar (Sat, 08 Jul 2017 02:18:15 GMT):
It can be integrated outside of fabric.
ashutosh_kumar (Sat, 08 Jul 2017 02:18:15 GMT):
It can be integrated outside of fabric meaning thereby Fabric will not act as oAuth Authorization Server.
DannyWong (Sat, 08 Jul 2017 03:27:17 GMT):
Has joined the channel.
kuperlen (Sat, 08 Jul 2017 12:10:13 GMT):
Has joined the channel.
kuperlen (Sat, 08 Jul 2017 12:13:22 GMT):
@husky-parul , if you're using e2e running manually instructions, try using different paths for the certification files:
kuperlen (Sat, 08 Jul 2017 12:13:22 GMT):
@husky-parul , if you're using e2e running manually instructions, try using different paths for the certification files:
kuperlen (Sat, 08 Jul 2017 12:13:56 GMT):
e2e example doc needs new paths for --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem in peer channel create, peer chaincode instantiate, and peer chaincode invoke examples for example02 and marbles02 examples. Examples stopped working with the old paths starting with fabric v1.0.0-rc1 tag.
Glen (Mon, 10 Jul 2017 15:25:56 GMT):
Has joined the channel.
Glen (Mon, 10 Jul 2017 15:29:51 GMT):
Hi, Is there any information about How MSP works, like its architecture and how it works
yacovm (Mon, 10 Jul 2017 15:38:08 GMT):
https://hyperledger-fabric.readthedocs.io/en/latest/msp.html
yacovm (Mon, 10 Jul 2017 15:38:10 GMT):
@Glen ^
Glen (Mon, 10 Jul 2017 15:41:52 GMT):
yes, I know it, I'm confused with why it needs so many certificates and how the certificates effect, can give some introduction about this ? thanks@yacovm
jaswanth (Wed, 12 Jul 2017 06:51:22 GMT):
Iam going through the official getting-started guide (hyperledger-fabric-rc1). I done it before and its successful .but now when I run( in windows ) `./byfn.sh -m up -c mychannel` getting an error ``` Cannot run peer because error when setting up MSP from directory /etc/hyperledger/fabric/msp: err CA Certificate is not valid``` i had my crypto files. any help with this
jtrayfield (Wed, 12 Jul 2017 14:08:07 GMT):
I'm having trouble accessing the MSP. I copied and pasted this code from msp_test.go:
conf, err := msp.GetLocalMspConfig("/etc/hyperledger/fabric/msp", nil, "xxx")
if err != nil {
logger.Infof("Setup should have succeeded, got err %s instead", err)
return
}
but I get this error:
01:59:24.427 [main] main.go:874 INFO : Setup should have succeeded, got err Could not load a valid signer certificate from directory /etc/hyperledger/fabric/msp/signcerts, err stat /etc/hyperledger/fabric/msp/signcerts: no such file or directory instead
"ls" shows the directory exists. Any ideas?
farhan3 (Wed, 12 Jul 2017 16:14:36 GMT):
@jtrayfield Permissions issue maybe?
jtrayfield (Wed, 12 Jul 2017 16:15:28 GMT):
@farhan3 no, I think it's because the chaincode server must have had chroot() called when it started....
jaswanth (Thu, 13 Jul 2017 05:54:43 GMT):
iam trying to run official getting started . when i run `./byfn.sh -m up -c mychannel` only cli is running the peer are stopping with ``` Cannot run peer because error when setting up MSP from directory /etc/hyperledger/fabric/msp: err CA Certificate is not valid``` .. can anyone help me with this
jaswanth (Thu, 13 Jul 2017 05:54:43 GMT):
iam trying to run official getting started . when i run `./byfn.sh -m up -c mychannel` only cli (fabric-tools) is running all the peer containers are stopping with ``` Cannot run peer because error when setting up MSP from directory /etc/hyperledger/fabric/msp: err CA Certificate is not valid``` .. can anyone help me with this
jaswanth (Thu, 13 Jul 2017 05:54:43 GMT):
iam trying to run official getting started . when i run `./byfn.sh -m up -c mychannel` only cli (fabric-tools) is running and all the peer containers are stopping with ``` Cannot run peer because error when setting up MSP from directory /etc/hyperledger/fabric/msp: err CA Certificate is not valid``` .. can anyone help me with this
Rouven (Thu, 13 Jul 2017 12:25:53 GMT):
Has joined the channel.
pschnap (Thu, 13 Jul 2017 13:13:20 GMT):
Has joined the channel.
pschnap (Thu, 13 Jul 2017 13:17:46 GMT):
@jaswanth did you generate the crypto material beforehand? You have to run `./byfn.sh -m generate -c mychannel` once before you can run `up` or `down`
pschnap (Thu, 13 Jul 2017 13:19:29 GMT):
you may also have to install the crypto generation programs to get that work, see https://hyperledger-fabric.readthedocs.io/en/latest/samples.html
VamsiKrishnak (Thu, 13 Jul 2017 13:37:54 GMT):
@here why which cryptogen is not working for me?
cbf (Thu, 13 Jul 2017 13:38:44 GMT):
did you install via the directions here http://hyperledger-fabric.readthedocs.io/en/latest/samples.html#binaries ?
cbf (Thu, 13 Jul 2017 13:39:18 GMT):
if so, then you will want to add
VamsiKrishnak (Thu, 13 Jul 2017 13:41:08 GMT):
No, But after configuring fabric it should show.
cbf (Thu, 13 Jul 2017 13:44:13 GMT):
after configuring fabric, meaning you deployed a network and it is not found inside the containers?
cbf (Thu, 13 Jul 2017 13:45:22 GMT):
cryptogen and configtxgen etc are not included in the containers - they are distributed as platform-specific binaries
cbf (Thu, 13 Jul 2017 13:46:10 GMT):
we are working on developing platform-specific installers (e.g. Homebrew for Mac)
VamsiKrishnak (Thu, 13 Jul 2017 13:51:28 GMT):
thanks
thakkarparth007 (Thu, 13 Jul 2017 14:12:12 GMT):
Has joined the channel.
thakkarparth007 (Thu, 13 Jul 2017 14:12:55 GMT):
Hello, I'm looking at the bccsp implementation, and was wondering how certificate revocations are handled.
thakkarparth007 (Thu, 13 Jul 2017 14:13:15 GMT):
Like, does the bccsp instance get rebuilt in case the certs change?
thakkarparth007 (Thu, 13 Jul 2017 14:13:19 GMT):
How does it work?
adc (Fri, 14 Jul 2017 06:02:23 GMT):
@thakkarparth007 bccsp does not handle directly certificates. Are you referring to MSP? In that case, if the MSPs get reconfigured in a channel then when the committing peer will parse that configuration transaction, it will reload the MSPs
adc (Fri, 14 Jul 2017 06:03:56 GMT):
for the local MSP on a peer, an administrator needs to change it manually and restart the peer
adc (Fri, 14 Jul 2017 06:04:07 GMT):
does this answer your question?
thakkarparth007 (Fri, 14 Jul 2017 08:35:16 GMT):
Yes, it does. Thank you.
tiennv (Fri, 14 Jul 2017 09:13:20 GMT):
Has joined the channel.
yifanxiang (Fri, 14 Jul 2017 09:32:04 GMT):
Has joined the channel.
yifanxiang (Fri, 14 Jul 2017 09:32:49 GMT):
hi,I want add a org3 to exists orderer(orderer's genesis.block only org1 and org2).how should I do?
Rachitga (Fri, 14 Jul 2017 09:40:48 GMT):
Has joined the channel.
Rachitga (Fri, 14 Jul 2017 10:17:43 GMT):
Hello all, I was facing some trouble regarding the certificates,
I am running the java sdk client, and the whole setup that has been mentioned here,
https://github.com/hyperledger/fabric-sdk-java
when I regenerate the certificates inside crypto-config using
build/bin/cryptogen generate --config crypto-config.yaml --output=crypto-config
I get the following error:
The ca containers stopped starting due to the following error:
The error the ca-service gives is this:
ca_peerOrg1 | Error: Failed to store certificate: open /etc/hyperledger/fabric-ca-server-config/ca.org1.example.com-cert.pem: read-only file system
ca_peerOrg1 exited with code 1
After receiving this error, I changed inside some things inside the docker-compose file,
```
ca0:
image: hyperledger/fabric-ca${IMAGE_TAG_FABRIC_CA}
environment:
- FABRIC_CA_HOME=/etc/hyperledger/fabric-ca-server
ports:
- "7054:7054"
command: sh -c 'fabric-ca-server start --ca.certfile /etc/hyperledger/fabric-ca-server-config/ca.org1.example.com-cert.pem --ca.keyfile /etc/hyperledger/fabric-ca-server-config/bbb1df5d64a2477f94c718a384db675cf23ac22364b157a492bf2a952bf26be2_sk -b admin:adminpw ${ORG_HYPERLEDGER_FABRIC_SDKTEST_INTEGRATIONTESTS_CA_TLS} --tls.certfile /etc/hyperledger/fabric-ca-server-config/ca.org1.example.com-cert.pem --tls.keyfile /etc/hyperledger/fabric-ca-server-config/bbb1df5d64a2477f94c718a384db675cf23ac22364b157a492bf2a952bf26be2_sk -d'
volumes:
- ./e2e-2Orgs/channel/crypto-config/peerOrganizations/org1.example.com/ca/:/etc/hyperledger/fabric-ca-server-config:rw
container_name: ca_peerOrg1
ca1:
image: hyperledger/fabric-ca${IMAGE_TAG_FABRIC_CA}
environment:
- FABRIC_CA_HOME=/etc/hyperledger/fabric-ca-server
ports:
- "8054:7054"
command: sh -c 'fabric-ca-server start --ca.certfile /etc/hyperledger/fabric-ca-server-config/ca.org2.example.com-cert.pem --ca.keyfile /etc/hyperledger/fabric-ca-server-config/f32d52f74d7607ab296e612c7dd7fa09cba597b1cb8b7c3ad81742205d5f0666_sk -b admin:adminpw ${ORG_HYPERLEDGER_FABRIC_SDKTEST_INTEGRATIONTESTS_CA_TLS} --tls.certfile /etc/hyperledger/fabric-ca-server-config/ca.org2.example.com-cert.pem --tls.keyfile /etc/hyperledger/fabric-ca-server-config/f32d52f74d7607ab296e612c7dd7fa09cba597b1cb8b7c3ad81742205d5f0666_sk -d'
volumes:
- ./e2e-2Orgs/channel/crypto-config/peerOrganizations/org2.example.com/ca/:/etc/hyperledger/fabric-ca-server-config:rw
container_name: ca_peerOrg2
```
note that the volumes are changed from ro to rw
after i made these changes am getting the following error:
Principal deserialization failed: (The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "ca.org1.example.com"))
Rachitga (Fri, 14 Jul 2017 10:17:43 GMT):
Hello all, I was facing some trouble regarding the certificates,
I am running the java sdk client, and the whole setup that has been mentioned here,
https://github.com/hyperledger/fabric-sdk-java
when I regenerate the certificates inside crypto-config using
build/bin/cryptogen generate --config crypto-config.yaml --output=crypto-config
I get the following error:
The ca containers stopped starting due to the following error:
The error the ca-service gives is this:
ca_peerOrg1 | Error: Failed to store certificate: open /etc/hyperledger/fabric-ca-server-config/ca.org1.example.com-cert.pem: read-only file system
ca_peerOrg1 exited with code 1
After receiving this error, I changed inside some things inside the docker-compose file,
```
volumes:
- ./e2e-2Orgs/channel/crypto-config/peerOrganizations/org1.example.com/ca/:/etc/hyperledger/fabric-ca-server-config:rw
container_name: ca_peerOrg1
volumes:
- ./e2e-2Orgs/channel/crypto-config/peerOrganizations/org2.example.com/ca/:/etc/hyperledger/fabric-ca-server-config:rw
container_name: ca_peerOrg2
```
note that the volumes are changed from ro to rw
after i made these changes am getting the following error:
Principal deserialization failed: (The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "ca.org1.example.com"))
Does anyone know how to fix these certificate errors?
mastersingh24 (Fri, 14 Jul 2017 11:25:55 GMT):
@Rachitga - Hard to say what the issue is without your setup, but the "ro" versus "rw" leads me to believe that you might not have change the value of the value of the `--ca.keyfile` option in the command here https://github.com/hyperledger/fabric-sdk-java/blob/master/src/test/fixture/sdkintegration/docker-compose.yaml#L15
Rachitga (Fri, 14 Jul 2017 11:39:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=ejXr4WE57826RCYNR) @mastersingh24 thanks! I understood what you are mentioning, I will try it out.
Rachitga (Sat, 15 Jul 2017 06:34:42 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=ejXr4WE57826RCYNR) @mastersingh24 Thanks! This worked.
cre8bidio (Mon, 17 Jul 2017 00:44:40 GMT):
Has joined the channel.
qsmen (Mon, 17 Jul 2017 07:15:37 GMT):
Has joined the channel.
qsmen (Mon, 17 Jul 2017 07:16:55 GMT):
fabric is based on pki, why not base it on ibs(identity based signature)?
JonathanTan (Mon, 17 Jul 2017 09:22:36 GMT):
Message Attachments
JonathanTan (Mon, 17 Jul 2017 09:23:42 GMT):
Hi Everyone, does anyone know what does this error mean? I generated crypto material, network is able to start ok, but channel creation just does not seem to work
jeffgarratt (Mon, 17 Jul 2017 14:31:49 GMT):
@JonathanTan this means that you have not signed the config update TX per the policy required
jeffgarratt (Mon, 17 Jul 2017 14:31:49 GMT):
@JonathanTan this means that you have not signed the config update TX per the policy required (In this case I assume the create channel request)
jeffgarratt (Mon, 17 Jul 2017 14:33:04 GMT):
this is controlled by the channel creation policy specified for the consortium for which the channel is to be created
jtrayfield (Mon, 17 Jul 2017 14:33:14 GMT):
I'm having trouble with the v1.0 version of fabric:
2017-07-17 14:18:01.374 UTC [main] main -> ERRO 001 Cannot run peer because error when setting up MSP from directory /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/oats.ibm.com/users/Admin@oats.ibm.com/msp: err admin 0 is invalid, validation error Could not obtain certification chain, err A CA certificate cannot be used directly by this MSP
DennisM330 (Mon, 17 Jul 2017 14:33:36 GMT):
What needs to be considered when using a 3rd party CA authority for the Membership Provider in Hyperledger Fabric 1.0? Any useful papers published on this?
yacovm (Mon, 17 Jul 2017 14:34:28 GMT):
read the MSP section in the docs, Dennis
jtrayfield (Mon, 17 Jul 2017 15:03:15 GMT):
I get the same problem running through https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html
jtrayfield (Mon, 17 Jul 2017 15:03:32 GMT):
root@e6c7ada21912:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer channel create -o orderer.example.com:7050 -c OATS -f ./channel-artifacts/channel.tx --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
2017-07-17 15:01:14.203 UTC [main] main -> ERRO 001 Cannot run peer because error when setting up MSP from directory /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/oats.ibm.com/users/Admin@oats.ibm.com/msp: err admin 0 is invalid, validation error Could not obtain certification chain, err A CA certificate cannot be used directly by this MSP
uber.twin (Mon, 17 Jul 2017 17:47:28 GMT):
Has joined the channel.
jtrayfield (Mon, 17 Jul 2017 19:37:58 GMT):
https://jira.hyperledger.org/browse/FAB-5348
Asara (Mon, 17 Jul 2017 20:23:51 GMT):
Has joined the channel.
Sania 2 (Tue, 18 Jul 2017 01:04:38 GMT):
Has joined the channel.
jtrayfield (Tue, 18 Jul 2017 01:06:29 GMT):
Now I'm having a problem at a later stage:
2017-07-18 00:56:59.574 UTC [deliveryClient] StartDeliverForChannel -> DEBU 2b6 This peer will pass blocks from orderer service to other peers for channel oats
2017-07-18 00:56:59.579 UTC [ConnProducer] NewConnection -> ERRO 2b7 Failed connecting to orderer.example.com:7050 , error: x509: certificate signed by unknown authority
2017-07-18 00:56:59.579 UTC [deliveryClient] connect -> ERRO 2b8 Failed obtaining connection: Could not connect to any of the endpoints: [orderer.example.com:7050]
jtrayfield (Tue, 18 Jul 2017 01:07:02 GMT):
(that's the peer log)
jtrayfield (Tue, 18 Jul 2017 01:07:43 GMT):
how are the certificate authorizations supposed to work for peer <-> orderer?
tom.appleyard (Tue, 18 Jul 2017 07:04:07 GMT):
Using cryptogen, how would I set the username of a user?
JonathanTan (Tue, 18 Jul 2017 10:54:36 GMT):
@tom.appleyard I think it might be in the crypto-config.yaml
tom.appleyard (Tue, 18 Jul 2017 11:12:43 GMT):
How so, you seem to define the number of users per organisation rather than individual profiles per se
Vadim (Tue, 18 Jul 2017 11:14:18 GMT):
@tom.appleyard not sure cryptogen can do it, you need fabric-ca
vu3mmg (Tue, 18 Jul 2017 11:28:19 GMT):
Has joined the channel.
rohitrocket (Tue, 18 Jul 2017 11:32:53 GMT):
Has joined the channel.
tom.appleyard (Tue, 18 Jul 2017 11:58:38 GMT):
Ah - no worries then, thanks!
Eman0 (Tue, 18 Jul 2017 13:35:40 GMT):
Has joined the channel.
highlander (Tue, 18 Jul 2017 20:27:23 GMT):
Has joined the channel.
JonathanTan (Wed, 19 Jul 2017 02:26:47 GMT):
@tom.appleyard , @Vadim seems right, http://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html#enrolling-the-bootstrap-identity
rohitrocket (Wed, 19 Jul 2017 06:03:27 GMT):
First we generate certificates using cryptogen
later when we need to add a peer , how to incrementally generate certificate ?
tallharish (Wed, 19 Jul 2017 16:54:16 GMT):
Has joined the channel.
tallharish (Wed, 19 Jul 2017 16:54:44 GMT):
In Fabric 1.0, I would like to do access control, essentially certain peers should be able to invoke certain chaincode function. The way decribed in the example here:
```func (t *SampleChaincode) Invoke(stub shim.ChaincodeStubInterface, function string, args []string) ([]byte, error) {
if function == "CreateLoanApplication" {
username, _ := GetCertAttribute(stub, "username")
role, _ := GetCertAttribute(stub, "role")
if role == "Bank_Home_Loan_Admin" {
return CreateLoanApplication(stub, args)
} else {
return nil, errors.New(username + " with role " + role + " does not have access to create a loan application")
}
}
return nil, nil
}```https://www.ibm.com/developerworks/cloud/library/cl-ibm-blockchain-chaincode-development-using-golang/index.html
Can I do this in 1.0 as well? I dont find any documentation on Tcerts (transaction certificates). Can anyone please point me out to examples? thanks
adc (Thu, 20 Jul 2017 03:45:41 GMT):
Hi @tallharish, TCerts are not supported directly by fabric. I think @smithbk can tell you more on this.
adc (Thu, 20 Jul 2017 03:46:42 GMT):
So far, what you can do with v1 is reasoning about the creator of the proposal. It is accessible via the GetCreator method
adc (Thu, 20 Jul 2017 03:46:42 GMT):
So far, what you can do with v1 is reasoning about the creator of the proposal. It is accessible via the GetCreator method. It returns a byte array representing a serialized msp identity (look at the SerializedIdentity struct)
adc (Thu, 20 Jul 2017 03:48:55 GMT):
It does not support yet attributes
colinGrahms (Thu, 20 Jul 2017 07:16:59 GMT):
Has joined the channel.
smithbk (Thu, 20 Jul 2017 08:43:58 GMT):
@tallharish @adc @elli-androulaki Yes, we still need to agree on TCert direction, but I am currently working on support for attributes in ECerts which will support RBAC (Role Based Access Control). See https://jira.hyperledger.org/browse/FAB-5346
adc (Thu, 20 Jul 2017 08:44:27 GMT):
cool, thanks :)
elli-androulaki (Thu, 20 Jul 2017 08:56:32 GMT):
Thanks!
gauthampamu (Thu, 20 Jul 2017 12:28:17 GMT):
Has joined the channel.
tallharish (Thu, 20 Jul 2017 14:39:20 GMT):
@adc Thanks. I am fine with this approach for now. But I am facing an issue importing protobuf/proto library for unmarshal. I am importing it like this `"github.com/hyperledger/fabric/vendor/github.com/golang/protobuf/proto"
tallharish (Thu, 20 Jul 2017 14:39:20 GMT):
@adc Thanks. I am fine with this approach for now. But I am facing an issue importing protobuf/proto library for unmarshal. I am importing it like this `"github.com/hyperledger/fabric/vendor/github.com/golang/protobuf/proto"`. But the I see the following error on instantiating the chaincode: ```Error: Error endorsing chaincode: rpc error: code = Unknown desc = Error starting container: Failed to generate platform-specific docker build: Error returned from build: 1 "package github.com/hyperledger/fabric/examples/chaincode/go/tracking
imports github.com/hyperledger/fabric/vendor/github.com/golang/protobuf/proto: use of vendored package not allowed```
tallharish (Thu, 20 Jul 2017 14:39:20 GMT):
@adc Thanks. I am fine with this approach for now. But I am facing an issue importing protobuf/proto library for unmarshal. I am importing it like this `"github.com/hyperledger/fabric/vendor/github.com/golang/protobuf/proto"`. But the I see the following error on instantiating the chaincode: ```Error: Error endorsing chaincode: rpc error: code = Unknown desc = Error starting container: Failed to generate platform-specific docker build: Error returned from build: 1 "package github.com/hyperledger/fabric/examples/chaincode/go/tracking
imports github.com/hyperledger/fabric/vendor/github.com/golang/protobuf/proto: use of vendored package not allowed```
tallharish (Thu, 20 Jul 2017 14:39:20 GMT):
@adc Thanks. I am fine with this approach for now. But I am facing an issue importing protobuf/proto library for unmarshal. I am importing it like this `"github.com/hyperledger/fabric/vendor/github.com/golang/protobuf/proto"`. But the I see the following @sqwerrels or on instantiating the chaincode: ```Error: Error endorsing chaincode: rpc error: code = Unknown desc = Error starting container: Failed to generate platform-specific docker build: Error returned from build: 1 "package github.com/hyperledger/fabric/examples/chaincode/go/tracking
imports github.com/hyperledger/fabric/vendor/github.com/golang/protobuf/proto: use of vendored package not allowed```
This is how I plan to use: ```
creator, err := stub.GetCreator()
if err != nil {
return shim.Error(fmt.Sprintf("Failed getting proposal's creator [%s]", err))
}
// Map creator to serializedIdentity, and extract the MSP_ID
fmt.Sprintf("creator is %s", creator)
si := &msp.SerializedIdentity{}
err := proto.Unmarshal(creator, si)
if err != nil {
return nil, err
}```
tallharish (Thu, 20 Jul 2017 14:39:20 GMT):
@adc Thanks. I am fine with this approach for now. But I am facing an issue importing protobuf/proto library for unmarshal. I am importing it like this `"github.com/hyperledger/fabric/vendor/github.com/golang/protobuf/proto"`. But the I see the following on instantiating the chaincode: ```Error: Error endorsing chaincode: rpc error: code = Unknown desc = Error starting container: Failed to generate platform-specific docker build: Error returned from build: 1 "package github.com/hyperledger/fabric/examples/chaincode/go/tracking
imports github.com/hyperledger/fabric/vendor/github.com/golang/protobuf/proto: use of vendored package not allowed```
This is how I plan to use: ```
creator, err := stub.GetCreator()
if err != nil {
return shim.Error(fmt.Sprintf("Failed getting proposal's creator [%s]", err))
}
// Map creator to serializedIdentity, and extract the MSP_ID
fmt.Sprintf("creator is %s", creator)
si := &msp.SerializedIdentity{}
err := proto.Unmarshal(creator, si)
if err != nil {
return nil, err
}```
sb2407 (Thu, 20 Jul 2017 15:41:04 GMT):
Has joined the channel.
n91 (Thu, 20 Jul 2017 21:10:43 GMT):
Has joined the channel.
n91 (Thu, 20 Jul 2017 21:10:53 GMT):
How can I use a different user name other than User1 ?
tallharish (Thu, 20 Jul 2017 21:25:33 GMT):
@adc
tallharish (Thu, 20 Jul 2017 21:25:33 GMT):
@adc Looks like I need to clone the protobuf library inside the fabric-ccenv container.
adc (Fri, 21 Jul 2017 01:15:42 GMT):
@tallharish, please, import it without pointing the vendor folder. At the chaincode installation, the peer will figure out the dependencies automagically :)
Glen (Fri, 21 Jul 2017 02:20:40 GMT):
[root@ testdata]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c15c69321e92 dev-peer1.org2.example.com-mycc-1.0 "chaincode -peer.a..." 3 minutes ago Up 3 minutes dev-peer1.org2.example.com-mycc-1.0
5b8320683bf1 dev-peer0.org1.example.com-mycc-1.0 "chaincode -peer.a..." 4 minutes ago Up 4 minutes dev-peer0.org1.example.com-mycc-1.0
01a1785a614f dev-peer0.org2.example.com-mycc-1.0 "chaincode -peer.a..." 6 minutes ago Up 6 minutes dev-peer0.org2.example.com-mycc-1.0
a77a5a304471 hyperledger/fabric-peer "/bin/bash -c './s..." 8 minutes ago Up 8 minutes cli
b130e5c2d6da hyperledger/fabric-orderer "orderer" 9 minutes ago Up 8 minutes 0.0.0.0:8101->6101/tcp, 0.0.0.0:9050->7050/tcp orderer2.example.com
1728fe526605 hyperledger/fabric-orderer "orderer" 9 minutes ago Up 8 minutes 0.0.0.0:9101->6101/tcp, 0.0.0.0:10050->7050/tcp orderer3.example.com
531f62b358dc hyperledger/fabric-orderer "orderer" 9 minutes ago Up 8 minutes 0.0.0.0:7101->6101/tcp, 0.0.0.0:8050->7050/tcp orderer1.example.com
230ad08bc11c hyperledger/fabric-peer "peer node start -..." 9 minutes ago Up 8 minutes 0.0.0.0:8051->7051/tcp, 0.0.0.0:8053->7053/tcp peer1.org1.example.com
e78e32a08262 hyperledger/fabric-peer "peer node start -..." 9 minutes ago Up 8 minutes 0.0.0.0:10051->7051/tcp, 0.0.0.0:10053->7053/tcp peer1.org2.example.com
c6158fa11a34 hyperledger/fabric-peer "peer node start -..." 9 minutes ago Up 8 minutes 0.0.0.0:9051->7051/tcp, 0.0.0.0:9053->7053/tcp peer0.org2.example.com
3951ae3307d4 hyperledger/fabric-peer "peer node start -..." 9 minutes ago Up 9 minutes 0.0.0.0:7051->7051/tcp, 0.0.0.0:7053->7053/tcp peer0.org1.example.com
b53a40cb0c85 hyperledger/fabric-orderer "orderer" 9 minutes ago Up 9 minutes 0.0.0.0:6101->6101/tcp, 0.0.0.0:7050->7050/tcp orderer0.example.com
[root@gaomanager1 testdata]#
Glen (Fri, 21 Jul 2017 02:20:40 GMT):
[root@gaomanager1 testdata]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c15c69321e92 dev-peer1.org2.example.com-mycc-1.0 "chaincode -peer.a..." 3 minutes ago Up 3 minutes dev-peer1.org2.example.com-mycc-1.0
5b8320683bf1 dev-peer0.org1.example.com-mycc-1.0 "chaincode -peer.a..." 4 minutes ago Up 4 minutes dev-peer0.org1.example.com-mycc-1.0
01a1785a614f dev-peer0.org2.example.com-mycc-1.0 "chaincode -peer.a..." 6 minutes ago Up 6 minutes dev-peer0.org2.example.com-mycc-1.0
a77a5a304471 hyperledger/fabric-peer "/bin/bash -c './s..." 8 minutes ago Up 8 minutes cli
b130e5c2d6da hyperledger/fabric-orderer "orderer" 9 minutes ago Up 8 minutes 0.0.0.0:8101->6101/tcp, 0.0.0.0:9050->7050/tcp orderer2.example.com
1728fe526605 hyperledger/fabric-orderer "orderer" 9 minutes ago Up 8 minutes 0.0.0.0:9101->6101/tcp, 0.0.0.0:10050->7050/tcp orderer3.example.com
531f62b358dc hyperledger/fabric-orderer "orderer" 9 minutes ago Up 8 minutes 0.0.0.0:7101->6101/tcp, 0.0.0.0:8050->7050/tcp orderer1.example.com
230ad08bc11c hyperledger/fabric-peer "peer node start -..." 9 minutes ago Up 8 minutes 0.0.0.0:8051->7051/tcp, 0.0.0.0:8053->7053/tcp peer1.org1.example.com
e78e32a08262 hyperledger/fabric-peer "peer node start -..." 9 minutes ago Up 8 minutes 0.0.0.0:10051->7051/tcp, 0.0.0.0:10053->7053/tcp peer1.org2.example.com
c6158fa11a34 hyperledger/fabric-peer "peer node start -..." 9 minutes ago Up 8 minutes 0.0.0.0:9051->7051/tcp, 0.0.0.0:9053->7053/tcp peer0.org2.example.com
3951ae3307d4 hyperledger/fabric-peer "peer node start -..." 9 minutes ago Up 9 minutes 0.0.0.0:7051->7051/tcp, 0.0.0.0:7053->7053/tcp peer0.org1.example.com
b53a40cb0c85 hyperledger/fabric-orderer "orderer" 9 minutes ago Up 9 minutes 0.0.0.0:6101->6101/tcp, 0.0.0.0:7050->7050/tcp orderer0.example.com
[root@gaomanager1 testdata]#
Glen (Fri, 21 Jul 2017 02:20:59 GMT):
I've run sbft with four peers
adc (Fri, 21 Jul 2017 02:40:00 GMT):
sbft? which fabric version are you using, @Glen?
Glen (Fri, 21 Jul 2017 02:46:20 GMT):
alpha2
adc (Fri, 21 Jul 2017 02:55:16 GMT):
oh, I see. Interesting
vu3mmg (Fri, 21 Jul 2017 03:02:54 GMT):
could you please give me pointers for using TCerts and invalidating Tcerts after one transaction
adc (Fri, 21 Jul 2017 03:17:51 GMT):
@vu3mmg, please look at this message https://chat.hyperledger.org/channel/fabric-crypto?msg=e7jDiPLKXCoPoTw5n
vu3mmg (Fri, 21 Jul 2017 03:30:16 GMT):
Thank you
indirajith (Fri, 21 Jul 2017 10:20:54 GMT):
Has joined the channel.
bylikai (Fri, 21 Jul 2017 16:25:41 GMT):
Has joined the channel.
jaswanth (Mon, 24 Jul 2017 04:09:13 GMT):
Hi all , I am trying to create a new channel in balance transfer example from node sdk. I provided an mychanneltx.tx file in the channelConfigPath , i got `channel mychanneltx has created ` output . but when i try to join peers into the channel getting error ```Error: chaincode error (status: 500, message: Cannot create ledger from genesis block, due to LedgerID already exists)``` . Do i need an another genesis block ,if so can anyone suggest how can i create it dynamically.
jaswanth (Mon, 24 Jul 2017 04:10:27 GMT):
and also I am using couchdb ..after mychanneltx channel created there is no new mychanneltx database .
adc (Mon, 24 Jul 2017 05:08:17 GMT):
it looks like you are submitting a create channel transaction for a channel name that already exists at the orderers.
jaswanth (Mon, 24 Jul 2017 06:20:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=XwLbLv4LZtEHrKiKD) @adc .i created a mychanneltx.tx file by using configtxgen tool ..my first channel is mychannel. channel creation gave me success output ..failed to join the peers
pmontagn (Mon, 24 Jul 2017 06:22:26 GMT):
Has joined the channel.
tomveugelers (Mon, 24 Jul 2017 09:18:20 GMT):
Has joined the channel.
traviscox (Mon, 24 Jul 2017 13:24:09 GMT):
Has joined the channel.
ankursam (Mon, 24 Jul 2017 13:28:45 GMT):
Has joined the channel.
joshhw (Mon, 24 Jul 2017 15:06:07 GMT):
Has joined the channel.
gormand (Mon, 24 Jul 2017 15:56:26 GMT):
Hi - Can I confirm that peers and orderers don't have or need a connection to fabric-ca? Is a connection only made to fabric-ca for issuing credentials (register/enroll) and from an admin to get the latest CRL which they update on the channel.
yacovm (Mon, 24 Jul 2017 15:58:49 GMT):
yes, the peer and orderer have no means of using the CA
gormand (Mon, 24 Jul 2017 16:05:18 GMT):
thanks @yacovm
uber.twin (Tue, 25 Jul 2017 09:19:57 GMT):
hi, is there any technique to ensure the restricted visibility of Assets, based on their relation to their respective owners?
JohnWhitton (Wed, 26 Jul 2017 00:04:36 GMT):
Hi all I'm trying to add a peer to a channel using
`peer channel join -b /etc/hyperledger/configtx/loyyal-genesis.block --logging-level=DEBUG`
It's giving the following error message
_Error: proposal failed (err: rpc error: code = Unknown desc = chaincode error (status: 500, message: "JoinChain" for chainID = testchainid failed because of validation of configuration block, because of Invalid configuration block, missing Application configuration group))_
I think it's coming from https://github.com/hyperledger/fabric/blob/d9c320297bd2a4eff2eb253ce84dc431ef860972/core/scc/cscc/configure.go#L180
JohnWhitton (Wed, 26 Jul 2017 00:05:12 GMT):
Any advice as to what might be causing this, or how to fix it would be appreciated.
howardhou (Wed, 26 Jul 2017 07:49:20 GMT):
Has joined the channel.
tennenjl (Wed, 26 Jul 2017 13:48:11 GMT):
Hi, does anyone I can contact to learn more regarding pen testing or other security testing being done against HLFV1? Thanks!
cbf (Wed, 26 Jul 2017 14:06:00 GMT):
@tennenjl @ashutosh_kumar can help you with a description of the tests that we ran - many of these were documented in JIRA (the static scans)
tennenjl (Wed, 26 Jul 2017 14:06:22 GMT):
@cbf Thank you so much!
cbf (Wed, 26 Jul 2017 14:06:59 GMT):
some of the static scans are being integrated into the CI pipeline
tennenjl (Wed, 26 Jul 2017 14:07:32 GMT):
Thank you that is good news that I can share.
cbf (Wed, 26 Jul 2017 14:07:41 GMT):
and when we get to having a long running environment(s) we'll likley add some of the dynamic stuff as well
tennenjl (Wed, 26 Jul 2017 14:08:25 GMT):
OK, I will reach out and also see if I can find some of the tests in JIRA
cbf (Wed, 26 Jul 2017 14:10:47 GMT):
sure thing https://jira.hyperledger.org/browse/FAB-4547 this was the tracker for the static scans... IBM ran its own pen testing of Fabric in our offering and Hyperledger is planning on having independent code audit and pen testing by a vendor in the next month or so on top of what we have already done
cbf (Wed, 26 Jul 2017 14:11:44 GMT):
@tennenjl also relevant is https://wiki.hyperledger.org/security/bug-handling-process
tennenjl (Wed, 26 Jul 2017 14:12:02 GMT):
Going there now :-)
tennenjl (Wed, 26 Jul 2017 14:13:41 GMT):
Do I need some userid to access the JIRA?
ashutosh_kumar (Wed, 26 Jul 2017 14:25:56 GMT):
@tennenjl , you need Linux Foundation Id.
tennenjl (Wed, 26 Jul 2017 14:26:21 GMT):
@ashutosh_kumar I have that, I will login using that thanks!
tennenjl (Wed, 26 Jul 2017 14:43:48 GMT):
@ashutosh_kumar the esteemed cbf provided great information, do you have any other recommendations where I can read more? Thanks!
uber.twin (Wed, 26 Jul 2017 14:44:48 GMT):
hi, when starting a CA server with explicit --ca.certfile and --ca.keyfile options, aren't those values suppose to be reflected in the CA config file? (fabric-ca-server-config.yaml)
uber.twin (Wed, 26 Jul 2017 14:46:23 GMT):
CA section looks like a default, i.e.
```
ca:
# Name of this CA
name:
# Key file (default: ca-key.pem)
keyfile: ca-key.pem
# Certificate file (default: ca-cert.pem)
certfile: ca-cert.pem
# Chain file (default: chain-cert.pem)
chainfile: ca-chain.pem
```
howardhou (Thu, 27 Jul 2017 10:16:05 GMT):
I learned all of users and peers have signature key-pair and encryption key-pair, and chain also has key-pair, does anyone know where are they stored?
kelly_ (Thu, 27 Jul 2017 16:22:57 GMT):
hey all, what cryptography library does fabric leverage?
yacovm (Thu, 27 Jul 2017 16:26:39 GMT):
@kelly_ the crypto library in fabric is called `bccsp` (blockchain crypto service provider) and it uses the golang crypto library when it is configured in software mode, and it uses pkcs11 with plugin to https://github.com/miekg/pkcs11 when in HSM mode.
@vpaprots / @adc please correct me if I'm wrong
kelly_ (Thu, 27 Jul 2017 17:48:48 GMT):
thanks @yacovm
dijun (Fri, 28 Jul 2017 08:30:43 GMT):
Has joined the channel.
jmcnevin (Fri, 28 Jul 2017 15:48:50 GMT):
Am I correct in assuming that, since admin roles are determined by doing a byte-for-byte analysis of certs in the admin certs directory, that enrolling with an admin identity in various places won't necessarily allow me to carry out admin role functions, since the provisioned certificate will be different each time?
mastersingh24 (Fri, 28 Jul 2017 20:27:00 GMT):
That's correct - the admin role currently only applies to the fabric-ca itself when registering / enrolling users
(https://chat.hyperledger.org/channel/fabric-crypto?msg=TXokbtTtdFJMxRCaf) @jmcnevin
vdods (Sun, 30 Jul 2017 00:29:46 GMT):
Using the `fabric-ca-cryptogen.sh` script from a (still unmerged?) CR as a starting point, I've been modifying it so I can specify a custom configuration for each CA, though I'm getting errors from the orderer during channel creation: `UTC [cauthdsl] func2 -> ERRO 1b0 Principal deserialization failure (The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority) for identity 0a074f7267...`
vdods (Sun, 30 Jul 2017 00:30:10 GMT):
I'm wondering how I would go about debugging this -- e.g. what identity was expected vs actually encountered, etc
rhudson (Mon, 31 Jul 2017 08:00:28 GMT):
Has joined the channel.
rhudson (Mon, 31 Jul 2017 08:03:45 GMT):
The private-public cryptography that Hyperledger Fabric relies on is expected to be cracked within the next ten years using quantum computing (Shor's algorithm). Obviously, the same is true of most internet traffic. However, the difference is that while most internet traffic is only recorded when the NSA chooses to do so and the encrypted data is then only available to the NSA, blockchain by definition distributes and maintains copies of all the encrypted data at multiple nodes. Is there an exit strategy for the point in time when the encryption algorithms are no longer secure?
yacovm (Mon, 31 Jul 2017 09:40:30 GMT):
well but data is replicated only in the channel
rhudson (Mon, 31 Jul 2017 12:03:19 GMT):
Thanks for the quick answer, now I understand the idea (I am new to Hyperledger). One more question: how does a channel differ from a completely separate blockchain instance? For example, are the hash values from each channel written to some sort of global channel or blockchain? If not, is not the problem that a channel sized based on confidentiality domains is likely to lack the scale to get the decentralized integrity benefits from blockchain?
OliverNo (Tue, 01 Aug 2017 08:09:12 GMT):
Has joined the channel.
yacovm (Tue, 01 Aug 2017 15:10:49 GMT):
@aso @adc @elli-androulaki may you take a look at the discussion in the change set please?
https://gerrit.hyperledger.org/r/#/c/12077/
jyellick (Tue, 01 Aug 2017 15:39:10 GMT):
As a little bit of background, my the goal of the CR series is to make the policy framework take identities instead of signatures.
In my investigation @aso pointed me to
https://jira.hyperledger.org/browse/FAB-4252
which I thought had been resolved for the policy framework as a whole, but instead was apparently addressed as a special case of the SCC. So, the v1 policy framework is in a position where it sometimes de-duplicates signatures, and sometimes does not.
The lack of deduplication in the framework at large was a problem which needs to be fixed, but, addressing it does change the policy semantics (honoring the contract, but breaking compatibility with v1). Since it is breaking compatibility, it seemed prudent to make the other semantics more consistent. So, this CR opts for making all 'non-well-formed' errors fatal. In particular, if the message includes an identity which cannot be deserialized or a signature which cannot be verified, then the signature set is considered not to be well formed and discarded.
I think the real world implications of this compatibility breakage is quite low. The vast majority of our policy checks are against a single signature which is unaffected by this change, and where signature sets which are well formed (ie, contain only valid signatures for valid identities), there are also no affects. Still, this is a breaking change, and should require some thought and discussion.
jyellick (Tue, 01 Aug 2017 15:40:52 GMT):
I'd also like to hear @mastersingh24 's take on this.
yacovm (Tue, 01 Aug 2017 15:52:07 GMT):
@jyellick
> but instead was apparently addressed as a special case of the SCC
Care to give a pointer?
jyellick (Tue, 01 Aug 2017 15:52:19 GMT):
https://github.com/hyperledger/fabric/blob/release/core/scc/vscc/validator_onevalidsignature.go#L426
yacovm (Tue, 01 Aug 2017 15:53:13 GMT):
I see. Can't we though de-duplicate a signature set in the policy framework though?
yacovm (Tue, 01 Aug 2017 15:53:27 GMT):
why was it done this way? even though I understand VSCC is the only place where we evaluate a signature set
yacovm (Tue, 01 Aug 2017 15:53:32 GMT):
the rest is a single signature
jyellick (Tue, 01 Aug 2017 15:54:57 GMT):
> I see. Can't we though de-duplicate a signature set in the policy framework though?
We can... which is what I am pushing for? But since it is not done today, does break compatibility
> why was it done this way?
I do not know. Had I seen, this would have received a hard -2 from me.
> even though I understand VSCC is the only place where we evaluate a signature set
> the rest is a single signature
The configtx code also deals with signature sets
yacovm (Tue, 01 Aug 2017 15:55:34 GMT):
but de-duplication isn't equivalent to "if some signature is not verified- the rest are not evaluated and considered"
jyellick (Tue, 01 Aug 2017 15:55:45 GMT):
This is true
jyellick (Tue, 01 Aug 2017 15:56:20 GMT):
As I said, it was a decision that "while we are breaking compatibility, let's make the semantics better"
yacovm (Tue, 01 Aug 2017 15:56:42 GMT):
> The configtx code also deals with signature sets
right, I forgot that
yacovm (Tue, 01 Aug 2017 15:57:34 GMT):
if we move the de-duplication from the VSCC to the policy - it doesn't break anything does it?
jyellick (Tue, 01 Aug 2017 15:57:42 GMT):
It breaks configtx processing
yacovm (Tue, 01 Aug 2017 15:58:00 GMT):
is it a feasible use case though?
yacovm (Tue, 01 Aug 2017 15:58:18 GMT):
I mean - do the tools we have produce such use cases?
jyellick (Tue, 01 Aug 2017 15:59:35 GMT):
Yes
jyellick (Tue, 01 Aug 2017 16:00:42 GMT):
The default configuration for a channel with 2 or more members requires multiple signatures to change membership (and this is something many people have done)
jyellick (Tue, 01 Aug 2017 16:00:42 GMT):
The default configuration for a channel with 2 or more members requires multiple signatures to change membership (and this is something many people are doing)
yacovm (Tue, 01 Aug 2017 16:01:49 GMT):
but the question is - how can they sign with signatures that some of them are not validated and some are?
yacovm (Tue, 01 Aug 2017 16:01:54 GMT):
isn't it a binary thing?
yacovm (Tue, 01 Aug 2017 16:02:03 GMT):
or do you claim, that if the policy is that only 1 valid sig is enough
jyellick (Tue, 01 Aug 2017 16:03:49 GMT):
> but the question is - how can they sign with signatures that some of them are not validated and some are?
As I pointed out above, if users are doing the 'right thing', their signature sets will be well formed, and you will see no difference from this CR series.
The only way a user should have a bad signature, is if they are doing something like signing the wrong bytes. And the only way they should have a bad identity is if they try to use a user for an org not in the channel.
jyellick (Tue, 01 Aug 2017 16:05:27 GMT):
The only way you really see 'breakage' is if the signature set contains more signatures than necessary, but some of the signatures are wrong, or some of the identities are wrong.
jyellick (Tue, 01 Aug 2017 16:06:35 GMT):
The latter seems the most likely case. For someone doing lazy automation for instance, they might simply sign all config changes with all admins for all orgs. It's a contrived example, and not a real world use case, but is the only sort of plausible explanation I see for including too many signatures (some of which are not valid in a channel)
yacovm (Tue, 01 Aug 2017 16:16:08 GMT):
I see.
yacovm (Tue, 01 Aug 2017 16:16:38 GMT):
@mastersingh24 what do you think?
yacovm (Tue, 01 Aug 2017 16:16:38 GMT):
@mastersingh24 , @elli-androulaki @adc @aso what do you think?
mastersingh24 (Tue, 01 Aug 2017 17:49:46 GMT):
(reading)
jyellick (Wed, 02 Aug 2017 13:41:02 GMT):
A gentle ping to @mastersingh24 @elli-androulaki @adc @aso as a reminder of the above :slight_smile:
aso (Wed, 02 Aug 2017 13:56:26 GMT):
@jyellick trying to digest, let me see if I got it. There are 2 issues on the table, namely, how should the new interface handle a signature set:
- with duplicate identities
- with incorrect signatures
aso (Wed, 02 Aug 2017 13:56:48 GMT):
are they the right questions? Any other?
jyellick (Wed, 02 Aug 2017 14:01:23 GMT):
And one more implicit one:
- Can this behavior be different than v1 (especially in context that the v1 behavior is inconsistent/buggy)
aso (Wed, 02 Aug 2017 14:03:27 GMT):
ok so, wrt `with duplicate identities`, just for the sake of discussion, what would happen if we accepted such a signature set, counting the duplicate identity only once?
jyellick (Wed, 02 Aug 2017 14:07:22 GMT):
Nothing earth shatteringly bad:
1. We'd waste some space storing a redundant signature
2. We'd allow a mild DOS attack vector for someone to include a single signature N times then force a complex policy to be evaluated over it many times.
3. We'd mask client bugs which are not following the correct endorsement/signing semantics (this is, I think the most serious problem)
aso (Wed, 02 Aug 2017 14:09:09 GMT):
1. agreed
2. is that true, though? wouldn't the policy be evaluated on the (deduplicated) set of identities only? If we architect the deduplication code well, we'd detect the duplicate early on and skip signature verification
3. true, we could log it of course but God know whether anyone will read that
jyellick (Wed, 02 Aug 2017 14:10:11 GMT):
2. Good point, if we are smart, we deduplicate before verifying signature.
mastersingh24 (Wed, 02 Aug 2017 14:10:59 GMT):
2. This should be easy to do - I thought we already kinda did this but just a little further down today
jyellick (Wed, 02 Aug 2017 14:11:50 GMT):
Agreed, (2) is a non-issue. Really, (3) is the strongest motivation.
jyellick (Wed, 02 Aug 2017 14:13:12 GMT):
I'll add one more to your list @aso
- with an identity for an msp ID unknown in the channel
jyellick (Wed, 02 Aug 2017 14:13:12 GMT):
I'll two one more to your list @aso
- with an identity for an msp ID unknown in the channel
- with an identity which cannot be deserialized
jyellick (Wed, 02 Aug 2017 14:13:12 GMT):
I'll add two more to your list @aso
- with an identity for an msp ID unknown in the channel
- with an identity which cannot be deserialized
aso (Wed, 02 Aug 2017 14:13:44 GMT):
I think 3 is the biggest issue for both points
```
- with duplicate identities
- with incorrect signatures
```
aso (Wed, 02 Aug 2017 14:13:59 GMT):
I don't really see any security issues otherwise
mastersingh24 (Wed, 02 Aug 2017 14:14:07 GMT):
So it seems like we have some (pre)processing to do
jyellick (Wed, 02 Aug 2017 14:15:07 GMT):
https://gerrit.hyperledger.org/r/#/c/12077/ implements this pre-processing as "all errors are fatal". The problem is, this means a policy which evaluates to true in v1, may evaluate to false in v1.1.
jyellick (Wed, 02 Aug 2017 14:15:36 GMT):
The security issue, is that a clever person could tailor a transaction to be valid under v1 which is not valid under v1.1 by carefully violating the policy semantics
aso (Wed, 02 Aug 2017 14:16:07 GMT):
but but.. we have a version number somewhere right?
jyellick (Wed, 02 Aug 2017 14:16:15 GMT):
I think it's mitigated by the fact that the submitter must be authorized on the channel, so this is not a vector for a random attacker. But, it causes a problem in a mixed mode v1/v1.1 environment
mastersingh24 (Wed, 02 Aug 2017 14:17:15 GMT):
So give me an example of something that will pass with v1 and not with v1.1?
jyellick (Wed, 02 Aug 2017 14:17:28 GMT):
Someone gets two endorsements for the same tx from the same endorser
jyellick (Wed, 02 Aug 2017 14:17:38 GMT):
(With an endorsement policy requiring one signature)
jyellick (Wed, 02 Aug 2017 14:17:38 GMT):
(With an endorsement policy requiring one endorsement)
mastersingh24 (Wed, 02 Aug 2017 14:17:59 GMT):
Why would this fail in v1.1?
jyellick (Wed, 02 Aug 2017 14:18:19 GMT):
If we declare duplicating identities to be a fatal error, rather than ignoring
mastersingh24 (Wed, 02 Aug 2017 14:18:42 GMT):
Ah - right - ok - wanted to make sure
mastersingh24 (Wed, 02 Aug 2017 14:18:49 GMT):
But why does it need to be fatal?
mastersingh24 (Wed, 02 Aug 2017 14:19:09 GMT):
For example, can't we just filter them out but not throw a fatal error?
jyellick (Wed, 02 Aug 2017 14:19:35 GMT):
The crux is, that today, the only place deduplication is done, is in the VSCC, which means for any other part of the system which verifies signatures, there is no de-duplication. So, if we change it to even filter them, you can still construct the identical attack
jyellick (Wed, 02 Aug 2017 14:19:54 GMT):
My reasoning was, if we're going to be making an incompatible change that allows this attack, let's go all in and just fix it 'correctly'
aso (Wed, 02 Aug 2017 14:20:12 GMT):
actually, I think v1 GA'd without that ugly code @jyellick
aso (Wed, 02 Aug 2017 14:20:21 GMT):
which is good
aso (Wed, 02 Aug 2017 14:20:44 GMT):
that ugly code = the deduplication in vscc
jyellick (Wed, 02 Aug 2017 14:21:02 GMT):
Although I hate that code... that actually makes our problem worse.
jyellick (Wed, 02 Aug 2017 14:21:16 GMT):
Deduplicating at all will cause this attack vector to open up.
aso (Wed, 02 Aug 2017 14:21:29 GMT):
v1 GA'd with a restriction documented
aso (Wed, 02 Aug 2017 14:21:52 GMT):
that said that it was illegal to use policies requiring multiple sigs from the same policy principal
aso (Wed, 02 Aug 2017 14:22:05 GMT):
and no defensive code around that
aso (Wed, 02 Aug 2017 14:22:15 GMT):
to enforce the restriction
jyellick (Wed, 02 Aug 2017 14:23:11 GMT):
Wish I had not missed this discussion.
jyellick (Wed, 02 Aug 2017 14:23:45 GMT):
That mitigates things a bit
aso (Wed, 02 Aug 2017 14:24:25 GMT):
so basically *IF* we stick to the restriction, any policies requiring multiple sigs is illegal in v1 -> undefined behaviour
aso (Wed, 02 Aug 2017 14:24:38 GMT):
and we could enforce one that we like post v1
aso (Wed, 02 Aug 2017 14:24:59 GMT):
if on the other hand we think someone might have used that feature, then we need to decide how to handle it
jyellick (Wed, 02 Aug 2017 14:25:16 GMT):
Unfortunately it still doesn't quite work. A policy doesn't have to require multiple sigs from the same policy principal in order for a client to submit them.
mastersingh24 (Wed, 02 Aug 2017 14:25:49 GMT):
@jyellick - I think I am missing something
aso (Wed, 02 Aug 2017 14:26:16 GMT):
right, sorry, I've tentatively accepted that we shouldn't treat duplicate signatures as terminal errors @jyellick
mastersingh24 (Wed, 02 Aug 2017 14:26:31 GMT):
Are you trying to add a protection in v1.1 to prevent someone from overloading us with a ton of duplicate / bad signatures?
mastersingh24 (Wed, 02 Aug 2017 14:27:00 GMT):
Otherwise, I'm not sure why we would need to treat dups as fatal?
mastersingh24 (Wed, 02 Aug 2017 14:27:16 GMT):
We simply need to build up the unique / valid list
jyellick (Wed, 02 Aug 2017 14:27:21 GMT):
How about the other three classes?
jyellick (Wed, 02 Aug 2017 14:27:50 GMT):
* duplicates
* cannot be deserialized
* not an MSP ID in this channel
* bad signature
jyellick (Wed, 02 Aug 2017 14:27:50 GMT):
* duplicates -- (proposed we ignore)
* cannot be deserialized
* not an MSP ID in this channel
* bad signature
mastersingh24 (Wed, 02 Aug 2017 14:28:36 GMT):
I don't think it would be fatal
mastersingh24 (Wed, 02 Aug 2017 14:28:36 GMT):
I don't think it should be fatal
mastersingh24 (Wed, 02 Aug 2017 14:28:47 GMT):
You just filter those out of the input list
yacovm (Wed, 02 Aug 2017 14:28:53 GMT):
you mean "should" right?
mastersingh24 (Wed, 02 Aug 2017 14:29:16 GMT):
Or are they fatal today
aso (Wed, 02 Aug 2017 14:29:18 GMT):
I think we have to reject bad signatures - otherwise anyone can fill the ledger with invalid txes
mastersingh24 (Wed, 02 Aug 2017 14:29:34 GMT):
OK
jyellick (Wed, 02 Aug 2017 14:29:35 GMT):
Well, it wouldn't pass the policy with the bad signature
yacovm (Wed, 02 Aug 2017 14:29:38 GMT):
well it is filled with MVCC invalid Txns now too
yacovm (Wed, 02 Aug 2017 14:29:39 GMT):
no?
jyellick (Wed, 02 Aug 2017 14:29:44 GMT):
We would end up with an empty identity set, which doesn't pass
yacovm (Wed, 02 Aug 2017 14:29:44 GMT):
what's the difference?
jyellick (Wed, 02 Aug 2017 14:29:58 GMT):
Difference is that at least the submitter mus be authorized on the channel
aso (Wed, 02 Aug 2017 14:30:05 GMT):
right, I think the real point is
* bad signature in otherwise good policy
aso (Wed, 02 Aug 2017 14:30:05 GMT):
right, I think the real point is
* bad signature in otherwise good signature set
jyellick (Wed, 02 Aug 2017 14:30:12 GMT):
Ah, okay
yacovm (Wed, 02 Aug 2017 14:30:52 GMT):
The question here is simply - if we have the required threshold signatures but 1 of the signatures (out of the threshold) is not valid - should we reject the entire signature set or not
yacovm (Wed, 02 Aug 2017 14:30:52 GMT):
The question here is simple - if we have the required threshold signatures but 1 of the signatures (out of the threshold) is not valid - should we reject the entire signature set or not
yacovm (Wed, 02 Aug 2017 14:30:52 GMT):
The question here is simple - if we have the required threshold signatures but 1 of the signatures (out of the threshold) is not valid ( error deserializing the identity, or the identity not being from an MSP in the channel) - should we reject the entire signature set or not
yacovm (Wed, 02 Aug 2017 14:30:59 GMT):
the current behavior AFAIK doesn't reject
yacovm (Wed, 02 Aug 2017 14:31:04 GMT):
the new behavior in Jason's change set - rejects
jyellick (Wed, 02 Aug 2017 14:31:05 GMT):
Correct
elli-androulaki (Wed, 02 Aug 2017 14:31:25 GMT):
it should reject imho
jyellick (Wed, 02 Aug 2017 14:31:26 GMT):
Same with errors deserializing the identity, or the identity not being from an MSP in the channel
yacovm (Wed, 02 Aug 2017 14:31:46 GMT):
> Same with errors deserializing the identity, or the identity not being from an MSP in the channel
yes.
jyellick (Wed, 02 Aug 2017 14:32:10 GMT):
I think the cleanest behavior, is to reject. As really, I see no way any of these should happen without buggy clients. However, we didn't reject for v1, our mistake, so maybe we have to live with it.
yacovm (Wed, 02 Aug 2017 14:32:54 GMT):
there is a 3rd option in theory - make it configurable
yacovm (Wed, 02 Aug 2017 14:32:58 GMT):
(not saying we should)
yacovm (Wed, 02 Aug 2017 14:33:17 GMT):
ah actually
yacovm (Wed, 02 Aug 2017 14:33:19 GMT):
it's in VSCC
yacovm (Wed, 02 Aug 2017 14:33:20 GMT):
so no
jyellick (Wed, 02 Aug 2017 14:33:28 GMT):
Why no?
yacovm (Wed, 02 Aug 2017 14:33:40 GMT):
you're always thinking configuration via config block Jason
yacovm (Wed, 02 Aug 2017 14:33:47 GMT):
I meant by mistake locally ;)
yacovm (Wed, 02 Aug 2017 14:33:58 GMT):
I think we shouldn't go that way
yacovm (Wed, 02 Aug 2017 14:34:07 GMT):
but in theory one can add to the config block this
aso (Wed, 02 Aug 2017 14:34:09 GMT):
so, to sum up, how about:
* duplicates -- (proposed we log+ignore)
* cannot be deserialized -- (propose we reject)
* not an MSP ID in this channel -- (propose we log+ignore)
* bad signature -- (propose we reject)
aso (Wed, 02 Aug 2017 14:34:09 GMT):
so, to sum up, how about:
1 duplicates -- (proposed we log+ignore)
2 cannot be deserialized -- (propose we reject)
3 not an MSP ID in this channel -- (propose we log+ignore)
4 bad signature -- (propose we reject)
jyellick (Wed, 02 Aug 2017 14:34:30 GMT):
I say absolutely not
jyellick (Wed, 02 Aug 2017 14:34:38 GMT):
Because we are breaking semantics if we do that
jyellick (Wed, 02 Aug 2017 14:34:44 GMT):
Today, all 4 of those are non-fatal
jyellick (Wed, 02 Aug 2017 14:34:55 GMT):
If we make any of them fatal, I say we make them all fatal
aso (Wed, 02 Aug 2017 14:36:53 GMT):
yeah, you're right on this point
> we are breaking semantics if we do that
jyellick (Wed, 02 Aug 2017 14:37:03 GMT):
In order to not break with the contract in v1.0.0, I think they all have to be non-fatal. And, if we even get a release where we do not allow mixed-mode with an older release, we can revisit.
jyellick (Wed, 02 Aug 2017 14:37:03 GMT):
In order to not break with the contract in v1.0.0, I think they all have to be non-fatal. And, if we ever get a release where we do not allow mixed-mode with an older release, we can revisit.
aso (Wed, 02 Aug 2017 14:37:20 GMT):
we could bump up the policy version
aso (Wed, 02 Aug 2017 14:37:38 GMT):
and maintain backward compatibilty (not saying we should, it's an option though)
jyellick (Wed, 02 Aug 2017 14:37:49 GMT):
We could. But then you cannot run a mixed v1.0.x v1.1.x environment
jyellick (Wed, 02 Aug 2017 14:38:30 GMT):
(As the v1.0.x clients would error trying to parse the newer policy structure)
yacovm (Wed, 02 Aug 2017 14:38:32 GMT):
policy version???
yacovm (Wed, 02 Aug 2017 14:38:40 GMT):
what's that?
jyellick (Wed, 02 Aug 2017 14:38:41 GMT):
There is a version in the policy field
jyellick (Wed, 02 Aug 2017 14:38:41 GMT):
There is a version in the policy message
aso (Wed, 02 Aug 2017 14:38:55 GMT):
hmmm, couldn't you? a v1.X peer would understand both policies and honor each type; a v1.0 peer would only understand its type
aso (Wed, 02 Aug 2017 14:38:55 GMT):
hmmm, couldn't you? a v1.X peer would understand both policies and honor each type; a v1.0 peer would only understand its type and refuse any other
jyellick (Wed, 02 Aug 2017 14:39:01 GMT):
Currently must be 0, may never be used. But was put there pre-emptively
jyellick (Wed, 02 Aug 2017 14:39:27 GMT):
> a v1.0 peer would only understand its type and refuse any other
So the v1.0 peer would reject the tx, and the v1.1 would accept it, and the state diverges
aso (Wed, 02 Aug 2017 14:40:33 GMT):
in a transition of this kind (which we'll have to go through eventually), all clients would only be entitled to use new features when all peers are running the new version
aso (Wed, 02 Aug 2017 14:42:00 GMT):
but at any rate, I don't think we should use the version option
aso (Wed, 02 Aug 2017 14:42:15 GMT):
for this kind of behaviour, it seems an overkill
elli-androulaki (Wed, 02 Aug 2017 14:42:18 GMT):
+1, also for vscc and other components' version upgrades, no?
mastersingh24 (Wed, 02 Aug 2017 14:42:58 GMT):
We can always have different VSCC
aso (Wed, 02 Aug 2017 14:43:00 GMT):
exactly, upgrading fabric and enabling new features should be handled carefully
mastersingh24 (Wed, 02 Aug 2017 14:43:18 GMT):
Unfortunately the VSCC today is a bit tangled
mastersingh24 (Wed, 02 Aug 2017 14:43:21 GMT):
BUt
mastersingh24 (Wed, 02 Aug 2017 14:43:26 GMT):
That should not stop us
mastersingh24 (Wed, 02 Aug 2017 14:44:50 GMT):
Also - when it comes to validating blocks, there are two things:
1) New inbound blocks
2) Ledger replay / sync based on state transfer
mastersingh24 (Wed, 02 Aug 2017 14:45:08 GMT):
2) is the one we need to worry about compatibility
mastersingh24 (Wed, 02 Aug 2017 14:45:08 GMT):
2) is the one we need to worry about compatibility for determinism
aso (Wed, 02 Aug 2017 14:45:51 GMT):
agreed; I expect an update will happen in 2 stages
- stage 1: updating. The network has peers of version n and n+1. All peers of version n+1 should behave in compat mode
- stage 2: committing the update. When all peers have been updated to version n+1, they can begin to behave in the "new" mopde
aso (Wed, 02 Aug 2017 14:45:51 GMT):
agreed; I expect an update will happen in 2 stages
- stage 1: updating. The network has peers of version n and n+1. All peers of version n+1 should behave in compat mode
- stage 2: committing the update. When all peers have been updated to version n+1, they can begin to behave in the "new" mode
yacovm (Wed, 02 Aug 2017 14:46:58 GMT):
wait wait, you can't upgrade VSCC
elli-androulaki (Wed, 02 Aug 2017 14:47:05 GMT):
Actually it may be that the network of peers need to have all n +1 versions supported (no?) cause they may be two or more versions back
elli-androulaki (Wed, 02 Aug 2017 14:47:05 GMT):
Actually it may be that the network of peers need to have all n +1 versions supported (no?) cause the channel may be one or more versions back
mastersingh24 (Wed, 02 Aug 2017 14:47:08 GMT):
Hopefully we can also leverage chaincode version to map back to the point in time policies and VSCC in play at the time
yacovm (Wed, 02 Aug 2017 14:47:09 GMT):
a SYSCC is a per-peer entity
yacovm (Wed, 02 Aug 2017 14:47:20 GMT):
if you upgrade it that'd lead to forks
yacovm (Wed, 02 Aug 2017 14:47:45 GMT):
or if done correctly - with changing the `vscc` property in the channel
aso (Wed, 02 Aug 2017 14:47:51 GMT):
> if you upgrade it that'd lead to forks
not if you upgrade with the 2 stages I suggested above (I hope)
elli-androulaki (Wed, 02 Aug 2017 14:47:52 GMT):
I would see a similar process as with chaincode upgrade to need to take place
yacovm (Wed, 02 Aug 2017 14:47:54 GMT):
that would lead for peers unable to validate
jyellick (Wed, 02 Aug 2017 14:48:50 GMT):
Okay, so to quickly return to the original point. The conclusion is -- *treat all signature set errors as non-fatal* -- perhaps re-address in the future once we've sorted upgrade out.
yacovm (Wed, 02 Aug 2017 14:49:13 GMT):
so back to the original semantics, Jason?
jyellick (Wed, 02 Aug 2017 14:49:19 GMT):
Correct
mastersingh24 (Wed, 02 Aug 2017 14:49:30 GMT):
But we'll optimize the processing?
jyellick (Wed, 02 Aug 2017 14:49:42 GMT):
Yes, will still restructure the processing, consolidate the checks as the CR series does
mastersingh24 (Wed, 02 Aug 2017 14:49:48 GMT):
Cool
jyellick (Wed, 02 Aug 2017 14:49:51 GMT):
Will just convert the errors in that path to warnings
mastersingh24 (Wed, 02 Aug 2017 14:49:52 GMT):
We really need that
aso (Wed, 02 Aug 2017 14:50:12 GMT):
@jyellick
> Okay, so to quickly return to the original point. The conclusion is -- *treat all signature set errors as non-fatal* -- perhaps re-address in the future once we've sorted upgrade out
with the significant difference that we deduplicate identities, right?
mastersingh24 (Wed, 02 Aug 2017 14:50:13 GMT):
Right now, the difference between 1 and 6 endorsers is pretty bad
mastersingh24 (Wed, 02 Aug 2017 14:50:25 GMT):
performance wise
jyellick (Wed, 02 Aug 2017 14:51:51 GMT):
@aso
> with the significant difference that we deduplicate identities, right?
Yes. Since we doc-ed that this for endorsement policy, we should be okay. There is the problem that the configtx did not doc this, and it supports multi-sig sets. However, I do not think anyone is setting their own admin policies yet, and even if they were, it would require a conspiracy of channel admins to fork the channel, which seems like an acceptable security risk.
aso (Wed, 02 Aug 2017 15:08:40 GMT):
@jyellick @elli-androulaki @mastersingh24
I checked and - sigh - the ugly vscc dedup code is indeed part of v1 :(
which complicates things
because it does two things
```
serializedIdentity := &msp.SerializedIdentity{}
if err := proto.Unmarshal(endorsement.Endorser, serializedIdentity); err != nil {
logger.Errorf("Unmarshal endorser error: %s", err)
return nil, fmt.Errorf("Unmarshal endorser error: %s", err)
}
```
so bad identity is fatal
aso (Wed, 02 Aug 2017 15:08:40 GMT):
@jyellick @elli-androulaki @mastersingh24 @yacovm
I checked and - sigh - the ugly vscc dedup code is indeed part of v1 :(
which complicates things
because it does two things
```
serializedIdentity := &msp.SerializedIdentity{}
if err := proto.Unmarshal(endorsement.Endorser, serializedIdentity); err != nil {
logger.Errorf("Unmarshal endorser error: %s", err)
return nil, fmt.Errorf("Unmarshal endorser error: %s", err)
}
```
so bad identity is fatal
aso (Wed, 02 Aug 2017 15:09:06 GMT):
but
aso (Wed, 02 Aug 2017 15:09:31 GMT):
duplicate identity isn't
```
identity := serializedIdentity.Mspid + string(serializedIdentity.IdBytes)
if _, ok := signatureMap[identity]; ok {
// Endorsement with the same identity has already been added
logger.Warningf("Ignoring duplicated identity, Mspid: %s, pem:\n%s", serializedIdentity.Mspid, serializedIdentity.IdBytes)
continue
}
```
bad identity being fatal is in contradiction with what the rest of the system does...
jyellick (Wed, 02 Aug 2017 15:10:10 GMT):
Indeed @aso, this complicates things considerably... so we do have inconsistent policy behavior in the system. And if we standardize it either way, we introduce an incompatibility
aso (Wed, 02 Aug 2017 15:11:22 GMT):
I'm not too worried about silently discarding duplicate identities
aso (Wed, 02 Aug 2017 15:12:14 GMT):
the issue is that v1 rejects endorsements with identities that cannot be deserialized
mastersingh24 (Wed, 02 Aug 2017 15:12:39 GMT):
It's ok to keep that behavior in v1.1 then?
aso (Wed, 02 Aug 2017 15:13:06 GMT):
I guess we have no other choice..
aso (Wed, 02 Aug 2017 15:14:00 GMT):
otherwise a v1.1 peer and a v1 peer will disagree on the validity of a ledger
aso (Wed, 02 Aug 2017 15:14:51 GMT):
@jyellick: how about we go ahead with what we agreed before (treat all signature set errors as non-fatal), and leave this extra code in VSCC?
aso (Wed, 02 Aug 2017 15:14:51 GMT):
@mastersingh24 @jyellick @elli-androulaki @yacovm : how about we go ahead with what we agreed before (treat all signature set errors as non-fatal), and leave this extra code in VSCC?
aso (Wed, 02 Aug 2017 15:15:45 GMT):
fatal marshalling errors will only be a "feature" of the current version of VSCC
aso (Wed, 02 Aug 2017 15:15:45 GMT):
fatal identity marshalling errors will only be a "feature" of the current version of VSCC
mastersingh24 (Wed, 02 Aug 2017 15:15:53 GMT):
That might be tricky? Since shouldn't this all be in VSCC?
mastersingh24 (Wed, 02 Aug 2017 15:16:06 GMT):
We could just implement new VSCC
aso (Wed, 02 Aug 2017 15:16:10 GMT):
right, only VSCC will behave that way
aso (Wed, 02 Aug 2017 15:16:24 GMT):
we need to find a way to do system chaincode versioning
aso (Wed, 02 Aug 2017 15:16:33 GMT):
if and when we modify that behaviour
mastersingh24 (Wed, 02 Aug 2017 15:16:37 GMT):
Leave current VSCC which would be associated with any existing blocks (via the chaincode version)
mastersingh24 (Wed, 02 Aug 2017 15:16:37 GMT):
Leave current VSCC which would be associated with any existing blocks/transactions (via the chaincode version)
aso (Wed, 02 Aug 2017 15:17:36 GMT):
yeah
aso (Wed, 02 Aug 2017 15:18:05 GMT):
however, currently every cc lists in its lscc entry only the name of its vscc
aso (Wed, 02 Aug 2017 15:18:08 GMT):
and not its version
mastersingh24 (Wed, 02 Aug 2017 15:18:34 GMT):
that's fine
mastersingh24 (Wed, 02 Aug 2017 15:18:44 GMT):
we can register new vscc with diffeent name
mastersingh24 (Wed, 02 Aug 2017 15:18:44 GMT):
we can register new vscc with different name
aso (Wed, 02 Aug 2017 15:18:47 GMT):
the new VSCC could be called vscc.1
aso (Wed, 02 Aug 2017 15:18:47 GMT):
right
aso (Wed, 02 Aug 2017 15:19:02 GMT):
LGTM
aso (Wed, 02 Aug 2017 15:20:23 GMT):
so, do we agree that we go ahead with the policy framework change we suggested before (=treat all signature set errors as non-fatal) + keep this "feature" in the current version of VSCC?
adc (Thu, 03 Aug 2017 09:46:12 GMT):
please, may you clarify again the reasons why the validation should not fail if an identity does not parse or there is a duplication?
adc (Thu, 03 Aug 2017 10:04:00 GMT):
my 5 cents, if a client submits something that contains invalid parts, that something should be rejected and the client punished in some way
mastersingh24 (Thu, 03 Aug 2017 10:04:32 GMT):
@adc - If we are able to implement the "new" processing rules in a new VSCC, then I suppose we can change the "rules" to be whatever we want.
If we believe that duplicate identities and non-parseable identities are an attack vector (e.g. someone just loads up a transaction with a large number of duplicate endorsements or bad identities), then failing makes sense.
adc (Thu, 03 Aug 2017 10:05:02 GMT):
the client has the tools to verify the validity of what it is submitting, no?
mastersingh24 (Thu, 03 Aug 2017 10:05:24 GMT):
Yes - the client can indeed do this
adc (Thu, 03 Aug 2017 10:05:36 GMT):
indeed
adc (Thu, 03 Aug 2017 10:06:10 GMT):
so, the VSCC in v1 does not reject always. This is the issue?
mastersingh24 (Thu, 03 Aug 2017 10:06:31 GMT):
I'm fine as long as we ensure that transactions submitted under the current rules will be processed under the current rules and transactions submitted when the 1.1 rules are in place will be processed with the 1.1 rules
mastersingh24 (Thu, 03 Aug 2017 10:07:13 GMT):
In v1 I think it only rejects when it can't parse an identity (and of course when the policy is not met)
mastersingh24 (Thu, 03 Aug 2017 10:07:55 GMT):
To be honest, we could likely get away with changing the rules given that it's HIGHLY unlikely that we'll see duplicate identities in the existing records
adc (Thu, 03 Aug 2017 10:08:20 GMT):
if we finally add versioning to the protobuf messages then, it should become easier to which VSCC to default
adc (Thu, 03 Aug 2017 10:08:20 GMT):
I see
mastersingh24 (Thu, 03 Aug 2017 10:08:22 GMT):
BUT - I really do like going down the path of adding a new VSCC to change the rules
mastersingh24 (Thu, 03 Aug 2017 10:08:48 GMT):
VSCC is assigned to chaincode during instantiation
mastersingh24 (Thu, 03 Aug 2017 10:09:01 GMT):
So it's already associated with the CC lifecycle record
mastersingh24 (Thu, 03 Aug 2017 10:09:51 GMT):
Although I'm not sure if we actually serialize the default or just use the default if it's not there
adc (Thu, 03 Aug 2017 10:10:02 GMT):
I agree that it would be better to not add another default VSCC
adc (Thu, 03 Aug 2017 10:11:14 GMT):
got it, @aso pointed to the code that tells us that duplications are not a problem in v1
adc (Thu, 03 Aug 2017 10:11:55 GMT):
I have now the full picture, thanks
mastersingh24 (Thu, 03 Aug 2017 10:12:44 GMT):
@adc - while I have you, got time for a few questions on some other topics?
adc (Thu, 03 Aug 2017 10:12:55 GMT):
please, go ahead
mastersingh24 (Thu, 03 Aug 2017 10:20:56 GMT):
One of the *biggest* pain points right now is the chicken and egg problem with admincerts for local MSPs and also in general the issue of "distributing" local MSPs to peers
So a couple of thoughts comes to mind:
1) We could allow a peer to boot with a local MSP that does not contain admincerts (this would be nice because we could then embed the fabric-ca-client in the peer image and peers would then be able to enroll and populate their local MSP with everything except admincerts
2) We would then provide an API to for updating the admincerts (could also be more broadly for updating the MSP in general which we also need)
3) But this of course presents a problem in that we need to provide some type of authentication mechanism for this API in the case where admincerts is not populated
I've been thinking that we could off a one-time password scheme here but looking for other options
mastersingh24 (Thu, 03 Aug 2017 10:20:56 GMT):
*Question 1*
One of the *biggest* pain points right now is the chicken and egg problem with admincerts for local MSPs and also in general the issue of "distributing" local MSPs to peers
So a couple of thoughts comes to mind:
1) We could allow a peer to boot with a local MSP that does not contain admincerts (this would be nice because we could then embed the fabric-ca-client in the peer image and peers would then be able to enroll and populate their local MSP with everything except admincerts
2) We would then provide an API to for updating the admincerts (could also be more broadly for updating the MSP in general which we also need)
3) But this of course presents a problem in that we need to provide some type of authentication mechanism for this API in the case where admincerts is not populated
I've been thinking that we could off a one-time password scheme here but looking for other options
mastersingh24 (Thu, 03 Aug 2017 10:21:28 GMT):
(in the case where admincerts is populated, clearly we can protect the peer admin API with admincerts)
adc (Thu, 03 Aug 2017 10:32:52 GMT):
interesting and dangerous at the same time
adc (Thu, 03 Aug 2017 10:33:25 GMT):
the one-time password might be a solution but then you already know that the passwords used will be 12345, right?
adc (Thu, 03 Aug 2017 10:34:20 GMT):
we might say that admincerts do not need to be valid msp identities
adc (Thu, 03 Aug 2017 10:34:44 GMT):
so one can put a self signed cert as admincert to authenticate the first time as admin and then it will be replaced
mastersingh24 (Thu, 03 Aug 2017 10:35:02 GMT):
That's another option as well
adc (Thu, 03 Aug 2017 10:35:34 GMT):
if there is an ldap in the system that can be leveraged
mastersingh24 (Thu, 03 Aug 2017 10:35:43 GMT):
I was going to basically allow you to specify the one time password as part of the config and require that it actually be a hash
mastersingh24 (Thu, 03 Aug 2017 10:36:00 GMT):
Right - the other option is to allow non-cert based auth for the API
adc (Thu, 03 Aug 2017 10:36:07 GMT):
yeah
adc (Thu, 03 Aug 2017 10:36:11 GMT):
that might be an option
adc (Thu, 03 Aug 2017 10:36:21 GMT):
we can equip the peer with other MSP implementations
mastersingh24 (Thu, 03 Aug 2017 10:36:43 GMT):
And yet another option is to allow you to specify an attribute/role rather than an explicit public cert?
mastersingh24 (Thu, 03 Aug 2017 10:36:59 GMT):
OK - I have enough to go on
mastersingh24 (Thu, 03 Aug 2017 10:37:07 GMT):
Will create a JIRA and present some options
adc (Thu, 03 Aug 2017 10:37:59 GMT):
yeah, but we need a way to verify that the caller has that role
adc (Thu, 03 Aug 2017 10:38:10 GMT):
but why not, in principal at least
mastersingh24 (Thu, 03 Aug 2017 10:38:15 GMT):
;)
adc (Thu, 03 Aug 2017 10:39:17 GMT):
:)
mastersingh24 (Thu, 03 Aug 2017 10:40:14 GMT):
*Question 2*
Encrypting the payloads and/or values sent to the orderer
In the case of encrypting the values (and even the keys if desired), I see that we have a dilemma in distributing the encryption key(s)
adc (Thu, 03 Aug 2017 10:41:23 GMT):
indeed
mastersingh24 (Thu, 03 Aug 2017 10:41:40 GMT):
The same if we want to encrypt the entire payload that is signed and sent to the orderer as well
adc (Thu, 03 Aug 2017 10:42:28 GMT):
yeah, this requires a deep dive
adc (Thu, 03 Aug 2017 10:42:36 GMT):
one solution is the one proposed by SideDB
adc (Thu, 03 Aug 2017 10:42:45 GMT):
so, hashes are sent to the orderders
adc (Thu, 03 Aug 2017 10:42:45 GMT):
so, hashes are sent to the orderers
adc (Thu, 03 Aug 2017 10:43:17 GMT):
and then there is the replication among the endorsers of the private values
adc (Thu, 03 Aug 2017 10:43:26 GMT):
still not clear what the other committing peers will validate then
mastersingh24 (Thu, 03 Aug 2017 10:43:28 GMT):
Sure - and we can take that a slightly different direction where we don't have secret data as well but still send the hashes only
adc (Thu, 03 Aug 2017 10:44:37 GMT):
as a side note, hashes need to be computed with some salt otherwise they might be used to perform some brute force attack if the hashed message does not contain enough entropy
adc (Thu, 03 Aug 2017 10:45:17 GMT):
another interesting direction might be of implementing the enigma protocol on top of fabric
adc (Thu, 03 Aug 2017 10:45:30 GMT):
but that is more complex I would say :)
adc (Thu, 03 Aug 2017 10:45:58 GMT):
https://www.enigma.co/enigma_full.pdf
adc (Thu, 03 Aug 2017 10:46:04 GMT):
I'm just speculating now
mastersingh24 (Thu, 03 Aug 2017 11:05:59 GMT):
So here was my thought on this one (for the more general solution for sending hashes but actually ending up with data on the public ledger and public state database (as opposed to the private ones in sidedb)):
1) Basically, when we prepare the response we send to the client rather than actual serializing the ChaincodeAction and including it in the ProposalResponsePayload, we'll actually just include the hash of it
2) Now we'll basically need to store the serialize ChaincodeAction locally at the endorser (as well as gossip it to other members of the channel) (this is the equivalent of how sidedb deals with private RWSets)
3) Client packages up the endorsement response as usual and send to the orderer
4) Peers receive blocks with these transactions in them (we can decide how we'll indicate these types of transactions)
5) Peer checks to see if it has the associated ChaincodeAction data locally and if not requests it from other peer(s) in the channel
6) Now we can of course process this just like normal since we have all the pieces
7) Updating the state store remains the same, but now when we actually serialize the block we can actually inject the ChaincodeAction data back into the structure
8) Block validation rules would mean you have to have this data plus you do the hash and sign the hash to validate the transactions in the block (or something like that)
mastersingh24 (Thu, 03 Aug 2017 11:05:59 GMT):
So here was my thought on this one (for the more general solution for sending hashes but actually ending up with data on the public ledger and public state database (as opposed to the private ones in sidedb)):
1) Basically, when we prepare the response we send to the client rather than actual serializing the ChaincodeAction and including it in the ProposalResponsePayload, we'll actually just include the hash of it
2) Now we'll basically need to store the serialize ChaincodeAction locally at the endorser (as well as gossip it to other members of the channel) (this is the equivalent of how sidedb deals with private RWSets)
3) Client packages up the endorsement response as usual and send to the orderer
4) Peers receive blocks with these transactions in them (we can decide how we'll indicate these types of transactions)
5) Peer checks to see if it has the associated ChaincodeAction data locally and if not requests it from other peer(s) in the channel
6) Now we can of course process this just like normal since we have all the pieces
7) Updating the state store remains the same, but now when we actually serialize the block we can actually inject the ChaincodeAction data back into the structure
8 ) Block validation rules would mean you have to have this data plus you do the hash and sign the hash to validate the transactions in the block (or something like that)
Eric.Bui (Thu, 03 Aug 2017 17:23:07 GMT):
Has joined the channel.
adc (Fri, 04 Aug 2017 01:20:31 GMT):
got it, so this would be a general solution to protect confidentiality against the orderers, got it. SideDB additionally can provide confidentiality against members of the channel.
adc (Fri, 04 Aug 2017 01:20:42 GMT):
We should have both mechanisms, I guess
sklump (Fri, 04 Aug 2017 10:54:29 GMT):
Has joined the channel.
sklump (Fri, 04 Aug 2017 10:57:43 GMT):
Hello, I was wondering how the cryptogen utility names a private key? I've been walking through the sample networks and can't seem to find any reference to the *_sk file names in any corresponding X.509 certificates. How would I match a certificate to its corresponding key? Thanks!
Vadim (Fri, 04 Aug 2017 11:00:54 GMT):
@sklump it matches cryptographically, i.e. with a priv key you can sign the message and only with the matching pub key you can validate it
sklump (Fri, 04 Aug 2017 11:07:20 GMT):
Yes, that much is clear. For example, I've generated a first-network via byfn.sh (calling cryptogen) and am in first-network/crypto-config/.
find . -name '*_sk' | grep -iP 'A5.*DD'
sklump (Fri, 04 Aug 2017 11:07:33 GMT):
gives back
./peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/keystore/a5dd6ee681e48c51595349cf9a765a61c8589dcf7e2bfeefa182e2e550b8fc8c_sk
sklump (Fri, 04 Aug 2017 11:08:08 GMT):
great, now to find what certificate corresponds to it?
for X in $(find . -name *.pem); do openssl x509 -in $X -noout -text | grep -liP 'A5.*DD'; done
sklump (Fri, 04 Aug 2017 11:08:25 GMT):
correction for X in $(find . -name \*.pem); do openssl x509 -in $X -noout -text | grep -liP 'A5.*DD'; done
sklump (Fri, 04 Aug 2017 11:08:41 GMT):
(sorry, the markup takes the star)
sklump (Fri, 04 Aug 2017 11:09:20 GMT):
Anyway, nothing comes back in openssl x509 showing anything like the name in *_sk and I'd like to know how cryptogen builds it?
Vadim (Fri, 04 Aug 2017 11:09:35 GMT):
but cryptogen always generates a key in msp/keystore and corresponding cert in msp/signcerts
sklump (Fri, 04 Aug 2017 11:10:58 GMT):
So in this case, peer0.org1.example.com-cert.pem matches the key in ./peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/keystore/.
sklump (Fri, 04 Aug 2017 11:11:35 GMT):
I want to add a peer organization - does the name of the private key file matter to the network?
sklump (Fri, 04 Aug 2017 11:11:51 GMT):
(Back in 10)
Vadim (Fri, 04 Aug 2017 11:13:21 GMT):
@sklump 1) yes, 2) no
sklump (Fri, 04 Aug 2017 11:19:53 GMT):
Thanks!
sklump (Fri, 04 Aug 2017 15:21:54 GMT):
I've been trying to add a peer to the byfn.sh network that comes in the v1.0 samples, as per Mr. Choi's instructions:
https://github.com/ChoiSD/how-to-Hyperledger-Fabric/blob/master/Docs/Add-Peer-On-Existing-Org.md
When I try to bring up the the docker container for org2/peer2, the docker logs reveal:
$ docker logs peer2.org2.example.com
2017-08-04 15:04:38.400 UTC [main] main -> ERRO 001 Cannot run peer because error when setting up MSP from directory /etc/hyperledger/fabric/msp: err KeyMaterial not found in SigningIdentityInfo
Would anyone have any pointers on how to troubleshoot this condition? What KeyMaterial might the peer (binary) be looking for?
sklump (Fri, 04 Aug 2017 15:33:24 GMT):
Never mind, found it! There can only be one signCert certificate in crypto-config/peerOrganizations/org2.example.com/peers/peer2.org2.example.com/msp/signcerts.
DrissB (Fri, 04 Aug 2017 16:21:48 GMT):
Has joined the channel.
eacoeytaux (Fri, 04 Aug 2017 19:53:21 GMT):
Has joined the channel.
shubhamvrkr (Sat, 05 Aug 2017 08:56:30 GMT):
Has joined the channel.
shubhamvrkr (Sat, 05 Aug 2017 08:56:44 GMT):
Consider i have one MSP instance for one organization . Is it possible to define my own MSP rules for identity validations .?
yacovm (Sat, 05 Aug 2017 11:04:58 GMT):
@shubhamvrkr you mean an MSP that isn't an x509 MSP?
Selvam_Annamalai (Sun, 06 Aug 2017 02:40:44 GMT):
Has joined the channel.
Selvam_Annamalai (Sun, 06 Aug 2017 02:41:06 GMT):
i, I am trying to execute first-network tutorial. I am getting below error when I execute ./byfn.sh -m up command. Can you please tell me how to resolve this issue?
Build your first network (BYFN) end-to-end test
Channel name : mychannel
Creating channel...
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/c
rypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto
/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.key
CORE_PEER_LOCALMSPID=Org1MSP
CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypt
o/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.crt
CORE_PEER_TLS_ENABLED=true
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypt
o/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
CORE_PEER_ID=cli
CORE_LOGGING_LEVEL=DEBUG
CORE_PEER_ADDRESS=peer0.org1.example.com:7051
2017-08-05 03:27:29.240 UTC [main] main -> ERRO 001 Cannot run peer because erro
r when setting up MSP from directory /opt/gopath/src/github.com/hyperledger/fabr
ic/peer/crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/m
sp: err CA Certificate is not valid, (SN: 23928727680478186216358925795005272960
) [Could not obtain certification chain, err The supplied identity is not valid,
Verify() returned x509: certificate has expired or is not yet valid]
!!!!!!!!!!!!!!! Channel creation failed !!!!!!!!!!!!!!!!
========= ERROR !!! FAILED to execute End-2-End Scenario ==========
mastersingh24 (Sun, 06 Aug 2017 10:34:33 GMT):
@Selvam_Annamalai https://chat.hyperledger.org/channel/fabric-questions?msg=3wakvC5DhoSYutvTn
shubhamvrkr (Sun, 06 Aug 2017 16:04:18 GMT):
@yacovm yes
yacovm (Sun, 06 Aug 2017 16:08:54 GMT):
Implement you own MSP
y204990 (Sun, 06 Aug 2017 16:25:53 GMT):
Has joined the channel.
shubhamvrkr (Mon, 07 Aug 2017 04:10:18 GMT):
@yacovm any docs on how to implement an msp?
BhavishaDawda (Tue, 08 Aug 2017 13:11:20 GMT):
Has joined the channel.
dileban (Wed, 09 Aug 2017 04:21:44 GMT):
Has joined the channel.
Selvam_Annamalai (Thu, 10 Aug 2017 10:04:02 GMT):
I have modified the first network
• Generated certificates and channel artifacts in the first machine with configtx and crypto-config yaml files (which contains both the org details,the 4 nodes & one Orderer) by running the command ./byfn.sh –m generate
• Updated docker-compose-cli, docker-compose-couch, docker-compose-e2e-template and docker-compose-base yaml files to contain first org, 2 peer nodes and 1 Orderer.
• Started the network (First Org with 2 nodes and Orderer) in the first machine by running the command ./byfn.sh –m up
• Copied the generated certificates and the channel artifacts in to the second machine
• Updated docker-compose-cli, docker-compose-couch, docker-compose-e2e-template and docker-compose-base yaml files to contain second org, 2 peer nodes and without Orderer.
• Did not call CreateChannel function in script.sh file. Commented out.
• Started the network (Second Org with 2 nodes without Orderer) in the second machine by running the command ./byfn.sh –m up
• Got the exception “Error: genesis block file not found open mychannel.block: no such file or directory” during Channel Join Operation.
Can you please tell me how to resolve this issue?
mastersingh24 (Thu, 10 Aug 2017 14:01:01 GMT):
You need the mychannel.block from the first machine in order for the peers on the second machine to join the channel
viampietro (Thu, 10 Aug 2017 15:17:43 GMT):
Has joined the channel.
viampietro (Thu, 10 Aug 2017 15:17:54 GMT):
Good morning everyone !
I have a question.
I'm trying to build a blockchain application with hyperledger fabric.
I used cryptogen to generate the crypto materials for my orderers and my peers, and I wrote my chaincode program and tested it with the command line 'peer' executable.
Now I'm trying to write a client app to query the chaincode with the Node SDK. I don't understand how to use the crypto-material generated with cryptogen in order to authenticate a user, and not being pushed out by the network every time I try to transact with the blockchain.
In the 'query.js' file of the 'fabcar' app example, the crypto material used to authenticate the user is located in the network/creds directory.
There are three files in this directory one private key, one public key and one json file containing a key, but again I don't understand where these crypto-materials are coming from.
Does anyone ever leverage the crypto-material generated with the cryptogen within a Node SDK hyperledger fabric application ?
berserkr (Sat, 12 Aug 2017 04:42:15 GMT):
ditto ^^^^
berserkr (Sat, 12 Aug 2017 04:42:58 GMT):
many of us are having the same issue, fabric-ca is perhaps the best place to ask, I am yet to get a good answer :(
mastersingh24 (Sat, 12 Aug 2017 18:27:49 GMT):
@viampietro @berserkr - If you want to use the material generated by cryptogen with the NodeSDK, you can use the https://fabric-sdk-node.github.io/Client.html#createUser__anchor method of the SDK which allows you to specify existing key and cert files
mastersingh24 (Sat, 12 Aug 2017 18:30:31 GMT):
```
/Users/gsingh/Projects/gerrit-hl/fabric-samples/crypto-config/peerOrganizations/org1.example.com/users
Garis-MBP:users gsingh$ ls -l Admin\@org1.example.com/
msp/ tls/
Garis-MBP:users gsingh$ ls -l Admin\@org1.example.com/msp/
total 0
drwxr-xr-x 3 gsingh staff 102 Aug 12 14:28 admincerts
drwxr-xr-x 3 gsingh staff 102 Aug 12 14:28 cacerts
drwxr-xr-x 3 gsingh staff 102 Aug 12 14:28 keystore
drwxr-xr-x 3 gsingh staff 102 Aug 12 14:28 signcerts
drwxr-xr-x 3 gsingh staff 102 Aug 12 14:28 tlscacerts
Garis-MBP:users gsingh$ ls -l User1\@org1.example.com/msp/
total 0
drwxr-xr-x 3 gsingh staff 102 Aug 12 14:28 admincerts
drwxr-xr-x 3 gsingh staff 102 Aug 12 14:28 cacerts
drwxr-xr-x 3 gsingh staff 102 Aug 12 14:28 keystore
drwxr-xr-x 3 gsingh staff 102 Aug 12 14:28 signcerts
drwxr-xr-x 3 gsingh staff 102 Aug 12 14:28 tlscacerts
```
mastersingh24 (Sat, 12 Aug 2017 18:30:44 GMT):
The output above is from cryptogen
mastersingh24 (Sat, 12 Aug 2017 18:31:48 GMT):
There are 2 "users" generated - one is an admin and the other is a regular user. The private key is in the `keystore` folder and the public key is in the `signcerts` folder
mastersingh24 (Sat, 12 Aug 2017 18:35:13 GMT):
Here's some sample code which loads up the admin user: https://github.com/hyperledger/fabric-sdk-node/blob/master/test/unit/util.js#L165
ydk210999 (Sun, 13 Aug 2017 07:23:32 GMT):
Has joined the channel.
wy (Sun, 13 Aug 2017 15:37:46 GMT):
Has joined the channel.
wy (Sun, 13 Aug 2017 15:37:53 GMT):
hi guys
wy (Sun, 13 Aug 2017 15:38:49 GMT):
@here is it possible to change/update the public key or certs of a specific organisation once the network is up?
yacovm (Sun, 13 Aug 2017 15:39:15 GMT):
yes
wy (Sun, 13 Aug 2017 15:39:28 GMT):
how can this be done? @yacovm
yacovm (Sun, 13 Aug 2017 15:39:31 GMT):
it's a similar process of doing a channel reconfiguration
yacovm (Sun, 13 Aug 2017 15:39:39 GMT):
you need to update the root CA certs
yacovm (Sun, 13 Aug 2017 15:39:43 GMT):
and issue a config update
yacovm (Sun, 13 Aug 2017 15:39:48 GMT):
but.... that's tricky
yacovm (Sun, 13 Aug 2017 15:39:54 GMT):
in v1.0 we have some constraints for this
yacovm (Sun, 13 Aug 2017 15:39:55 GMT):
for example
yacovm (Sun, 13 Aug 2017 15:40:07 GMT):
the organization you change the root CA certs for
yacovm (Sun, 13 Aug 2017 15:40:10 GMT):
can't have an orderer :(
yacovm (Sun, 13 Aug 2017 15:40:23 GMT):
so... you can only change root CA certs of orgs that have no orderers
wy (Sun, 13 Aug 2017 15:40:47 GMT):
i see..
wy (Sun, 13 Aug 2017 15:41:10 GMT):
is there a page with instructions on how to achieve this?
wy (Sun, 13 Aug 2017 15:41:38 GMT):
@yacovm
wy (Sun, 13 Aug 2017 15:43:54 GMT):
and also i am wondering if adding a new organisation is possible once the network is up?
yacovm (Sun, 13 Aug 2017 15:53:21 GMT):
yes it is
yacovm (Sun, 13 Aug 2017 15:54:03 GMT):
https://github.com/hyperledger/fabric/blob/release/docs/source/configtxlator.rst
tennenjl (Mon, 14 Aug 2017 17:59:10 GMT):
Hi Team, is it possible to have a shared CA implementation that points to multiple organization LDAPs? Thanks!
Jonny (Tue, 15 Aug 2017 14:10:36 GMT):
Has joined the channel.
vdods (Tue, 15 Aug 2017 23:00:54 GMT):
Hi all, I'm finally getting around to turning on TLS on all the different components of my fabric app (ca, peer, orderer), and I'm getting the following error upon call to client createChannel:
```www.example.com | debug: [Client.js]: _createOrUpdateChannel - start
www.example.com | debug: [Client.js]: _createOrUpdateChannel - have config_update
www.example.com | debug: [Client.js]: _stringToSignature - signature is protobuf
www.example.com | debug: [client-utils.js]: buildChannelHeader - type 2 channel_id mychannel tx_id NaN epoch % chaincode_id undefined
www.example.com | debug: [crypto_ecdsa_aes]: ecdsa signature: negative=0, words=[44159681, 33315475, 53322140, 42476587, 76906, 61675239, 21784406, 65193161, 49097892, 243760, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], length=10, red=null, negative=0, words=[9106481, 31610191, 42272797, 49233964, 41914201, 18550706, 21840844, 32934240, 31744129, 1806021, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], length=10, red=null, recoveryParam=0
www.example.com | debug: [Client.js]: _createOrUpdateChannel - about to send envelope
www.example.com | debug: [Orderer.js]: sendBroadcast - start
www.example.com | debug: [Orderer.js]: sendBroadcast - sent message
www.example.com | E0815 22:50:47.367759189 29 ssl_transport_security.c:651] Invalid cipher list: undefined.
www.example.com | E0815 22:50:47.367877671 29 security_connector.c:837] Handshaker factory creation failed with TSI_INVALID_ARGUMENT.
www.example.com | E0815 22:50:47.367906876 29 secure_channel_create.c:127] Failed to create secure subchannel for secure name 'orderer.example.com:7050'
www.example.com | E0815 22:50:47.367913099 29 secure_channel_create.c:158] Failed to create subchannel arguments during subchannel creation.
www.example.com | error: [Orderer.js]: sendBroadcast - timed out after:3000
```
vdods (Tue, 15 Aug 2017 23:01:21 GMT):
The error message isn't particularly useful in debugging
vdods (Tue, 15 Aug 2017 23:02:13 GMT):
This is using fabric-sdk-node (and I asked in that channel to no response), but I'm asking here because I'm looking for clues on how to debug the problem
vdods (Tue, 15 Aug 2017 23:18:27 GMT):
Which cipher is used by orderer TLS?
ashutosh_kumar (Wed, 16 Aug 2017 16:13:01 GMT):
@vdods , the TLS version has been set to 1.2 on Server. Make sure your client is on that level.
ashutosh_kumar (Wed, 16 Aug 2017 16:16:12 GMT):
the best way to debug this problem is to start with TLS level. Cipher suite approach will be much more difficult.
jmcnevin (Wed, 16 Aug 2017 16:58:14 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=k8mR65BnxWLgbbvdp) @jtrayfield Did you ever resolve this issue?
gauthampamu (Thu, 17 Aug 2017 02:34:20 GMT):
Has anyone test the Hyperledger Fabric or the Node SDK with any HSM products that support PKCS11 API. Can you provide some suggestions for the HSM products that are supported with Fabric.
gauthampamu (Thu, 17 Aug 2017 02:34:20 GMT):
Has anyone tested the Hyperledger Fabric or the Node SDK with any HSM products that support PKCS11 API. Can you provide some suggestions for the HSM products that are supported with Fabric.
gauthampamu (Thu, 17 Aug 2017 02:41:25 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=sWyNq5Wq6fPZSyHNL) @ashutosh_kumar Just to confirm. We use TLS 1.2 by default right for the Peer, Orderer and Kafka Cluster.
ashutosh_kumar (Thu, 17 Aug 2017 13:56:48 GMT):
Peer and Orderer are on TLS 1.2. I am not sure about Kafka.
ashutosh_kumar (Thu, 17 Aug 2017 13:57:17 GMT):
We have tested HSM using softHSM.
ashutosh_kumar (Thu, 17 Aug 2017 13:57:59 GMT):
Any product that supports PKCS11 should work
Ashish (Sat, 19 Aug 2017 06:43:10 GMT):
Has joined the channel.
mastersingh24 (Sat, 19 Aug 2017 10:41:43 GMT):
@eetti - Could you provide a few more details on exactly what you were doing here?
And can you share the openssl command you used to generate the certificates?
(https://chat.hyperledger.org/channel/fabric-ca?msg=stPoegXzS9mB6PSKB)
eetti (Sat, 19 Aug 2017 10:41:44 GMT):
Has joined the channel.
eetti (Sat, 19 Aug 2017 12:45:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=SQJTnZteKSBqyzNAG) @mastersingh24 Okay, a certificates were generated for the admin user and nodes {orderers,peers}. Unfortunately I cant share the openssl commands, I created csr's and the certificates were generated/signed elsewhere. So i created a folder msp and 3 sub-folders (admincerts,cacerts,tlscacerts) and set the path in the MSPDIR under the ordererOrg in configtx.yaml. The contents of the sub-folders corresponded with the certs that were given back to me.
mastersingh24 (Sat, 19 Aug 2017 13:04:56 GMT):
I don't suppose you can share the public X509 certificate(s)? Did you request EC or RSA certs?
ashutosh_kumar (Sat, 19 Aug 2017 13:10:19 GMT):
openssl command for ECERT does not seem to be straightforward , at least the way I do it. For that reason , I suggest folks to use cfssl.
ashutosh_kumar (Sat, 19 Aug 2017 13:10:19 GMT):
openssl command for elliptic curve does not seem to be straightforward , at least the way I do it. For that reason , I suggest folks to use cfssl.
eetti (Sat, 19 Aug 2017 13:20:13 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=PPts5YWmHAnRCtct2) @mastersingh24 I requested ECDSA for each of the nodes the curve was secp256k1
eetti (Sat, 19 Aug 2017 13:20:13 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=PPts5YWmHAnRCtct2) @mastersingh24 I requested ECDSA for each of the nodes the type of elliptic curve was secp256k1
ashutosh_kumar (Sat, 19 Aug 2017 17:13:36 GMT):
@eetti , if you can share certificate with me , I can try to parse it on my end.
aso (Sun, 20 Aug 2017 06:20:11 GMT):
@ashutosh_kumar
> openssl command for elliptic curve does not seem to be straightforward
here's an example of how I do it, might be useful for others
```
# generate ca private key
openssl ecparam -name prime256v1 -out $curveParamFile
openssl ecparam -in $curveParamFile -genkey -noout -out $cakeyFile
# generate ca cert
openssl req -config $confFile -key $cakeyFile -new -x509 -days 7300 -sha256 -extensions v3_ca -out $cacertFile -subj "/O=$orgName/OU=$orgName/CN=CA"
# generate the signing key for this entity
keyFile=$kyDir/key-$entity.pem
openssl ecparam -in $curveParamFile -genkey -noout -out $keyFile
# generate CSR for the entity
csrFile=$entityDir/csr.pem
openssl req -key $keyFile -new -sha256 -out $csrFile -subj "/O=$orgName/OU=$orgName/OU=$entity/CN=$entity"
# issue a certificate for this entity
certFile=$ceDir/cert-$entity.pem
openssl ca -config $confFile -extensions usr_cert -days 7300 -md sha256 -in $csrFile -out $certFile -batch -notext
```
aso (Sun, 20 Aug 2017 06:23:31 GMT):
@eetti: if you want to parse a cert with openssl:
```
openssl x509 -in $cert -noout -text
```
mastersingh24 (Sun, 20 Aug 2017 17:06:57 GMT):
@eetti - I have not been able to produce the exact issue, but some research shows that the issue was likely with the fact that your private key file was generated with ecparams. You'll want to use the `-noout` option when generating the EC private key. Also, FYI - once you get past that issue you'll hit another: fabric does not support `secp256k1` curves - only the default curves provides by the Go (which are the FIPS curves) are supported - typically p256 and p384.
(https://chat.hyperledger.org/channel/fabric-crypto?msg=fGreZEMZ7sRFwqNaT)
eetti (Sun, 20 Aug 2017 20:45:58 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=Do8Bz6jTL4yQkGi8c) @mastersingh24 That's very true, I created the private key with ecparams. Thanks a lot, I will create new csr's and generate the private key without ecparams. Then make sure I use either prime256v1/secp384r1/secp521r1 .
eetti (Sun, 20 Aug 2017 20:47:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=m7kZgB8g8sDvCGApN) @aso Noted, thanks.
ashutosh_kumar (Mon, 21 Aug 2017 00:46:32 GMT):
@aso , I also use the same way sans parameter file. Using Parameter file introduces extra parameter construct in the private key file which Go does not like .
ashutosh_kumar (Mon, 21 Aug 2017 00:46:32 GMT):
@aso , I also use the same way sans curve parameter file. Using Parameter file introduces extra parameter construct in the private key file which Go does not like .
ashutosh_kumar (Mon, 21 Aug 2017 00:46:32 GMT):
@aso , I also use the same way sans curve parameter file. I saw , @mastersingh24 also mentioned it.Using Parameter file introduces extra parameter construct in the private key file which Go does not like .
ashutosh_kumar (Mon, 21 Aug 2017 00:48:20 GMT):
as you elaborated above , openssl for EC seems not too intutitive to me , hence I like CFSSL much better.
ashutosh_kumar (Mon, 21 Aug 2017 00:48:20 GMT):
as you elaborated above , openssl for EC seems not too intutitive (at least to me) , hence I like CFSSL much better
Hangyu (Mon, 21 Aug 2017 01:52:58 GMT):
Has joined the channel.
wy (Mon, 21 Aug 2017 03:43:29 GMT):
hi guys, i see that `cryotogen.sh` created the private key for the admin user in `/crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/keystore`
wy (Mon, 21 Aug 2017 03:43:29 GMT):
hi guys, i see that `cryptogen.sh` created the private key for the admin user in `/crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/keystore`
wy (Mon, 21 Aug 2017 03:43:47 GMT):
where is the public key though?
yacovm (Mon, 21 Aug 2017 05:48:52 GMT):
../signcerts
shubhamvrkr (Mon, 21 Aug 2017 06:21:05 GMT):
hi .. why do we need Org1MSPanchors.tx or Org2MSPanchors.tx file? while creating the channel.tx file , anchor peers is alrady mentioned in the channelprofile itself
stanacton (Mon, 21 Aug 2017 12:04:24 GMT):
Hi.. I'm using the byfn.sh scripts to generate the certs which use the cryptogen tool. When the certs are generated, despite the cert date saying it's valid immediately, it keeps being unusable for 5 min.. has anyone seen this behaviour? Is this normal?
Vadim (Mon, 21 Aug 2017 12:04:52 GMT):
@stanacton I guess your docker container time lags behind
stanacton (Mon, 21 Aug 2017 12:05:11 GMT):
I thought that too, but when I check it, it has a valid time.
Vadim (Mon, 21 Aug 2017 12:05:32 GMT):
exactly the same as on your host?
stanacton (Mon, 21 Aug 2017 12:05:42 GMT):
yes, but UTC time.
stanacton (Mon, 21 Aug 2017 12:05:52 GMT):
the Cert is in UTC time too
Vadim (Mon, 21 Aug 2017 12:06:19 GMT):
did you check when the certificate is valid from?
stanacton (Mon, 21 Aug 2017 12:07:01 GMT):
yes. It always set the valid from time/date to when I generated it.
Vadim (Mon, 21 Aug 2017 12:07:57 GMT):
so why is it unusable for 5 min then=?
Vadim (Mon, 21 Aug 2017 12:07:57 GMT):
so why is it unusable for 5 min then?
stanacton (Mon, 21 Aug 2017 12:08:41 GMT):
great question. I don't know. It is ok for a normal scenario, but I want to be able to spin up networks and pull them down to do Testing.. but if I have to wait 5 min each iteration, then it's a pain.
stanacton (Mon, 21 Aug 2017 12:08:56 GMT):
BUT... I might be doing something wrong. I just thought I'd check here to see if I'm missing anything obvious.
Vadim (Mon, 21 Aug 2017 12:09:40 GMT):
which fabric component tells that the certificate is not valid?
stanacton (Mon, 21 Aug 2017 12:10:24 GMT):
I believe it's a peer. I can communicate with the CA ok. I'm using the fabric-sdk-node too
Vadim (Mon, 21 Aug 2017 12:10:44 GMT):
it's not fabric-sdk-nodeè
Vadim (Mon, 21 Aug 2017 12:10:44 GMT):
it's not fabric-sdk-node?
Vadim (Mon, 21 Aug 2017 12:11:02 GMT):
can you post the error message here?
stanacton (Mon, 21 Aug 2017 12:11:15 GMT):
sure.. hold on.
stanacton (Mon, 21 Aug 2017 12:13:59 GMT):
Error: Failed to deserialize creator identity, err The supplied identity is not valid, Verify() returned x509: certificate has expired or is not yet valid
Vadim (Mon, 21 Aug 2017 12:14:36 GMT):
I still think that the peer time lags behind
stanacton (Mon, 21 Aug 2017 12:15:00 GMT):
I think you're right that it might be the fabric-sdk... When the install scripts run from the CLI tools container, they can use the Certs fine... it's only when I run the SDK from the host it doesn't work for 5 min.
stanacton (Mon, 21 Aug 2017 12:15:09 GMT):
I'll keep investigating.
stanacton (Mon, 21 Aug 2017 12:15:33 GMT):
@Vadim Thanks for your help!! I appreciate it!
Vadim (Mon, 21 Aug 2017 12:15:38 GMT):
can you execute on your peer container `docker exec
Vadim (Mon, 21 Aug 2017 12:16:01 GMT):
I mean, not on peer container, on your host
stanacton (Mon, 21 Aug 2017 12:16:17 GMT):
Mon 21 Aug 2017 13:16:11 BST
Vadim (Mon, 21 Aug 2017 12:16:36 GMT):
perhaps even better `docker exec
stanacton (Mon, 21 Aug 2017 12:16:57 GMT):
Mon Aug 21 12:16:49 UTC 2017
Mon 21 Aug 2017 13:16:49 BST
Vadim (Mon, 21 Aug 2017 12:17:19 GMT):
yeah, looks the same
stanacton (Mon, 21 Aug 2017 12:17:44 GMT):
it must be some quirk with the SDK. I'll check in that channel. Thanks again for your help!
Vadim (Mon, 21 Aug 2017 12:17:53 GMT):
no problem
eetti (Mon, 21 Aug 2017 14:43:34 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=m7kZgB8g8sDvCGApN) @aso Are you saying I should use the same curveParamFile to create the ca private key and node private key (signcerts) ?
aso (Mon, 21 Aug 2017 15:58:07 GMT):
yup - the curve should be the same
aso (Mon, 21 Aug 2017 15:58:17 GMT):
@eetti ^
eetti (Mon, 21 Aug 2017 15:59:31 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=gcmTMtioH86x7PfMy) @aso Okay, I previously used different curve param files. Let me used the same one.
aso (Mon, 21 Aug 2017 16:01:20 GMT):
@eetti at the end of the day it doesn't matter, the command will deterministically produce the same file with the description of the `prime256v1` standard curve
aso (Mon, 21 Aug 2017 16:01:34 GMT):
it's always the same curve
eetti (Mon, 21 Aug 2017 16:28:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=sbqn5Zh9pGr5bQMpE) @aso Okay, thank you
raidinesh80 (Mon, 21 Aug 2017 17:13:32 GMT):
Has joined the channel.
eetti (Mon, 21 Aug 2017 19:11:46 GMT):
I got this error
2017-08-21 15:09:57.158 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-08-21 15:09:57.200 EDT [configvalues/msp] TemplateGroupMSPWithAdminRolePrincipal -> CRIT 002 Setting up the MSP manager failed, err CA Certificate is not valid, (SN: 6) [Could not obtain certification chain, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority]
Failed to generate orderer genesis block...
When I checked my self signed certs, the issuer information was missing. I followed the same commands @ashutosh_kumar provided for openssl.
eetti (Mon, 21 Aug 2017 19:11:46 GMT):
I got this error
2017-08-21 16:02:08.124 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-08-21 16:02:08.132 EDT [configvalues/msp] TemplateGroupMSPWithAdminRolePrincipal -> CRIT 002 Setting up the MSP manager failed, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority
Failed to generate orderer genesis block...
eetti (Mon, 21 Aug 2017 19:11:46 GMT):
I got this error, when I used the root-ca to sign the tls cert
2017-08-21 16:02:08.124 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-08-21 16:02:08.132 EDT [configvalues/msp] TemplateGroupMSPWithAdminRolePrincipal -> CRIT 002 Setting up the MSP manager failed, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority
Failed to generate orderer genesis block...
2017-08-21 17:31:46.996 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-08-21 17:31:47.016 EDT [configvalues/msp] TemplateGroupMSPWithAdminRolePrincipal -> CRIT 002 Setting up the MSP manager failed, err The supplied identity is not valid, Verify() returned x509: certificate specifies an incompatible key usage
Failed to generate orderer genesis block...
eetti (Mon, 21 Aug 2017 19:11:46 GMT):
I got this error, when I used the root-ca to sign the tls cert
2017-08-21 16:02:08.124 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-08-21 16:02:08.132 EDT [configvalues/msp] TemplateGroupMSPWithAdminRolePrincipal -> CRIT 002 Setting up the MSP manager failed, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority
Failed to generate orderer genesis block...
I got this error, when I did not use the root-ca to sign the tls cert
2017-08-21 17:31:46.996 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-08-21 17:31:47.016 EDT [configvalues/msp] TemplateGroupMSPWithAdminRolePrincipal -> CRIT 002 Setting up the MSP manager failed, err The supplied identity is not valid, Verify() returned x509: certificate specifies an incompatible key usage
Failed to generate orderer genesis block...
eetti (Mon, 21 Aug 2017 19:11:46 GMT):
I got this error, when I used the root-ca to sign the tls cert
2017-08-21 16:02:08.124 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-08-21 16:02:08.132 EDT [configvalues/msp] TemplateGroupMSPWithAdminRolePrincipal -> CRIT 002 Setting up the MSP manager failed, err The supplied identity is not valid, Verify() returned x509: *certificate signed by unknown authority*
Failed to generate orderer genesis block...
I got this error, when I did not use the root-ca to sign the tls cert
2017-08-21 17:31:46.996 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-08-21 17:31:47.016 EDT [configvalues/msp] TemplateGroupMSPWithAdminRolePrincipal -> CRIT 002 Setting up the MSP manager failed, err The supplied identity is not valid, Verify() returned x509: *certificate specifies an incompatible key usage*
Failed to generate orderer genesis block...
eetti (Mon, 21 Aug 2017 21:10:06 GMT):
tls
ashutosh_kumar (Mon, 21 Aug 2017 21:56:38 GMT):
For the first error , you need to put your self signed cert in the msp/cacerts directory.If you follow the @aso directions , you'll get cert issued by your local CA. In that case , you need to put your local CA cert in msp/cacerts directory.
ashutosh_kumar (Mon, 21 Aug 2017 21:58:29 GMT):
what did you use to sign TLS cert ? openssl ? Looks like you are not setting up KeyUsage extension correctly.
eetti (Mon, 21 Aug 2017 22:35:07 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=7Sw5GeBchzssKRZSd) @ashutosh_kumar openssl
eetti (Mon, 21 Aug 2017 22:35:07 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=7Sw5GeBchzssKRZSd) @ashutosh_kumar I am using openssl, what's KeyUsage extension
yacovm (Mon, 21 Aug 2017 22:45:02 GMT):
key usage extension defines what purposes this certificate can be used for
yacovm (Mon, 21 Aug 2017 22:45:11 GMT):
for example- client authentication, server authentication, etc. etc.
eetti (Mon, 21 Aug 2017 22:46:52 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=HTnYEuW6sRiwcaTPk) @yacovm Okay, I checked my KeyUsage was critical, nonRepudiation, digitalSignature, keyEncipherment so I changed it to just have digitalSignature, keyEncipherment
eetti (Mon, 21 Aug 2017 22:46:52 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=HTnYEuW6sRiwcaTPk) @yacovm Okay, I checked my KeyUsage was *critical, nonRepudiation, digitalSignature, keyEncipherment* so I changed it to just have *digitalSignature, keyEncipherment*
eetti (Mon, 21 Aug 2017 22:47:28 GMT):
Now I get this error
2017-08-21 18:44:36.219 EDT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-08-21 18:44:36.246 EDT [configvalues/msp] TemplateGroupMSPWithAdminRolePrincipal -> CRIT 002 Setting up the MSP manager failed, err *CA Certificate did not have the Subject Key Identifier extension*, (SN: 6)
Failed to generate orderer genesis block...
ashutosh_kumar (Mon, 21 Aug 2017 22:47:36 GMT):
your cert should not ca flg set to true,
eetti (Mon, 21 Aug 2017 22:48:14 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=W4vwxCfSLDKbEZroY) @ashutosh_kumar
Do you mean this?
basicConstraints = CA:FALSE
ashutosh_kumar (Mon, 21 Aug 2017 22:48:35 GMT):
yeah. you are good from that perspective.
ashutosh_kumar (Mon, 21 Aug 2017 22:49:30 GMT):
Now the error that you are showing on CA cert , is that related to MSP ?
eetti (Mon, 21 Aug 2017 22:50:06 GMT):
Yes, the serial Number for the affected cert points to the TLS cert
ashutosh_kumar (Mon, 21 Aug 2017 22:51:37 GMT):
whatever , your CA cert does not seem right. SKI is hash of cert.
eetti (Mon, 21 Aug 2017 22:51:48 GMT):
I finally got it working, I didnt use the root cert to sign the TLS
ashutosh_kumar (Mon, 21 Aug 2017 22:51:51 GMT):
you need to set SKI in CA cert
ashutosh_kumar (Mon, 21 Aug 2017 22:51:54 GMT):
ok.
ashutosh_kumar (Mon, 21 Aug 2017 22:51:59 GMT):
awesome.
eetti (Mon, 21 Aug 2017 22:52:05 GMT):
Thanks
eetti (Mon, 21 Aug 2017 23:20:41 GMT):
I am still getting the same issue, I was using the wront crypto-config folder in my configtx.yaml file.
2017-08-21 19:19:37.289 EDT [configvalues/msp] TemplateGroupMSPWithAdminRolePrincipal -> CRIT 002 Setting up the MSP manager failed, *err CA Certificate did not have the Subject Key Identifier extension*, (SN: 6)
Failed to generate orderer genesis block...
I checked the cert it has X509v3 Subject Key Identifier and it matches to the root certs authority Key Identifier
aso (Tue, 22 Aug 2017 06:16:02 GMT):
`CA Certificate did not have the Subject Key Identifier extension` means that your CA cert - whatever it is - does not have this extension
```
X509v3 extensions:
...
X509v3 Subject Key Identifier:
17:67:42:3D:AA:9E:82:3F:C4:C5:1D:9F:5B:C3:99:D1:B5:9C:48:10
```
aso (Tue, 22 Aug 2017 06:16:45 GMT):
@eetti try to inspect your cert with `openssl x509 -in your_cacert_file -noout -text`
aso (Tue, 22 Aug 2017 06:16:56 GMT):
and verify whether that extension is present
sklump (Tue, 22 Aug 2017 11:51:00 GMT):
Has left the channel.
eetti (Tue, 22 Aug 2017 12:47:59 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=ebfvNQCbtaGXThANM) @aso The ca cert has the subject key identifier extension. Its possible I am doing something wrong. How would I create admin certs and tlscacert for use in msp folder in order to generate a genesis block? I think this is where i have issues.
aso (Tue, 22 Aug 2017 18:21:10 GMT):
@eetti which tool do you use to generate certs?
eetti (Tue, 22 Aug 2017 18:49:14 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=o9mfsnYjMLtKgb4bc) @aso openssl
aso (Tue, 22 Aug 2017 18:54:11 GMT):
@eetti I'll share the openssl-based script I use to generate certs
aso (Tue, 22 Aug 2017 18:54:11 GMT):
@eetti I'll share with you in pvt the openssl-based script I use to generate certs
eetti (Tue, 22 Aug 2017 18:54:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=HypQzvh3q4fJaKiLe) @aso Thanks, that would be great
habpygo (Tue, 22 Aug 2017 20:55:58 GMT):
Has joined the channel.
Hai-XuCheng (Wed, 23 Aug 2017 08:42:39 GMT):
Has joined the channel.
ajp (Wed, 23 Aug 2017 19:25:50 GMT):
Has joined the channel.
ajp (Wed, 23 Aug 2017 19:27:41 GMT):
Hi all I was directed here for this question. I was wondering if there is any work in place to prevent the owner of a peer, or an attacker who has managed to gain access to a peer, to enter the currently running chaincode container (via docker exec) and simply replacing the existing binary with their own, thus allowing any chaincode to run without other parties' knowledge?
nimtiazm (Thu, 24 Aug 2017 00:27:55 GMT):
Has joined the channel.
qsmen (Thu, 24 Aug 2017 01:15:36 GMT):
hello，are transaction certs used in fabric 1.0? can we know who sign a transaction just from the signature signed by the transaction cert? Thank you.
aso (Thu, 24 Aug 2017 07:15:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=JoatX34uDKBL8Pxcz) @ajp No, a malicious admin is free to tamper with its own peer (and so is an attacker who has gained control of the peer). However by replacing the chaincode you don't gain much *IF* endorsement policies require signatures from more than one organization. The rogue chaincode will produce different results than those produced by honest peers, and so the transaction will not be endorsed.
aso (Thu, 24 Aug 2017 07:17:54 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=TTCyhz3Qpj8Dkqpnx) @qsmen In v1, certificates used by entities that transact are long-term ones and so they can be used to identify the transactor and link their transactions. There are plans to integrate one-time use certificates (aka tcerts) or idemix to resolve these issues.
simoneromani (Fri, 25 Aug 2017 08:17:57 GMT):
Has joined the channel.
gauthampamu (Fri, 25 Aug 2017 12:19:04 GMT):
https://chat.hyperledger.org/channel/fabric-ca?msg=8JZkrPnNf5nZNK4Ey I have question on use of RSA based cert for the Fabric CA and can it issue ECDSA cert even though its CA cert is configured with RSA.
mastersingh24 (Fri, 25 Aug 2017 13:17:30 GMT):
@gauthampamu - Please just use EC crypto for everything
gauthampamu (Fri, 25 Aug 2017 13:26:13 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=m7kZgB8g8sDvCGApN) @aso [ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=m7kZgB8g8sDvCGApN) @aso Can you also share the sample confFile you used for certs
gauthampamu (Fri, 25 Aug 2017 13:26:13 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=m7kZgB8g8sDvCGApN) @aso [ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=m7kZgB8g8sDvCGApN) @ashutosh_kumar Can you also share the sample confFile you used for certs
aso (Fri, 25 Aug 2017 13:30:38 GMT):
@gauthampamu I'll paste my script but be warned - it contains some `rm`'s and some `find -exec rm` so I recommend you have a look before you execute it
aso (Fri, 25 Aug 2017 13:30:52 GMT):
That said, I've used it a gazillion times and it has never failed me!
aso (Fri, 25 Aug 2017 13:31:11 GMT):
also: on MAC it has issues, it requires at least openssl v1
aso (Fri, 25 Aug 2017 13:31:21 GMT):
and on MAC, `readlink -f` doesn't work
aso (Fri, 25 Aug 2017 13:31:25 GMT):
```
#!/bin/bash
# Copyright Alessandro Sorniotti - IBM Research Zurich
orgName=$1
basedir=`readlink -f $orgName`
shift
entities=$@
if test -d $orgName
then
echo "directory $basedir already exists"
rm -rf $orgName
mkdir $orgName
# exit -1
else
echo "making directory $basedir"
mkdir $orgName
fi
cd $basedir
# generate some useful aliases
confFile=$basedir/caconf
cakeyFile=$basedir/cakey-$orgName.pem
cacertFile=$basedir/cacert-$orgName.pem
curveParamFile=$basedir/secp256k1.pem
serialFile=$basedir/serial
dbFile=$basedir/db
cat <<- EOF > $confFile
[ ca ]
default_ca = CA_default
[ CA_default ]
dir = $basedir
certs = $basedir/
crl_dir = $basedir/
new_certs_dir = $basedir/
database = $dbFile
serial = $basedir/serial
RANDFILE = $basedir/
private_key = $cakeyFile
certificate = $cacertFile
crlnumber = $basedir/number
crl = $basedir/
crl_extensions = crl_ext
default_crl_days = 30
default_md = sha256
name_opt = ca_default
cert_opt = ca_default
default_days = 375
preserve = no
policy = policy_strict
[ policy_strict ]
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
[ usr_cert ]
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection, serverAuth
[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha256
x509_extensions = v3_ca
[ req_distinguished_name ]
0.organizationName = Organization Name
organizationalUnitName = Organizational Unit Name
commonName = Common Name
emailAddress = Email Address
EOF
# create the file with the serial numbers
echo 01 > $serialFile
# create an empty DB file
touch $dbFile
# generate ca private key
openssl ecparam -name prime256v1 -out $curveParamFile
openssl ecparam -in $curveParamFile -genkey -noout -out $cakeyFile
# generate ca cert
openssl req -config $confFile -key $cakeyFile -new -x509 -days 7300 -sha256 -extensions v3_ca -out $cacertFile -subj "/O=$orgName/OU=$orgName/CN=CA"
# handle each of the entities individually
for entity in $entities; do
echo "Generating material for entity $entity"
entityDir=$basedir/$entity
mkdir $entityDir
cd $entityDir
adDir=$entityDir/admincerts
caDir=$entityDir/cacerts
kyDir=$entityDir/keystore
ceDir=$entityDir/signcerts
mkdir $adDir $caDir $kyDir $ceDir
# copy the ca cert
cp $cacertFile $caDir
# generate the signing key for this entity
keyFile=$kyDir/key-$entity.pem
openssl ecparam -in $curveParamFile -genkey -noout -out $keyFile
pkcs8key=$kyDir/pkcs8.key
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in $keyFile -out $pkcs8key
# generate CSR for the entity
csrFile=$entityDir/csr.pem
openssl req -key $keyFile -new -sha256 -out $csrFile -subj "/O=$orgName/OU=$orgName/OU=$entity/CN=$entity"
# issue a certificate for this entity
certFile=$ceDir/cert-$entity.pem
openssl ca -config $confFile -extensions usr_cert -days 7300 -md sha256 -in $csrFile -out $certFile -batch -notext
# remove the csr
rm $csrFile
cd ..
done
# remove all extraneous files
find . -maxdepth 1 -type f -delete
# add admins
find . -name admincerts | while read admdir
do
find . -name signcerts | while read dname
do
find $dname -type f | while read fn
do
echo cp $fn $admdir
cp $fn $admdir
done
done
done
```
nnao (Fri, 25 Aug 2017 17:52:52 GMT):
Has joined the channel.
hamptonsmith (Mon, 28 Aug 2017 17:09:38 GMT):
Has joined the channel.
wy (Tue, 29 Aug 2017 09:10:26 GMT):
hi guys
for the certificate field in my user file:
```
{"name":"admin","mspid":"Org1MSP","roles":null,"affiliation":"","enrollmentSecret":"","enrollment":{"signingIdentity":"096d49bb3f64f82c3e35cef6348387891fb4dc29ef5f26fb6c4167045d7ba2bf","identity":{"certificate":"-----BEGIN CERTIFICATE-----\nMIICFjCCAbygAwIBAgIQWiKB6xSGpmb8WE+3YyFRvTAKBggqhkjOPQQDAjBxMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEYMBYGA1UEChMPbWFzLmV4YW1wbGUuY29tMRswGQYDVQQDExJjYS5t\nYXMuZXhhbXBsZS5jb20wHhcNMTcwODIxMTA0ODU2WhcNMjcwODE5MTA0ODU2WjBa\nMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2Fu\nIEZyYW5jaXNjbzEeMBwGA1UEAwwVQWRtaW5AbWFzLmV4YW1wbGUuY29tMFkwEwYH\nKoZIzj0CAQYIKoZIzj0DAQcDQgAEI5AyduroislS4auoM25AOzG5m+GXPdppGi7j\n3h6/lpK50gnypUyOBPTML9fBjiBu2s4Auura5vYe+m/w8a/N9aNNMEswDgYDVR0P\nAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwKwYDVR0jBCQwIoAg5WteuR6tLEW/fwVa\nFk0kL7q2Wde4t30XrspL1HemIHEwCgYIKoZIzj0EAwIDSAAwRQIhAILKNhvzgCX6\nj6YWXOvShhlfwzKbCaFznjI+e41qHZvrAiBE/SqrXe8W7mI8Udgp9LoZVnhA4Mhj\nyddnRgYDwIzJEQ==\n-----END CERTIFICATE-----\n"}}}
```
what certificate is this actually referring to?
Vadim (Tue, 29 Aug 2017 09:18:32 GMT):
@wy it's the identity certificate of the admin user, it is used to sign proposals and transactions when you send them to peers. Peers will verify that this certificate belongs to one of the known MSPs. Peer chaincode can retrieve this certificate with stub.GetCreator() and e.g. perform an access control.
Vadim (Tue, 29 Aug 2017 09:18:32 GMT):
@wy it's the identity certificate of the admin user (in your case), it is used to sign proposals and transactions when you send them to peers. Peers will verify that this certificate belongs to one of the known MSPs. Peer chaincode can retrieve this certificate with stub.GetCreator() and e.g. perform an access control.
yacovm (Tue, 29 Aug 2017 09:33:42 GMT):
@wy the x509 certificate, in PEM encoding
anishman (Wed, 30 Aug 2017 14:34:26 GMT):
Has joined the channel.
greg.haskins (Wed, 30 Aug 2017 20:13:39 GMT):
Has left the channel.
DarshanBc (Thu, 31 Aug 2017 03:38:45 GMT):
Has joined the channel.
DarshanBc (Thu, 31 Aug 2017 03:39:02 GMT):
Hi After generating crypto artifacts again I am trying to run balance transfer its giving this error
```
using the store: {"opts":{"path":"/tmp/fabric-client-kvs_peerOrg2"}}
[2017-08-30 16:10:04.235] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore.js - constructor
[2017-08-30 16:10:04.236] [DEBUG] Helper - [utils.CryptoKeyStore]: _getKeyStore returning ks
[2017-08-30 16:10:04.236] [DEBUG] Helper - [crypto_ecdsa_aes]: generateKey, store.setValue
[2017-08-30 16:10:04.237] [DEBUG] Helper - [ecdsa/key.js]: ECDSA curve param X: 51fd4a6a4b13a238e62ed66ee9a9b515bde84453f6cc863b3fb9d8ef5ad661bb
[2017-08-30 16:10:04.237] [DEBUG] Helper - [ecdsa/key.js]: ECDSA curve param Y: 61520973daaf7d9dd54ad5606c125b735041c64363e66d4f0a1ce9d0badd89c5
[2017-08-30 16:10:04.242] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore -- setValue
[2017-08-30 16:10:04.312] [ERROR] Helper - Error: Calling enrollment endpoint failed with error [Error: write EPROTO 140004699469632:error:1411713E:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc cert not for signing:../deps/openssl/openssl/ssl/ssl_lib.c:2512:
140004699469632:error:14082130:SSL routines:ssl3_check_cert_and_algorithm:bad ecc cert:../deps/openssl/openssl/ssl/s3_clnt.c:3544:
]
at ClientRequest.
Vadim (Thu, 31 Aug 2017 06:36:32 GMT):
@DarshanBc Which certificate are you using? Because the error says "certificate is not for signing", so looks like you are trying to use the wrong certificate.
habpygo (Thu, 31 Aug 2017 06:36:40 GMT):
Has left the channel.
DarshanBc (Thu, 31 Aug 2017 06:46:28 GMT):
@Vadim I dont know which is being used what I did is I deleted crypto-config and /tmp/fabric-client-kvs_peerOrg2 directory and ran this command `cryptogen generate --config=./cryptogen.yaml` after that I a trying to run node app of balance transfer module
DarshanBc (Thu, 31 Aug 2017 06:46:28 GMT):
@Vadim I dont know which is being used what I did is I deleted crypto-config and /tmp/fabric-client-kvs_peerOrg2 directory and ran this command `cryptogen generate --config=./cryptogen.yaml` after that I am trying to run node app of balance transfer module
eetti (Fri, 01 Sep 2017 11:27:07 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=hN96K7JjRGcDKBH82) @DarshanBc I was getting the same error this morning. i haven't found a resolution yet. My guess is that the tls certs is not created properly. So how do we create tls certs for Fabric CA server.
DarshanBc (Fri, 01 Sep 2017 11:52:10 GMT):
@etti I ceated using cryptogen tool
rhudson (Fri, 01 Sep 2017 13:45:57 GMT):
Hi everyone, I am trying to set up a Fabric demo with multiple organisations. In my setup each organisation has its own root CA both for signing blockchain messages and for TLS and I have come up against the problem of specifying multiple TLS root CAs to peers. Unlike at the corresponding position in orderer.yaml, there only seems to be the possibility to specify a single value under CORE_PEER_TLS_ROOTCERT_FILE in core.yaml. So how do I start a peer with multiple TLS root CAs? I am very new to hyperledger, so apologies in advance if I have misunderstood what is going on. Could it also be that the certificates are actually loaded directly from the MSP path and that I have somehow messed up with the file paths?
yacovm (Fri, 01 Sep 2017 13:48:51 GMT):
Why would you want a peer with multiple TLS root CAs @rhudson ? Does your org have 2 TLS root CAs?
yacovm (Fri, 01 Sep 2017 13:49:21 GMT):
the TLS_ROOTCERT_FILE applies only to peers in your org
yacovm (Fri, 01 Sep 2017 13:49:39 GMT):
not of other orgs- these are updated at runtime when they join channels that have other orgs
rhudson (Fri, 01 Sep 2017 13:57:00 GMT):
@yacovm, thankyou very much for the rapid response! I have now realised that I had misunderstood how the gossip bootstrapping worked (I have just read the relevant comment in core.yaml) and had a peer in one organisation trying to bootstrap to a peer in another organisation. I got an error about TLS root CAs which is why I thought that was my problem.
yacovm (Fri, 01 Sep 2017 13:57:23 GMT):
hmm ok
DarshanBc (Fri, 01 Sep 2017 13:57:38 GMT):
@eetti I Think we need to change ` - FABRIC_CA_SERVER_TLS_KEYFILE=/etc/hyperledger/fabric-ca-server-config/0e729224e8b3f31784c8a93c5b8ef6f4c1c91d9e6e577c45c33163609fe40011_sk` in docker-compose.yaml its hard coded so i we change ....._sk to currently generated one it may work I figured but did't try please try and let me know if it works
yacovm (Fri, 01 Sep 2017 13:57:49 GMT):
I don't understand what you're trying to say, but I hope I helped you
rhudson (Fri, 01 Sep 2017 13:58:53 GMT):
@yacovm, definitely, you have solved my problem, we can leave it at that unless it would be helpful to anyone else for me to elaborate.
leixianting (Mon, 04 Sep 2017 05:14:49 GMT):
Has joined the channel.
wy (Mon, 04 Sep 2017 05:48:08 GMT):
hi guys
wy (Mon, 04 Sep 2017 05:48:27 GMT):
having trouble after enabling TLS
wy (Mon, 04 Sep 2017 05:48:36 GMT):
```2017-09-04 05:45:27.818 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2017-09-04 05:45:27.818 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2017-09-04 05:45:27.821 UTC [channelCmd] InitCmdFactory -> INFO 003 Endorser and orderer connections initialized
2017-09-04 05:45:27.821 UTC [msp] GetLocalMSP -> DEBU 004 Returning existing local MSP
2017-09-04 05:45:27.821 UTC [msp] GetDefaultSigningIdentity -> DEBU 005 Obtaining default signing identity
2017-09-04 05:45:27.821 UTC [msp] GetLocalMSP -> DEBU 006 Returning existing local MSP
2017-09-04 05:45:27.821 UTC [msp] GetDefaultSigningIdentity -> DEBU 007 Obtaining default signing identity
2017-09-04 05:45:27.822 UTC [msp/identity] Sign -> DEBU 008 Sign: plaintext: 0A8C060A076D6173724D53501280062D...0A0E52544753436F6E736F727469756D
2017-09-04 05:45:27.822 UTC [msp/identity] Sign -> DEBU 009 Sign: digest: 804E70AA428629CF1306E9C00C4FAF7C659ACFF9646E2462D33DC19CA420B383
2017-09-04 05:45:27.822 UTC [msp] GetLocalMSP -> DEBU 00a Returning existing local MSP
2017-09-04 05:45:27.822 UTC [msp] GetDefaultSigningIdentity -> DEBU 00b Obtaining default signing identity
2017-09-04 05:45:27.822 UTC [msp] GetLocalMSP -> DEBU 00c Returning existing local MSP
2017-09-04 05:45:27.822 UTC [msp] GetDefaultSigningIdentity -> DEBU 00d Obtaining default signing identity
2017-09-04 05:45:27.822 UTC [msp/identity] Sign -> DEBU 00e Sign: plaintext: 0AC8060A1A08021A0608F7D0B3CD0522...B03E634022FFC1E539F103E02B3FB391
2017-09-04 05:45:27.822 UTC [msp/identity] Sign -> DEBU 00f Sign: digest: E9B9BB04A222BCF41CA5A9E4AD7A9C1746DC9FF8B30995B734F4BCD72CCB171A
2017-09-04 05:45:27.823 UTC [grpc] Printf -> DEBU 010 transport: http2Client.notifyError got notified that the client transport was broken unexpected EOF.
2017-09-04 05:45:27.826 UTC [grpc] Printf -> DEBU 011 transport: http2Client.notifyError got notified that the client transport was broken read tcp 10.0.0.7:55650->10.0.0.12:7050: read: connection reset by peer.
Error: rpc error: code = Internal desc = transport is closing
Usage:
peer channel create [flags]```
wy (Mon, 04 Sep 2017 05:49:09 GMT):
got this error when trying to create channels, anyone know whats wrong? am i missing something?
yacovm (Mon, 04 Sep 2017 06:27:00 GMT):
Probably didn't define certificates
wy (Mon, 04 Sep 2017 09:07:50 GMT):
i got that fixed and now i see this
```
peer chaincode instantiate -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mascschannel -n bilateralchannel_cc -v 1.0 -c {"Args":["init"]} -P AND('masMSP.member','csMSP.member')
2017-09-04 08:20:57.269 UTC [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2017-09-04 08:20:57.269 UTC [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2017-09-04 08:20:57.275 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2017-09-04 08:20:57.276 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2017-09-04 08:20:57.277 UTC [msp/identity] Sign -> DEBU 005 Sign: plaintext: 0A98070A6A08031A0C08E999B4CD0510...734D53500A04657363630A0476736363
2017-09-04 08:20:57.277 UTC [msp/identity] Sign -> DEBU 006 Sign: digest: 96B6DE3E6E4C0BCDAEF32F63DBBC577024EF8D3A3977E571C1E4B5B9E137EE78
Error: Error endorsing chaincode: rpc error: code = Unknown desc = Timeout expired while starting chaincode bilateralchannel_cc:1.0(networkid :D ev,peerid :P eer0.masr.example.com,tx:76e1bca42bd03e0f42552cef43cd2bdb04e562c2ed9b57ac278f115414ca3936)
```
it just got stuck there for quite some time before getting this timeout error
yacovm (Mon, 04 Sep 2017 09:15:04 GMT):
do `docker logs
yacovm (Mon, 04 Sep 2017 09:15:08 GMT):
when it starts up
yacovm (Mon, 04 Sep 2017 09:15:11 GMT):
and tell me what you see
wy (Mon, 04 Sep 2017 09:31:45 GMT):
@yacovm which container should i check?
yacovm (Mon, 04 Sep 2017 09:31:55 GMT):
the chaincode one
wy (Mon, 04 Sep 2017 09:32:15 GMT):
i used cli container to try to instantiate on another one
wy (Mon, 04 Sep 2017 09:42:43 GMT):
```
2017-09-04 09:36:31.744 UTC [chaincode] filterError -> DEBU 150b Ignoring NoTransitionError: no transition
2017-09-04 09:36:31.744 UTC [chaincode] processStream -> DEBU 150c [af9bd799]sending state message RESPONSE
2017-09-04 09:36:31.744 UTC [shim] func1 -> DEBU 150d [af9bd799]Received message RESPONSE from shim
2017-09-04 09:36:31.744 UTC [shim] handleMessage -> DEBU 150e [af9bd799]Handling ChaincodeMessage of type: RESPONSE(state:ready)
2017-09-04 09:36:31.745 UTC [shim] sendChannel -> DEBU 150f [af9bd799]before send
2017-09-04 09:36:31.745 UTC [shim] sendChannel -> DEBU 1510 [af9bd799]after send
2017-09-04 09:36:31.745 UTC [shim] afterResponse -> DEBU 1511 [af9bd799]Received RESPONSE, communicated (state:ready)
2017-09-04 09:36:31.745 UTC [shim] handlePutState -> DEBU 1512 [af9bd799]Received RESPONSE. Successfully updated state
2017-09-04 09:36:31.745 UTC [shim] func1 -> DEBU 1513 [af9bd799]Transaction completed. Sending COMPLETED
2017-09-04 09:36:31.745 UTC [shim] func1 -> DEBU 1514 [af9bd799]Move state message COMPLETED
2017-09-04 09:36:31.745 UTC [shim] handleMessage -> DEBU 1515 [af9bd799]Handling ChaincodeMessage of type: COMPLETED(state:ready)
2017-09-04 09:36:31.745 UTC [shim] func1 -> DEBU 1516 [af9bd799]send state message COMPLETED
2017-09-04 09:36:31.745 UTC [chaincode] processStream -> DEBU 1517 [af9bd799]Received message COMPLETED from shim
2017-09-04 09:36:31.745 UTC [chaincode] HandleMessage -> DEBU 1518 [af9bd799]Fabric side Handling ChaincodeMessage of type: COMPLETED in state ready
2017-09-04 09:36:31.745 UTC [chaincode] HandleMessage -> DEBU 1519 [af9bd799c265abca503ab69bbdeae2dd0d66335f25689e40cf6ba425b2ed2f01]HandleMessage- COMPLETED. Notify
2017-09-04 09:36:31.745 UTC [chaincode] notify -> DEBU 151a notifying Txid:af9bd799c265abca503ab69bbdeae2dd0d66335f25689e40cf6ba425b2ed2f01
2017-09-04 09:36:31.745 UTC [chaincode] Execute -> DEBU 151b Exit
2017-09-04 09:36:31.745 UTC [ccprovider] NewCCContext -> DEBU 151c NewCCCC (chain=mascschannel,chaincode=bilateralchannel_cc,version=1.0,txid=af9bd799c265abca503ab69bbdeae2dd0d66335f25689e40cf6ba425b2ed2f01,syscc=false,proposal=0xc421af2dc0,canname=bilateralchannel_cc:1.0
2017-09-04 09:36:31.745 UTC [chaincode] Launch -> DEBU 151d launchAndWaitForRegister fetched 7790 bytes from file system
2017-09-04 09:36:31.745 UTC [chaincode] getArgsAndEnv -> DEBU 151e Executable is chaincode
2017-09-04 09:36:31.745 UTC [chaincode] getArgsAndEnv -> DEBU 151f Args [chaincode -peer.address=peer0.masr.example.com:7051]
2017-09-04 09:36:31.745 UTC [chaincode] launchAndWaitForRegister -> DEBU 1520 start container: bilateralchannel_cc:1.0(networkid:dev,peerid:peer0.masr.example.com)
2017-09-04 09:36:31.745 UTC [chaincode] launchAndWaitForRegister -> DEBU 1521 start container with args: chaincode -peer.address=peer0.masr.example.com:7051
2017-09-04 09:36:31.745 UTC [chaincode] launchAndWaitForRegister -> DEBU 1522 start container with env:
CORE_CHAINCODE_ID_NAME=bilateralchannel_cc:1.0
CORE_PEER_TLS_ENABLED=true
CORE_CHAINCODE_LOGGING_LEVEL=DEBUG
CORE_CHAINCODE_LOGGING_SHIM=warning
CORE_CHAINCODE_LOGGING_FORMAT=%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}
2017-09-04 09:36:31.745 UTC [container] lockContainer -> DEBU 1523 waiting for container(dev-peer0.masr.example.com-bilateralchannel_cc-1.0) lock
2017-09-04 09:36:31.746 UTC [container] lockContainer -> DEBU 1524 got container (dev-peer0.masr.example.com-bilateralchannel_cc-1.0) lock
2017-09-04 09:36:31.746 UTC [dockercontroller] Start -> DEBU 1525 Cleanup container dev-peer0.masr.example.com-bilateralchannel_cc-1.0
2017-09-04 09:36:31.747 UTC [dockercontroller] stopInternal -> DEBU 1526 Stop container dev-peer0.masr.example.com-bilateralchannel_cc-1.0(No such container: dev-peer0.masr.example.com-bilateralchannel_cc-1.0)
2017-09-04 09:36:31.747 UTC [dockercontroller] stopInternal -> DEBU 1527 Kill container dev-peer0.masr.example.com-bilateralchannel_cc-1.0 (No such container: dev-peer0.masr.example.com-bilateralchannel_cc-1.0)
2017-09-04 09:36:31.748 UTC [dockercontroller] stopInternal -> DEBU 1528 Remove container dev-peer0.masr.example.com-bilateralchannel_cc-1.0 (No such container: dev-peer0.masr.example.com-bilateralchannel_cc-1.0)
2017-09-04 09:36:31.748 UTC [dockercontroller] Start -> DEBU 1529 Start container dev-peer0.masr.example.com-bilateralchannel_cc-1.0
2017-09-04 09:36:31.748 UTC [dockercontroller] createContainer -> DEBU 152a Create container: dev-peer0.masr.example.com-bilateralchannel_cc-1.0
2017-09-04 09:36:31.934 UTC [dockercontroller] createContainer -> DEBU 152b Created container: dev-peer0.masr.example.com-bilateralchannel_cc-1.0
2017-09-04 09:36:33.392 UTC [dockercontroller] Start -> DEBU 152c Started container dev-peer0.masr.example.com-bilateralchannel_cc-1.0
2017-09-04 09:36:33.392 UTC [container] unlockContainer -> DEBU 152d container lock deleted(dev-peer0.masr.example.com-bilateralchannel_cc-1.0)```
wy (Mon, 04 Sep 2017 09:43:00 GMT):
theres too much to paste so heres all i can paste
wy (Mon, 04 Sep 2017 09:43:09 GMT):
@yacovm
wy (Mon, 04 Sep 2017 09:44:40 GMT):
```2017-09-04 09:36:31.748 UTC [dockercontroller] Start -> DEBU 1529 Start container dev-peer0.masr.example.com-bilateralchannel_cc-1.0
2017-09-04 09:36:31.748 UTC [dockercontroller] createContainer -> DEBU 152a Create container: dev-peer0.masr.example.com-bilateralchannel_cc-1.0
2017-09-04 09:36:31.934 UTC [dockercontroller] createContainer -> DEBU 152b Created container: dev-peer0.masr.example.com-bilateralchannel_cc-1.0
2017-09-04 09:36:33.392 UTC [dockercontroller] Start -> DEBU 152c Started container dev-peer0.masr.example.com-bilateralchannel_cc-1.0
2017-09-04 09:36:33.392 UTC [container] unlockContainer -> DEBU 152d container lock deleted(dev-peer0.masr.example.com-bilateralchannel_cc-1.0)
2017-09-04 09:41:33.393 UTC [chaincode] launchAndWaitForRegister -> DEBU 152e stopping due to error while launching Timeout expired while starting chaincode bilateralchannel_cc:1.0(networkid:dev,peerid:peer0.masr.example.com,tx:af9bd799c265abca503ab69bbdeae2dd0d66335f25689e40cf6ba425b2ed2f01)
2017-09-04 09:41:33.393 UTC [container] lockContainer -> DEBU 152f waiting for container(dev-peer0.masr.example.com-bilateralchannel_cc-1.0) lock
2017-09-04 09:41:33.393 UTC [container] lockContainer -> DEBU 1530 got container (dev-peer0.masr.example.com-bilateralchannel_cc-1.0) lock
2017-09-04 09:41:33.394 UTC [dockercontroller] stopInternal -> DEBU 1531 Stop container dev-peer0.masr.example.com-bilateralchannel_cc-1.0(Container not running: dev-peer0.masr.example.com-bilateralchannel_cc-1.0)
2017-09-04 09:41:33.395 UTC [dockercontroller] stopInternal -> DEBU 1532 Kill container dev-peer0.masr.example.com-bilateralchannel_cc-1.0 (API error (500): {"message":"Cannot kill container dev-peer0.masr.example.com-bilateralchannel_cc-1.0: Container 14ed6815ce4c48624d5a179aa0168634cd5e4e63398218208107c5a6f5804235 is not running"}
)
2017-09-04 09:41:33.452 UTC [dockercontroller] stopInternal -> DEBU 1533 Removed container dev-peer0.masr.example.com-bilateralchannel_cc-1.0
2017-09-04 09:41:33.452 UTC [container] unlockContainer -> DEBU 1534 container lock deleted(dev-peer0.masr.example.com-bilateralchannel_cc-1.0)
2017-09-04 09:41:33.452 UTC [chaincode] Launch -> ERRO 1535 launchAndWaitForRegister failed Timeout expired while starting chaincode bilateralchannel_cc:1.0(networkid:dev,peerid:peer0.masr.example.com,tx:af9bd799c265abca503ab69bbdeae2dd0d66335f25689e40cf6ba425b2ed2f01)
2017-09-04 09:41:33.453 UTC [endorser] callChaincode -> DEBU 1536 Exit
2017-09-04 09:41:33.453 UTC [endorser] simulateProposal -> ERRO 1537 failed to invoke chaincode name:"lscc" on transaction af9bd799c265abca503ab69bbdeae2dd0d66335f25689e40cf6ba425b2ed2f01, error: Timeout expired while starting chaincode bilateralchannel_cc:1.0(networkid:dev,peerid:peer0.masr.example.com,tx:af9bd799c265abca503ab69bbdeae2dd0d66335f25689e40cf6ba425b2ed2f01)
2017-09-04 09:41:33.453 UTC [endorser] simulateProposal -> DEBU 1538 Exit
2017-09-04 09:41:33.453 UTC [lockbasedtxmgr] Done -> DEBU 1539 Done with transaction simulation / query execution [767f6454-7f80-4f1f-aa45-06ac7c202875]
2017-09-04 09:41:33.453 UTC [endorser] ProcessProposal -> DEBU 153a Exit```
wy (Mon, 04 Sep 2017 09:44:51 GMT):
it just timed out and here are the new lines
yacovm (Mon, 04 Sep 2017 09:45:22 GMT):
... do `docker ps`
yacovm (Mon, 04 Sep 2017 09:45:28 GMT):
what command did you type
yacovm (Mon, 04 Sep 2017 09:45:33 GMT):
to present this log?
wy (Mon, 04 Sep 2017 09:46:12 GMT):
`docker logs ubin_peer0-masr.1.fttb6thbrapvjr28ll668zpdy`
yacovm (Mon, 04 Sep 2017 09:46:51 GMT):
is that a peer or a container?
yacovm (Mon, 04 Sep 2017 09:46:51 GMT):
is that a peer or a chaincode container?
yacovm (Mon, 04 Sep 2017 09:46:57 GMT):
you need to present the log of the *container*
yacovm (Mon, 04 Sep 2017 09:46:57 GMT):
you need to present the log of the *chaincodecontainer*
wy (Mon, 04 Sep 2017 09:47:39 GMT):
the chaincode didnt get instantiated so there is no chaincode container
yacovm (Mon, 04 Sep 2017 09:47:54 GMT):
it starts
yacovm (Mon, 04 Sep 2017 09:48:01 GMT):
and the crashes and deleted
yacovm (Mon, 04 Sep 2017 09:48:08 GMT):
if you're quick, you can catch it on time :)
wy (Mon, 04 Sep 2017 09:48:27 GMT):
okay let me try
wy (Mon, 04 Sep 2017 09:51:22 GMT):
i dont see it get started @yacovm
yacovm (Mon, 04 Sep 2017 09:51:45 GMT):
hm so I don't know - @muralisr any ideas?
muralisr (Mon, 04 Sep 2017 13:12:17 GMT):
@wy @yacovm if you add CORE_VM_DOCKER_ATTACHSTDOUT=true CORE_CHAINCODE_LOGGING_LEVEL=debug to the peer all logs from chaincode will be directed to peers log.... assuming you put some logs in the chaincode, this would help debug...
muralisr (Mon, 04 Sep 2017 13:12:42 GMT):
the other suggestion would be to try debug in devmode
wy (Tue, 05 Sep 2017 01:11:00 GMT):
@muralisr okay cool, let me try that out later
DarshanBc (Tue, 05 Sep 2017 08:31:02 GMT):
I am running CA-server as a container I need to edit Fabric CA client’s configuration file how do I do It
rwadhwa (Tue, 05 Sep 2017 12:38:03 GMT):
Has joined the channel.
smithbk (Tue, 05 Sep 2017 12:46:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=sAsYZCbq48PacPfoN) @DarshanBc I responded in the #fabric-ca channel
zemtsov (Tue, 05 Sep 2017 12:46:41 GMT):
Has left the channel.
DarshanBc (Tue, 05 Sep 2017 12:48:33 GMT):
Thank You @smithbk You have been a Saviour for us
smithbk (Tue, 05 Sep 2017 13:02:23 GMT):
glad to help
eetti (Tue, 05 Sep 2017 19:51:27 GMT):
I have this error when trying to install/instantiate chaincode,
```Error starting Simple chaincode: Error trying to connect to local peer: x509: cannot validate certificate for 172.17.0.8 because it doesn't contain any IP SANs
```
I have tls enabled
jyellick (Tue, 05 Sep 2017 20:12:12 GMT):
@eetti TLS verifies the certificate by hostname, and you are connecting with an IP address instead of a hostname. Try using the hostname as defined in the TLS cert.
yacovm (Tue, 05 Sep 2017 20:23:36 GMT):
Or alternatively you can generate the TLS certificates with ip addresses.
If you're using cryptogen - the master branch version already supports that
yacovm (Tue, 05 Sep 2017 20:23:45 GMT):
but doing what Jason proposed is easier
eetti (Tue, 05 Sep 2017 20:45:43 GMT):
@jyellick @yacovm Thanks, I will try that.
FollowingGhosts (Wed, 06 Sep 2017 10:51:56 GMT):
Has joined the channel.
eetti (Wed, 06 Sep 2017 16:57:39 GMT):
@jyellick @yacovm I had to set the environment variable for the peer `CORE_PEER_ADDRESSAUTODETECT` to false. I also had to set the hostname for the docker container and I added the address and host ip to the hosts file. Then everything worked. I don't know if I needed to do all this extra config but the chaincode container has now been created with no errors.
AnthonyBisong (Wed, 06 Sep 2017 20:11:22 GMT):
Has joined the channel.
boliang (Thu, 07 Sep 2017 08:47:09 GMT):
Has joined the channel.
ulysses (Thu, 07 Sep 2017 11:38:27 GMT):
Has joined the channel.
tom.appleyard (Thu, 07 Sep 2017 16:41:19 GMT):
Is anyone here an expert on how certificates are issued?
tom.appleyard (Thu, 07 Sep 2017 16:41:34 GMT):
Specifically with regards to why a recently enrolled certificate might be rejected
jimthematrix (Thu, 07 Sep 2017 20:42:51 GMT):
@mastersingh24 can you confirm the merit of this JIRA (resulted from a discussion @nickgaski and I had today): https://jira.hyperledger.org/browse/FAB-6078, I'm pretty sure based on reviewing the code it's accurate, but want to make sure you don't have something cooking already: https://jira.hyperledger.org/browse/FAB-6078
jimthematrix (Thu, 07 Sep 2017 20:42:51 GMT):
@mastersingh24 can you confirm the merit of this JIRA (resulted from a discussion @nickgaski and I had today): https://jira.hyperledger.org/browse/FAB-6078, I'm pretty sure based on reviewing the code it's accurate, but want to make sure you don't have something cooking already
jimthematrix (Thu, 07 Sep 2017 20:42:51 GMT):
@mastersingh24 can you confirm the merit of this JIRA (resulted from a discussion @nickgaski and I had today): https://jira.hyperledger.org/browse/FAB-6078, I'm pretty sure based on reviewing the code it's accurate, but want to double check and make sure you don't have something cooking already
kostas (Fri, 08 Sep 2017 20:17:50 GMT):
Has left the channel.
jyellick (Sun, 10 Sep 2017 02:41:54 GMT):
@elli-androulaki @adc @aso I was looking at the identity mixer MSP implementation in https://gerrit.hyperledger.org/r/#/c/12439/ in particular, the `SatisfiesPrincipal` implementation. My understanding had been that for this to work in identity mixer would also require the signature (and why I abandoned the CR series to modify the policy framework to take only identities)
jyellick (Sun, 10 Sep 2017 02:41:54 GMT):
@elli-androulaki @adc @aso I was looking at the identity mixer MSP implementation in https://gerrit.hyperledger.org/r/#/c/12439/ in particular, the `SatisfiesPrincipal` implementation. My understanding had been that for this to work in identity mixer, the interface definition for `SatisfiesPrincipal` would be modified to require the signature of the identity as well. I had abandoned the CR series to modify the policy framework to take only identities based on this understanding, and was wondering whether it was worth trying to revive.
jyellick (Sun, 10 Sep 2017 02:41:54 GMT):
@elli-androulaki @adc @aso I was looking at the identity mixer MSP implementation in https://gerrit.hyperledger.org/r/#/c/12439/ in particular, the `SatisfiesPrincipal` implementation. My understanding had been that for this to work in identity mixer, the interface definition for `SatisfiesPrincipal` would be modified to require the signature of the identity as well. I had abandoned a CR series to modify the policy framework to take only identities based on this understanding, and was wondering whether it was worth trying to revive.
jyellick (Sun, 10 Sep 2017 02:41:54 GMT):
@elli-androulaki @adc @aso I was looking at the identity mixer MSP implementation in https://gerrit.hyperledger.org/r/#/c/12439/ in particular, the `SatisfiesPrincipal` implementation. My understanding had been that for this to work in identity mixer, the interface definition for `SatisfiesPrincipal` would be modified to require the signature of the identity as well. I had abandoned a CR series to modify the policy framework to take only identities based on this understanding, and was wondering whether it was worth trying to revive, or whether this interface definition is still slated to change.
elli-androulaki (Sun, 10 Sep 2017 09:49:17 GMT):
@jyellick, idemix msp as of now has different semantics for identity validity function indeed. This is to be changed and https://jira.hyperledger.org/browse/FAB-6044 covers this aspect. We essentially found a way to allow idemix identity validation to be properly assessed via identity structure that would allow us to also run the satisifesPrincipal with the given interface.
Regarding your old CRs, we need to think if we wish to remove the signatures entirely from policy evaluation function, or convert signatures to "Opts" that would be optionally passing in signatures, timestamps, and/or other parameters.
elli-androulaki (Sun, 10 Sep 2017 09:50:08 GMT):
This would allow us to do policy evaluation and message authentiaction at the same time.
jyellick (Sun, 10 Sep 2017 20:28:36 GMT):
> We essentially found a way to allow idemix identity validation to be properly assessed via identity structure that would allow us to also run the satisifesPrincipal with the given interface.
So the idea here is that `Validate` and `SatisfiesPrincipal` are redundant checks? (I believe they are in the X.509 case as well?). I know we already have a cache for identity validation, it seems like maybe it is not such a big deal to perform things 2x if the second time will simply hit the cache?
> Regarding your old CRs, we need to think if we wish to remove the signatures entirely from policy evaluation function,
To me, it seems like a good separation of concerns. It simplifies the code by removing the complexity of three different types of failure "bad identity", "bad signature", and "wwrong identity", down to simply checking for "wrong identity".
> or convert signatures to "Opts" that would be optionally passing in signatures, timestamps, and/or other parameters.
I'm quite wary of this approach. As soon as it's not immediately clear how to take a signature set, and validate it against a policy (ie, do we set opt A? how about opt B? etc.) I think we are likely to end up getting it wrong and introducing non-determinism into the validation path.
> This would allow us to do policy evaluation and message authentiaction at the same time.
Is this a goal purely for efficiency? If so, I would again point towards caching techniques as perhaps a better solution so that the code is conceptually simpler.
elli-androulaki (Mon, 11 Sep 2017 08:25:30 GMT):
>So the idea here is that `Validate` and `SatisfiesPrincipal` are redundant checks?
Not sure what you mean by "redundant checks".
- Validate checks that an identity has been constructed given the rules of the MSP it claims to be a member of.
- SatisfiesPrincipal checks that the identity conforms to some principal, that can be a member, admin, OU-member, (in the near future) client, peer, (in the far future) owner of certain attributes. It extends identity validate to the extend one could merge the two in one call.
> To me, it seems like a good separation of concerns.
Agreed. But, there is a caveat: separation of concerns works only if people know how to combine them to achieve the intended result. And interfaces need to smartly built to disallow people to do at least "easy" mistakes. That's what we are trying to avoid.
> As soon as it's not immediately clear how to take a signature set, and validate it against a policy (ie, do we set opt A? how about opt B? etc.) I think we are likely to end up getting it wrong and introducing non-determinism into the validation path.
I don't think i fully understand this. The validation logic we will be writing, properly using the interfaces. Therefore non-determinism would not be an issue. The interfaces of the MSP though could be used by the chaincodes later in time, and this is where we want to protect them from not doing things right.
rhudson (Mon, 11 Sep 2017 08:56:09 GMT):
Hi everyone, a quick question about the cryptography standards Fabric supports. So far I have only managed to get things working with the two NIST-standard elliptic curves. Attempting to use other elliptic curves leads to an error message that they are not supported. However, the standard NIST curves are widely regarded as suboptimal and might be expected to leave data open to examination by the NSA. Is there any way of using Fabric with other elliptic curves, and, if not, where do I place an appropriate feature request?
mathiasb303 (Mon, 11 Sep 2017 09:09:00 GMT):
Has joined the channel.
atclik 1 (Mon, 11 Sep 2017 09:47:28 GMT):
Has joined the channel.
atclik 1 (Mon, 11 Sep 2017 09:49:05 GMT):
Hello guys,
I am trying to deploy an hyperledger fabric instance through a docker orchestrator that doesn't support dots in the containers-names. (peer0.org1.example.com doesn't works)
I already tryed to change only the name of the containers but it seems that this modification raise some certificates errors.
Here is the question:
Is it possible to avoid setting Domain Names in the crypto-config.yaml when running the cryptogen tool to generate certificates.
(I already try to simply remove the Domain Name in the crypto-config.yaml. The cryptogen tool set the certificate paths and the name as follows: "peers/peer1./..." and "tlsca.-cert.pem")
any advices are welcome 🙂
thanks
elli-androulaki (Mon, 11 Sep 2017 10:08:24 GMT):
@rhudson, Fabric crypto operations are performed by a component called blockchain crypto service provider (BCCSP). The software implementation of BCCSP allows for the two curves that you mentioned, but one could either enhance the existing one to support more/different curves.
elli-androulaki (Mon, 11 Sep 2017 10:11:06 GMT):
For this feature requests we use jira. You can for example create a jira item (as "new feature") here https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=65&view=planning.nodetail, listing fabric-crypto among the affected components.
atclik 1 (Mon, 11 Sep 2017 10:14:24 GMT):
Is there any manual process described to build the cryptography material required for using TLS ? (Without using the of cryptogen tool)
mastersingh24 (Tue, 12 Sep 2017 12:02:33 GMT):
[You can use the SANS element of the template to explicitly specific any name you want ](https://chat.hyperledger.org/channel/fabric-crypto?msg=hbmjCgx7QrYgFETdL) @atclik 1
mastersingh24 (Tue, 12 Sep 2017 12:02:33 GMT):
You can use the SANS element of the template to explicitly set any value(s) you want, but the TLS certificate(s) also add a SAN that is just the hostname - e.g. peer0.
(https://chat.hyperledger.org/channel/fabric-crypto?msg=hbmjCgx7QrYgFETdL) @atclik 1
mastersingh24 (Tue, 12 Sep 2017 12:02:33 GMT):
You can use the SANS element of the template to explicitly set any value(s) you want, but the TLS certificate(s) also add a SAN that is just the hostname - e.g. peer0.
(https://chat.hyperledger.org/channel/fabric-crypto?msg=hbmjCgx7QrYgFETdL) @atclik 1
aleksandar.likic (Tue, 12 Sep 2017 19:53:07 GMT):
Has joined the channel.
biljana_lukovic (Tue, 12 Sep 2017 20:19:11 GMT):
Has joined the channel.
aleksandar.likic (Wed, 13 Sep 2017 15:54:06 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=xHjeLk4dZPXTvtuSN) @ashutosh_kumar It looks like there is only a unit test that runs against a docker image that has only softhsm2. We've been trying to have both the peer and softhsm2 in a single docker container based on statically compiled peer image, and it doesn't work: peer0.org1.example.com | =======================================================================
peer0.org1.example.com | > STARTING PEER DAEMON...
peer0.org1.example.com | =======================================================================
peer0.org1.example.com |
peer0.org1.example.com | fatal error: unexpected signal during runtime execution
peer0.org1.example.com | [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]
peer0.org1.example.com |
peer0.org1.example.com | runtime stack:
peer0.org1.example.com | runtime.throw(0xe16822, 0x2a)
peer0.org1.example.com | /opt/go/src/runtime/panic.go:566 +0x95
peer0.org1.example.com | runtime.sigpanic()
peer0.org1.example.com | /opt/go/src/runtime/sigpanic_unix.go:12 +0x2cc
peer0.org1.example.com |
peer0.org1.example.com | goroutine 1 [syscall, locked to thread]:
peer0.org1.example.com | runtime.cgocall(0xb49dc0, 0xc42017d440, 0xc400000000)
peer0.org1.example.com | /opt/go/src/runtime/cgocall.go:131 +0x110 fp=0xc42017d410 sp=0xc42017d3d0
peer0.org1.example.com | github.com/hyperledger/fabric/vendor/github.com/miekg/pkcs11._Cfunc_New(0x2939be0, 0x0)
peer0.org1.example.com | ??:0 +0x4a fp=0xc42017d440 sp=0xc42017d410
peer0.org1.example.com | github.com/hyperledger/fabric/vendor/github.com/miekg/pkcs11.New(0xc420231290, 0x30, 0x0)
peer0.org1.example.com | /opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/miekg/pkcs11/pkcs11.go:763 +0xc4 fp=0xc42017d480 sp=0xc42017d440
peer0.org1.example.com | github.com/hyperledger/fabric/bccsp/pkcs11.loadLib(0xc420231290, 0x30, 0xc42020d780, 0x8, 0xc42020d770, 0x9, 0xc420295560, 0x0, 0x0, 0x0, ...)
peer0.org1.example.com | /opt/gopath/src/github.com/hyperledger/fabric/bccsp/pkcs11/pkcs11.go:39 +0x13d fp=0xc42017d720 sp=0xc42017d480
peer0.org1.example.com | github.com/hyperledger/fabric/bccsp/pkcs11.New(0x100, 0xc42020d7e8, 0x4, 0x0, 0xc420298fe0, 0x0, 0xc420231290, 0x30, 0xc42020d770, 0x9, ...)
peer0.org1.example.com | /opt/gopath/src/github.com/hyperledger/fabric/bccsp/pkcs11/impl.go:64 +0x259 fp=0xc42017d870 sp=0xc42017d720
peer0.org1.example.com | github.com/hyperledger/fabric/bccsp/factory.(*PKCS11Factory).Get(0x14c2fa8, 0xc42025fb80, 0xc42017d9a8, 0xc42017d998, 0x1, 0x1)
aleksandar.likic (Wed, 13 Sep 2017 16:54:28 GMT):
Perhaps the HSM confusion (in my head at least) is around the fact that BCCSP is a stand-alone package that is only sharing a project space with Fabric. It is not *a part* of fabric, it is *used* by fabric. Yes, BCCSP is tested against softhsm2, but fabric itself has not been tested with it. It seems that there are gaps that need to be closed before one we declare that Fabric supports PKCS11?
aleksandar.likic (Wed, 13 Sep 2017 16:54:28 GMT):
Perhaps the HSM confusion (in my head at least) is around the fact that BCCSP is a stand-alone package that is only sharing a project space with Fabric. It is not *a part* of fabric, it is *used* by fabric. Yes, BCCSP is tested against softhsm2, but fabric itself has not been. It seems that there are gaps that need to be closed before we declare that Fabric supports PKCS11?
aleksandar.likic (Wed, 13 Sep 2017 16:54:28 GMT):
Perhaps the HSM confusion is around the fact that BCCSP is a stand-alone package that is only sharing a project space with Fabric. It is not *a part* of fabric, it is *used* by fabric. Yes, BCCSP is tested against softhsm2, but fabric itself has not been. It seems that there are gaps that need to be closed before we declare that Fabric supports PKCS11?
DarshanBc (Wed, 13 Sep 2017 17:11:50 GMT):
Hi I need to know whether the Creators 2 transactions are same or not only through Transaction IDs without querying transactions any idea how that can be done?
gbolo (Thu, 14 Sep 2017 14:24:08 GMT):
Has joined the channel.
gbolo (Thu, 14 Sep 2017 14:24:35 GMT):
hey folks, please contribute your thoughts to this ticket: https://jira.hyperledger.org/browse/FAB-6161
LeoKotschenreuther (Thu, 14 Sep 2017 18:27:23 GMT):
Has joined the channel.
vdods (Sun, 17 Sep 2017 18:59:44 GMT):
Has left the channel.
atclik 1 (Mon, 18 Sep 2017 10:40:51 GMT):
@mastersingh24
Thanks for your answer.
Everything is working fine now.
mastersingh24 (Mon, 18 Sep 2017 11:26:04 GMT):
@gbolo is basically alluding to the answer here (you cannot use statically compile binaries and PKCS#11 together)
(https://chat.hyperledger.org/channel/fabric-crypto?msg=awG8RcS3Ecm5gNo8z) @aleksandar.likic
simoneromani (Mon, 18 Sep 2017 13:00:08 GMT):
hello, question regarding the signing the certificate of one organization's admin and most importantly with TLS enabled. I see that the CN is ca.organization bla bla.. but is it possible to change it at the moment of certificate generation (using cryptogen) into tlsca.organization bla bla? because when I try to issue an identity, Admin doesn't recognize the tlsca as the correct CA but searches for the ca.
yoyokeen (Tue, 19 Sep 2017 01:24:34 GMT):
Has joined the channel.
smallX (Tue, 19 Sep 2017 09:29:17 GMT):
Has joined the channel.
vdods (Tue, 19 Sep 2017 22:29:15 GMT):
Has joined the channel.
vdods (Tue, 19 Sep 2017 22:32:41 GMT):
Hi all, are ECDSA keys still the only supported key type, or are RSA keys supported yet?
Jacky_Sheng (Wed, 20 Sep 2017 03:20:44 GMT):
Has joined the channel.
aleksandar.likic (Wed, 20 Sep 2017 17:26:28 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=jZ7imRby28C6xzLwe) @mastersingh24 Apparently, one cannot take an official fabric image and use it with PKCS11. Given that Fabric is advertised as having PKCS11 support, what is a recommended approach to configuring fabric with PKCS11 in production?
vdods (Wed, 20 Sep 2017 22:21:51 GMT):
Hi all, I'm trying to get fabric-ca-server up and running using a cert/key pair that I've generated myself via openssl. However, I get the following error:
vdods (Wed, 20 Sep 2017 22:22:02 GMT):
`Error: Validation of certificate and key failed: Invalid certificate and/or key in files '/fabric-ca-server/ca.cert.pem' and '/fabric-ca-server/ca.key.pem': Failed parsing EC private key: asn1: structure error: tags don't match (16 vs {class:0 tag:6 length:8 isCompound:false}) {optional:false explicit:false application:false defaultValue:
vdods (Wed, 20 Sep 2017 22:24:31 GMT):
However, using `openssl verify`, the cert and key match
vdods (Wed, 20 Sep 2017 22:31:13 GMT):
Nevermind -- the problem was that I had a section `-----BEGIN EC PARAMETERS-----` at the beginning of my key. I remember reading somewhere that must begin with somethign like "BEGIN PRIVATE KEY". Deleting this section allows the server to boot.
vdods (Wed, 20 Sep 2017 22:31:59 GMT):
Are all keys in Fabric of type prime256v1? If not, how is the elliptic curve name specified if not by a "BEGIN EC PARAMETERS" section?
qingsongGuo (Thu, 21 Sep 2017 05:00:55 GMT):
Has joined the channel.
aakanshaparmar (Thu, 21 Sep 2017 07:10:05 GMT):
Has joined the channel.
aakanshaparmar (Thu, 21 Sep 2017 07:23:44 GMT):
Hi, is it possible to build more production grade certificates using the cryptogen tool. For example can we configure the duration of certificate validity and other parameters like the location, city etc?
nickyng (Thu, 21 Sep 2017 07:58:48 GMT):
Has joined the channel.
DarshanBc (Thu, 21 Sep 2017 11:55:21 GMT):
if there are 2 Jim in my usecase how would I identify them uniquely?
DarshanBc (Thu, 21 Sep 2017 11:55:21 GMT):
if there are 2 users Jim in my usecase how would I identify them uniquely?
DarshanBc (Thu, 21 Sep 2017 11:55:21 GMT):
if there are 2 users "Jim" in my usecase how would I identify them uniquely?
DarshanBc (Thu, 21 Sep 2017 11:55:43 GMT):
without using separate DB
ashutosh_kumar (Thu, 21 Sep 2017 14:09:03 GMT):
@vdods , you can setup your curve type to be one of these kinds : p224 , p256 , p384 and p521 by setting up the key size in csr-json file of fabric ca server : "key": { "algo": "ecdsa", "size": 256 }.
vdods (Thu, 21 Sep 2017 18:13:13 GMT):
@ashutosh_kumar But once it's set, all keys must be that type?
ashutosh_kumar (Thu, 21 Sep 2017 18:35:13 GMT):
yes. if you want to change curve type , you can change setting.
ashutosh_kumar (Thu, 21 Sep 2017 18:35:38 GMT):
I am just curious, why do you want it to be dynamic.
aleksandar.likic (Fri, 22 Sep 2017 22:09:08 GMT):
Hi @mastersingh24 , I am referring to https://jira.hyperledger.org/browse/FAB-6189 and PKCS11 support in general. Does this @divyank s comment in https://jira.hyperledger.org/browse/FAB-6161 fairly reflects how one should be able to configure Fabric with PKCS11 (obviously without the last line, which is current behaviour)? Thanks.
From https://jira.hyperledger.org/browse/FAB-6161:
Divyank Katira added a comment - 2 hours ago - edited
Just a summary of what we're trying to do in case it isn't clear:
- Pull official fabric peer images from docker hub: https://hub.docker.com/r/hyperledger/fabric-peer/
- Enable BCCSP PKCS11 option
- Mount .so files using docker volumes. These .so files can be HSM libraries or Go plugins.
- Run container
- In both cases (initializing PKCS11 or Go plugins), we see segfaults due to the unsupported -static build
aleksandar.likic (Fri, 22 Sep 2017 22:09:08 GMT):
Hi @mastersingh24 , I am referring to https://jira.hyperledger.org/browse/FAB-6189 and PKCS11 support in general. Does this @divyank s comment in https://jira.hyperledger.org/browse/FAB-6161 fairly reflects how one should be able to configure Fabric with PKCS11 (obviously without the last line, which is current behaviour)? Thanks.
From https://jira.hyperledger.org/browse/FAB-6161:
Divyank Katira added a comment - 2 hours ago - edited
Just a summary of what we're trying to do in case it isn't clear:
-Pull official fabric peer images from docker hub: https://hub.docker.com/r/hyperledger/fabric-peer/
- Enable BCCSP PKCS11 option
- Mount .so files using docker volumes. These .so files can be HSM libraries or Go plugins.
- Run container
- In both cases (initializing PKCS11 or Go plugins), we see segfaults due to the unsupported -static build
aleksandar.likic (Fri, 22 Sep 2017 22:09:08 GMT):
Hi @mastersingh24 , I am referring to https://jira.hyperledger.org/browse/FAB-6189 and PKCS11 support in general. Does this @divyank s comment in https://jira.hyperledger.org/browse/FAB-6161 fairly reflects how one should be able to configure Fabric with PKCS11 (obviously without the last line, which is current behaviour)? Thanks.
From https://jira.hyperledger.org/browse/FAB-6161:
Divyank Katira added a comment - 2 hours ago - edited
Just a summary of what we're trying to do in case it isn't clear:
- Pull official fabric peer images from docker hub: https://hub.docker.com/r/hyperledger/fabric-peer/
- Enable BCCSP PKCS11 option
- Mount .so files using docker volumes. These .so files can be HSM libraries or Go plugins.
- Run container
- In both cases (initializing PKCS11 or Go plugins), we see segfaults due to the unsupported -static build
toriaezunama (Mon, 25 Sep 2017 12:13:13 GMT):
Has joined the channel.
DarshanBc (Mon, 25 Sep 2017 15:17:22 GMT):
Can anyone help me I want to send an asset from A to B, A will encrypt asset details with public key of B and send it to chaincode chaincode retrieves Private key of B decrypts it and add the asset to B's inventory how can I go about this
vpetryk (Mon, 25 Sep 2017 15:51:26 GMT):
Has joined the channel.
jyellick (Mon, 25 Sep 2017 16:02:52 GMT):
@DarshanBc You might want to take a look at https://jira.hyperledger.org/browse/FAB-830 which is adding a library and a number of samples for encrypting chaincode data.
yushan (Tue, 26 Sep 2017 09:16:39 GMT):
Has joined the channel.
AnthonyMiclet (Tue, 26 Sep 2017 16:09:02 GMT):
Has joined the channel.
ujjwalmishra (Tue, 26 Sep 2017 21:07:46 GMT):
Has joined the channel.
tsnyder (Wed, 27 Sep 2017 15:13:57 GMT):
@aleksandar.likic - We use the PKCS11 support with an HSM. One key is to pull your images from https://hub.docker.com/u/ibmblockchain which contain dynamically built images. Or you can build the images yourself.
wy (Fri, 29 Sep 2017 02:43:32 GMT):
Does anyone know how we can make use of the certs defined for the fabric network to verify signatures in my chaincode?
1) Are there any built in chaincode functions which i can use to pull the cert/public keys of a particular org/identity?
2) If so, how can i use them for verification?
mastersingh24 (Fri, 29 Sep 2017 11:41:20 GMT):
@wy - what exactly are you trying to verify in your chaincode?
wy (Fri, 29 Sep 2017 12:11:18 GMT):
im trying to verify a signature generated on the API layer, using the public keys/certs used in the fabric network
wy (Fri, 29 Sep 2017 12:11:24 GMT):
@mastersingh24
mastersingh24 (Fri, 29 Sep 2017 14:59:59 GMT):
What are you actually signing outside of what Fabric clients sign?
mastersingh24 (Fri, 29 Sep 2017 15:00:54 GMT):
If you chose to use the same key that the client uses to sign with, you can get the corresponding public key needed to verify a signature using the GetCreator() function available in chaincode
firas.qutishat (Fri, 29 Sep 2017 17:18:28 GMT):
Has joined the channel.
firas.qutishat (Fri, 29 Sep 2017 17:18:34 GMT):
Hi,
firas.qutishat (Fri, 29 Sep 2017 17:20:30 GMT):
Hi,
Is there plan to extend BCCSP to decrypt using PKC11
qsmen (Sat, 30 Sep 2017 03:54:04 GMT):
HI, From the configtx.yaml, we obtain the orderer genesis block directly and indrectly the channel genesis block. The two blocks contains many access control policies. Is there any other method we can set access control policy? Thank you.
qsmen (Sat, 30 Sep 2017 03:54:41 GMT):
I dont know if this is the right place to ask this question.
C0rWin (Sun, 01 Oct 2017 07:46:54 GMT):
@qsmen, you can use `configtxlator`, please see more details here: https://github.com/hyperledger/fabric/blob/master/examples/configtxupdate/README.md
BernardLin (Sun, 01 Oct 2017 18:29:45 GMT):
Has joined the channel.
asaningmaxchain (Tue, 03 Oct 2017 12:00:35 GMT):
Has joined the channel.
lovesh (Tue, 03 Oct 2017 14:03:55 GMT):
Has joined the channel.
jyellick (Tue, 03 Oct 2017 17:50:52 GMT):
li
AlekNS (Wed, 04 Oct 2017 05:14:28 GMT):
Has joined the channel.
KevinLeyssens (Wed, 04 Oct 2017 10:47:46 GMT):
Has joined the channel.
asaningmaxchain (Wed, 04 Oct 2017 15:45:14 GMT):
@mastersingh24 can you explain the msp?
asaningmaxchain (Wed, 04 Oct 2017 15:45:14 GMT):
@mastersingh24 can you explain the msp and how the fabric use the msp to control the policy
yacovm (Wed, 04 Oct 2017 15:48:39 GMT):
@asaningmaxchain there is a great read here https://hyperledger-fabric.readthedocs.io/en/latest/msp.html
yacovm (Wed, 04 Oct 2017 15:48:45 GMT):
just FYI
asaningmaxchain (Wed, 04 Oct 2017 15:53:03 GMT):
@yacovm thx
asaningmaxchain (Thu, 05 Oct 2017 08:35:43 GMT):
@yacovm @mastersingh24 i got from the doc is that msp is a role to control the privilege who has right to do something,and each org contains a msp,but i don't understand how the `This provides modularity of membership operations, and interoperability across different membership standards and architectures.`
asaningmaxchain (Thu, 05 Oct 2017 08:35:43 GMT):
@yacovm @mastersingh24 i got from the doc is that msp is a role to control the privilege who has right to do something,and each org contains a msp,but i don't understand how the `This provides modularity of membership operations, and interoperability across different membership standards and architectures.` can you provide a example
asaningmaxchain (Thu, 05 Oct 2017 08:35:43 GMT):
@yacovm @mastersingh24 @jyellick i got from the doc is that msp is a role to control the privilege who has right to do something,and each org contains a msp,but i don't understand how the `This provides modularity of membership operations, and interoperability across different membership standards and architectures.` can you provide a example
yacovm (Thu, 05 Oct 2017 09:40:41 GMT):
yes of course
yacovm (Thu, 05 Oct 2017 09:40:55 GMT):
so the MSP type that fabric v1.0 has is based on x509 PKI
yacovm (Thu, 05 Oct 2017 09:41:30 GMT):
but at some point in the future we'll have a new MSP type- an identity mixer MSP that is for clients only (users) and their transactions are un-linkable.
yacovm (Thu, 05 Oct 2017 09:41:30 GMT):
but at some point in the future we'll have a new MSP type- an identity mixer MSP that is for clients only (users) and their transactions are un-linkable. ( @Maria / @manu please correct me if I'm wrong here)
yacovm (Thu, 05 Oct 2017 09:43:00 GMT):
Now, the idemix MSP obfuscates the users behind the transactions, by randomly generating a pseudo identity upon each signature and signing the transaction with a zero knowledge proof scheme, that an idemix MSP inside a peer can verify the signature without knowing who is the user behind it.
yacovm (Thu, 05 Oct 2017 09:44:14 GMT):
So, Fabric code itself doesn't care whether a given identity or a transaction is signed by an x509 certificate or an idemix one - the MSP implementation abstracts out all the security/identity stuff from the fabric code
yacovm (Thu, 05 Oct 2017 09:45:31 GMT):
And if you want to implement your own MSP - lets say, an MSP that rolls a fair dice and determines if a signature is valid or not (bad, bad idea! don't do this!) - then all you need is to implement the MSP interface(s) and ensure all peers and orderers have this code in them, and you're all set.
yacovm (Thu, 05 Oct 2017 09:45:31 GMT):
And if you want to implement your own MSP - lets say, an MSP that flips a coin and determines if a signature is valid or not (bad, bad idea! don't do this!) - then all you need is to implement the MSP interface(s) and ensure all peers and orderers have this code in them, and you're all set.
yacovm (Thu, 05 Oct 2017 09:45:35 GMT):
This is for the modularity part.
yacovm (Thu, 05 Oct 2017 09:47:51 GMT):
@asaningmaxchain ^
mastersingh24 (Thu, 05 Oct 2017 12:16:19 GMT):
@asaningmaxchain , in addition to what @yacovm posted above, think about it like this:
1) The MSP design provides the flexibility for multiple organizations to use their own membership services provider(s). It's also possible for these providers to be shared as well (for example the default X509-based MSP can share a central certificate authority and make use of OU's to uniquely identify / differentiate organizations). This is different from the v0.6 and earlier versions of Hyperledger Fabric where there was only a single, centralized membership service provider
2) As @yacovm mentioned, the MSP implementation defines a set of standard interfaces which are consumed by the various Fabric components. Today we only have a single concrete MSP implementation based on standard X509 PKI, but you'll see that there is a second implementation based on a technology called Identity Mixer in the works
asaningmaxchain (Thu, 05 Oct 2017 12:18:23 GMT):
@mastersingh24 can we use the e2e_cli to take an example?
asaningmaxchain (Thu, 05 Oct 2017 12:18:56 GMT):
i know in the e2e_cli it provides the shell to produce the artifacts for the fabric network
balaji.viswanathan (Fri, 06 Oct 2017 09:04:38 GMT):
Has joined the channel.
DarshanBc (Tue, 10 Oct 2017 06:56:00 GMT):
I am trying to bring up 4 org system using method followed in balance transfer All the containers are up including 4 ca_Peers but while registering users I am getting the above error ```[2017-10-10 11:57:11.245] [DEBUG] SampleWebApp - End point : /users
[2017-10-10 11:57:11.245] [DEBUG] SampleWebApp - User name : Barry
[2017-10-10 11:57:11.245] [DEBUG] SampleWebApp - Org name : org2
[2017-10-10 11:57:11.249] [DEBUG] Helper - ORGS[org].name :org2
[2017-10-10 11:57:11.249] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore.js - constructor
[2017-10-10 11:57:11.251] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore -- getValue
[2017-10-10 11:57:11.252] [DEBUG] Helper - ORGS[org].name :org2
[2017-10-10 11:57:11.252] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore.js - constructor
[2017-10-10 11:57:11.253] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore -- getValue
[2017-10-10 11:57:11.303] [DEBUG] Helper - [utils.CryptoKeyStore]: This class requires a CryptoKeyStore to save keys, using the store: {"opts":{"path":"/tmp/fabric-client-kvs_peerOrg2"}}
[2017-10-10 11:57:11.304] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore.js - constructor
[2017-10-10 11:57:11.304] [DEBUG] Helper - [utils.CryptoKeyStore]: _getKeyStore returning ks
[2017-10-10 11:57:11.304] [DEBUG] Helper - [crypto_ecdsa_aes]: generateKey, store.setValue
[2017-10-10 11:57:11.305] [DEBUG] Helper - [ecdsa/key.js]: ECDSA curve param X: 10e7408518fe34d480431c4d8c0abe2776b1a14ec3cb58a6824d7898f1a5a80f
[2017-10-10 11:57:11.305] [DEBUG] Helper - [ecdsa/key.js]: ECDSA curve param Y: 1516697123fea2c0e4763b32b0fe4344a758c3bd35c42e886efff70f799689fc
[2017-10-10 11:57:11.310] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore -- setValue
[2017-10-10 11:57:11.488] [ERROR] Helper - Error: Calling enrollment endpoint failed with error [Error: write EPROTO 140583861933888:error:1411713E:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc cert not for signing:../deps/openssl/openssl/ssl/ssl_lib.c:2512:
140583861933888:error:14082130:SSL routines:ssl3_check_cert_and_algorithm:bad ecc cert:../deps/openssl/openssl/ssl/s3_clnt.c:3544:
]
at ClientRequest.
DarshanBc (Tue, 10 Oct 2017 06:56:00 GMT):
I am trying to bring up 4 org system using method followed in balance transfer All the containers are up including 4 ca_Peers but while registering users I am getting the below error ```[2017-10-10 11:57:11.245] [DEBUG] SampleWebApp - End point : /users
[2017-10-10 11:57:11.245] [DEBUG] SampleWebApp - User name : Barry
[2017-10-10 11:57:11.245] [DEBUG] SampleWebApp - Org name : org2
[2017-10-10 11:57:11.249] [DEBUG] Helper - ORGS[org].name :org2
[2017-10-10 11:57:11.249] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore.js - constructor
[2017-10-10 11:57:11.251] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore -- getValue
[2017-10-10 11:57:11.252] [DEBUG] Helper - ORGS[org].name :org2
[2017-10-10 11:57:11.252] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore.js - constructor
[2017-10-10 11:57:11.253] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore -- getValue
[2017-10-10 11:57:11.303] [DEBUG] Helper - [utils.CryptoKeyStore]: This class requires a CryptoKeyStore to save keys, using the store: {"opts":{"path":"/tmp/fabric-client-kvs_peerOrg2"}}
[2017-10-10 11:57:11.304] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore.js - constructor
[2017-10-10 11:57:11.304] [DEBUG] Helper - [utils.CryptoKeyStore]: _getKeyStore returning ks
[2017-10-10 11:57:11.304] [DEBUG] Helper - [crypto_ecdsa_aes]: generateKey, store.setValue
[2017-10-10 11:57:11.305] [DEBUG] Helper - [ecdsa/key.js]: ECDSA curve param X: 10e7408518fe34d480431c4d8c0abe2776b1a14ec3cb58a6824d7898f1a5a80f
[2017-10-10 11:57:11.305] [DEBUG] Helper - [ecdsa/key.js]: ECDSA curve param Y: 1516697123fea2c0e4763b32b0fe4344a758c3bd35c42e886efff70f799689fc
[2017-10-10 11:57:11.310] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore -- setValue
[2017-10-10 11:57:11.488] [ERROR] Helper - Error: Calling enrollment endpoint failed with error [Error: write EPROTO 140583861933888:error:1411713E:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc cert not for signing:../deps/openssl/openssl/ssl/ssl_lib.c:2512:
140583861933888:error:14082130:SSL routines:ssl3_check_cert_and_algorithm:bad ecc cert:../deps/openssl/openssl/ssl/s3_clnt.c:3544:
]
at ClientRequest.
DarshanBc (Tue, 10 Oct 2017 09:07:24 GMT):
Hi I am trying to bring up 4 org systems similar with node sdk when I am trying to register a new user I am getting this error in docker logs of ca_Peer
```
2017/10/10 08:44:00 [DEBUG] Received request
POST /api/v1/register
Authorization: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUI4VENDQVplZ0F3SUJBZ0lVWEg5OG0zaGpqZktnbHNHZ1gxNW5UOU1iVURRd0NnWUlLb1pJemowRUF3SXcKY3pFTE1Ba0dBMVVFQmhNQ1ZWTXhFekFSQmdOVkJBZ1RDa05oYkdsbWIzSnVhV0V4RmpBVUJnTlZCQWNURFZOaApiaUJHY21GdVkybHpZMjh4R1RBWEJnTlZCQW9URUc5eVp6TXVaWGhoYlhCc1pTNWpiMjB4SERBYUJnTlZCQU1UCkUyTmhMbTl5WnpNdVpYaGhiWEJzWlM1amIyMHdIaGNOTVRjeE1ERXdNRGd4TmpBd1doY05NVGd4TURFd01EZ3gKTmpBd1dqQVFNUTR3REFZRFZRUURFd1ZoWkcxcGJqQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQQpCSnZmUk9zRm9DcmVid1JYMitaaGlyQWtzQktEeVpqM1RNMy9PTHJjUm9jS2tMT1BnY0ExQlBPTlN2Wmlxby84CmxMellFVU1DQzhVdHZrclR6b1FvYkZXamJEQnFNQTRHQTFVZER3RUIvd1FFQXdJSGdEQU1CZ05WSFJNQkFmOEUKQWpBQU1CMEdBMVVkRGdRV0JCU2JoL1JWS3VGcS9rZW4xREw1ZVgxTEYwVzkyekFyQmdOVkhTTUVKREFpZ0NDMgo1aWF6cVFKM3dzTUVsaDNlV2YxYXEwcEo4OXV5UTlaSkEvSkhCeEN1YlRBS0JnZ3Foa2pPUFFRREFnTklBREJGCkFpRUFxWEQwZlMzbVRIT2VoN0pVZW9lTEZhc1Vmc1E3a2Q3UHdEVzBMY1U2Q3hjQ0lBSWtXeDRLTFppeWFoQk4KeGpJcGlmeWFRazlNak9jY0x2VkJwS21FYk9EUgotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==.MEQCIBvfkrVrJolnlhcH9Om+cb/y6z1J2y2cRSJvkqww+p6WAiAGBQu6XC/w0qnIyH/KmAAL5Vsy+O/uaQZKnQCEanYCqQ==
{"id":"Alie","type":"client","affiliation":"org3.department1","max_enrollments":1,"caName":""}
2017/10/10 08:44:00 [DEBUG] Directing traffic to default CA
2017/10/10 08:44:00 [DEBUG] Checking for revocation/expiration of certificate owned by 'admin'
2017/10/10 08:44:00 [DEBUG] DB: Get certificate by serial (5c7f7c9b78638df2a096c1a05f5e674fd31b5034) and aki (b6e626b3a90277c2c304961dde59fd5aab4a49f3dbb243d64903f2470710ae6d)
2017/10/10 08:44:00 [DEBUG] Successful authentication of 'admin'
2017/10/10 08:44:00 [DEBUG] Register request received
2017/10/10 08:44:00 [DEBUG] Received registration request from admin: &{RegistrationRequest:{Name:Alie Type:client Secret:<
amolpednekar (Wed, 11 Oct 2017 05:16:08 GMT):
Has joined the channel.
nhrishi (Wed, 11 Oct 2017 07:43:12 GMT):
Hi, I'm trying to add new peer and hence require new certs for this new peer. I ran cryptogen but how do I make sure its signed by same CA that was used for other 2 existing peers.
nhrishi (Wed, 11 Oct 2017 07:43:12 GMT):
Hi, I'm trying to add new peer and hence require new certs for this new peer. I ran cryptogen but how do I make sure its signed by same CA that was used for other 2 existing peers. I'm getting below error while joining the peer ```Error: proposal failed (err: rpc error: code = Unknown desc = Failed to deserialize creator identity, err The supplied identity is not valid, Verify() returned x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "ca.org.example.com"))```
yacovm (Wed, 11 Oct 2017 07:51:18 GMT):
so when you run cryptogen it regenerates also the root CA certs
yacovm (Wed, 11 Oct 2017 07:51:28 GMT):
so you can't
nhrishi (Wed, 11 Oct 2017 07:53:18 GMT):
So in my case, I'm killing an existing peer and starting new. But some docker daemon doesnt allow me to create a new peer with same name.
nhrishi (Wed, 11 Oct 2017 07:53:44 GMT):
Hence i'm trying to create a new peer with different name but now this issue
nhrishi (Wed, 11 Oct 2017 07:56:43 GMT):
is there anyway we can completely remove this existing peer from the docker network without restarting docker daemon
Vadim (Wed, 11 Oct 2017 07:57:38 GMT):
@nhrishi you probably should remove the stopped container
nhrishi (Wed, 11 Oct 2017 07:59:16 GMT):
@Vadim I did, it had some issue and I think its not removed completely. Now docker doesnt allow me to create with same name
Vadim (Wed, 11 Oct 2017 07:59:28 GMT):
docker ps -a?
nhrishi (Wed, 11 Oct 2017 07:59:52 GMT):
its not in that as well
nhrishi (Wed, 11 Oct 2017 08:00:44 GMT):
I get this error ```docker: Error response from daemon: service endpoint with name peer.example.com already exists.``` when I try to start with same name.
nhrishi (Wed, 11 Oct 2017 08:00:44 GMT):
I get this error ```docker: Error response from daemon: service endpoint with name peer0.example.com already exists.``` when I try to start with same name.
nhrishi (Wed, 11 Oct 2017 08:03:02 GMT):
@Vadim do you think this command ```docker network disconnect --force bridge peer0.example.com``` would help?
nhrishi (Wed, 11 Oct 2017 08:03:37 GMT):
I'm currently in UAT env so dont want to take a chance. So want to confirm.
nhrishi (Wed, 11 Oct 2017 08:03:37 GMT):
I'm currently in UAT env so dont want to take a chance and want to confirm.
nhrishi (Wed, 11 Oct 2017 08:05:04 GMT):
@yacovm just to confirm, so there is no way right now to add a new peer with the same original CA ?
yacovm (Wed, 11 Oct 2017 08:08:14 GMT):
not with cryptogen
yacovm (Wed, 11 Oct 2017 08:08:19 GMT):
you need to use `openssl` command
nhrishi (Wed, 11 Oct 2017 08:09:15 GMT):
Okay
nhrishi (Wed, 11 Oct 2017 08:12:13 GMT):
Thanks @yacovm Do you have it handy by anychance. I need it little urgently.
yacovm (Wed, 11 Oct 2017 08:13:20 GMT):
no but maybe @aso does
nhrishi (Wed, 11 Oct 2017 08:48:32 GMT):
@aso We need to create certs for new peer for an existing network. Do you have openssl commands to create certs using existing root CAs. Could you pls share. Would be really helpful
Vadim (Wed, 11 Oct 2017 08:51:40 GMT):
@nhrishi I think it's also possible to do with CA
Vadim (Wed, 11 Oct 2017 08:51:41 GMT):
https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html#enrolling-a-peer-identity
nhrishi (Wed, 11 Oct 2017 09:24:09 GMT):
@Vadim Thanks. Do i need to register and enroll this new peer
nhrishi (Wed, 11 Oct 2017 09:24:09 GMT):
@Vadim Thanks. Do i need to register and enroll this new peer and it'll create certs?
Vadim (Wed, 11 Oct 2017 09:25:02 GMT):
@nhrishi ```
Now that you have successfully registered a peer identity, you may now enroll the peer given the enrollment ID and secret (i.e. the password from the previous section). This is similar to enrolling the bootstrap identity except that we also demonstrate how to use the “-M” option to populate the Hyperledger Fabric MSP (Membership Service Provider) directory structure.
Vadim (Wed, 11 Oct 2017 09:25:11 GMT):
it's what the link says
nhrishi (Wed, 11 Oct 2017 09:50:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=NeCgrAdA4mBx8Dkvv) @Vadim I tried this one. It doesnt work. Gives me error ```root@b4115dfb2ec4:/etc/hyperledger/fabric-ca-server-config# fabric-ca-client getcacert -u http://10.21.135.15:7054 -M $FABRIC_CA_CLIENT_HOME/msp
2017/10/11 09:49:24 [INFO] User provided config file: /root/fabric-ca/clients/peer2/fabric-ca-client-config.yaml
2017/10/11 09:49:24 [INFO] Configuration file location: /root/fabric-ca/clients/peer2/fabric-ca-client-config.yaml
Error: POST failure [Post http://10.21.135.15:7054/cainfo: malformed HTTP response "\x15\x03\x01\x00\x02\x02\x16"]; not sending
POST http://10.21.135.15:7054/cainfo
Authorization:
{}
```
Vadim (Wed, 11 Oct 2017 09:51:41 GMT):
@nhrishi getcacert?
Vadim (Wed, 11 Oct 2017 09:51:50 GMT):
what are you trying to do?
nhrishi (Wed, 11 Oct 2017 09:52:16 GMT):
@Vadim @yacovm I've an issue staring a "peer0". This is an anchor peer. I also have non-anchor peer "peer1". Can I make "Peer1" as anchor peer now.
nhrishi (Wed, 11 Oct 2017 09:54:28 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=MsNRjxHaXvXRXvn8j) @Vadim Sorry dont understnad this completely. I thought this can get me new certs using existing CA root.
nhrishi (Wed, 11 Oct 2017 09:54:47 GMT):
do you think just enrollment would suffice?
Vadim (Wed, 11 Oct 2017 09:57:22 GMT):
did you read the link?
Vadim (Wed, 11 Oct 2017 09:57:34 GMT):
the command there is "enroll", not "getcacert"
Vadim (Wed, 11 Oct 2017 09:58:11 GMT):
```export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/peer1
fabric-ca-client enroll -u http://peer1:peer1pw@localhost:7054 -M $FABRIC_CA_CLIENT_HOME/msp
nhrishi (Wed, 11 Oct 2017 10:01:40 GMT):
Yes I did enroll. it doesnt give me certs though. Aren't those required for new peer to join channel?
Vadim (Wed, 11 Oct 2017 10:41:30 GMT):
@nhrishi $FABRIC_CA_CLIENT_HOME/msp is empty?
nhrishi (Wed, 11 Oct 2017 10:44:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=uYgch4HosP97AuoEK) @Vadim yes I see empty dirs ```root@b4115dfb2ec4:~/fabric-ca/clients/peer2/msp# find .
.
./keystore
./signcerts
./cacerts
```
Vadim (Wed, 11 Oct 2017 10:45:12 GMT):
you are saying that those directories are empty?
Vadim (Wed, 11 Oct 2017 10:45:25 GMT):
and you did not have any errors?
nhrishi (Wed, 11 Oct 2017 10:46:57 GMT):
yes I didnt have any errors. I did exec bash into Org CA, and run below command ```export FABRIC_CA_CLIENT_HOME=$HOME/fabric-ca/clients/peer2
fabric-ca-client enroll -u http://peer2:peer2pw@10.21.135.15:7054 -M $FABRIC_CA_CLIENT_HOME/msp
```
Vadim (Wed, 11 Oct 2017 10:48:20 GMT):
@nhrishi this is strange, ask on #fabric-ca
nhrishi (Wed, 11 Oct 2017 10:53:57 GMT):
@Vadim sorry i tried again. It throughs me an error. ```root@b4115dfb2ec4:~/fabric-ca/clients/peer2/msp# fabric-ca-client enroll -u http://peer2:peer2pw@localhost:7054 -M $FABRIC_CA_CLIENT_HOME/msp
2017/10/11 10:53:20 [INFO] User provided config file: /root/fabric-ca/clients/peer2/fabric-ca-client-config.yaml
2017/10/11 10:53:20 [INFO] generating key: &{A:ecdsa S:256}
2017/10/11 10:53:20 [INFO] encoded CSR
Error: POST failure [Post http://localhost:7054/enroll: malformed HTTP response "\x15\x03\x01\x00\x02\x02\x16"]; not sending
POST http://localhost:7054/enroll
Authorization: Basic cGVlcjI6cGVlcjJwdw==
{"hosts":["b4115dfb2ec4"],"certificate_request":"-----BEGIN CERTIFICATE REQUEST-----\nMIIBQTCB6QIBADBdMQswCQYDVQQGEwJVUzEXMBUGA1UECBMOTm9ydGggQ2Fyb2xp\nbmExFDASBgNVBAoTC0h5cGVybGVkZ2VyMQ8wDQYDVQQLEwZGYWJyaWMxDjAMBgNV\nBAMTBXBlZXIyMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEkJkgaRzbeN9Kpcsr\n6x9UGNYq9t1oYuER5Fqj12yQzP+PiKtTtSp1G5nztaoMNAeorUxzM4Jvw6D17M+k\nB9izRqAqMCgGCSqGSIb3DQEJDjEbMBkwFwYDVR0RBBAwDoIMYjQxMTVkZmIyZWM0\nMAoGCCqGSM49BAMCA0cAMEQCIF+4/zJNhUO1rV8FIWNjTsBzzaISNvE71zTIOQoT\nkfuGAiBrGh7oQQEYQ2sRuWBU5Xi+VZyxqc6/dLmflHkvOfnlPw==\n-----END CERTIFICATE REQUEST-----\n","profile":"","crl_override":"","label":"","CAName":""}
root@b4115dfb2ec4:~/fabric-ca/clients/peer2/msp# find .
.
./keystore
./keystore/382bea8bd65d0f11b750daeffeb790de0431c51cd286fa58d487648c496737cc_sk
./keystore/1611a81b1c9d2a2b94f691997a665e15f9375cd80b35cefb784648c6d92cad86_sk
./signcerts
./cacerts
root@b4115dfb2ec4:~/fabric-ca/clients/peer2/msp#
```
Vadim (Wed, 11 Oct 2017 10:57:30 GMT):
@nhrishi is TLS enabled in your client?
nhrishi (Wed, 11 Oct 2017 10:57:51 GMT):
yes
nhrishi (Wed, 11 Oct 2017 10:58:27 GMT):
I think os
Vadim (Wed, 11 Oct 2017 10:58:38 GMT):
strange that it's POSTing to http, not https
Vadim (Wed, 11 Oct 2017 10:59:03 GMT):
perhaps check https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html#enabling-tls
RezwanKabir (Thu, 12 Oct 2017 08:02:41 GMT):
By using generate.sh I am creating certificates for 2 orgs.. each org has 2 peers. Those certificates work fine with balance transfer example. But when I generate 3 peers for each org and use these certificates in balance transfer project it shows creator identity not found... Am I missing something ?
rajasekharpippalla (Thu, 12 Oct 2017 10:59:51 GMT):
Has joined the channel.
rajasekharpippalla (Thu, 12 Oct 2017 11:00:29 GMT):
how we can implement self sovereign identity in hyperledger fabric?
Asara (Thu, 12 Oct 2017 17:48:57 GMT):
Curious, is it currently possible to set up a fabric network without using cryptogen? As in use the fabric-ca to handle registration of orderers/peers as well as sdk clients?
mastersingh24 (Thu, 12 Oct 2017 20:28:35 GMT):
@Asara - There is nothing special about the crypto material generated by `cryptogen`. It's just a convenience tool to get you up and running quickly
mastersingh24 (Thu, 12 Oct 2017 20:29:31 GMT):
You can set up your own fabric-ca's and register and enroll peers, orderers, clients using the fabric-ca-client or any of the SDKs
Asara (Thu, 12 Oct 2017 20:29:40 GMT):
Yeap found this after asking: http://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html#registering-a-new-identity
Asara (Thu, 12 Oct 2017 20:29:43 GMT):
Thanks!
mastersingh24 (Thu, 12 Oct 2017 20:30:07 GMT):
Sure thing. I wrote cryptogen for convenience ;)
jrosmith (Thu, 12 Oct 2017 20:30:59 GMT):
Has joined the channel.
jimthematrix (Fri, 13 Oct 2017 04:23:12 GMT):
@elli-androulaki can I ask you a favor to review the documentation on `getBinding()` for node.js chaincode API? https://fabric-shim.github.io/ChaincodeStub.html#getBinding
jimthematrix (Fri, 13 Oct 2017 04:24:42 GMT):
thanks!
vu3mmg (Sat, 14 Oct 2017 01:36:51 GMT):
@mastersingh24 could you please help me to understand the contents generated by cryptogen for balance-transfer application .I think latest version is different from earlier version of generated artificats .
vu3mmg (Sat, 14 Oct 2017 01:37:26 GMT):
|____peerOrganizations
| |____org1.example.com
| | |____ca
| | | |____0e729224e8b3f31784c8a93c5b8ef6f4c1c91d9e6e577c45c33163609fe40011_sk
| | | |____ca.org1.example.com-cert.pem
| | |____msp
| | | |____admincerts
| | | | |____Admin@org1.example.com-cert.pem
| | | |____cacerts
| | | | |____ca.org1.example.com-cert.pem
| | | |____tlscacerts
| | | | |____tlsca.org1.example.com-cert.pem
| | |____peers
| | | |____peer0.org1.example.com
| | | | |____msp
| | | | | |____admincerts
| | | | | | |____Admin@org1.example.com-cert.pem
| | | | | |____cacerts
| | | | | | |____ca.org1.example.com-cert.pem
| | | | | |____keystore
| | | | | | |____27db82c96b1482480baa1c75f80e5cce249beaab27b70c741bb0e2554355957e_sk
| | | | | |____signcerts
| | | | | | |____peer0.org1.example.com-cert.pem
| | | | | |____tlscacerts
| | | | | | |____tlsca.org1.example.com-cert.pem
| | | | |____tls
| | | | | |____ca.crt
| | | | | |____server.crt
| | | | | |____server.key
| | | |____peer1.org1.example.com
| | | | |____msp
| | | | | |____admincerts
| | | | | | |____Admin@org1.example.com-cert.pem
| | | | | |____cacerts
| | | | | | |____ca.org1.example.com-cert.pem
| | | | | |____keystore
| | | | | | |____fdee12a3510fde3155c37128cfec26090ae249bfbca28f884e60c21338493edd_sk
| | | | | |____signcerts
| | | | | | |____peer1.org1.example.com-cert.pem
| | | | | |____tlscacerts
| | | | | | |____tlsca.org1.example.com-cert.pem
| | | | |____tls
| | | | | |____ca.crt
| | | | | |____server.crt
| | | | | |____server.key
| | |____tlsca
| | | |____945092d936f5838c5a6f6484db974d857933706737d00d04bf65f74e3976f9f8_sk
| | | |____tlsca.org1.example.com-cert.pem
| | |____users
| | | |____Admin@org1.example.com
| | | | |____msp
| | | | | |____admincerts
| | | | | | |____Admin@org1.example.com-cert.pem
| | | | | |____cacerts
| | | | | | |____ca.org1.example.com-cert.pem
| | | | | |____keystore
| | | | | | |____5890f0061619c06fb29dea8cb304edecc020fe63f41a6db109f1e227cc1cb2a8_sk
| | | | | |____signcerts
| | | | | | |____Admin@org1.example.com-cert.pem
| | | | | |____tlscacerts
| | | | | | |____tlsca.org1.example.com-cert.pem
| | | | |____tls
| | | | | |____ca.crt
| | | | | |____server.crt
| | | | | |____server.key
| | | |____User1@org1.example.com
| | | | |____msp
| | | | | |____admincerts
| | | | | | |____User1@org1.example.com-cert.pem
| | | | | |____cacerts
| | | | | | |____ca.org1.example.com-cert.pem
| | | | | |____keystore
| | | | | | |____73cdc0072c7203f1ec512232c780fc84acc9752ef30ebc16be1f4666c02b614b_sk
| | | | | |____signcerts
| | | | | | |____User1@org1.example.com-cert.pem
| | | | | |____tlscacerts
| | | | | | |____tlsca.org1.example.com-cert.pem
| | | | |____tls
| | | | | |____ca.crt
| | | | | |____server.crt
| | | | | |____server.key
vu3mmg (Sat, 14 Oct 2017 01:40:22 GMT):
@mastersingh24 Sorry for the above long paste . please find the https://pastebin.com/d1invCDd could you please help me to understand the contents generated by cryptogen for balance-transfer application .I think latest version is different from earlier version of generated artificats .I could see msps multiple times in the organization
mastersingh24 (Sat, 14 Oct 2017 10:57:48 GMT):
@vu3mmg - might be easier if you could let us know what issue you are having? off the top of my head, I don't see anything different from the standard output from cryptogen
vu3mmg (Sat, 14 Oct 2017 14:12:06 GMT):
I am getting following error
vu3mmg (Sat, 14 Oct 2017 14:12:08 GMT):
sendPeersProposal - Promise is rejected: Error: Failed to deserialize creator identity, err MSP Org1MSP is unknown
at /Users/maheshgovind/pilot/fx/node_modules/grpc/src/node/src/client.js:554:15
vu3mmg (Sat, 14 Oct 2017 14:12:20 GMT):
I checked docker version it seems to be correct
vu3mmg (Sat, 14 Oct 2017 14:13:04 GMT):
based on https://jira.hyperledger.org/browse/FAB-5154
vu3mmg (Sat, 14 Oct 2017 14:13:21 GMT):
i am not sure which configuration to look at
vu3mmg (Sat, 14 Oct 2017 14:25:07 GMT):
createChannel,JoinChannel,InstallChainCode are succeeding
vu3mmg (Sat, 14 Oct 2017 14:25:27 GMT):
but during instantiating the chaincode I am getting the above error
vu3mmg (Sat, 14 Oct 2017 15:00:19 GMT):
@mastersingh24 I have no clue how to solve the above
mastersingh24 (Sat, 14 Oct 2017 18:13:57 GMT):
@vu3mmg - Are you just running the sample as is - i.e. no modifications?
vu3mmg (Sun, 15 Oct 2017 00:14:40 GMT):
@mastersingh24 I tried to modify , but the same org structure , crypto config etc ..
vu3mmg (Sun, 15 Oct 2017 00:18:25 GMT):
is there any special dependency we need to take care .
vu3mmg (Sun, 15 Oct 2017 02:39:50 GMT):
@mastersingh24 i was able to get though the error . Two reasons - chaincode was getting installed only in one node, instantiate proposal was sent to both the nodes , lack of knowledge of naming and fetching of peers for balance transfer
mastersingh24 (Sun, 15 Oct 2017 10:07:33 GMT):
@vu3mmg - Glad to hear you got through the error. So your goal was to take the sample and modify it? Looks like you were trying to add another organization and some additional peers? Just asking so that we can figure out what to better document
vu3mmg (Sun, 15 Oct 2017 15:25:01 GMT):
@mastersingh24 earlier I had created a remittance settlement app for bank based on old version of balance transfer. I wanted to port it to new hyperledger version . It took some 3-4 days for me to port it .Number of orgs were same ,But I had added some controllers and services . This application was running between dubai and india , across data centers. If you could give some insights about MSP , and how a peer validates a signature of client app . (my assumption is it is based on CA's cert ?) It will be helpful. I have created some simple ladder diagrams , if you could review it ones , it will be really helpful and I will post it in some blog .
CodeReaper (Sun, 15 Oct 2017 18:39:52 GMT):
Hey I saw that we can have a number of users included for an organization mentioned in the crypto-config.yaml. So those users crypto-material is generated (equivalent to registering and enrollment) at the beginning along with the the peers crypto material. Hence we can use these users to register and enroll new users dynamically with the SDK where each node app corresponds to a particular user(assigning admin in network-config to a particular user
CodeReaper (Sun, 15 Oct 2017 18:39:52 GMT):
Hey I saw that we can have a number of users included for an organization mentioned in the crypto-config.yaml. So those users crypto-material is generated (equivalent to registering and enrollment) at the beginning along with the the peers crypto material. Hence we can use these users to register and enroll new users dynamically with the SDK where each node app corresponds to a particular user(assigning admin in network-config to a particular user
CodeReaper (Sun, 15 Oct 2017 18:43:46 GMT):
Hey, in the example of balance transfer what is admins field in config.json file?? Is it the admin user of CA or one of the users(Admin@org1.example.com) created by the crypto-config at the begginning for the organization??
mastersingh24 (Mon, 16 Oct 2017 09:44:58 GMT):
@CodeReaper - it's the admin user for the CA
Lavanya5896 (Tue, 17 Oct 2017 05:49:04 GMT):
Has joined the channel.
vdods (Tue, 17 Oct 2017 22:13:14 GMT):
I'm getting a very frustrating error `Verify() returned x509: certificate has expired or is not yet valid` when the peer checks the admin cert, and found this code:
```
func (msp *bccspmsp) getValidityOptsForCert(cert *x509.Certificate) x509.VerifyOptions {
// First copy the opts to override the CurrentTime field
// in order to make the certificate passing the expiration test
// independently from the real local current time.
// This is a temporary workaround for FAB-3678
var tempOpts x509.VerifyOptions
tempOpts.Roots = msp.opts.Roots
tempOpts.DNSName = msp.opts.DNSName
tempOpts.Intermediates = msp.opts.Intermediates
tempOpts.KeyUsages = msp.opts.KeyUsages
tempOpts.CurrentTime = cert.NotBefore.Add(time.Second)
return tempOpts
}
```
which references this Jira ticket https://jira.hyperledger.org/browse/FAB-3678 . However, even though the cert validity options CurrentTime is being set to one second after the NotBefore time for the cert, the time check is still failing. Is anyone else having this problem?
vdods (Tue, 17 Oct 2017 22:13:28 GMT):
E.g.
```
cert.Subject.CommonName = "peer0-admin"
NotBefore = time.Time{sec:63643868520, nsec:0, loc:(*time.Location)(nil)},
NotAfter = time.Time{sec:63675404520, nsec:0, loc:(*time.Location)(nil)},
opts = x509.VerifyOptions{DNSName:"", Intermediates:(*x509.CertPool)(0xc4201e7710), Roots:(*x509.CertPool)(0xc4201e7680), CurrentTime:time.Time{sec:63643868521, nsec:0, loc:(*time.Location)(nil)}, KeyUsages:[]x509.ExtKeyUsage(nil)}
```
Noting that indeed, NotBefore < CurrentTime < NotAfter -- here, the CurrentTime is the one in the validity opts
yacovm (Tue, 17 Oct 2017 22:13:56 GMT):
so I think this might be because of the CA certs and not the admin cert
yacovm (Tue, 17 Oct 2017 22:14:13 GMT):
can you check the date on the CA certs and the admin certs with `openssl`
yacovm (Tue, 17 Oct 2017 22:14:20 GMT):
and post it here?
vdods (Tue, 17 Oct 2017 22:15:46 GMT):
ok
vdods (Tue, 17 Oct 2017 22:17:01 GMT):
Root CA cert:
```cert.Subject.CommonName = "RootCA",
NotBefore = time.Time{sec:63643349472, nsec:0, loc:(*time.Location)(nil)},
NotAfter = time.Time{sec:64274069472, nsec:0, loc:(*time.Location)(nil)},
opts = x509.VerifyOptions{DNSName:"", Intermediates:(*x509.CertPool)(0xc42028eb70), Roots:(*x509.CertPool)(0xc42028eae0), CurrentTime:time.Time{sec:63643349473, nsec:0, loc:(*time.Location)(nil)}, KeyUsages:[]x509.ExtKeyUsage(nil)}```
vdods (Tue, 17 Oct 2017 22:17:40 GMT):
intermediate CA cert:
```cert.Subject.CommonName = "localhost",
NotBefore = time.Time{sec:63643868799, nsec:0, loc:(*time.Location)(nil)},
NotAfter = time.Time{sec:63959228799, nsec:0, loc:(*time.Location)(nil)},
opts = x509.VerifyOptions{DNSName:"", Intermediates:(*x509.CertPool)(0xc42028eb70), Roots:(*x509.CertPool)(0xc42028eae0), CurrentTime:time.Time{sec:63643868800, nsec:0, loc:(*time.Location)(nil)}, KeyUsages:[]x509.ExtKeyUsage(nil)}```
yacovm (Tue, 17 Oct 2017 22:17:50 GMT):
where is that output from/?
vdods (Tue, 17 Oct 2017 22:18:10 GMT):
In both cases, getValidityOptsForCert slams opts.CurrentTime to one second after the cert's NotBefore time
vdods (Tue, 17 Oct 2017 22:18:17 GMT):
I added printfs to mspimpl.go
yacovm (Tue, 17 Oct 2017 22:18:48 GMT):
brb bringing a calculator
vdods (Tue, 17 Oct 2017 22:18:49 GMT):
both the root and intermediate CA certs pass the validity checks
vdods (Tue, 17 Oct 2017 22:19:35 GMT):
as far as I can tell, msp.getValidityOptsForCert should cause the cert time check to always pass
vdods (Tue, 17 Oct 2017 22:19:43 GMT):
unless the cert itself isn't valid for more than 1 second
vdods (Tue, 17 Oct 2017 22:20:39 GMT):
The odd thing is, I've had this work before, and I can't seem to replicate that condition
vdods (Tue, 17 Oct 2017 22:21:43 GMT):
BTW, I'm generating the root CA and intermediate CA certs myself using openssl
yacovm (Tue, 17 Oct 2017 22:21:50 GMT):
so the problem is:
yacovm (Tue, 17 Oct 2017 22:21:56 GMT):
the notBefore of the admin
vdods (Tue, 17 Oct 2017 22:21:58 GMT):
then giving the intermediate cert/key to fabric-ca to run the intermediate CA
yacovm (Tue, 17 Oct 2017 22:22:07 GMT):
oh, wait
yacovm (Tue, 17 Oct 2017 22:22:38 GMT):
aha
yacovm (Tue, 17 Oct 2017 22:23:03 GMT):
so `63643868799 - 63643868520 = 279`
yacovm (Tue, 17 Oct 2017 22:23:31 GMT):
so, the intermediate is.. in the future
yacovm (Tue, 17 Oct 2017 22:23:39 GMT):
in relation to the admin
yacovm (Tue, 17 Oct 2017 22:23:49 GMT):
and the verify options is calculated on the leaf, I think
vdods (Tue, 17 Oct 2017 22:23:50 GMT):
Weird, that shouldn't be happening -- I make them intermediate, then admin
yacovm (Tue, 17 Oct 2017 22:23:59 GMT):
well but look at the time
vdods (Tue, 17 Oct 2017 22:24:06 GMT):
right
vdods (Tue, 17 Oct 2017 22:24:11 GMT):
I wonder how it's getting an earlier time
yacovm (Tue, 17 Oct 2017 22:24:15 GMT):
try to do a sleep
yacovm (Tue, 17 Oct 2017 22:24:20 GMT):
when you generate them
vdods (Tue, 17 Oct 2017 22:24:28 GMT):
yes, but 279 seconds is a lot
yacovm (Tue, 17 Oct 2017 22:24:37 GMT):
ah it's seconds
vdods (Tue, 17 Oct 2017 22:24:55 GMT):
I'd believe if they were within a few seconds, but the other way around is weird
yacovm (Tue, 17 Oct 2017 22:25:23 GMT):
yeah. Anyway that's the problem I believe. Let me find the relevant JIRA...
vdods (Tue, 17 Oct 2017 22:25:32 GMT):
Ok, thanks for your insight, I've got my own debugging to do now :)
vdods (Tue, 17 Oct 2017 22:26:08 GMT):
Note that I've written my own scripts (loosely based on fabric-ca-cryptogen.sh) to do the crypto material generation
yacovm (Tue, 17 Oct 2017 22:29:50 GMT):
found it @vdods
yacovm (Tue, 17 Oct 2017 22:29:56 GMT):
FAB-4617
yacovm (Tue, 17 Oct 2017 22:30:07 GMT):
https://jira.hyperledger.org/browse/FAB-4617
vdods (Tue, 17 Oct 2017 23:28:17 GMT):
Thanks
ascatox (Wed, 18 Oct 2017 08:13:43 GMT):
Has joined the channel.
asaningmaxchain (Wed, 18 Oct 2017 08:36:20 GMT):
@mastersingh24 can you explain why the the peer/orderer node should config local msp
asaningmaxchain (Wed, 18 Oct 2017 08:36:20 GMT):
@mastersingh24 can you explain why the the peer/orderer node should config local msp?
mastersingh24 (Wed, 18 Oct 2017 08:53:54 GMT):
@asaningmaxchain - http://hyperledger-fabric.readthedocs.io/en/latest/msp.html#msp-setup-on-the-peer-orderer-side explains how the crypto material in the local MSP is used by the peer and orderer nodes
The quick answer is that both peers and orderers need to be able to provide digital signatures as part of the overall transaction flow. Peers sign endorsement responses and orderers sign blocks. The local MSP holds the crypto material needed to do this. Additionally, peers and orderers need to have some type of built-in adminstration and the local MSP is referenced for authorizing / verifying identities used to perform admin actions on the peer and/or orderer node(s)
vu3mmg (Wed, 18 Oct 2017 09:16:53 GMT):
@mastersingh24 if I understood correctly , the admission control is the responsibility of local MSP and , peers & Ordererers verify the signatures based on trusted CA for each of the org ?
vu3mmg (Wed, 18 Oct 2017 09:17:46 GMT):
If a trusted CA signs a certificate , peer will consider as signature is valid ?
mastersingh24 (Wed, 18 Oct 2017 09:23:24 GMT):
Let me clarify - admission control for "local / administrative" actions use the local MSP.
For the peer, this includes install chaincode, join channel and connecting to the event hub. Peers also use their local MSP (specifically the keystore and signcerts) to sign endorsement responses as well.
For the orderer, the local MSP is used for the initial bootstrap of the orderer (for example to create the genesis block for the system channel) and it also used by the orderer node(s) to sign blocks.
For channel-related actions (for example sending endorsement proposals to peers, sending transactions to the orderer), the MSPs are actually obtained from the configuration of the channels themselves
vu3mmg (Wed, 18 Oct 2017 09:25:34 GMT):
@mastersingh24 " the MSPs are actually obtained from the configuration of the channels themselves" is a bit confusing . could you please explain a bit
mastersingh24 (Wed, 18 Oct 2017 09:30:06 GMT):
@vu3mmg - Have you ever looked closely at `configtxgen` or `configtx.yaml`?
vu3mmg (Wed, 18 Oct 2017 09:30:14 GMT):
yes
vu3mmg (Wed, 18 Oct 2017 09:30:35 GMT):
in confitx.yaml we need to feed the msp details
vu3mmg (Wed, 18 Oct 2017 09:31:33 GMT):
ID:MSP ?
vu3mmg (Wed, 18 Oct 2017 09:31:44 GMT):
and msp directory
mastersingh24 (Wed, 18 Oct 2017 09:31:49 GMT):
Correct
vu3mmg (Wed, 18 Oct 2017 09:31:57 GMT):
the point which confuse me
vu3mmg (Wed, 18 Oct 2017 09:32:24 GMT):
if all the peers are running on different machines , how this is going to help
vu3mmg (Wed, 18 Oct 2017 09:33:37 GMT):
or this is only for the tool ?
vu3mmg (Wed, 18 Oct 2017 09:33:46 GMT):
configtxgen ?
mastersingh24 (Wed, 18 Oct 2017 09:35:03 GMT):
When you actually run `configtxgen`, the output is basically a configuration transaction / config block. If you were to actually look inside the contents of the transaction / block which is generated, you would actually say that it actually contains the serialized MSPs for each organization referenced. It uses the MSP directory to find the material and "load" it into the block / transaction
mastersingh24 (Wed, 18 Oct 2017 09:35:59 GMT):
So what actually goes to the orderer in create channel actually has the contents of the MSPs in it. The same holds true for the material used in the JoinChannel call to the peer as well
vu3mmg (Wed, 18 Oct 2017 09:36:24 GMT):
OK. for example crypto-config/ordererOrganizations/example.com/msp contains the certificates which are public
vu3mmg (Wed, 18 Oct 2017 09:36:38 GMT):
which needs to be shared across the nodes in the network
vu3mmg (Wed, 18 Oct 2017 09:36:45 GMT):
is this understanding right
vu3mmg (Wed, 18 Oct 2017 09:37:09 GMT):
which is encoded into genesis block
vu3mmg (Wed, 18 Oct 2017 09:37:20 GMT):
and genesis block is shared to all
mastersingh24 (Wed, 18 Oct 2017 09:37:56 GMT):
Right - so when a peer joins a channel, the contents of the config block have this information in it
mastersingh24 (Wed, 18 Oct 2017 09:38:40 GMT):
And then if you make config updates to the channel configuration, it is distributed as a config block on the channel and therefore goes to all peers connected to the channel
vu3mmg (Wed, 18 Oct 2017 09:38:50 GMT):
ok
vu3mmg (Wed, 18 Oct 2017 09:40:27 GMT):
one more query regarding a comment in balance transfer configtx.yaml
vu3mmg (Wed, 18 Oct 2017 09:40:35 GMT):
"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
'"
vu3mmg (Wed, 18 Oct 2017 09:40:50 GMT):
saw the above comment related to anchor peer
vu3mmg (Wed, 18 Oct 2017 09:42:12 GMT):
But there was no configuration in the application section of yaml file . Does this means anchor peers written in anchor peer section , will be added in the application section of genesis.block , even if Application section is empty in yaml file
vu3mmg (Wed, 18 Oct 2017 09:42:30 GMT):
to be honest , i never understood the Application section which is empty in the yaml file
vu3mmg (Wed, 18 Oct 2017 09:42:43 GMT):
The following part
vu3mmg (Wed, 18 Oct 2017 09:42:44 GMT):
Application: &ApplicationDefaults
# Organizations is the list of orgs which are defined as participants on
# the application side of the network
Organizations:
asaningmaxchain (Wed, 18 Oct 2017 09:56:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=G7qDSjPKn8ukG4maK) @mastersingh24 how the fabric identity the admin msp
KristofSajdak (Wed, 18 Oct 2017 09:58:50 GMT):
Has joined the channel.
asaningmaxchain (Wed, 18 Oct 2017 10:04:15 GMT):
@mastersingh24 i see the `example/e2e_cli/script/script.sh` when create channel it need the admins right
asaningmaxchain (Wed, 18 Oct 2017 10:04:15 GMT):
@mastersingh24 i see the `example/e2e_cli/script/script.sh` when create channel it need the admins right so the peer contains the admin msp
asaningmaxchain (Wed, 18 Oct 2017 10:04:15 GMT):
@mastersingh24 i see the `example/e2e_cli/script/script.sh` when create channel it need the admins right so the peer contains the admin msp?
JosephChang (Wed, 18 Oct 2017 13:16:37 GMT):
Has joined the channel.
CodeReaper (Wed, 18 Oct 2017 14:11:08 GMT):
hey, I was going through the crypto material generated by cryptogen, I wanted to ask whether each user (mentioned in the users directory containing crypto material for each organization) can enroll as same as CA admin or the new users registered by the CA??? I'm basically trying to divide node apps for CA and the users, so i want those users also be able to register new ones but I can't seem to enroll those bootstrapped users and get their context.
Menniti (Wed, 18 Oct 2017 19:21:06 GMT):
Has joined the channel.
mastersingh24 (Thu, 19 Oct 2017 10:24:19 GMT):
@CodeReaper - the users generated by cryptogen are not registered with the fabric-ca. However, the signing key pair used for those users (as well as for the MSP for each organization) are provided so that you can spin up a fabric-ca and register and enroll your own users (and still have them belong to the orgs created by cryptogen)
Ratnakar (Fri, 20 Oct 2017 13:31:18 GMT):
Has joined the channel.
mnosseir (Fri, 20 Oct 2017 20:08:43 GMT):
Has joined the channel.
CodeReaper (Sat, 21 Oct 2017 15:16:14 GMT):
@mastersingh24 Can I register and enroll new users with the help of these auto-created users, doesnt this require for them to register and enroll themselves first?? If not, how can I use these users??
mastersingh24 (Sat, 21 Oct 2017 17:06:01 GMT):
@CodeReaper - You can't use the users created by cryptogen to register new users with the fabric-ca. You can, however, directly use the users created by cryptogen. Most people end up using them from the CLI and then spinning up a fabric-ca using the root certs found in the `ca` folder for each of the orgs generated by cryptogen and then registering and enrolling users using one of the SDKs. It's possible to directly use these users from the SDKs as well (without requiring communication with the fabric-ca). Each SDK seems to have a slightly different way of importing existing identities
CodeReaper (Sun, 22 Oct 2017 16:24:20 GMT):
@mastersingh24 Thanks a lot to clear my confusion. To confirm, I just need to import these users by their key and certificates and I can use their context directly for my invocations??
mastersingh24 (Sun, 22 Oct 2017 22:14:16 GMT):
correct
shubhammangla (Mon, 23 Oct 2017 07:06:36 GMT):
Has joined the channel.
shubhammangla (Mon, 23 Oct 2017 07:16:41 GMT):
Hello all,
I am trying to setup a network across two different servers. The orderer is running on a host (lets call orderer_host), and peer is running on another host (lets call peer_host). After starting the network in orderer_host, I am copying over the crypto config folder from orderer_host to the peer_host.
When I try to update the peer as the anchor node of the organization, I get the below error in the peer log. I have checked that the ports being passed are correct.
`2017-10-23 06:53:44.638 UTC [ConnProducer] NewConnection -> ERRO 31c Failed connecting to orderer_host.orderer.net:7050 , error: x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "tlsca.orderer.net")`
Any pointers on what this issue could be?
Menniti (Mon, 23 Oct 2017 13:13:17 GMT):
Guys,
Concept question
Once I finish my transaction and it has been registered in my ledger, the information storage there is encrypted ???
yacovm (Mon, 23 Oct 2017 13:30:02 GMT):
no
Menniti (Mon, 23 Oct 2017 15:17:59 GMT):
@yacovm Thankss
rock_martin (Tue, 24 Oct 2017 08:51:20 GMT):
Has joined the channel.
shivann (Tue, 24 Oct 2017 12:12:50 GMT):
Has joined the channel.
Menniti (Tue, 24 Oct 2017 16:20:28 GMT):
Hey guys,
Maybe someone is interested
Hyperledger Course in EdX
https://www.edx.org/course/blockchain-business-introduction-linuxfoundationx-lfs171x
kostas (Wed, 25 Oct 2017 14:58:42 GMT):
Has joined the channel.
kostas (Wed, 25 Oct 2017 14:59:18 GMT):
Is a CA the best level of granularity we can achieve when revoking certificates?
kostas (Wed, 25 Oct 2017 14:59:28 GMT):
Looking at the MSP documentation and I read this:
kostas (Wed, 25 Oct 2017 14:59:31 GMT):
> A list of certificate revocation lists (CRLs) each corresponding to exactly one of the listed (intermediate or root) MSP Certificate Authorities; this is an optional parameter.
kostas (Wed, 25 Oct 2017 15:00:17 GMT):
And this is inline with what Gari's changeset yesterday does: https://gerrit.hyperledger.org/r/c/14773/
kostas (Wed, 25 Oct 2017 15:00:55 GMT):
But I'm wondering how we'd go about revoking specific certificates.
yacovm (Wed, 25 Oct 2017 15:10:11 GMT):
@kostas what do you mean? From what I know you can revoke a specific certificate.
yacovm (Wed, 25 Oct 2017 15:11:33 GMT):
a config update can have a CRL list and a CRL is basically a list of "certificate pointers and their issuers" and then a signature over it
yacovm (Wed, 25 Oct 2017 15:11:33 GMT):
a config update can have a CRL list and a CRL is basically a list of issuer-->revoked serial numbers and then a signature over it
kostas (Wed, 25 Oct 2017 15:20:36 GMT):
If I am to revoke a serial number, how does the orderer server pick up on this change?
kostas (Wed, 25 Oct 2017 15:21:29 GMT):
As best as I can tell, it just updates the root CA pool.
kostas (Wed, 25 Oct 2017 15:21:29 GMT):
As best as I can tell, it updates the root CA pool.
kostas (Wed, 25 Oct 2017 15:22:07 GMT):
And since we don't blacklist/revoke the CA, the orderer will be unaffected if we wish to revoke a cert issued by a CA.
kostas (Wed, 25 Oct 2017 15:22:07 GMT):
And since we don't blacklist/revoke the CA, the orderer will be unaffected if we just wish to revoke a cert issued by a CA.
kostas (Wed, 25 Oct 2017 15:22:07 GMT):
And since we don't blacklist/revoke the CA (but instead we only blacklist a cert issued by the CA), the orderer will be unaffected.
kostas (Wed, 25 Oct 2017 15:22:48 GMT):
If I'm wrong, let me know.
yacovm (Wed, 25 Oct 2017 16:01:53 GMT):
Ah you mean tls revocation?
yacovm (Wed, 25 Oct 2017 16:02:52 GMT):
So i am not in front of a computer but maybe you can specify a revocation list in the tls config?
kostas (Wed, 25 Oct 2017 16:03:05 GMT):
> Ah you mean tls revocation?
Correct.
kostas (Wed, 25 Oct 2017 16:04:02 GMT):
As best as I can tell, the server only operates on a CA-level of granularity. e.g. "Symantec is bad so let's remove them from the trusted list of CAs."
yacovm (Wed, 25 Oct 2017 16:04:31 GMT):
Thats what we do in fabric today but why are you concerned about tls revocation?
yacovm (Wed, 25 Oct 2017 16:04:55 GMT):
We give data ot authrnticate according to ebrollement certificates
yacovm (Wed, 25 Oct 2017 16:04:55 GMT):
We give data or authrnticate according to ebrollement certificates
kostas (Wed, 25 Oct 2017 16:05:35 GMT):
> Thats what we do in fabric today but why are you concerned about tls revocation?
Seemed like a logical follow-up question, after I reviewed that CR yesterday.
yacovm (Wed, 25 Oct 2017 16:06:03 GMT):
What is the question?
kostas (Wed, 25 Oct 2017 16:06:13 GMT):
> But I'm wondering how we'd go about revoking specific certificates.
kostas (Wed, 25 Oct 2017 16:07:05 GMT):
If Symantec issued a cert to John Doe, I want to blacklist John Doe and have my server (the orderer) drop any connection attempts from him. I don't want to drop all connections from all users that had certs issued by Symantec.
kostas (Wed, 25 Oct 2017 16:07:28 GMT):
(I'm aware of the concept of intermediate CAs but the problem is still there.)
yacovm (Wed, 25 Oct 2017 16:16:04 GMT):
@kostas so checked and what we can do to make this happen is use:
```
// VerifyPeerCertificate, if not nil, is called after normal
// certificate verification by either a TLS client or server. It
// receives the raw ASN.1 certificates provided by the peer and also
// any verified chains that normal processing found. If it returns a
// non-nil error, the handshake is aborted and that error results.
//
// If normal verification fails then the handshake will abort before
// considering this callback. If normal verification is disabled by
// setting InsecureSkipVerify then this callback will be considered but
// the verifiedChains argument will always be nil.
VerifyPeerCertificate func(rawCerts [][]byte, verifiedChains [][]*x509.Certificate) error
yacovm (Wed, 25 Oct 2017 16:16:07 GMT):
it's from the TLS config
yacovm (Wed, 25 Oct 2017 16:16:21 GMT):
I don't think it was in go 1.7, at least I don't recall that
yacovm (Wed, 25 Oct 2017 16:17:55 GMT):
But the problem is that we don't have TLS CRLs in msp_config proto structure
yacovm (Wed, 25 Oct 2017 16:18:56 GMT):
so, I _ guess _ if the TLS CA and the enrollment CA are the same, you _ could _ piggyback on the CRLs in the MSP config to accomplish that
kostas (Wed, 25 Oct 2017 16:19:16 GMT):
*gimme a sec to check, not sure I follow
yacovm (Wed, 25 Oct 2017 16:21:22 GMT):
but, it's not well defined, because you'd need to iterate over all MSPs of all channels to make this happen. and lets say that you have an MSP where the identity is revoked and an MSP where the identity isn't revoked
yacovm (Wed, 25 Oct 2017 16:21:23 GMT):
what do you do?
yacovm (Wed, 25 Oct 2017 16:22:59 GMT):
I guess - we can be either restrictive or lenient, but there is no way to know which MSP config is more updated, since there is no total order among channels.
kostas (Wed, 25 Oct 2017 16:27:19 GMT):
So walk me through the process. I want to ban cert `foo` issued by cert `bar`. Is a CRL update via config update the very first step on my list?
yacovm (Wed, 25 Oct 2017 16:32:09 GMT):
Yes
kostas (Wed, 25 Oct 2017 16:32:59 GMT):
Cool, now the server (the orderer) updates its pool of root CAs. In our case, this pool will remain identical. Yay or nay?
yacovm (Wed, 25 Oct 2017 16:33:23 GMT):
It should
kostas (Wed, 25 Oct 2017 16:33:37 GMT):
As best as I can tell after reviewing the changeset yesterday, the answer is yay, the pool will remain identical.
yacovm (Wed, 25 Oct 2017 16:33:54 GMT):
But i am envisionimg that we cache the crls in the SecureServer
yacovm (Wed, 25 Oct 2017 16:34:10 GMT):
And override that method i put above
kostas (Wed, 25 Oct 2017 16:35:52 GMT):
OK, so just to close one thread before spawning another. You and I seem to agree that preventing user `foo` from connecting to the orderer is not possible today, even if we revoke `foo`'s cert.
kostas (Wed, 25 Oct 2017 16:35:52 GMT):
OK, so just to close one thread before spawning another. You and I seem to agree that preventing user `foo` from connecting to the orderer is not (or at least doesn't seem to be) happening in our code today, even if we revoke `foo`'s cert.
kostas (Wed, 25 Oct 2017 16:36:12 GMT):
(Via a CRL update.)
yacovm (Wed, 25 Oct 2017 16:38:31 GMT):
Right but kt doesnt matter security wise
yacovm (Wed, 25 Oct 2017 16:38:31 GMT):
Right but it doesnt matter security wise
yacovm (Wed, 25 Oct 2017 16:38:47 GMT):
There is no security hole
yacovm (Wed, 25 Oct 2017 16:39:25 GMT):
A user is authenticated after the connection
kostas (Wed, 25 Oct 2017 16:39:27 GMT):
Because they're unable to broadcast or deliver.
kostas (Wed, 25 Oct 2017 16:39:29 GMT):
Right.
kostas (Wed, 25 Oct 2017 16:39:36 GMT):
Gotcha.
kostas (Wed, 25 Oct 2017 16:45:08 GMT):
I'll note that it strikes me as somewhat inconsistent that we won't let users from blacklisted CAs to connect (if mutual TLS is on), while blacklisted users from whitelisted CAs can connect, but I understand this might be a nit and there are practical reasons for not enforcing this.
kostas (Wed, 25 Oct 2017 16:49:04 GMT):
What I'm concerned about is this: a user has established a Deliver stream and they've asked the orderer to keep sending them blocks whenever they're ready. If a config update comes in that blacklists them, as best as I can tell they will keep on receiving blocks.
kostas (Wed, 25 Oct 2017 16:49:04 GMT):
RE: Security hole, what I'm concerned about is this: a user has established a Deliver stream and they've asked the orderer to keep sending them blocks whenever they're ready. If a config update comes in that blacklists them, as best as I can tell they will keep on receiving blocks.
kostas (Wed, 25 Oct 2017 16:49:04 GMT):
What I'm concerned with and need to double-check on, is what happens if a user has established a Deliver stream and they've asked the orderer to keep sending them blocks whenever they're ready. If a config update comes in that blacklists them, if memory serves me well they will keep on receiving blocks.
yacovm (Wed, 25 Oct 2017 17:23:27 GMT):
I don't think you're right @kostas
```
currentConfigSequence := chain.Sequence()
if currentConfigSequence > lastConfigSequence {
lastConfigSequence = currentConfigSequence
if err := sf.Apply(envelope); err != nil {
logger.Warningf("[channel: %s] Client authorization revoked for deliver request from %s: %s", chdr.ChannelId, addr, err)
return sendStatusReply(srv, cb.Status_FORBIDDEN)
}
}
kostas (Wed, 25 Oct 2017 17:24:31 GMT):
Ah, indeed. I was going off on memory here. Thanks @yacovm
jaswanth (Thu, 26 Oct 2017 05:49:14 GMT):
I am trying to do some access control in chaincode .. i cloned the fabric from github and ran ` git checkout master` ( as only this branch has the `cid`) . then i ran `make clean ` and `make docker ` .. i cloned fabric-samples examples from github.. and changed the `balance-tranfer` examples chaincode and ran `./run
jaswanth (Thu, 26 Oct 2017 05:49:14 GMT):
I am trying to do some access control in chaincode .. i cloned the fabric from github and ran ` git checkout master` ( as only this branch has the `cid`) . then i ran `make clean ` and `make docker ` .. i cloned fabric-samples examples from github.. and changed the `balance-tranfer` examples chaincode and ran `./runAPIs.sh` ..on instantiation i got ```
error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: error starting container: Failed to generate platform-specific docker build: Error returned from build: 1 "chaincode/input/src/github.com/example_cc/example_cc.go:25:2: cannot find package "github.com/hyperledger/fabric/core/chaincode/lib/cid" in any of:
/opt/go/src/github.com/hyperledger/fabric/core/chaincode/lib/cid (from $GOROOT)
/chaincode/input/src/github.com/hyperledger/fabric/core/chaincode/lib/cid (from $GOPATH)
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/lib/cid
" ``` .. is am doing all correct ? any help here
mastersingh24 (Thu, 26 Oct 2017 11:36:51 GMT):
@jaswanth - you need to use something like `govendor` to vendor the dependency on the `github.com/hyperledger/fabric/core/chaincode/lib/cid` package
jaswanth (Thu, 26 Oct 2017 11:39:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=uoBLbHGC5Ttqxh2MR) @mastersingh24 can you specify exactly how can i do that .. or can you suggest ma a doc from where i can proceed
mastersingh24 (Thu, 26 Oct 2017 11:41:33 GMT):
@jaswanth -
```
go get -u github.com/kardianos/govendor
cd $GOPATH/src/github.com/example_cc
govendor init
mastersingh24 (Thu, 26 Oct 2017 11:41:33 GMT):
@jaswanth -
```
go get -u github.com/kardianos/govendor
cd $GOPATH/src/github.com/example_cc
govendor init
govendor fetch github.com/hyperledger/fabric/core/chaincode/lib/cid
```
jaswanth (Thu, 26 Oct 2017 11:49:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=9p7WGXJAdzwv7Qe7h) @mastersingh24 got `govendor: command not found` error
jaswanth (Thu, 26 Oct 2017 11:49:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=9p7WGXJAdzwv7Qe7h) @mastersingh24 got `govendor: command not found` error at `govender init`
jaswanth (Thu, 26 Oct 2017 11:49:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=9p7WGXJAdzwv7Qe7h) @mastersingh24 got `govendor: command not found` error at `govendor init`
asaningmaxchain (Fri, 27 Oct 2017 07:39:59 GMT):
@jaswanth you should add the `govendor` add the PATH and take effect
asaningmaxchain (Fri, 27 Oct 2017 07:39:59 GMT):
@jaswanth you should add the `govendor` to the PATH and take effect
jaswanth (Fri, 27 Oct 2017 08:48:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=jbk5jFgGtGREfpgE3) @asaningmaxchain can you specify exctly how can i do that
asaningmaxchain (Fri, 27 Oct 2017 08:48:56 GMT):
can you find the location of the govendor
asaningmaxchain (Fri, 27 Oct 2017 08:48:56 GMT):
can you find the location of the govendor?
jaswanth (Fri, 27 Oct 2017 08:49:48 GMT):
yes it is under `$GOPATH/src/github.com/kardianos/govender`
asaningmaxchain (Fri, 27 Oct 2017 08:51:51 GMT):
no what i say the `govendor` binary
asaningmaxchain (Fri, 27 Oct 2017 08:51:51 GMT):
no! what i say the `govendor` binary
asaningmaxchain (Fri, 27 Oct 2017 08:53:03 GMT):
please go into the `$GOAPTH/bin` and then you will find the `govendor` binary and the cp the govendor to the `/usr/local/bin/`
asaningmaxchain (Fri, 27 Oct 2017 08:53:03 GMT):
please go into the `$GOAPTH/bin` and then you will find the `govendor` binary and the cp the `govendor` to the `/usr/local/bin/`
nikit-os (Fri, 27 Oct 2017 12:28:17 GMT):
Has joined the channel.
kostas (Sun, 29 Oct 2017 16:41:42 GMT):
Has left the channel.
alimamacoin (Mon, 30 Oct 2017 05:01:50 GMT):
Has joined the channel.
jaswanth (Mon, 30 Oct 2017 06:13:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=HgwmpHToxzq5ivKvH) @asaningmaxchain now i got this error ```Error: Package "/home/jaswanth/goProjects/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example01" not a go package or not in GOPATH```
`echo $GOPATH --> /home/jaswanth/goProjects/`
jaswanth (Mon, 30 Oct 2017 06:13:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=HgwmpHToxzq5ivKvH) @asaningmaxchain now i got this error ```Error: Package "/home/jaswanth/goProjects/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example01" not a go package or not in GOPATH```
`echo $GOPATH ` Prints ` /home/jaswanth/goProjects/`
jaswanth (Mon, 30 Oct 2017 06:13:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=HgwmpHToxzq5ivKvH) @asaningmaxchain now i got this error ```Error: Package "/home/jaswanth/goProjects/src/github.com/Dev_setup_v1/artifacts/src/github.com/example_cc" not a go package or not in GOPATH```
`echo $GOPATH ` Prints ` /home/jaswanth/goProjects/`
jaswanth (Mon, 30 Oct 2017 06:13:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=HgwmpHToxzq5ivKvH) @asaningmaxchain now i got this error ```Error: Package "/home/jaswanth/goProjects/src/github.com/Dev_setup_v1/artifacts/src/github.com/example_cc" not a go package or not in GOPATH```
`echo $GOPATH ` Prints ` /home/jaswanth/goProjects/`
jaswanth (Mon, 30 Oct 2017 06:13:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=HgwmpHToxzq5ivKvH) @asaningmaxchain now i got this error ```Error: Package "/home/jaswanth/goProjects/src/github.com/Dev_setup_v1/artifacts/src/github.com/example_cc" not a go package or not in GOPATH```
but when i run `go list` it shows the `_/home/jaswanth/goProjects/src/github.com/Dev_setup_v1/artifacts/src/github.com/example_cc`
`echo $GOPATH ` Prints ` /home/jaswanth/goProjects/`
jaswanth (Mon, 30 Oct 2017 06:13:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=HgwmpHToxzq5ivKvH) @asaningmaxchain now i got this error at `govendor init` ```Error: Package "/home/jaswanth/goProjects/src/github.com/Dev_setup_v1/artifacts/src/github.com/example_cc" not a go package or not in GOPATH```
but when i run `go list` it shows the `_/home/jaswanth/goProjects/src/github.com/Dev_setup_v1/artifacts/src/github.com/example_cc`
`echo $GOPATH ` Prints ` /home/jaswanth/goProjects/`
jaswanth (Mon, 30 Oct 2017 06:13:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=HgwmpHToxzq5ivKvH) @asaningmaxchain now i got this error at `govendor init` ```Error: Package "/home/jaswanth/goProjects/src/github.com/Dev_setup_v1/artifacts/src/github.com/example_cc" not a go package or not in GOPATH```
but when i run `go list` it shows `_/home/jaswanth/goProjects/src/github.com/Dev_setup_v1/artifacts/src/github.com/example_cc`
`echo $GOPATH ` Prints ` /home/jaswanth/goProjects/`
jaswanth (Mon, 30 Oct 2017 06:13:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=HgwmpHToxzq5ivKvH) @asaningmaxchain i copied the binary to `usr/local/bin` . now i got this error at `govendor init` ```Error: Package "/home/jaswanth/goProjects/src/github.com/Dev_setup_v1/artifacts/src/github.com/example_cc" not a go package or not in GOPATH```
but when i run `go list` it shows `_/home/jaswanth/goProjects/src/github.com/Dev_setup_v1/artifacts/src/github.com/example_cc`
`echo $GOPATH ` Prints ` /home/jaswanth/goProjects/`
Vadim (Mon, 30 Oct 2017 08:13:58 GMT):
@jaswanth the path looks strange, note that it has "src/github.com" repeating twice
Vadim (Mon, 30 Oct 2017 08:14:29 GMT):
should be just "/home/jaswanth/goProjects/src/github.com/example_cc"
DanielDaucik (Tue, 31 Oct 2017 12:48:12 GMT):
Has joined the channel.
tmkaranraj (Tue, 31 Oct 2017 17:07:19 GMT):
Has joined the channel.
RezwanKabir (Tue, 31 Oct 2017 18:46:37 GMT):
hi guys I want to create more channels. how can i generate more certificates for channel for a single MSP ?
jyellick (Tue, 31 Oct 2017 19:02:23 GMT):
@RezwanKabir If you are interested in dynamically adding more users to an organization, I would recommend you look at #fabric-ca (my assumption is that today you are only using `cryptogen` )
SubhodI (Wed, 01 Nov 2017 13:32:49 GMT):
Has joined the channel.
SubhodI (Wed, 01 Nov 2017 13:33:59 GMT):
While making channel update transaction, orderer throws "[
Rejecting CONFIG_UPDATE because: Error authorizing update: Error validating DeltaSet: Policy for [Groups] /Channel/Application not satisfied: Failed to reach implicit threshold of 2 sub-policies, required 1 remaining
" exception
SubhodI (Wed, 01 Nov 2017 13:34:46 GMT):
What exactly is implicit threshold and how can change it ?
matanyahu (Thu, 02 Nov 2017 18:30:47 GMT):
I am working on securing confidentiality inside a Fabric network. The scenario is based on four organizations within a single channel, sharing endorsement peers among each other to submit transactions to a single smart contract. Version 0.6 had tCerts which ensured that only relevant parties to the transaction can see its contents. I am looking for something similarly transparent for both end users and developers in version 1.0. Currently, the only option I see is to apply encryption at the application level. However, this does not ensure a proper redistribution of encryption keys across the organisation. Any alternatives would be greatly appreciated.
srongzhe (Sat, 04 Nov 2017 13:53:33 GMT):
Has joined the channel.
handasontam (Wed, 08 Nov 2017 07:56:20 GMT):
Has joined the channel.
handasontam (Wed, 08 Nov 2017 08:26:28 GMT):
I want set up a network, using openssl to sign the root ca cert, and using this root CA Cert(ROOTCA) to sign serval admin cert.
My problem is that when creating the genesis block using the command:
`CONFIGTXGEN -profile TwoOrgsOrdererGenesis -outputBlock "$FABRIC_CFG_PATH/genesis.block"`,
The error message is:
```
2017-11-08 08:15:53.692 GMT [common/configtx/tool] main -> INFO 001 Loading configuration
2017-11-08 08:16:00.908 GMT [configvalues/msp] TemplateGroupMSPWithAdminRolePrincipal -> CRIT 002 Setting up the MSP manager failed, err The supplied identity is not valid, Verify() returned x509: certificate has expired or is not yet valid
```
I have traced in the MSP Module, it return error from function below:
```
func (msp *bccspmsp) Setup(conf1 *m.MSPConfig) error {
...
// Setup CAs
if err := msp.setupCAs(conf); err != nil {
return err
}
...
}
```
and it fails to check the valid period of root ca cert (ROOTCA).
```
func (c *Certificate) isValid(certType int, currentChain []*Certificate, opts *VerifyOptions) error {
...
now := opts.CurrentTime
if now.IsZero() {
now = time.Now()
}
if now.Before(c.NotBefore) || now.After(c.NotAfter) {
return CertificateInvalidError{c, Expired}
}
...
}
```
The time `now` is smaller (before) `c.NotBefore`.
We checked the issued root ca cert (ROOTCA) is correct ( the valid period is correct, it is okay using openssl verify command )
Does anyone have any idea? Thx.
mastersingh24 (Wed, 08 Nov 2017 13:19:36 GMT):
@handasontam - My guess is that this should be working now? You can't use a CA certificate that is not yet valid.
dijun (Wed, 08 Nov 2017 23:31:27 GMT):
About China Crypto Standard support
I am trying to do something on China Crypto Standard Support(SMx) in fabric，here are some problems should be discussed for.
It’s not difficult in bccsp to support SMx, it does not take too much time. The real problem I found is that x509 in go standard library does not support SMx natively which is hard imported in bccsp, msp, crytogen, etc.
So if we don’t do something on x509, there is no way to generate SMx key or parse/create SMx certificate.
My current solution:
(1) Customise crypto standard library in go package to support SMx. So it must add custom go standard library in baseimage to support SMx.
Alternative:
(2) Copy crypto standard library to fabric and do SMx support on it.
The good and the bad:
(1) Fabric can support SMx decently， because crpto/x509 in go packages are support SMx natively. But SMx supported library must be installed in the baseimage. more over, if native tools like cryptogen, configtxgen you want to use or you want to run fabric in your native environment, you should compile your native SMx go env.
(2) Copy crypto standard library to fabric and do SMx support on it. In this way, it doesn’t need do anything in go standard library, so we don’t need to care about the go env we currently use. But fabric need to modified heavily, because crypto/x509 is imported everywhere in project. And I think tls can’t support SMx, because tls package is also a standard library that uses crypto/x509.So there is nothing we could do to make it support it.
So which way is better you think? Any alternatives would be appreciated.
handasontam (Thu, 09 Nov 2017 02:56:23 GMT):
https://github.com/hyperledger/fabric/commit/d54542f9de0540ab7a0a318b81586d1f29a72ae9
> cryptogen currently sets the NotBefore field
> for certificates to the current time.
> Fabric CA sets the NotBefore field to
> current time - 5 minutes.
may I ask why fabric-ca sets the NotBefore field to current time - 5 minutes? thx
yacovm (Thu, 09 Nov 2017 06:29:32 GMT):
@smithbk ^
smithbk (Thu, 09 Nov 2017 13:01:48 GMT):
@handasontam We inherit the default backdating of 5 minutes from CFSSL. There is no specific description in the code, but my assumption is that it is to allow a certificate which was just issued to be valid elsewhere allowing for 5 minutes of clock skew. Anyway, this is just the default behavior.
mastersingh24 (Thu, 09 Nov 2017 17:30:08 GMT):
@handasontam - It's actually pretty common practice to do that for the reason @smithbk - adjust for clock skew
handasontam (Fri, 10 Nov 2017 01:17:42 GMT):
@yacovm @smithbk @mastersingh24 Thank you so much!
danielleekc (Fri, 10 Nov 2017 01:24:04 GMT):
Has joined the channel.
bh4rtp (Sat, 11 Nov 2017 12:45:08 GMT):
hi, when using `cryptogen` to generate certificates, where can i find the key and cert files for peer admin and network admin?
yacovm (Sat, 11 Nov 2017 15:24:27 GMT):
under the users folder, the key is in the signcerts folder
bh4rtp (Sun, 12 Nov 2017 00:15:00 GMT):
@yacovm thanks.
thiago-moreira (Sun, 12 Nov 2017 01:24:09 GMT):
Has joined the channel.
latitiah (Mon, 13 Nov 2017 17:42:48 GMT):
Has joined the channel.
latitiah (Mon, 13 Nov 2017 17:44:27 GMT):
Hi, I'm using fabric-ca to generate my certificates. Unfortunately, I am receiving an error when starting the orderer: ```2017-11-13 16:30:24.115 UTC [orderer/multichain] newLedgerResources -> CRIT 078 Error creating configtx manager and handlers: Setting up the MSP manager failed, err admin 0 is invalid, validation error Could not obtain certification chain, err A CA certificate cannot be used directly by this MSP
panic: Error creating configtx manager and handlers: Setting up the MSP manager failed, err admin 0 is invalid, validation error Could not obtain certification chain, err A CA certificate cannot be used directly by this MSP
goroutine 1 [running]:
panic(0xb31bc0, 0xc420383a10)
/opt/go/src/runtime/panic.go:500 +0x1a1
github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*Logger).Panicf(0xc4201ec810, 0xc71091, 0x30, 0xc420383960, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/logger.go:194 +0x127
github.com/hyperledger/fabric/orderer/multichain.(*multiLedger).newLedgerResources(0xc42039b540, 0xc42038b830, 0xc42038b830)
/opt/gopath/src/github.com/hyperledger/fabric/orderer/multichain/manager.go:164 +0x393
github.com/hyperledger/fabric/orderer/multichain.NewManagerImpl(0x122a3a0, 0xc4203aa6e0, 0xc42038b6e0, 0x1226ea0, 0x126ee88, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/orderer/multichain/manager.go:114 +0x23b
main.initializeMultiChainManager(0xc4202286c0, 0x1226ea0, 0x126ee88, 0xc4201eef00, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/orderer/main.go:219 +0x27a
main.main()
/opt/gopath/src/github.com/hyperledger/fabric/orderer/main.go:75 +0x392``` It's not clear to me what certificate it is complaining about. I am using fabric-ca to generate the certificates. Can someone tell me what I'm missing?
latitiah (Mon, 13 Nov 2017 17:44:53 GMT):
I first asked in #fabric-orderer and was referred here instead
yacovm (Mon, 13 Nov 2017 17:48:44 GMT):
that's simple @latitiah
yacovm (Mon, 13 Nov 2017 17:49:00 GMT):
it complains (I think) that the peer's certificate has the `IsCA` tag
yacovm (Mon, 13 Nov 2017 17:49:08 GMT):
if you post here the PEM (if it's not confidential)
yacovm (Mon, 13 Nov 2017 17:49:21 GMT):
I can see if that's the case
latitiah (Mon, 13 Nov 2017 17:54:05 GMT):
sure, but I haven't started the peer yet at this point. This is for the orderer... Ah. I see what you mean. Thanks!
yacovm (Mon, 13 Nov 2017 17:54:22 GMT):
ah I didn't look at the stack trace
yacovm (Mon, 13 Nov 2017 17:54:25 GMT):
indeed it's for the orderer
rajasekharpippalla (Tue, 14 Nov 2017 05:54:05 GMT):
Oracle ---->>> verification module
JPMorgan ---->>> verification module
1. Oracle as well as JPMorgan has done transactions with verfication module.
2. Now verification module can have information for both Oracle and JPMorgan.
3. Oracle should not have access for JPMorgan data and vice-versa.
How can we implement this kind of requirement? Can we implement this by using channels and how we can implement if we have any chances?
ascatox (Tue, 14 Nov 2017 09:52:20 GMT):
Hi All! I've a question what's the difference between Admin and PeerAdmin in a fabric environment with ca server?
UtkarshSingh (Tue, 14 Nov 2017 13:59:01 GMT):
Has joined the channel.
UtkarshSingh (Tue, 14 Nov 2017 13:59:11 GMT):
Hie all, I have a question regarding MSP n TLS folder
In MSP folder, a peer will have an unique pub-pri key-pair
Similarly, In TLS folder, a peer has pub-pri key-pair, but it is signed by TLSCA
Both pub-pri key-pair are same or different ??
Vadim (Tue, 14 Nov 2017 14:01:09 GMT):
different
yacovm (Tue, 14 Nov 2017 14:01:10 GMT):
they are different
yacovm (Tue, 14 Nov 2017 14:01:16 GMT):
ah vadim beat me to it
Vadim (Tue, 14 Nov 2017 14:01:25 GMT):
yeah, like 0.5 sec
flyq (Wed, 15 Nov 2017 04:41:51 GMT):
Has joined the channel.
flyq (Wed, 15 Nov 2017 04:42:48 GMT):
Has left the channel.
LeoKotschenreuther (Wed, 15 Nov 2017 17:25:25 GMT):
Has left the channel.
matanyahu (Wed, 15 Nov 2017 22:18:21 GMT):
Can anyone confirm if Hyperledger Fabric went through a formal and documented security audit and/or can confirm a security certificate given by an authority of any kind (ISO, CERT, ISACA etc.)?
alainN (Thu, 16 Nov 2017 00:51:30 GMT):
Has joined the channel.
siesero (Thu, 16 Nov 2017 13:58:42 GMT):
Has joined the channel.
ashutosh_kumar (Thu, 16 Nov 2017 14:22:49 GMT):
We run Pen Test and Code scanning. Other compliance items are hosting related AFAIK.
nileshyjadhav (Thu, 16 Nov 2017 16:52:57 GMT):
Has joined the channel.
eetti (Fri, 17 Nov 2017 00:25:35 GMT):
is it possible to update the tls certs used for peers/orderers? Would I also have to change the tlscacert used in the genesis block (i.e modifiy channel config) ?
jaswanth (Fri, 17 Nov 2017 05:10:36 GMT):
Hi all, i'm able to get attribute (`position`) in certificate.. but in chaincode ,i'am getting `mspid` as `Org1msp` , but its says `The client identity does not possess the attribute` for the attribute ..any help ?
i got info in enrollment certificate as `cert extensions[......] {"attrs":{"position":"admin"}}`
my chaincode where i used `cid` is
```
func(t *StudentChainCode) Init(stub shim.ChaincodeStubInterface) pb.Response {
fmt.Println("Student's chaincode is starting up")
fmt.Println(" - ready for action");
id, err := cid.GetID(stub);
fmt.Printf("id obtained %v",id);
mspid, err := cid.GetMSPID(stub);
fmt.Printf("mspid obtained %v",mspid);
val, ok, err := cid.GetAttributeValue(stub, "position");
if err != nil {
fmt.Println("There was an error trying to retrieve the attribute");
}else if !ok {
fmt.Println("The client identity does not possess the attribute");
}else{
fmt.Printf("value obtained %v",val);
}
return shim.Success(nil)
}
```
jaswanth (Fri, 17 Nov 2017 05:10:36 GMT):
Hi all, i'm able to get attribute (`position`) in certificate.. in chaincode ,i'am getting `mspid` as `Org1msp` as i wanted , but its says `The client identity does not possess the attribute` for the attribute ..any help ?
i got info in enrollment certificate as `cert extensions[......] {"attrs":{"position":"admin"}}`
my chaincode where i used `cid` is
```
func(t *StudentChainCode) Init(stub shim.ChaincodeStubInterface) pb.Response {
fmt.Println("Student's chaincode is starting up")
fmt.Println(" - ready for action");
id, err := cid.GetID(stub);
fmt.Printf("id obtained %v",id);
mspid, err := cid.GetMSPID(stub);
fmt.Printf("mspid obtained %v",mspid);
val, ok, err := cid.GetAttributeValue(stub, "position");
if err != nil {
fmt.Println("There was an error trying to retrieve the attribute");
}else if !ok {
fmt.Println("The client identity does not possess the attribute");
}else{
fmt.Printf("value obtained %v",val);
}
return shim.Success(nil)
}
```
PavelL 1 (Fri, 17 Nov 2017 22:10:14 GMT):
Has joined the channel.
PavelL 1 (Fri, 17 Nov 2017 22:13:41 GMT):
Hi, Is it possible to generate crypto materials (using fabric-ca) for a new org without regenerating certs for whole network?
eetti (Sat, 18 Nov 2017 00:25:06 GMT):
How can I update tlscacert specified in the genesis block for an existing network? I have seen how to use configtxlator to convert the genesis block to JSON, the field for the tlscacert is hashed and I can't modify the value that is there
dante (Sun, 19 Nov 2017 03:29:05 GMT):
Has joined the channel.
JayJong (Sun, 19 Nov 2017 15:33:23 GMT):
Has joined the channel.
JayJong (Mon, 20 Nov 2017 05:52:19 GMT):
Hi all, I have some questions regarding encryption. I wish to encrypt transaction data with multiple client's public keys (multisig) and store the ciphertext into the fabric ledger. Any client is able to decrypt it using their private key. From my understanding, there is no way to use the keys generated by the fabric-ca so that's why I'm thinking of generating additional public/private keys for encryption. Recently, I found out about fabric's encryption chaincode (https://github.com/hyperledger/fabric/tree/master/examples/chaincode/go/enccc_example)
So my question is should I generate the additional keys outside of fabric or can i use the keys generated by fabric-ca in fabric through the encryption chaincode?
yacovm (Mon, 20 Nov 2017 07:23:02 GMT):
@JayJong IIRC the encshim is for AES not for asymmetric encryption
Riussi (Mon, 20 Nov 2017 08:50:54 GMT):
Has joined the channel.
JayJong (Mon, 20 Nov 2017 11:51:46 GMT):
@yacovm Do i have to generate the AES keys from openssl or can i use the keys from fabric-ca?
yacovm (Mon, 20 Nov 2017 11:52:37 GMT):
@smithbk does fabric-CA produce AES keys?
jesus.diaz.vico (Mon, 20 Nov 2017 12:10:27 GMT):
Has joined the channel.
smithbk (Mon, 20 Nov 2017 12:51:40 GMT):
@yacovm No ... fabric-ca generates only asymmetric keys
yacovm (Mon, 20 Nov 2017 12:51:58 GMT):
@JayJong ^ there you go
JayJong (Tue, 21 Nov 2017 02:35:06 GMT):
@smithbk thanks for the clarification, can i use the asymmetric keys in fabric-ca to encrypt my data?
@yacovm why would fabric come up with an encryption chaincode that works for symmetric encryption and not asymmetric since fabric-ca already creates the asymmetric keys
malkochoglu (Tue, 21 Nov 2017 02:46:52 GMT):
Has joined the channel.
malkochoglu (Tue, 21 Nov 2017 03:27:13 GMT):
Hi,Since there is an encryption discussion going on, can you please let me understand whether data in the
malkochoglu (Tue, 21 Nov 2017 03:27:13 GMT):
Hi,Since there is an encryption discussion going on, I have some questions around this topic.Can you please let me understand 1) Whether data in the ledger is encrypted or not? 2) After a channel is initiated do peers share a channel specific symmetric key for encrypt/decrypt messages? 3) If answer is no to 2 do all peers and orderers exchange their public keys for submitting trxs? 4)I could not find something in the docs mentioning these topics in detail, are there any documentation explaining in detail which encryption practices are used at which stage (invoke, send transaction, receive message, read/write from ledger, enrollment, etc...)? I see some references to certificates in CA which is more basically around enrollment. I was able to run some examples and tests but still not clear on this topic. I appreciate any help...
Vadim (Tue, 21 Nov 2017 08:24:30 GMT):
@JayJong you need to generate a sym key and then use it to encrypt the data, the asymm keys are only for signing
Vadim (Tue, 21 Nov 2017 08:27:04 GMT):
@malkochoglu 1) no 2) the messages in transit are encrypted with TLS, so the protocol handles key exchange and encryption/decryption 3) no 4) because there is no data-at-rest encryption, only data-in-transit which is TLS
doraemon7 (Wed, 22 Nov 2017 05:31:30 GMT):
Has joined the channel.
jojialex2 (Wed, 22 Nov 2017 11:15:11 GMT):
Hi, Please help on the following error :
peer chaincode instantiate using kafka orderer giving following error,
←[34;1mpeer0.org1.example.com |←[0m ←[33m2017-11-22 10:47:31.505 UTC [gossip/comm] sendToEndpoint -> WARN 54d←[0m Failed obtaining connection for 172.18.0.15:7051, PKIid:[71 88 115 27 28 222 244 157 196 20 206 87 238 41 173 71 185 195 175 121 236 34 206 183 63 153 178 63 241 226 254 204] reason: x509: cannot validate certificate for 172.18.0.15 because it doesn't contain any IP SANs
mastersingh24 (Wed, 22 Nov 2017 14:16:45 GMT):
@jojialex2 - you should access the orderer nodes via their hostname rather than IP address
jackeyliliang (Fri, 24 Nov 2017 02:57:20 GMT):
Has joined the channel.
MohitYadav2317 (Fri, 24 Nov 2017 07:10:38 GMT):
Has joined the channel.
sasiedu (Sun, 26 Nov 2017 09:54:22 GMT):
Has joined the channel.
baoyangc (Sun, 26 Nov 2017 16:39:29 GMT):
Has joined the channel.
handasontam (Tue, 28 Nov 2017 03:13:48 GMT):
Hi, I want to know how the certificate were distributed between peers,
as far as I know, each peer should get the cert of other peers for verifying their signature (e.g. when the endorser peer receive the transaction proposal from the invoking peer, it has to verify the digital signature)
However, we only set up local msp when creating the peer. How would they get other's cert?
Thank you
muasif80 (Tue, 28 Nov 2017 03:18:17 GMT):
Has joined the channel.
yacovm (Tue, 28 Nov 2017 07:39:53 GMT):
The peer includes it certificate in the ebdorsement
newtorob (Tue, 28 Nov 2017 20:13:17 GMT):
Has joined the channel.
handasontam (Wed, 29 Nov 2017 07:25:33 GMT):
@yacovm then isn't it useless? Any client can send the signed proposal together its cert to the endorser and get verified by the endorser
yacovm (Wed, 29 Nov 2017 07:30:12 GMT):
I dont follow
swettdj (Wed, 29 Nov 2017 14:46:44 GMT):
Has joined the channel.
Russell-Columbia (Wed, 29 Nov 2017 22:59:15 GMT):
Has joined the channel.
blw (Thu, 30 Nov 2017 01:14:39 GMT):
Has joined the channel.
mastersingh24 (Thu, 30 Nov 2017 09:38:28 GMT):
@handasontam -
When a peer joins a channel, it receives the config block(s) for that channel. The config block for a channel contains the MSPs for all of the orgs which are a member of that channel. Each org has a unique MSP - denoted by both the mspid as well as a unique root/intermediate certificate authority.
Endorsement policies for chaincode are typically based on orgs as well (via their mspids). When a peer endorses a chaincode transaction, as @yacov stated it signs the endorsement and includes it's public key (X509 certificate) and MSPID in the proposal response.
As you know, the client collects, packages and sends the endorsement responses to the orderer which then sends blocks / transactions to the peers for validation and commitment.
Each peer than checks to make sure that all the signatures are valid. As mentioned, the public keys are included for each signature. But the peer also checks to make sure that each certificate was actually issued by the MSPID the endorser claims to be part of. After that, the peer checks to make sure that there are enough signatures from the appropriate MSPIDs (orgs) to meet the endorsement policy
mastersingh24 (Thu, 30 Nov 2017 09:38:28 GMT):
@handasontam -
When a peer joins a channel, it receives the config block(s) for that channel. The config block for a channel contains the MSPs for all of the orgs which are a member of that channel. Each org has a unique MSP - denoted by both the mspid as well as a unique root/intermediate certificate authority.
Endorsement policies for chaincode are typically based on orgs as well (via their mspids). When a peer endorses a chaincode transaction, as @yacovm stated it signs the endorsement and includes it's public key (X509 certificate) and MSPID in the proposal response.
As you know, the client collects, packages and sends the endorsement responses to the orderer which then sends blocks / transactions to the peers for validation and commitment.
Each peer than checks to make sure that all the signatures are valid. As mentioned, the public keys are included for each signature. But the peer also checks to make sure that each certificate was actually issued by the MSPID the endorser claims to be part of. After that, the peer checks to make sure that there are enough signatures from the appropriate MSPIDs (orgs) to meet the endorsement policy
iamprem (Thu, 30 Nov 2017 21:56:43 GMT):
Has joined the channel.
ArnabChatterjee (Fri, 01 Dec 2017 08:26:57 GMT):
Has joined the channel.
bh4rtp (Fri, 01 Dec 2017 09:06:38 GMT):
@mastersingh24 your descriptions are clear and helpful.
handasontam (Fri, 01 Dec 2017 10:16:19 GMT):
@mastersingh24 Thx a lot!
bizhenchao1201 (Sun, 03 Dec 2017 09:33:07 GMT):
Has joined the channel.
mp (Mon, 04 Dec 2017 21:18:46 GMT):
Has joined the channel.
Marshalll (Tue, 05 Dec 2017 10:19:12 GMT):
Has joined the channel.
muasif80 (Wed, 06 Dec 2017 11:46:05 GMT):
Clipboard - December 6, 2017 4:46 PM
muasif80 (Wed, 06 Dec 2017 12:22:29 GMT):
Has left the channel.
vudathasaiomkar (Thu, 07 Dec 2017 07:04:00 GMT):
Has joined the channel.
oralzb (Fri, 08 Dec 2017 15:36:56 GMT):
Has joined the channel.
nehirakdag (Sun, 10 Dec 2017 04:55:40 GMT):
Has joined the channel.
blw (Mon, 11 Dec 2017 03:12:52 GMT):
Hi all, I'm trying to generate some expired certs for a unit test for the MSP, and I keep running into this error: `KeyMaterial not found in SigningIdentityInfo`, which seems to indicate that a matching private key can not be found for the provided public key. What should I do to fix this? Thanks
yacovm (Mon, 11 Dec 2017 07:24:03 GMT):
@blw you need to set the name of the key to be the SKI of the certificate.
yacovm (Mon, 11 Dec 2017 07:24:24 GMT):
you can just use cryptogen for that though with temporarily setting the date backwards
elie (Mon, 11 Dec 2017 10:42:17 GMT):
Has joined the channel.
vu3mmg (Mon, 11 Dec 2017 13:25:33 GMT):
How do I make fabric-ca server to serve 3rd party CA certificate
vu3mmg (Mon, 11 Dec 2017 15:24:44 GMT):
@yacovm do you have some idea about , practically configuring fabric-ca to act as intermediate CAs of well known CAs
yacovm (Mon, 11 Dec 2017 15:25:04 GMT):
no, perhaps ask in #fabric-ca ?
vu3mmg (Mon, 11 Dec 2017 15:25:12 GMT):
ok
blw (Mon, 11 Dec 2017 16:00:58 GMT):
@yacovm I've tried using cryptogen, and setting the MSP dir to the generated admin and user directories, respectively. I'm still seeing the same error though. Is there a specific name field I need to add to the crypto-config.yml?
yacovm (Mon, 11 Dec 2017 16:01:29 GMT):
you're trying to use cryptogen to generate the certs and it doesn't work?
blw (Mon, 11 Dec 2017 16:02:10 GMT):
That's what it seems like, but I could be doing something wrong...
yacovm (Mon, 11 Dec 2017 16:02:46 GMT):
have you tried `./cryptogen --showtemplate` ?
yacovm (Mon, 11 Dec 2017 16:02:50 GMT):
or something like this
blw (Mon, 11 Dec 2017 16:06:21 GMT):
I just ran that. I don't see anything wrong with the template
blw (Mon, 11 Dec 2017 16:06:38 GMT):
```# ---------------------------------------------------------------------------
# "OrdererOrgs" - Definition of organizations managing orderer nodes
# ---------------------------------------------------------------------------
OrdererOrgs:
# ---------------------------------------------------------------------------
# Orderer
# ---------------------------------------------------------------------------
- Name: Orderer
Domain: example.com
# ---------------------------------------------------------------------------
# "Specs" - See PeerOrgs below for complete description
# ---------------------------------------------------------------------------
Specs:
- Hostname: orderer
```
blw (Mon, 11 Dec 2017 16:06:57 GMT):
```
# ---------------------------------------------------------------------------
# "PeerOrgs" - Definition of organizations managing peer nodes
# ---------------------------------------------------------------------------
PeerOrgs:
# ---------------------------------------------------------------------------
# Org1
# ---------------------------------------------------------------------------
- Name: Org1
Domain: org1.example.com
# ---------------------------------------------------------------------------
# "CA"
# ---------------------------------------------------------------------------
# Uncomment this section to enable the explicit definition of the CA for this
# organization. This entry is a Spec. See "Specs" section below for details.
# ---------------------------------------------------------------------------
# CA:
# Hostname: ca # implicitly ca.org1.example.com
# Country: US
# Province: California
# Locality: San Francisco
# OrganizationalUnit: Hyperledger Fabric
# StreetAddress: address for org # default nil
# PostalCode: postalCode for org # default nil
# ---------------------------------------------------------------------------
# "Specs"
# ---------------------------------------------------------------------------
# Uncomment this section to enable the explicit definition of hosts in your
# configuration. Most users will want to use Template, below
#
# Specs is an array of Spec entries. Each Spec entry consists of two fields:
# - Hostname: (Required) The desired hostname, sans the domain.
# - CommonName: (Optional) Specifies the template or explicit override for
# the CN. By default, this is the template:
#
# "{{.Hostname}}.{{.Domain}}"
#
# which obtains its values from the Spec.Hostname and
# Org.Domain, respectively.
# - SANS: (Optional) Specifies one or more Subject Alternative Names
# to be set in the resulting x509. Accepts template
# variables {{.Hostname}}, {{.Domain}}, {{.CommonName}}. IP
# addresses provided here will be properly recognized. Other
# values will be taken as DNS names.
# NOTE: Two implicit entries are created for you:
# - {{ .CommonName }}
# - {{ .Hostname }}
# ---------------------------------------------------------------------------
# Specs:
# - Hostname: foo # implicitly "foo.org1.example.com"
# CommonName: foo27.org5.example.com # overrides Hostname-based FQDN set above
# SANS:
# - "bar.{{.Domain}}"
# - "altfoo.{{.Domain}}"
# - "{{.Hostname}}.org6.net"
# - 172.16.10.31
# - Hostname: bar
# - Hostname: baz
# ---------------------------------------------------------------------------
# "Template"
# ---------------------------------------------------------------------------
# Allows for the definition of 1 or more hosts that are created sequentially
# from a template. By default, this looks like "peer%d" from 0 to Count-1.
# You may override the number of nodes (Count), the starting index (Start)
# or the template used to construct the name (Hostname).
#
# Note: Template and Specs are not mutually exclusive. You may define both
# sections and the aggregate nodes will be created for you. Take care with
# name collisions
# ---------------------------------------------------------------------------
Template:
Count: 1
# Start: 5
# Hostname: {{.Prefix}}{{.Index}} # default
# SANS:
# - "{{.Hostname}}.alt.{{.Domain}}"
# ---------------------------------------------------------------------------
# "Users"
# ---------------------------------------------------------------------------
# Count: The number of user accounts _in addition_ to Admin
# ---------------------------------------------------------------------------
Users:
Count: 1
# ---------------------------------------------------------------------------
# Org2: See "Org1" for full specification
# ---------------------------------------------------------------------------
- Name: Org2
Domain: org2.example.com
Template:
Count: 1
Users:
Count: 1```
yacovm (Mon, 11 Dec 2017 16:07:58 GMT):
please don't paste walls of text big as the wall of china here
yacovm (Mon, 11 Dec 2017 16:08:04 GMT):
use pastebin or a similar service
blw (Mon, 11 Dec 2017 16:08:12 GMT):
sorry, my mistake
yacovm (Mon, 11 Dec 2017 16:08:28 GMT):
so you say you outputted this to a file
yacovm (Mon, 11 Dec 2017 16:08:33 GMT):
then ran cryptogen on this file
yacovm (Mon, 11 Dec 2017 16:08:35 GMT):
and it didn't work?
blw (Mon, 11 Dec 2017 16:11:11 GMT):
That's correct
yacovm (Mon, 11 Dec 2017 16:12:32 GMT):
lets take this to direct messages
alexandra_g (Mon, 11 Dec 2017 18:28:30 GMT):
Has joined the channel.
guolidong (Tue, 12 Dec 2017 05:57:30 GMT):
Has joined the channel.
DarshanBc (Tue, 12 Dec 2017 11:55:56 GMT):
Hi I am trying to add org3 on my network I am folowing youtube video by @nickgaski but while executing `export FABRIC_CFG_PATH=$PWD && ../../bin/configtxgen -printOrg Org3MSP > ../channel-artifacts/org3.json` I am getting an error `flag provided but not defined: -printOrg`
nickgaski (Tue, 12 Dec 2017 13:08:07 GMT):
@DarshanBc - make sure your configtxgen utility is up to date. My guess is you have an older version. You want 1.1-preview.
DarshanBc (Tue, 12 Dec 2017 13:09:56 GMT):
Ok
PetrVlasekCA (Tue, 12 Dec 2017 16:49:46 GMT):
Has joined the channel.
DarshanBc (Wed, 13 Dec 2017 05:55:15 GMT):
Is it recommended to have a cli container in production environment?
jaswanth (Wed, 13 Dec 2017 10:07:37 GMT):
Hi all am trying to generate a genesis block .. with `../bin/configtxgen -profile GetInfoOrgsOrdererGenesis -outputBlock ./genesis.block` command but am getting an error as ```2017-12-13 15:32:05.346 IST [common/tools/configtxgen] main -> INFO 001 Loading configuration
2017-12-13 15:32:05.346 IST [common/tools/configtxgen/localconfig] Load -> CRIT 002 Error reading configuration: Unsupported Config Type ""
2017-12-13 15:32:05.346 IST [common/tools/configtxgen] func1 -> ERRO 003 Could not find configtx.yaml. Please make sure that FABRIC_CFG_PATH is set to a path which contains configtx.yaml```
my `FABRIC_CFG_PATH` is also set to the folder where it has `configtx.yaml`
jaswanth (Wed, 13 Dec 2017 10:07:37 GMT):
Hi all am trying to generate a genesis block .. with `sudo ../bin/configtxgen -profile GetInfoOrgsOrdererGenesis -outputBlock ./genesis.block` command but am getting an error as ```2017-12-13 15:32:05.346 IST [common/tools/configtxgen] main -> INFO 001 Loading configuration
2017-12-13 15:32:05.346 IST [common/tools/configtxgen/localconfig] Load -> CRIT 002 Error reading configuration: Unsupported Config Type ""
2017-12-13 15:32:05.346 IST [common/tools/configtxgen] func1 -> ERRO 003 Could not find configtx.yaml. Please make sure that FABRIC_CFG_PATH is set to a path which contains configtx.yaml```
my `FABRIC_CFG_PATH` is also set to the folder where it has `configtx.yaml`
Vadim (Wed, 13 Dec 2017 10:09:52 GMT):
@jaswanth don't use sudo
jaswanth (Wed, 13 Dec 2017 10:10:27 GMT):
with out sudo iam getting the below error ``` Error creating channel group: could not create consortiums group: failed to create consortium SampleConsortium: failed to create consortium org: 1 - Error loading MSP configuration for org: unversitiesMSP: could not load a valid ca certificate from directory /home/jaswanth/goProjects/src/github.com/Dev_setup_v2/artifacts/channel/crypto-config/peerOrganizations/unversities.example.com/msp/cacerts: stat /home/jaswanth/goProjects/src/github.com/Dev_setup_v2/artifacts/channel/crypto-config/peerOrganizations/unversities.example.com/msp/cacerts: no such file or directory```
Vadim (Wed, 13 Dec 2017 10:11:08 GMT):
@jaswanth it tells you that the directory does not exists
Vadim (Wed, 13 Dec 2017 10:11:08 GMT):
@jaswanth it tells you that the directory does not exist
jaswanth (Wed, 13 Dec 2017 10:11:38 GMT):
but i can see the `ca.unversities.examole.com` in the cacerts
Vadim (Wed, 13 Dec 2017 10:12:40 GMT):
does what does `ls /home/jaswanth/goProjects/src/github.com/Dev_setup_v2/artifacts/channel/crypto-config/peerOrganizations/unversities.example.com/msp/cacerts` show?
Vadim (Wed, 13 Dec 2017 10:12:40 GMT):
what does `ls /home/jaswanth/goProjects/src/github.com/Dev_setup_v2/artifacts/channel/crypto-config/peerOrganizations/unversities.example.com/msp/cacerts` show?
jaswanth (Wed, 13 Dec 2017 10:16:22 GMT):
no its not showing .. but i have the `cacerts` folder in `goProjects/src/github.com/Dev_setup_v2/artifacts/channel/crypto-config/peerOrganizations/unversities.example.com/msp/cacerts`
jaswanth (Wed, 13 Dec 2017 10:16:22 GMT):
@Vadim no its not showing .. but i have the `cacerts` folder in `goProjects/src/github.com/Dev_setup_v2/artifacts/channel/crypto-config/peerOrganizations/unversities.example.com/msp/cacerts`
Vadim (Wed, 13 Dec 2017 10:17:01 GMT):
it's not showing what?
Vadim (Wed, 13 Dec 2017 10:17:18 GMT):
bottom line, the path is wrong
DarshanBc (Wed, 13 Dec 2017 10:51:55 GMT):
Since working with cli container is not recomeneded in production environment how to add an org dynamically without using CLI container
Stecec (Wed, 13 Dec 2017 11:20:25 GMT):
Has joined the channel.
Stecec (Wed, 13 Dec 2017 11:27:54 GMT):
Hi, I'm working on the file crypto-config.yaml of "first-network" example. What is the difference between an "Admin" and the "Users" defined by the variable "Count" define under the comment "Count: The number of user accounts _in addition_ to Admin". Is possible/make sense to have a "PeerOrgs" without an "Admin"? Where is possible to find documentation about the Admin and it capability?
fabcan (Wed, 13 Dec 2017 11:49:09 GMT):
Has joined the channel.
van0303 (Thu, 14 Dec 2017 06:11:20 GMT):
Has joined the channel.
Pardha (Thu, 14 Dec 2017 15:28:29 GMT):
Has joined the channel.
Roger12 1 (Thu, 14 Dec 2017 16:21:14 GMT):
Has joined the channel.
Roger12 1 (Thu, 14 Dec 2017 16:33:13 GMT):
hi, how to edit crypto config yaml file to generate crypto for four organization and also wants to change the name of organization from org1 to something else i.e instead of org1 I would like to have name like 'Unisef' and also wants to change domain from example.com to "KPLO.com" .so, Is it possible to do this in hyperledger 1.0 ??? because when I tried doing this changes , during user enroll i'm getting error : unable to fine the keyvaulestore. and when I'll again change the organization name to default i.e just 'org1' and domain to 'example.com'. Then everything works fine..? So what I'm trying to do is that thing is possible or not??? I want my network peer should look like Unisef.KPLO.com instead of org1.example.com?? Pls help
Roger12 1 (Thu, 14 Dec 2017 18:18:23 GMT):
Hi How to generate custom crypto-config file Fabric V1.0?
blw (Fri, 15 Dec 2017 15:14:52 GMT):
Hi all, I'm trying to generate some expired certs for a unit test. Is there somewhere in cryptogen's crypto-config where I can specify an expiration date?
yacovm (Fri, 15 Dec 2017 15:17:25 GMT):
@blw Ben, you can just go to the cryptogen code and put custom date
yacovm (Fri, 15 Dec 2017 15:17:28 GMT):
and then recompile it
blw (Fri, 15 Dec 2017 15:17:47 GMT):
Ok great, thanks
DarshanBc (Fri, 15 Dec 2017 16:48:47 GMT):
There are 2org which access same key in a dB but members in one org should not be able to look at any txn done by members of other org how to do it
DarshanBc (Fri, 15 Dec 2017 16:49:48 GMT):
If I keep both orgs in 2different channels then key cannot be shared how to go about this
blw (Sat, 16 Dec 2017 17:27:19 GMT):
Hi all
I've noticed that when I run the following code, the signcerts path gets updated to the provided directory, but the keystore path remains at it's initial value. This can cause an `KeyMaterial not found in SigningIdentityInfo` error, because the public keys in the new path might now correspond with the private keys in the old path. Is this expected behavior?
```
conf, err := msp.GetLocalMspConfig(dir, bccspConfig, mspID)
if err != nil {
return err
}
localMSP := GetLocalMSP()
err = localMSP.Setup(conf)
```
yacovm (Sat, 16 Dec 2017 17:39:16 GMT):
I'm not sure but why not use: https://github.com/hyperledger/fabric/blob/master/msp/msp_test.go#L1012-L1027 ?
blw (Sat, 16 Dec 2017 18:01:50 GMT):
That method is private in the msp package, and the test I'm writing is in mgmt. I can't move the test to the msp package either, because importing mgmt in the msp package causes an import cycle
yacovm (Sat, 16 Dec 2017 18:53:39 GMT):
oh... hmmm
yacovm (Sat, 16 Dec 2017 18:54:23 GMT):
wait, hold on
yacovm (Sat, 16 Dec 2017 18:54:35 GMT):
can't the code be in the msp package, @blw ?
yacovm (Sat, 16 Dec 2017 18:54:40 GMT):
that'll solve it no?
yacovm (Sat, 16 Dec 2017 18:55:32 GMT):
maybe `Setup` return an error?
yacovm (Sat, 16 Dec 2017 18:55:46 GMT):
in case of a BCCSP MSP that is
blw (Sat, 16 Dec 2017 19:15:51 GMT):
I tried that, but if I move the unit test to the msp package, then I'll have to import mgmt into msp because the code I want to test is in mgmt, and that will also cause an import cycle
blw (Sat, 16 Dec 2017 19:16:48 GMT):
Unless you're talking about moving `LoadLocalMsp`, the function I'm testing, to msp?
blw (Sat, 16 Dec 2017 19:18:30 GMT):
that would be an interface change though... that might be too big a change to make for this bug
yacovm (Sat, 16 Dec 2017 19:58:20 GMT):
no, I'm saying you test it in another way, everything in the `msp` package @blw
yacovm (Sat, 16 Dec 2017 19:58:20 GMT):
no, I'm saying you solve the bug it in another way, everything in the `msp` package @blw
yacovm (Sat, 16 Dec 2017 19:58:35 GMT):
and then also have the UT there
yacovm (Sat, 16 Dec 2017 19:58:53 GMT):
the code you want to test is not actually in mgmt if we think about it
yacovm (Sat, 16 Dec 2017 19:59:09 GMT):
the signing identity is implemented in the msp package
blw (Sat, 16 Dec 2017 23:30:15 GMT):
@yacovm ah ok, I'll try that
blw (Sat, 16 Dec 2017 23:30:17 GMT):
thanks
sasiedu (Sun, 17 Dec 2017 09:40:54 GMT):
hi guys, does fabric-ca use SECP256k1 for encoding Private Keys as PEMs?
bruteforced (Sun, 17 Dec 2017 15:02:33 GMT):
Has joined the channel.
iyerrama25 (Sun, 17 Dec 2017 17:34:03 GMT):
Has joined the channel.
rrbaker (Mon, 18 Dec 2017 19:30:51 GMT):
Has joined the channel.
zhishui (Tue, 19 Dec 2017 08:09:47 GMT):
Has joined the channel.
mastersingh24 (Tue, 19 Dec 2017 10:19:19 GMT):
Fabric currently only uses NIST elliptic curves - P224,P256,P384 and P521
farhan3 (Tue, 19 Dec 2017 19:45:56 GMT):
@mastersingh24 Is it possible to change the Cipher suite for TLS?
farhan3 (Tue, 19 Dec 2017 19:48:51 GMT):
Or if anyone else knows if it's possible to change the Cipher suite settings for TLS
yacovm (Tue, 19 Dec 2017 19:58:19 GMT):
@farhan3 from what I see - the golang TLS supports:
```
TLS_RSA_WITH_RC4_128_SHA uint16 = 0x0005
TLS_RSA_WITH_3DES_EDE_CBC_SHA uint16 = 0x000a
TLS_RSA_WITH_AES_128_CBC_SHA uint16 = 0x002f
TLS_RSA_WITH_AES_256_CBC_SHA uint16 = 0x0035
TLS_RSA_WITH_AES_128_CBC_SHA256 uint16 = 0x003c
TLS_RSA_WITH_AES_128_GCM_SHA256 uint16 = 0x009c
TLS_RSA_WITH_AES_256_GCM_SHA384 uint16 = 0x009d
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA uint16 = 0xc007
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA uint16 = 0xc009
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA uint16 = 0xc00a
TLS_ECDHE_RSA_WITH_RC4_128_SHA uint16 = 0xc011
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA uint16 = 0xc012
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA uint16 = 0xc013
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA uint16 = 0xc014
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 uint16 = 0xc023
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 uint16 = 0xc027
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 uint16 = 0xc02f
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 uint16 = 0xc02b
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 uint16 = 0xc030
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 uint16 = 0xc02c
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 uint16 = 0xcca8
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 uint16 = 0xcca9
yacovm (Tue, 19 Dec 2017 19:58:30 GMT):
I don't think we have such a config in the fabric though
berestet (Tue, 19 Dec 2017 20:35:47 GMT):
@yacovm security scanners in our environment are flagging `3DES` ciphers supported by the fabric as a security threat, specifically: ``` ECDHE-RSA-DES-CBC3-SHA Kx=ECDH Au=RSA Enc=3DES-CBC(168) Mac=SHA1
DES-CBC3-SHA Kx=RSA Au=RSA Enc=3DES-CBC(168) Mac=SHA1```
Doing some research, other golang middleware (e.g. Kubernetes) are hitting similar issues and hence allowing masking of the weak/medium ciphers like `3DES` - as per: https://github.com/kubernetes/kubernetes/issues/41038
Can we request fabric take similar approach?
farhan3 (Tue, 19 Dec 2017 21:09:40 GMT):
Similar to what Kubernetes is doing, the change would be required here: https://github.com/hyperledger/fabric/blob/release/core/comm/server.go#L139
```
grpcServer.tlsConfig = &tls.Config{
Certificates: certificates,
SessionTicketsDisabled: true,
}
```
The `CipherSuites` option would need to be set (https://golang.org/pkg/crypto/tls/#Config):
```
grpcServer.tlsConfig = &tls.Config{
Certificates: certificates,
SessionTicketsDisabled: true,
}
```
farhan3 (Tue, 19 Dec 2017 21:09:40 GMT):
Similar to what Kubernetes is doing, the change would be required here: https://github.com/hyperledger/fabric/blob/release/core/comm/server.go#L139
```
grpcServer.tlsConfig = &tls.Config{
Certificates: certificates,
SessionTicketsDisabled: true,
}
```
The `CipherSuites` option would need to be set (https://golang.org/pkg/crypto/tls/#Config):
```
grpcServer.tlsConfig = &tls.Config{
Certificates: certificates,
SessionTicketsDisabled: true,
}
```
farhan3 (Tue, 19 Dec 2017 21:09:40 GMT):
Similar to what Kubernetes is doing, the change would be required here: https://github.com/hyperledger/fabric/blob/release/core/comm/server.go#L139
```
grpcServer.tlsConfig = &tls.Config{
Certificates: certificates,
SessionTicketsDisabled: true,
}
```
The `CipherSuites` option would need to be set (https://golang.org/pkg/crypto/tls/#Config):
```
grpcServer.tlsConfig = &tls.Config{
Certificates: certificates,
SessionTicketsDisabled: true,
CipherSuites: //list of suites
farhan3 (Tue, 19 Dec 2017 21:09:40 GMT):
Similar to what Kubernetes is doing, the change would be required here: https://github.com/hyperledger/fabric/blob/release/core/comm/server.go#L139
```
grpcServer.tlsConfig = &tls.Config{
Certificates: certificates,
SessionTicketsDisabled: true,
}
```
The `CipherSuites` option would need to be set (https://golang.org/pkg/crypto/tls/#Config):
```
grpcServer.tlsConfig = &tls.Config{
Certificates: certificates,
SessionTicketsDisabled: true,
CipherSuites: //list of suites
}
```
yacovm (Tue, 19 Dec 2017 22:11:27 GMT):
I guess we can technically but i'd like to hear opinions of @adc , @elli-androulaki and @aso
aso (Wed, 20 Dec 2017 07:10:35 GMT):
that actually makes sense - though I'd recommend the following: default with a secure list of ciphers and permit admin override. Wdyt?
yacovm (Wed, 20 Dec 2017 07:44:39 GMT):
you mean a config override
yacovm (Wed, 20 Dec 2017 07:44:43 GMT):
yes sounds good.
yacovm (Wed, 20 Dec 2017 07:44:43 GMT):
yes sounds good. from what I remember in TLS - the server selects the cipher suites so we can just do that in 1 place in the code and it ripples to the orderer and to the peer
yacovm (Wed, 20 Dec 2017 07:44:54 GMT):
@mastersingh24 wdyt? ^
mastersingh24 (Wed, 20 Dec 2017 17:14:48 GMT):
I was going to select a set of cipher suites
mastersingh24 (Wed, 20 Dec 2017 17:15:23 GMT):
The set is actually more limited when you combine TLS 1.2 with EC as well
mastersingh24 (Wed, 20 Dec 2017 17:15:45 GMT):
I have a few TLS hardening issues to enter
mastersingh24 (Wed, 20 Dec 2017 17:20:08 GMT):
We do this is the NodeSDK today:
```
var defaultCiphers = 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256' +
':ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-GCM-SHA384' +
':ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256' +
':ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384';
```
mastersingh24 (Wed, 20 Dec 2017 17:22:38 GMT):
You can also avoid these by using EC keys rather thn RSA ;) (https://chat.hyperledger.org/channel/fabric-crypto?msg=j6XxsdyoM9cJbrKis) @berestet
mastersingh24 (Wed, 20 Dec 2017 17:22:38 GMT):
You can also avoid these by using EC keys rather than RSA ;) (https://chat.hyperledger.org/channel/fabric-crypto?msg=j6XxsdyoM9cJbrKis) @berestet
yacovm (Wed, 20 Dec 2017 17:23:09 GMT):
I think that bccsp doesn't generate RSA keys anyway, right?
yacovm (Wed, 20 Dec 2017 17:23:27 GMT):
so that means cryptogen *and* fabric-CA don't too
mastersingh24 (Wed, 20 Dec 2017 17:23:30 GMT):
Except we don't use BCCSP for TLS in fabric
yacovm (Wed, 20 Dec 2017 17:23:40 GMT):
in fabric-CA we do....
mastersingh24 (Wed, 20 Dec 2017 17:23:51 GMT):
So it's possible to get them from a 3rd party CA
yacovm (Wed, 20 Dec 2017 17:24:00 GMT):
right
mastersingh24 (Wed, 20 Dec 2017 17:24:19 GMT):
I think for 1.1 we can limit the ciphers to a secure set
mastersingh24 (Wed, 20 Dec 2017 18:19:01 GMT):
@aso @yacovm @farhan3 - https://jira.hyperledger.org/browse/FAB-7525
mastersingh24 (Wed, 20 Dec 2017 18:19:09 GMT):
comment with any changes please
yacovm (Wed, 20 Dec 2017 18:21:44 GMT):
I have a question - so, if the TLS is set to use bccsp (in fabric this isn't the case, but it can be, right?)
then I think that the server might pick a cipher suite that isn't supported by TLS, like something with RSA and this would only be discovered at runtime, no?
yacovm (Wed, 20 Dec 2017 18:21:44 GMT):
I have a question - so, if the TLS is set to use bccsp (in fabric this isn't the case, but it can be in the future, right?)
then I think that the server might pick a cipher suite that isn't supported by TLS, like something with RSA and this would only be discovered at runtime, no?
yacovm (Wed, 20 Dec 2017 18:24:12 GMT):
@mastersingh24 ^
mastersingh24 (Wed, 20 Dec 2017 18:58:26 GMT):
no - BCCSP only provides the crypto.Signer
mastersingh24 (Wed, 20 Dec 2017 18:58:50 GMT):
basically the private key part of the TLS.Certificate
yacovm (Wed, 20 Dec 2017 19:05:28 GMT):
The private key is used for decryption too
yacovm (Wed, 20 Dec 2017 19:05:28 GMT):
The private key is used for decryption too (of the PMK)
yacovm (Wed, 20 Dec 2017 19:05:36 GMT):
at least this is my understanding
yacovm (Wed, 20 Dec 2017 19:06:15 GMT):
https://golang.org/src/crypto/tls/key_agreement.go
yacovm (Wed, 20 Dec 2017 19:06:26 GMT):
```
priv, ok := cert.PrivateKey.(crypto.Decrypter)
if !ok {
return nil, errors.New("tls: certificate private key does not implement crypto.Decrypter")
}
yacovm (Wed, 20 Dec 2017 19:06:26 GMT):
```
priv, ok := cert.PrivateKey.(crypto.Decrypter)
if !ok {
return nil, errors.New("tls: certificate private key does not implement crypto.Decrypter")
}
yacovm (Wed, 20 Dec 2017 19:07:20 GMT):
But I think I am just missing what you're saying
ashutosh_kumar (Wed, 20 Dec 2017 20:02:49 GMT):
@yacovm , the code that you use is for TLS negotiation where encryption/decryption takes place. @mastersingh24 is right in his statement on bccsp.
yacovm (Wed, 20 Dec 2017 20:08:24 GMT):
Can you elaborate please?
mastersingh24 (Wed, 20 Dec 2017 20:27:19 GMT):
@yacovm - What I was trying to say is that the cipher suite used by TLS will be independent of whether or not we use BCCSP to load the TLS certificates. The only mismatch which can happen is if the BCCSP config produces an RSA key pair and the cipher sites are set to an ECDSA-only family
mastersingh24 (Wed, 20 Dec 2017 20:27:51 GMT):
And the same can happen is you use file-based RSA keypair and select the wrong family of cipher suites
mastersingh24 (Wed, 20 Dec 2017 20:28:01 GMT):
But BCCSP does not provide the list of cipher suites
mastersingh24 (Wed, 20 Dec 2017 20:28:37 GMT):
I suppose if the BCCSP impl did not support one of the algorithms required there would be an issue as well
mastersingh24 (Wed, 20 Dec 2017 20:28:51 GMT):
But the cipher choice is independent
yacovm (Wed, 20 Dec 2017 20:28:58 GMT):
What if you configure an rsa cipher suite to be used? and then bccsp will need to do RSA which it does not support no?
mastersingh24 (Wed, 20 Dec 2017 20:29:51 GMT):
That's right. But the same thing would happen is you selected RSA cipher suite and configured EC X509 keypair
mastersingh24 (Wed, 20 Dec 2017 20:29:51 GMT):
That's right. But the same thing would happen if you selected RSA cipher suite and configured EC X509 keypair and vice versa
mastersingh24 (Wed, 20 Dec 2017 20:31:43 GMT):
I thought you were saying that BCCSP would be determining the list of ciphers. I guess you were saying it could limit which ciphers on the list could be used at runtime. And that's true but also true if you used pure file-based key pair as well
yacovm (Wed, 20 Dec 2017 20:32:01 GMT):
You're right. I didn't think about it
yacovm (Wed, 20 Dec 2017 20:32:12 GMT):
so basically, the TLS implementation has a way of knowing which cipher suite to pick
yacovm (Wed, 20 Dec 2017 20:32:16 GMT):
based on the key type
yacovm (Wed, 20 Dec 2017 20:32:22 GMT):
right at the beginning of the handshake
mastersingh24 (Wed, 20 Dec 2017 20:32:28 GMT):
yah
yacovm (Wed, 20 Dec 2017 20:32:34 GMT):
makes sense.
LefKok (Fri, 22 Dec 2017 21:36:39 GMT):
Has joined the channel.
Roger (Wed, 27 Dec 2017 03:28:26 GMT):
Has joined the channel.
JeroenDePrest (Thu, 28 Dec 2017 14:53:29 GMT):
Has joined the channel.
handasontam (Fri, 29 Dec 2017 08:25:45 GMT):
hi everyone, is it possible to set up tls connection between kafka and zookeeper using the docker image hyperledger/fabric-kafka and hyperledger/fabric-zookeeper? thank you.
gurel (Wed, 03 Jan 2018 17:41:10 GMT):
Has joined the channel.
allonblocks21 (Thu, 04 Jan 2018 11:07:33 GMT):
Has joined the channel.
antoniovassell (Thu, 04 Jan 2018 14:23:43 GMT):
Has joined the channel.
Glen (Mon, 08 Jan 2018 01:37:31 GMT):
Hi, all @mastersingh24 and @yacovm , is Identity Mixer supported now in Farbic, how to test it?thanks
tamycova (Tue, 09 Jan 2018 11:39:40 GMT):
Has joined the channel.
protip (Tue, 09 Jan 2018 15:34:58 GMT):
Has joined the channel.
aiur (Tue, 09 Jan 2018 18:30:32 GMT):
Has joined the channel.
dgale (Tue, 09 Jan 2018 23:56:53 GMT):
Has joined the channel.
shubhammangla (Wed, 10 Jan 2018 10:44:29 GMT):
Hi all, a quick question. I am getting an error when I am making the peer join a channel using the tx file. `2018-01-10 10:39:26.533 UTC [grpc] Printf -> DEBU 010 transport: http2Client.notifyError got notified that the client transport was broken read tcp 172.18.0.2:50096->172.18.0.4:7050: read: connection reset by peer.
2018-01-10 10:39:26.534 UTC [grpc] Printf -> DEBU 011 transport: http2Client.notifyError got notified that the client transport was broken read tcp 172.18.0.2:50100->172.18.0.4:7050: read: connection reset by peer.
2018-01-10 10:39:26.534 UTC [grpc] Printf -> DEBU 012 transport: http2Client.notifyError got notified that the client transport was broken unexpected EOF.
Error: rpc error: code = Internal desc = transport is closing
2018-01-10 10:39:26.534 UTC [grpc] Printf -> DEBU 013 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: Error while dialing dial tcp: operation was canceled"; Reconnecting to {orderer.example.com:7050
shubhammangla (Wed, 10 Jan 2018 10:44:29 GMT):
Hi all, a quick question. I am getting an error when I am making the peer join a channel using the tx file. ```2018-01-10 10:39:26.533 UTC [grpc] Printf -> DEBU 010 transport: http2Client.notifyError got notified that the client transport was broken read tcp 172.18.0.2:50096->172.18.0.4:7050: read: connection reset by peer.
2018-01-10 10:39:26.534 UTC [grpc] Printf -> DEBU 011 transport: http2Client.notifyError got notified that the client transport was broken read tcp 172.18.0.2:50100->172.18.0.4:7050: read: connection reset by peer.
2018-01-10 10:39:26.534 UTC [grpc] Printf -> DEBU 012 transport: http2Client.notifyError got notified that the client transport was broken unexpected EOF.
Error: rpc error: code = Internal desc = transport is closing
2018-01-10 10:39:26.534 UTC [grpc] Printf -> DEBU 013 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: Error while dialing dial tcp: operation was canceled"; Reconnecting to {orderer.example.com:7050
shubhammangla (Wed, 10 Jan 2018 10:44:54 GMT):
I confirmed that the orderer is running.
shubhammangla (Wed, 10 Jan 2018 10:45:05 GMT):
`
05:40$docker ps -a | grep orderer
c1975c4f5056 hyperledger/fabric-orderer:x86_64-1.0.3 "orderer" 37 minutes ago Up 37 minutes 0.0.0.0:7050->7050/tcp orderer.example.com
05:42$
`
shubhammangla (Wed, 10 Jan 2018 10:45:05 GMT):
`05:40$docker ps -a | grep orderer
c1975c4f5056 hyperledger/fabric-orderer:x86_64-1.0.3 "orderer" 37 minutes ago Up 37 minutes 0.0.0.0:7050->7050/tcp orderer.example.com
05:42$`
shubhammangla (Wed, 10 Jan 2018 10:45:05 GMT):
```05:40$docker ps -a | grep orderer
c1975c4f5056 hyperledger/fabric-orderer:x86_64-1.0.3 "orderer" 37 minutes ago Up 37 minutes 0.0.0.0:7050->7050/tcp orderer.example.com
05:42$```
shubhammangla (Wed, 10 Jan 2018 10:45:36 GMT):
Anybody who has come across this issue before?
niteshsolanki (Wed, 10 Jan 2018 11:39:07 GMT):
Hi, do every peer has rootCA certificate of others org present in the channel to verify chain of trust?
cotofei (Wed, 10 Jan 2018 13:45:12 GMT):
Has joined the channel.
jyellick (Wed, 10 Jan 2018 22:22:15 GMT):
@niteshsolanki I ended up responding to you in DM, but yes, through the channel configuration blocks (including the genesis block used to join a channel) the peer learns of the root CAs for all participants and may verify signatures from all identities in the network.
niteshsolanki (Thu, 11 Jan 2018 02:13:30 GMT):
Thanks @jyellick
nhrishi (Fri, 12 Jan 2018 06:50:27 GMT):
'''test'''
nhrishi (Fri, 12 Jan 2018 06:50:39 GMT):
```test```
shubhammangla (Fri, 12 Jan 2018 10:27:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=F6HhCGpRJDBQJS6kk) Finally found the problem. I added ```--tls=true``` to the peer join command and that took care of this. Just adding an update here so that it helps somebody else who comes across this issue.
JOYELIN (Tue, 16 Jan 2018 08:23:49 GMT):
Has joined the channel.
joaquimpedrooliveira (Tue, 16 Jan 2018 14:44:19 GMT):
Has joined the channel.
joaquimpedrooliveira (Tue, 16 Jan 2018 14:44:34 GMT):
Hello, all! Where can I find `OpenSSL` commands to generate all Peer MSP certificates needed? (admincerts, cacerts, keystore, signcerts, tlscerts)
joaquimpedrooliveira (Tue, 16 Jan 2018 14:45:57 GMT):
I'm trying to add a new peer to an existing network, so I cannot use `cryptogen` because it generates a new CA key to sign the peer certs
yacovm (Tue, 16 Jan 2018 14:52:00 GMT):
you can actually use `cryptogen` to extend
yacovm (Tue, 16 Jan 2018 14:52:04 GMT):
it has a sub-command
yacovm (Tue, 16 Jan 2018 14:52:06 GMT):
@joaquimpedrooliveira
joaquimpedrooliveira (Tue, 16 Jan 2018 16:53:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=XasnHqz6unXNPCqqC) @yacovm which one? I only see the following after `cryptogen help`:
```Commands:
help [
joaquimpedrooliveira (Tue, 16 Jan 2018 16:54:01 GMT):
I'm using version 1.0.2
yacovm (Tue, 16 Jan 2018 16:57:29 GMT):
1.0.2 is so 2017
yacovm (Tue, 16 Jan 2018 16:57:32 GMT):
Use v1.1
joaquimpedrooliveira (Tue, 16 Jan 2018 16:57:37 GMT):
:D
joaquimpedrooliveira (Tue, 16 Jan 2018 16:57:50 GMT):
when was this feature added to `cryptogen`?
yacovm (Tue, 16 Jan 2018 16:58:13 GMT):
A few weeks ago or a month ago
joaquimpedrooliveira (Tue, 16 Jan 2018 16:59:05 GMT):
Thanks!
joaquimpedrooliveira (Tue, 16 Jan 2018 16:59:23 GMT):
But if I want to use OpenSSL, where can I find the commands?
yacovm (Tue, 16 Jan 2018 16:59:33 GMT):
You need to use a script
yacovm (Tue, 16 Jan 2018 16:59:51 GMT):
@aso had a script once
yacovm (Tue, 16 Jan 2018 17:00:00 GMT):
Maybe he can post it here again
yacovm (Tue, 16 Jan 2018 17:00:16 GMT):
Of he sees this message and is available
yacovm (Tue, 16 Jan 2018 17:00:25 GMT):
Otherwise just google
joaquimpedrooliveira (Tue, 16 Jan 2018 17:00:26 GMT):
@aso , can you help me on this?
joaquimpedrooliveira (Tue, 16 Jan 2018 17:00:41 GMT):
I've been googling for two days without success :(
joaquimpedrooliveira (Tue, 16 Jan 2018 17:11:55 GMT):
@yacovm , is 1.1 final
joaquimpedrooliveira (Tue, 16 Jan 2018 17:11:55 GMT):
@yacovm , is 1.1 final?
joaquimpedrooliveira (Tue, 16 Jan 2018 17:11:56 GMT):
?
joaquimpedrooliveira (Tue, 16 Jan 2018 17:12:58 GMT):
I mean stable
joaquimpedrooliveira (Tue, 16 Jan 2018 17:35:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=m7kZgB8g8sDvCGApN) @yacovm Are these the scripts you mentioned?
yacovm (Tue, 16 Jan 2018 17:43:45 GMT):
No but try it can't hurt
AlexTheGreat 1 (Wed, 17 Jan 2018 06:01:59 GMT):
Has joined the channel.
javrevasandeep (Wed, 17 Jan 2018 08:18:55 GMT):
Has joined the channel.
aso (Wed, 17 Jan 2018 15:07:38 GMT):
@joaquimpedrooliveira ping me in pvt and I'll send you the script
jks3462 (Thu, 18 Jan 2018 11:30:33 GMT):
Has joined the channel.
joaquimpedrooliveira (Thu, 18 Jan 2018 12:56:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=PY3LHLi2dDHTcoNNB) @yacovm I downloaded v1.1.0 but couldn't identify this new option:
``` 82474540334@serpro-1531241 ~/projetos/esnec/blockchain/hyperledger/1.1.0/bin ./cryptogen help
usage: cryptogen [
joaquimpedrooliveira (Thu, 18 Jan 2018 12:56:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=PY3LHLi2dDHTcoNNB) @yacovm I downloaded v1.1.0 but couldn't identify this new option:
``` $ ./cryptogen version
cryptogen:
Version: 1.1.0-preview
Go version: go1.9
OS/Arch: linux/amd64
$ ./cryptogen help
usage: cryptogen [
yacovm (Thu, 18 Jan 2018 12:57:03 GMT):
just git clone the fabric repository....
yacovm (Thu, 18 Jan 2018 12:57:05 GMT):
it works for me:
yacovm (Thu, 18 Jan 2018 12:57:13 GMT):
```
yacovm@yacoVM ~/OBC/shared/gopath/src/github.com/hyperledger/fabric (FAB-7567) $ ./build/bin/cryptogen --help
usage: cryptogen [
joaquimpedrooliveira (Thu, 18 Jan 2018 12:59:02 GMT):
It's bleeding edge, isn't it? :)
yacovm (Thu, 18 Jan 2018 13:04:54 GMT):
the bleeding edge is the current branch I'm working on
yacovm (Thu, 18 Jan 2018 13:05:06 GMT):
the cryptogen has stopped bleeding long ago
joaquimpedrooliveira (Thu, 18 Jan 2018 13:10:48 GMT):
:)
joaquimpedrooliveira (Thu, 18 Jan 2018 13:14:05 GMT):
which branch should I build? `master`?
yacovm (Thu, 18 Jan 2018 13:24:13 GMT):
yes
joaquimpedrooliveira (Thu, 18 Jan 2018 13:26:22 GMT):
`vendor/github.com/miekg/pkcs11/pkcs11.go:29:18: fatal error: ltdl.h: No such file or directory`
yacovm (Thu, 18 Jan 2018 13:31:36 GMT):
`make cryptogen` makes you do that?
yacovm (Thu, 18 Jan 2018 13:31:36 GMT):
`make cryptogen` makes you output that?
yacovm (Thu, 18 Jan 2018 13:32:58 GMT):
try to do `sudo apt install libltdl-dev`
yacovm (Thu, 18 Jan 2018 13:33:13 GMT):
I guess maybe we should have a no-pkcs11 build option or something....
yacovm (Thu, 18 Jan 2018 13:33:19 GMT):
though not sure if we'd want that
yacovm (Thu, 18 Jan 2018 13:33:29 GMT):
@joaquimpedrooliveira
joaquimpedrooliveira (Thu, 18 Jan 2018 13:37:54 GMT):
Nevermind. I found the trick in FAB-2854. :)
joaquimpedrooliveira (Thu, 18 Jan 2018 14:04:33 GMT):
@yacovm , what should I provide to `cryptogen extend`? A YAML containing the initial structure plus the new ones or just the new ones?
yacovm (Thu, 18 Jan 2018 14:04:54 GMT):
just do `cryptogen extend --h`
yacovm (Thu, 18 Jan 2018 14:04:56 GMT):
it will tell you
joaquimpedrooliveira (Thu, 18 Jan 2018 14:05:57 GMT):
it's not saying much to me :)
```usage: cryptogen extend [
joaquimpedrooliveira (Thu, 18 Jan 2018 14:06:24 GMT):
oh, I saw.
joaquimpedrooliveira (Thu, 18 Jan 2018 14:06:25 GMT):
Sorry
joaquimpedrooliveira (Thu, 18 Jan 2018 14:06:30 GMT):
`--input`
joaquimpedrooliveira (Thu, 18 Jan 2018 14:06:34 GMT):
need some coffe :)
joaquimpedrooliveira (Thu, 18 Jan 2018 14:07:01 GMT):
so in `--config` I provide only the new elements, is it right?
yacovm (Thu, 18 Jan 2018 14:09:31 GMT):
yeah
yacovm (Thu, 18 Jan 2018 14:09:37 GMT):
and the --input is the "old" layout
yacovm (Thu, 18 Jan 2018 14:09:49 GMT):
the old `crypto-config` directory
bryancan (Thu, 18 Jan 2018 17:57:49 GMT):
Has joined the channel.
joaquimpedrooliveira (Thu, 18 Jan 2018 18:02:04 GMT):
thank you very much!
joaquimpedrooliveira (Thu, 18 Jan 2018 18:04:58 GMT):
@yacovm , I'm getting the following error when starting the new peer: `2018-01-18 18:04:04.972 UTC [main] main -> ERRO 001 Cannot run peer because error when setting up MSP of type bccsp from directory /etc/hyperledger/fabric/msp: the supplied identity is not valid: x509: certificate signed by unknown authority`
yacovm (Thu, 18 Jan 2018 18:05:36 GMT):
oh... really?
yacovm (Thu, 18 Jan 2018 18:06:15 GMT):
wait but how is that possible
yacovm (Thu, 18 Jan 2018 18:06:21 GMT):
the existing files shouldn't change
joaquimpedrooliveira (Thu, 18 Jan 2018 18:06:42 GMT):
The steps I did:
- Started first-network example: ` ./byfn.sh -m up -s couchdb`
- Waited the script that install/instantiate/query the chaincode (`script.sh`) to end
- Updated the config: `cryptogen extend --input=crypto-config --config=crypto-config-new-peer.yaml`
- Started the new peer: `docker-compose -f docker-compose-newpeer.yaml up -d`
yacovm (Thu, 18 Jan 2018 18:06:43 GMT):
I think you did something wron
joaquimpedrooliveira (Thu, 18 Jan 2018 18:06:56 GMT):
Then this message appears in the new peer's logs
yacovm (Thu, 18 Jan 2018 18:07:55 GMT):
is that only for the new peer?
yacovm (Thu, 18 Jan 2018 18:08:00 GMT):
or also for old peers?
joaquimpedrooliveira (Thu, 18 Jan 2018 18:08:24 GMT):
I didn't restarted the old ones. Is it needed?
yacovm (Thu, 18 Jan 2018 18:08:50 GMT):
I don't think so
yacovm (Thu, 18 Jan 2018 18:09:01 GMT):
but I'm asking if that happens for new peers only
yacovm (Thu, 18 Jan 2018 18:09:23 GMT):
did you perhaps make a mistake in the docker-compose yaml file?
yacovm (Thu, 18 Jan 2018 18:09:31 GMT):
I'd bet a copy-paste mistake
joaquimpedrooliveira (Thu, 18 Jan 2018 18:11:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=rrS42TkCDPXNGSi4M) @yacovm I don't see anything similar to this in other peers logs...Just messages related to chaincode execution
joaquimpedrooliveira (Thu, 18 Jan 2018 18:11:42 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=NR6FqxACgHHp5mdam) @yacovm You mean MSP config? Here is the file:
```services:
peer2.org1.example.com:
container_name: peer2.org1.example.com
extends:
file: base/peer-base.yaml
service: peer-base
environment:
- CORE_PEER_ID=peer2.org1.example.com
- CORE_PEER_ADDRESS=peer2.org1.example.com:7051
- CORE_PEER_GOSSIP_EXTERNALENDPOINT=peer2.org1.example.com:7051
- CORE_PEER_GOSSIP_BOOTSTRAP=peer0.org1.example.com:7051
- CORE_PEER_LOCALMSPID=Org1MSP
volumes:
- /var/run/:/host/var/run/
- ./crypto-config/peerOrganizations/org1.example.com/peers/peer2.org1.example.com/msp:/etc/hyperledger/fabric/msp
- ./crypto-config/peerOrganizations/org1.example.com/peers/peer2.org1.example.com/tls:/etc/hyperledger/fabric/tls
ports:
- 11051:7051
- 11053:7053
networks:
- byfn
joaquimpedrooliveira (Thu, 18 Jan 2018 18:12:20 GMT):
the crypto stuff to the new added peer was generated in `./crypto-config/peerOrganizations/org1.example.com/peers/peer2.org1.example.com/`. Is it correct?
yacovm (Thu, 18 Jan 2018 18:13:51 GMT):
seems ok
joaquimpedrooliveira (Thu, 18 Jan 2018 18:14:03 GMT):
To me too :)
joaquimpedrooliveira (Thu, 18 Jan 2018 18:14:48 GMT):
Any tips?
joaquimpedrooliveira (Thu, 18 Jan 2018 18:17:21 GMT):
I noticed something strange. The file `cacerts/ca.org1.example.com-cert.pem` from peer0 and peer1 are identical, but peer2 is not. It's different. I compared using Meld.
yacovm (Thu, 18 Jan 2018 18:17:54 GMT):
hmmmmm
yacovm (Thu, 18 Jan 2018 18:18:07 GMT):
when I reviewed the change set, it was the same :O
joaquimpedrooliveira (Thu, 18 Jan 2018 18:18:08 GMT):
admincerts and tlscacerts are identical in all 3 peers
yacovm (Thu, 18 Jan 2018 18:18:11 GMT):
I tested it
yacovm (Thu, 18 Jan 2018 18:18:41 GMT):
what happens if you copy the ca certificate from the old peers to the new?
joaquimpedrooliveira (Thu, 18 Jan 2018 18:19:05 GMT):
Does it work? I thought the cacert was used to sign peers `signcert` certificate
joaquimpedrooliveira (Thu, 18 Jan 2018 18:19:17 GMT):
Only copying is enough?
yacovm (Thu, 18 Jan 2018 18:19:17 GMT):
it's used to verify
yacovm (Thu, 18 Jan 2018 18:19:23 GMT):
try it
joaquimpedrooliveira (Thu, 18 Jan 2018 18:20:14 GMT):
OK. But just for curiosity, what private key should be used to sign peers `signcert` certificate? Is it the peer private key (`keystore` content)
yacovm (Thu, 18 Jan 2018 18:21:13 GMT):
the CA's
joaquimpedrooliveira (Thu, 18 Jan 2018 18:21:25 GMT):
Same thing: `2018-01-18 18:21:04.221 UTC [main] main -> ERRO 001 Cannot run peer because error when setting up MSP of type bccsp from directory /etc/hyperledger/fabric/msp: the supplied identity is not valid: x509: certificate signed by unknown authority`
joaquimpedrooliveira (Thu, 18 Jan 2018 18:21:37 GMT):
I copied the cacert from peer0
yacovm (Thu, 18 Jan 2018 18:21:38 GMT):
hmmm weird... open a JIRA bug
joaquimpedrooliveira (Thu, 18 Jan 2018 18:22:08 GMT):
Ok!
joaquimpedrooliveira (Thu, 18 Jan 2018 18:30:46 GMT):
I've noticed something: although I'm using `cryptogen 1.1.0-alpha`, which I built locally from git, the `first-network` I'm using is still based on tag `1.0.2`. Does it matter?
joaquimpedrooliveira (Thu, 18 Jan 2018 18:32:57 GMT):
I don't think it does, as `crypto-config` is generated by `cryptgen` and only read by the containers, but...
joaquimpedrooliveira (Thu, 18 Jan 2018 18:32:57 GMT):
I don't think it does, as `crypto-config` is generated by `cryptogen` and only read by the containers, but...
yacovm (Thu, 18 Jan 2018 18:35:49 GMT):
no
joaquimpedrooliveira (Thu, 18 Jan 2018 18:41:34 GMT):
When I just generated the crypto-config content and then updated, it's correct. I think `byfn.sh` is messing up something here.
joaquimpedrooliveira (Thu, 18 Jan 2018 18:41:51 GMT):
I'll check this carefully before opening a JIRA bug
yacovm (Thu, 18 Jan 2018 18:49:09 GMT):
oh, that's reassuring to hear
yacovm (Thu, 18 Jan 2018 18:49:24 GMT):
That means I wasn't hallucinating when I tried it myself
joaquimpedrooliveira (Thu, 18 Jan 2018 18:54:22 GMT):
:joy:
joaquimpedrooliveira (Thu, 18 Jan 2018 18:55:43 GMT):
It's really strange: even though the `which cryptogen` returns the right version (1.1.0-alpha), when called from `byfn.sh generate`, it's generating a different cacert in the new peer.
joaquimpedrooliveira (Thu, 18 Jan 2018 18:55:52 GMT):
I can't understand why
joaquimpedrooliveira (Thu, 18 Jan 2018 18:56:18 GMT):
But when I commented out this step from `byfn.sh` and executed `cryptogen` manually, it worked flawlessly
joaquimpedrooliveira (Thu, 18 Jan 2018 18:56:18 GMT):
But when I commented out this step from `byfn.sh` and executed `cryptogen` manually to generate the initial artifacts, it worked flawlessly
yacovm (Thu, 18 Jan 2018 19:00:44 GMT):
oh
cmgabriel (Fri, 19 Jan 2018 18:39:54 GMT):
Has joined the channel.
Brucepark (Sat, 20 Jan 2018 06:14:25 GMT):
Has joined the channel.
Glen (Mon, 22 Jan 2018 00:48:27 GMT):
Hi, @mastersingh24 as I tried to make the enccc_example run on v1.1.0-preview, I had compiled new fabric-tools and fabric-ccenv, but I still ran into the following error(log from dev-peer0 container, as it went down after being created by peer) when I tried to instantiate the chaincode
```
2018-01-21 12:00:18.309 UTC [shim] userChaincodeStreamGetter -> ERRO 001 open : no such file or directory
error trying to read file content
github.com/hyperledger/fabric/core/chaincode/shim.userChaincodeStreamGetter
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/chaincode.go:87
github.com/hyperledger/fabric/core/chaincode/shim.Start
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/chaincode.go:148
main.main
/chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02/chaincode_example02.go:189
runtime.main
/opt/go/src/runtime/proc.go:185
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2337```
Glen (Mon, 22 Jan 2018 00:48:27 GMT):
Hi, @mastersingh24 as I tried to make the enccc_example run on v1.1.0-preview, I had compiled new fabric-tools and fabric-ccenv, but I still ran into the following error(log from dev-peer0 container, as it went down after being created by peer) when I tried to instantiate the chaincode
```2018-01-21 12:00:18.309 UTC [shim] userChaincodeStreamGetter -> ERRO 001 open : no such file or directory
error trying to read file content
github.com/hyperledger/fabric/core/chaincode/shim.userChaincodeStreamGetter
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/chaincode.go:87
github.com/hyperledger/fabric/core/chaincode/shim.Start
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/chaincode.go:148
main.main
/chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02/chaincode_example02.go:189
runtime.main
/opt/go/src/runtime/proc.go:185
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2337```
Glen (Mon, 22 Jan 2018 00:48:59 GMT):
I used the command:
```peer chaincode instantiate -o orderer.example.com:7050 --tls true --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem -C mychannel -n mycc -v 1.0 -c '{"Args":["init"]}' -P "OR ('Org1MSP.member','Org2MSP.member')"
yacovm (Mon, 22 Jan 2018 07:57:42 GMT):
seems like you're missing a certificate definition
yacovm (Mon, 22 Jan 2018 07:57:53 GMT):
`open :` it was supposed to open a certificate file
Glen (Mon, 22 Jan 2018 15:01:11 GMT):
yes, not too sure how the peer stated the dev container, which certificate it needs here. Anybody has run the chaincode example successfully?
PiyaMahajan (Mon, 22 Jan 2018 21:35:53 GMT):
Has joined the channel.
StevenXu (Wed, 24 Jan 2018 01:20:32 GMT):
Has joined the channel.
ahmedsajid (Wed, 24 Jan 2018 14:17:33 GMT):
Has joined the channel.
ibmamnt (Thu, 25 Jan 2018 06:31:37 GMT):
Hi, in a tool "cryptogen", several "users" can be created along with Admin user. What is the original purpose of these users usage ?
mastersingh24 (Thu, 25 Jan 2018 08:16:27 GMT):
@ibmamnt - The idea was to create some sample users per org which could be used by applications created with the SDKs or with the CLI. This way you could get up and running and test a network without the need to setup the fabric-ca
tobowers (Thu, 25 Jan 2018 19:02:45 GMT):
Has joined the channel.
george.skrbic (Thu, 25 Jan 2018 21:25:13 GMT):
Has joined the channel.
Glen (Fri, 26 Jan 2018 05:28:00 GMT):
@mastersingh24 fabric ca allows to register users with some attributes, can these attributes to do something with privacy protection on the blockchain data?
Glen (Fri, 26 Jan 2018 05:28:00 GMT):
@mastersingh24 fabric ca allows to register users with some attributes, can these attributes be used to do something with privacy protection on the blockchain data?
niyuelin (Fri, 26 Jan 2018 08:49:43 GMT):
Has joined the channel.
ahmedsajid (Fri, 26 Jan 2018 14:57:44 GMT):
Hi, anyone know how to change key algorithm and size used for enrollment in fabric-ca-client?
Does it go under csr section?
csr:
cn: user1
serialnumber:
names:
- C: US
ST: North Carolina
L:
O: Hyperledger
OU: Fabric
hosts:
- peer1.example.com
ca:
pathlen:
pathlenzero:
expiry:
key:
algo: ecdsa
size: 384
ahmedsajid (Fri, 26 Jan 2018 14:57:44 GMT):
Hi, anyone know how to change key algorithm and size used for enrollment in fabric-ca-client?
Does it go under csr section?
`
Hi, anyone know how to change key algorithm and size used for enrollment in fabric-ca-client?
Does it go under csr section?
csr:
cn: user1
serialnumber:
names:
- C: US
ST: North Carolina
L:
O: Hyperledger
OU: Fabric
hosts:
- peer1.example.com
ca:
pathlen:
pathlenzero:
expiry:
key:
algo: ecdsa
size: 256
`
ahmedsajid (Fri, 26 Jan 2018 14:57:44 GMT):
Hi, anyone know how to change key algorithm and size used for enrollment in fabric-ca-client?
Does it go under csr section?
```
csr:
cn: user1
serialnumber:
names:
- C: US
ST: North Carolina
L:
O: Hyperledger
OU: Fabric
hosts:
- peer1.example.com
ca:
pathlen:
pathlenzero:
expiry:
key:
algo: ecdsa
size:
```
ahmedsajid (Fri, 26 Jan 2018 14:57:44 GMT):
Hi, anyone know how to change key algorithm and size used for enrollment in fabric-ca-client?
Does it go under csr section?
```
csr:
cn: user1
serialnumber:
names:
- C: US
ST: North Carolina
L:
O: Hyperledger
OU: Fabric
hosts:
- peer1.example.com
ca:
pathlen:
pathlenzero:
expiry:
key:
algo: ecdsa
size: 384
```
ahmedsajid (Fri, 26 Jan 2018 15:01:20 GMT):
Setting the above doesn't change anything.
```
2018/01/26 15:00:48 [INFO] User provided config file: /root/.fabric-ca-client/fabric-ca-client-config.yaml
2018/01/26 15:00:48 [INFO] generating key: &{A:ecdsa S:256}
2018/01/26 15:00:48 [INFO] encoded CSR
2018/01/26 15:00:48 [INFO] TLS Enabled
```
ahmedsajid (Fri, 26 Jan 2018 15:01:20 GMT):
Setting the above in /root/.fabric-ca-client/fabric-ca-client-config.yaml doesn't change anything.
```
2018/01/26 15:00:48 [INFO] User provided config file: /root/.fabric-ca-client/fabric-ca-client-config.yaml
2018/01/26 15:00:48 [INFO] generating key: &{A:ecdsa S:256}
2018/01/26 15:00:48 [INFO] encoded CSR
2018/01/26 15:00:48 [INFO] TLS Enabled
```
jrosmith (Fri, 26 Jan 2018 20:48:24 GMT):
@Glen yes, version 1.1 will support attribute based access control
Glen (Sat, 27 Jan 2018 05:54:27 GMT):
@jrosmith ,If one transaction is made between two companyies, the transaction data will be shared by the two organizations ,and others will not be able to see it without approval, this is the privacy protection I meant. Is that feasible by granting or revoking some attributes?
Glen (Sat, 27 Jan 2018 06:06:39 GMT):
Also these attributes can be checked in chaincode, right?
jrosmith (Mon, 29 Jan 2018 14:01:07 GMT):
@Glen yes this can be implemented
robinrob (Mon, 29 Jan 2018 14:26:43 GMT):
Has joined the channel.
rickr (Wed, 31 Jan 2018 17:17:36 GMT):
@mastersingh24 Does the servers (Fabric peer orderer) validate the IP/HOST in client certificate .. like the client will do for the server with mutual TLS? I would _assume_ not since clients host/ip could frequently change.
yacovm (Wed, 31 Jan 2018 17:42:26 GMT):
They dont
yacovm (Wed, 31 Jan 2018 17:42:38 GMT):
But i'm not @mastersingh24 :)
rickr (Wed, 31 Jan 2018 17:43:07 GMT):
Maybe some day :)
rickr (Wed, 31 Jan 2018 17:44:30 GMT):
Solely _out of curiosity_ is that standard behavior to not validate that for clients or is that something Fabric disabled ?
yacovm (Wed, 31 Jan 2018 17:47:12 GMT):
Well there is little meaning in doing this. Imagine you would, so the server can only verify an ip, not a dns name right?
yacovm (Wed, 31 Jan 2018 17:47:56 GMT):
Also what is the meaning of doing it?
rickr (Wed, 31 Jan 2018 17:50:23 GMT):
If I had a specific scenario few clients that I wanted a very strict only they are connecting ?
rickr (Wed, 31 Jan 2018 17:51:39 GMT):
Not here for a long debate just wanted to know for sure the behavior .. which lead me to wonder if that is standard
yacovm (Wed, 31 Jan 2018 17:55:20 GMT):
Well then op filtering isnt the best idea
yacovm (Wed, 31 Jan 2018 17:55:33 GMT):
*ip
yacovm (Wed, 31 Jan 2018 17:56:09 GMT):
You can just tell TLS in the peer only to trust specific certs
yacovm (Wed, 31 Jan 2018 17:56:33 GMT):
It is not supported yet in fabric but its doable in golang YLS config
yacovm (Wed, 31 Jan 2018 17:56:48 GMT):
*TLS
rickr (Wed, 31 Jan 2018 18:00:17 GMT):
Would the most likely use case of MTLS on the client to generate a single client certificate and distribute that ?
yacovm (Wed, 31 Jan 2018 18:04:43 GMT):
I wouldnt do that
yacovm (Wed, 31 Jan 2018 18:05:24 GMT):
There are standard common practices in pki such as CRLs etc. And best to follow them
yacovm (Wed, 31 Jan 2018 18:05:41 GMT):
Cls, expiration, etc
yacovm (Wed, 31 Jan 2018 18:05:59 GMT):
But i'm not a decurity expert
yacovm (Wed, 31 Jan 2018 18:06:07 GMT):
*Security
yacovm (Wed, 31 Jan 2018 18:06:45 GMT):
So better let others with more experience like Garo to chime in
yacovm (Wed, 31 Jan 2018 18:07:01 GMT):
*gari (on the phone)
rickr (Wed, 31 Jan 2018 18:20:51 GMT):
https://jira.hyperledger.org/browse/FAB-7231
If clients TLS certs are not all unique secured not seeing how hashing them will help with replay attacks
If they are then seems it would be unrealistic given the nature of clients being many mabye even hundreds to one server
yacovm (Wed, 31 Jan 2018 21:34:06 GMT):
they are unique, @rickr
yacovm (Wed, 31 Jan 2018 21:34:16 GMT):
> If they are then seems it would be unrealistic given the nature of clients being many mabye even hundreds to one server
Why is that?
rickr (Wed, 31 Jan 2018 21:44:09 GMT):
What aspect would be unique ?
rickr (Wed, 31 Jan 2018 21:44:09 GMT):
What aspect would be unique ? Crypto stuff is not something I have a lot of experience with.
yacovm (Wed, 31 Jan 2018 22:04:02 GMT):
the public and private keys are unique
yacovm (Wed, 31 Jan 2018 22:04:13 GMT):
I would assume also other attributes of the certificate
yacovm (Wed, 31 Jan 2018 22:04:40 GMT):
like subject name
tennenjl (Wed, 31 Jan 2018 22:24:18 GMT):
hash
y.yone (Thu, 01 Feb 2018 03:00:08 GMT):
Has joined the channel.
frankz (Thu, 01 Feb 2018 03:11:51 GMT):
Has joined the channel.
jf.villeret (Thu, 01 Feb 2018 10:50:11 GMT):
Has joined the channel.
jf.villeret (Thu, 01 Feb 2018 10:58:50 GMT):
Hi all, I'm trying to install the balance-transfer fabric example on 3 EC2 AMI instances. I'm struggling with the configuration of the crypto material (using cryptogen) and the configuration of the channel and genesis block. Can someone indicate me where I could find an example of those configuration files in a distributed mode? For instance, I'm wondering what to indicate as domain?
jf.villeret (Thu, 01 Feb 2018 11:00:06 GMT):
I forgot to mention that my objective is to have the org1 running 2 peers and a ca on server 1, org2 running 2 peers and a ca on server 2 and the orderer (currently in solo) running on the server 3
daygee (Fri, 02 Feb 2018 15:28:08 GMT):
Has joined the channel.
ArnabChatterjee (Thu, 08 Feb 2018 02:22:57 GMT):
Hello, Fabric Experts. If we want to establish TLS over a peer from a different org, then we need to ask for only the tls cert of the particular peer, right? Is it okay for orgs to give away certificates to other orgs?
yacovm (Thu, 08 Feb 2018 06:49:56 GMT):
No, you give it the TLS root ca cert
akshay.lawange (Thu, 08 Feb 2018 12:44:21 GMT):
Has joined the channel.
Caterina (Fri, 09 Feb 2018 18:45:08 GMT):
Has joined the channel.
Caterina (Fri, 09 Feb 2018 18:45:21 GMT):
Hi just joined
Caterina (Fri, 09 Feb 2018 18:45:26 GMT):
☺
BalaM (Fri, 09 Feb 2018 22:19:18 GMT):
Has joined the channel.
BalaM (Fri, 09 Feb 2018 22:19:22 GMT):
I have setup Fabric on AWS EC2 machine running on UBUNTU OS. While testing it with the first network sample project , I get the below error...
ubuntu@ip-10-35-128-73:~/fabric-samples/first-network$ ./byfn.sh generate
Generating certs and genesis block for with channel 'mychannel' and CLI timeout of '10' seconds and CLI delay of '3' seconds
Continue? [Y/n] y
proceeding ...
/home/ubuntu/bin/cryptogen
##########################################################
##### Generate certificates using cryptogen tool #########
##########################################################
org1.example.com
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x77c4fe]
yetanotheruser23 (Sat, 10 Feb 2018 01:19:44 GMT):
Has joined the channel.
yetanotheruser23 (Sat, 10 Feb 2018 01:20:45 GMT):
Can you try ./byfn.sh -m generate
yetanotheruser23 (Sat, 10 Feb 2018 01:21:18 GMT):
I think you've missed the mode "-m".
BalaM (Sat, 10 Feb 2018 12:43:09 GMT):
I tried with -m option, still getting the same error, find below the output
./byfn -m generate
bash: ./byfn: No such file or directory
mbtpani@ip-10-35-128-73:/home/ubuntu/fabric-samples/first-network$ ./byfn.sh -m generate
Generating certs and genesis block for with channel 'mychannel' and CLI timeout of '10' seconds and CLI delay of '3' seconds
Continue? [Y/n] y
proceeding ...
/home/ubuntu/bin/cryptogen
##########################################################
##### Generate certificates using cryptogen tool #########
##########################################################
org1.example.com
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x77c4fe]
goroutine 1 [running]:
github.com/hyperledger/fabric/common/tools/cryptogen/msp.GenerateVerifyingMSP(0xc42001c480, 0x34, 0x0, 0x0, 0xc4200129c0, 0x16)
/w/workspace/fabric-binaries-x86_64/gopath/src/github.com/hyperledger/fabric/common/tools/cryptogen/msp/generator.go:178 +0x1be
main.generatePeerOrg(0x88d674, 0xd, 0xc4200149f0, 0x4, 0xc420014a10, 0x10, 0x88b3f6, 0x2, 0xc420012980, 0x13, ...)
/w/workspace/fabric-binaries-x86_64/gopath/src/github.com/hyperledger/fabric/common/tools/cryptogen/main.go:536 +0x909
main.generate()
/w/workspace/fabric-binaries-x86_64/gopath/src/github.com/hyperledger/fabric/common/tools/cryptogen/main.go:394 +0x171
main.main()
/w/workspace/fabric-binaries-x86_64/gopath/src/github.com/hyperledger/fabric/common/tools/cryptogen/main.go:228 +0x2a0
Failed to generate certificates...
rizwan92 (Tue, 13 Feb 2018 08:57:44 GMT):
Has joined the channel.
rizwan92 (Tue, 13 Feb 2018 09:00:20 GMT):
./byfn.sh -m generate
Generating certs and genesis block for with channel 'mychannel' and CLI timeout of '10'
Continue (y/n)? y
proceeding ...
cryptogen tool not found. exiting
rizwan92 (Tue, 13 Feb 2018 09:00:20 GMT):
./byfn.sh -m generate
Generating certs and genesis block for with channel 'mychannel' and CLI timeout of '10'
Continue (y/n)? y
proceeding ...
cryptogen tool not found. exiting
rizwan92 (Tue, 13 Feb 2018 09:00:40 GMT):
what should i do
mastersingh24 (Tue, 13 Feb 2018 09:46:36 GMT):
@rizwan92 - did you download and install the binaries following http://hyperledger-fabric.readthedocs.io/en/release/samples.html ?
Note that the instructions assume that you run the download from within the `fabric-samples` directory
Lucifer (Wed, 14 Feb 2018 05:13:41 GMT):
Has joined the channel.
sakoula (Wed, 14 Feb 2018 07:27:16 GMT):
Has joined the channel.
sakoula (Wed, 14 Feb 2018 07:30:19 GMT):
hi, on the Security & Access Control FAQ it says: "within a channel you can restrict the input data to chaincode to the set of endorsers only, by using visibility settings." How can I setup the visibility settings. I cannot find anywhere else some reference. Thanks!
rickr (Wed, 14 Feb 2018 17:57:03 GMT):
I don't this is likely but just want to ask the _experts_ would there be a need to ever have different client tls certs for different peers ? orderers ?
rickr (Wed, 14 Feb 2018 17:59:31 GMT):
I generate from fabric CA the client tls to run our integration tests. Would those be accepted by a peer from another organization .. using a different CA ?
kakuzu (Thu, 15 Feb 2018 01:25:13 GMT):
Has joined the channel.
bfuentes@fr.ibm.com (Thu, 15 Feb 2018 16:37:50 GMT):
Simple question on theses lines from crypto-config.yaml :
bfuentes@fr.ibm.com (Thu, 15 Feb 2018 16:37:53 GMT):
# ---------------------------------------------------------------------------
# "Users"
# ---------------------------------------------------------------------------
# Count: The number of user accounts _in addition_ to Admin
# ---------------------------------------------------------------------------
bfuentes@fr.ibm.com (Thu, 15 Feb 2018 16:38:42 GMT):
Does this mean : is the number of user account allowed by this organisation OR this is the number of autogenerated user accounts ?
bfuentes@fr.ibm.com (Thu, 15 Feb 2018 16:38:44 GMT):
thanks
jyellick (Thu, 15 Feb 2018 16:47:40 GMT):
@bfuentes@fr.ibm.com `cryptogen` is a tool designed to quickly bootstrap some crypto material for your network. If you are interested in doing dynamic creation of users, you probably want to look at #fabric-ca
jyellick (Thu, 15 Feb 2018 16:47:40 GMT):
@bfuentes@fr.ibm.com
> this is the number of autogenerated user accounts ?
The number of user certificates that `cryptogen` will output
`cryptogen` is a tool designed to quickly bootstrap some crypto material for your network. If you are interested in doing dynamic creation of users, you probably want to look at #fabric-ca
yetanotheruser23 (Thu, 15 Feb 2018 17:04:09 GMT):
When I run cryptogen, I can see several sets of certificates getting generated. Is there a document that details when and where each of those certificates will be used?
jyellick (Thu, 15 Feb 2018 17:23:46 GMT):
@yetanotheruser23 Have you looked at http://hyperledger-fabric.readthedocs.io/en/latest/msp.html ?
yetanotheruser23 (Thu, 15 Feb 2018 18:21:08 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=r3cLsdiPCsdReu4qY) @jyellick Thanks! I went through it. All the docs mention the declaration of an mspID. Can you tell me where I would define an mspID? I'm configtx.yaml to define the profile, organizations and peers. I'm using core.yaml for the peers and orderer.yaml for the orderer. Since mspID is related to the channel, would I declare it as part of the Channel Profile in configtx.yaml?
bfuentes@fr.ibm.com (Thu, 15 Feb 2018 21:13:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=MaGNnxL4QwXFqqiL9) @jyellick Thanks, this confirms what I was testing. I think the documentation should say it is generated user for test only purpose
jyellick (Fri, 16 Feb 2018 02:32:28 GMT):
@yetanotheruser23 The MSPID is not tied directly to the crypto materal. This is necessary to for instance support both X.509 and Idemix (zero-knowledge) type MSPs
jyellick (Fri, 16 Feb 2018 02:32:28 GMT):
@yetanotheruser23 The MSPID is not tied directly to the crypto materal. This is necessary to for instance support both X.509 and Idemix (zero-knowledge) type MSPs. This is defined in `configtx.yaml` or similar when constructing your configuraton
fabcan (Fri, 16 Feb 2018 11:04:24 GMT):
Has left the channel.
kakuzu (Fri, 16 Feb 2018 21:45:27 GMT):
Clipboard - February 16, 2018 4:45 PM
kakuzu (Fri, 16 Feb 2018 21:45:35 GMT):
what to do
jrosmith (Fri, 16 Feb 2018 21:49:39 GMT):
@kakuzu do not spam channels
yetanotheruser23 (Fri, 16 Feb 2018 21:58:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=3jzxKCTEbejqCKdnz) @jyellick Thank you. I realized that that's the ID defined in configtx.
SjirNijssen (Sat, 17 Feb 2018 13:51:12 GMT):
Has joined the channel.
eclairamb (Sat, 17 Feb 2018 17:58:38 GMT):
Has joined the channel.
gospodin.bodurov (Mon, 19 Feb 2018 08:20:58 GMT):
Has joined the channel.
vitiko (Mon, 19 Feb 2018 11:43:11 GMT):
Has joined the channel.
nebsterboy (Tue, 20 Feb 2018 15:55:08 GMT):
Has joined the channel.
TomV 5 (Tue, 20 Feb 2018 16:07:02 GMT):
Has joined the channel.
ArnabChatterjee (Wed, 21 Feb 2018 02:17:19 GMT):
Hello Experts. Thanks for your support.
I wish to allow only read access to a given channel in the network. I think this can be done by setting the Channel's writer's policy. But I cannot find any specific procedure/examples to achieve this. Any ideas? Thanks. :).
PraveenKumar5 (Fri, 23 Feb 2018 00:47:20 GMT):
Has joined the channel.
jgm-learn (Fri, 23 Feb 2018 07:05:50 GMT):
Has joined the channel.
nebsterboy (Fri, 23 Feb 2018 13:31:32 GMT):
Hi, I want to include support for post quantum cryptography in hyperledger fabric. I found that the SDK has a CryptoSuite interface. Which component do I have to adopt in order to support PQC? I'm thankful for any advice.
yacovm (Fri, 23 Feb 2018 14:26:51 GMT):
@nebsterboy you mean signatures?
yacovm (Fri, 23 Feb 2018 14:27:07 GMT):
Or encryption?
nebsterboy (Fri, 23 Feb 2018 14:41:30 GMT):
At the end I like to supoort PQC for signatures and encryption. As far as I saw, the CryptoSuite interface in the Java SDK has just methods for signing and verifying. Encryption is done at another component?
tsnyder (Fri, 23 Feb 2018 20:39:24 GMT):
@nebsterboy - The java sdk supports Java JCA/JCE for signing. This is what is used to provide a PKCS11 interface for Gemalto HSMs. However, the underlying Fabric system currently mainly supports elliptical curve keys for a specific strength. I have seen some support for RSA keys, but not sure where that is at. The keys and certs created from the private keys for each of the organizations, peers, org users, and tls need to be published to the Orderer and embedded within each Peer for channel authorization and access. I know for the PKCS11 implementation, in order for the Peer signing and verification there is a dynamic build of the Orderers and Peers required to bind the specific PKSC11 implementation. One of the IBM Fellows who had prior experience with PKCS11 spent 3-6 months building out the PKSC11 implementation for the Fabric Peer, and a Gemalto engineer spent a couple of months on the Fabric SDK and Fabric CA client in addition. Unless it is a show stopper for you or a serious value add, and you have plenty of time, you might want to rethink. You will probably be into forking basic Fabric code and building dynamic bindings with Go code in order to do it.
jgm-learn (Sat, 24 Feb 2018 00:26:11 GMT):
Has left the channel.
nebsterboy (Sat, 24 Feb 2018 07:22:30 GMT):
@tsnyder thanks for your assessment. It sounds like providing an own CryptoSuite is not enough but one need to change the Go code of all components like orderer, Peer, CA. Did I understand this right?
grapebaba (Sat, 24 Feb 2018 09:38:11 GMT):
@here
grapebaba (Sat, 24 Feb 2018 09:39:17 GMT):
Clipboard - 2018年2月24日下午5点41分
grapebaba (Sat, 24 Feb 2018 09:40:13 GMT):
I saw if use SW bccsp, password and readonly flag is hard coded
grapebaba (Sat, 24 Feb 2018 09:40:41 GMT):
any reason make it cannot configurable?
tsnyder (Sat, 24 Feb 2018 12:44:34 GMT):
@nebsterboy - yes to the expected need to change Go Code in the components. I would take a look at any modifications for RSA certificates and keys that are included in the code, and the PKCS11 implementation to get a feel for what you would need to do.
nebsterboy (Sat, 24 Feb 2018 12:46:47 GMT):
@tsnyder okay, thanks for your help.
MikeGardiner (Mon, 26 Feb 2018 15:03:00 GMT):
@nebsterboy, Which PQC schemes are you interested in? I'm a big fan of building in cryptographic agility, and it's best to start thinking about PQ now but you may not want to make specific bets today without signing with multiple algorithms. The fact that hyperledger leverages standard APIs like Java JCA/JCE and PKCS#11 should make adopting new algorithms easy at that level but as @tsnyder has said, there are likely to be a number of other changes and all your components will need to understand the new crypto to do verification.
nebsterboy (Mon, 26 Feb 2018 15:34:32 GMT):
@MikeGardiner right now, I do not know which schemes we want to incorporate. My hope was that there are interfaces, like the CryptoSuite of the SDK, for all components so that providing and also exchanging new schemes is easy.
gskerry (Mon, 26 Feb 2018 17:14:37 GMT):
Has joined the channel.
phanikumar1210 (Mon, 26 Feb 2018 21:01:10 GMT):
Has joined the channel.
phal0r (Tue, 27 Feb 2018 02:59:32 GMT):
Has joined the channel.
dushyantbehl (Tue, 27 Feb 2018 08:50:32 GMT):
Has joined the channel.
AnomalRoil (Tue, 27 Feb 2018 13:52:00 GMT):
Has joined the channel.
AnomalRoil (Tue, 27 Feb 2018 14:20:02 GMT):
Hello there. I'm new to Fabric and having read a big part of the doc and papers, I'm still a bit left wanting for more details on the way the membership system is designed and its underlying crypto: how a given client might be granted broadcast access to some channel without being able to read what's in that channel. Is the data in channels encrypted? If so, what scheme is used? Can the access once granted be revoked? If so, what security guarantuee do we have?
Maybe I've missed a paper or document on these topics?
Typically if I were to design such a system, I would probably consider attribute based encryption, but I haven't seen much detail about what's being used in Fabric. Maybe I've missed a relevant publication?
AnomalRoil (Tue, 27 Feb 2018 14:20:02 GMT):
Hello there. I'm new to Fabric and having read a big part of the doc and papers, I'm still a bit left wanting for more details on the way the membership system is designed and its underlying crypto: how a given client might be granted broadcast access to some channel without being able to read what's in that channel. Is the data in channels encrypted? If so, what scheme is used? Can the access once granted be revoked? If so, what security guarantuee do we have?
Maybe I've missed a paper or document on these topics?
Typically if I were to design such a system, I would probably consider attribute based encryption, but I haven't seen much detail about what's being used in Fabric.
AnomalRoil (Tue, 27 Feb 2018 14:20:02 GMT):
Hello there. I'm new to Fabric and having read a big part of the doc and papers, I'm still a bit left wanting for more details on the way the membership system is designed and its underlying crypto: how a given client might be granted broadcast access to some channel without being able to read what's in that channel. Is the data in channels encrypted? If so, what scheme is used? Can the access once granted be revoked? If so, what security guarantuee do we have?
Maybe I've missed a paper or document on these topics?
Typically if I were to design such a system out of the blue, I would say I'd consider attribute based encryption, but I haven't seen much detail about what's being used in Fabric.
adc (Tue, 27 Feb 2018 14:59:46 GMT):
Hi @AnomalRoil, let's start from the fact that the genesis block of a channel contains the list of MPS recognized by that channel
adc (Tue, 27 Feb 2018 15:00:16 GMT):
the genesis block contains also policies to identifies MSP identities that allowed to read and write to the channel
adc (Tue, 27 Feb 2018 15:00:16 GMT):
the genesis block contains also policies to identify MSP identities that are allowed to read and write to the channel
adc (Tue, 27 Feb 2018 15:00:48 GMT):
in order to revoke an identity, a reconfiguration transaction needs to be issued containing updated CRLs
adc (Tue, 27 Feb 2018 15:01:00 GMT):
the ledger, by default, is not encrypted
AnomalRoil (Tue, 27 Feb 2018 15:05:14 GMT):
Yes, but who will enforce the MSP policies and how are those enforced?
AnomalRoil (Tue, 27 Feb 2018 15:07:16 GMT):
If the ledger is not encrypted, does it mean that anybody with access to the ledger can see what's going on in all channels?
AnomalRoil (Tue, 27 Feb 2018 15:09:37 GMT):
So all peers need to be trusted by all channels' members?
AnomalRoil (Tue, 27 Feb 2018 15:09:37 GMT):
So all peers need to be trusted by all channels' clients?
parsiya (Tue, 27 Feb 2018 18:00:53 GMT):
Has joined the channel.
carne 2 (Tue, 27 Feb 2018 18:06:19 GMT):
Has joined the channel.
TBiehn (Tue, 27 Feb 2018 18:11:12 GMT):
Has joined the channel.
koenbuyens (Tue, 27 Feb 2018 18:13:55 GMT):
Has joined the channel.
VikasJakhar (Tue, 27 Feb 2018 20:06:27 GMT):
Has joined the channel.
amirhosainh (Wed, 28 Feb 2018 07:13:30 GMT):
Has joined the channel.
adc (Wed, 28 Feb 2018 10:55:14 GMT):
MSP policies are enforced by the nodes of the network at different levels. For instance, when a client sends a proposal to an endorser, the endorser will check the writer policy to make sure the client is entitled to submit that proposal. The ordering service does something similar.
adc (Wed, 28 Feb 2018 10:56:38 GMT):
regarding confidentiality, of course, either you trust the nodes of the network or you put in place mechanisms to obfuscated the content of transactions. SideDB is an example of an obfuscation technique
adc (Wed, 28 Feb 2018 10:56:38 GMT):
regarding confidentiality, of course, either you trust the nodes of the network or you put in place mechanisms to obfuscate transactions' content. SideDB is an example of an obfuscation technique
AnomalRoil (Thu, 01 Mar 2018 10:20:12 GMT):
In fact I hadn't realized, I think, but I guess it means the read-write policy is enforced by the DB engine, not using client's keys or whatsoever, but as any DB would do it already
IgorSim (Fri, 02 Mar 2018 08:54:29 GMT):
Has joined the channel.
adc (Fri, 02 Mar 2018 10:29:16 GMT):
the check is based on signature verification. The client must sign the proposal and the transaction as well
AnomalRoil (Fri, 02 Mar 2018 11:45:25 GMT):
Okay, thanks
marque88 (Fri, 02 Mar 2018 14:29:53 GMT):
Has joined the channel.
marque88 (Fri, 02 Mar 2018 14:35:22 GMT):
Hi... I'm trying, without any result, to decode block data to read content of transaction. Are there encrypted with the user's or peer's keys?
yacovm (Fri, 02 Mar 2018 15:42:42 GMT):
no, they are just overly wrapped with protobuf
Ravi.Bodkai (Sat, 03 Mar 2018 11:16:21 GMT):
Has joined the channel.
GiorgiBlockchain (Mon, 05 Mar 2018 03:36:38 GMT):
Has joined the channel.
adc (Mon, 05 Mar 2018 07:50:19 GMT):
@marque88, if you look under the protos folder, there are multiple functions that we use to unmarshal
marque88 (Mon, 05 Mar 2018 07:58:00 GMT):
Ok thk @adc.
nebsterboy (Tue, 06 Mar 2018 13:52:50 GMT):
I like to exchange the signature scheme used inside fabric to provide an alternative to ecdsa. Any suggestions from you where to start to look inside the code?
adc (Tue, 06 Mar 2018 15:21:58 GMT):
the first place is the bccsp package
adc (Tue, 06 Mar 2018 15:22:10 GMT):
it contains the cryptographic algorithms used by fabric
adc (Tue, 06 Mar 2018 15:23:12 GMT):
once you have integrated the new signature scheme algorithms, then you have to modify the MSP, see the msp package, to call your scheme rather than ecdsa
nebsterboy (Tue, 06 Mar 2018 15:25:09 GMT):
@adc thanks for your advice
rjones (Tue, 06 Mar 2018 17:10:40 GMT):
dave.enyeart
rjones (Tue, 06 Mar 2018 17:10:47 GMT):
cbf
dave.enyeart (Tue, 06 Mar 2018 20:05:53 GMT):
adc
dave.enyeart (Tue, 06 Mar 2018 20:05:59 GMT):
elli-androulaki
dave.enyeart (Tue, 06 Mar 2018 20:06:10 GMT):
aso
jaswanth (Wed, 07 Mar 2018 11:14:47 GMT):
Hi all , got this error `Error: got unexpected status: BAD_REQUEST -- Attempted to include a member which is not in the consortium` when trying to create a channel by using```
peer channel create -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/channel.tx --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
```
configtx file is
```
Profiles:
CTBSOrdererGenesis:
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Consortiums:
SampleConsortium:
Organizations:
- *ContainerAgency
- *TruckAgency
- *RampAgency
- *Customers
CTBSChannel:
Consortium: SampleConsortium
Application:
<<: *ApplicationDefaults
Organizations:
- *ContainerAgency
- *TruckAgency
- *RampAgency
- *Customers
```
adc (Wed, 07 Mar 2018 12:13:22 GMT):
@jyellick, do you have any idea for that?
jyellick (Wed, 07 Mar 2018 14:30:17 GMT):
@adc @jaswanth just as the error message suggests, your consortium definition does not include the container agency, so it cannot be part of the new channel at genesis
tobowers (Wed, 07 Mar 2018 21:05:17 GMT):
Is this the right channel for libindy-crypto too?
vishwasbalakrishna (Wed, 07 Mar 2018 21:36:19 GMT):
Has joined the channel.
cheukchan (Thu, 08 Mar 2018 05:25:18 GMT):
Has joined the channel.
devchaud (Thu, 08 Mar 2018 05:55:33 GMT):
Has joined the channel.
devchaud (Thu, 08 Mar 2018 05:56:04 GMT):
hsm
SuvitPatil (Thu, 08 Mar 2018 06:03:27 GMT):
Has joined the channel.
purandam (Thu, 08 Mar 2018 06:03:50 GMT):
Has joined the channel.
SuvitPatil (Thu, 08 Mar 2018 06:04:19 GMT):
Hello Team, I am using Fabcar project from fabric-samples. I used PKCS11 environment variables before running enrollment.js :
export CRYPTO_PKCS11_LIB=/usr/local/lib/softhsm/libsofthsm2.so
export CRYPTO_PKCS11_SLOT="1"
export CRYPTO_PKCS11_PIN=98765432
but gives following error : Store path:/home/suvit/GoWork/fabric_V1/fabricNode/fabric-samples/fabcar/hfc-key-store
in if
Successfully enrolled admin user "admin"
Error: toBytes: not allowed for private key
at PKCS11_ECDSA_KEY.toBytes (/home/suvit/GoWork/fabric_V1/fabricNode/fabric-samples/fabcar/node_modules/fabric-client/lib/impl/ecdsa/pkcs11_key.js:165:10)
at fabric_ca_client.enroll.then (/home/suvit/GoWork/fabric_V1/fabricNode/fabric-samples/fabcar/enrollAdmin.js:61:66)
at
purandam (Thu, 08 Mar 2018 07:32:48 GMT):
Hi,
We are trying to implement the SOFTHSM in hyperledger fabric -rc1 version. I able to get “successful admin enroll message” but when try to register as a user then I got below error. “enrollment.key” has proper value but when it try to convert into a byte code then it is falling.
purandam (Thu, 08 Mar 2018 07:34:10 GMT):
enrollmentKey.png
adc (Thu, 08 Mar 2018 07:50:11 GMT):
Hi @purandam, how you already posted the question on #fabric-ca? That seems the right place to ask
adc (Thu, 08 Mar 2018 07:50:11 GMT):
Hi @purandam, have you already posted the question on #fabric-ca? That seems the right place to ask
jaswanth (Fri, 09 Mar 2018 04:49:13 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=bcCTRuqa4ZX2PiWhj) @jyellick thank you for the reply , but I'm really confused where it went worng ,
`your consortium definition does not include the container agency` i defined the same orgs in CTBSOrdererGenesis and CTBSChannel. can you explain where am doing wrong.
jaswanth (Fri, 09 Mar 2018 04:49:13 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=bcCTRuqa4ZX2PiWhj) @jyellick thank you for the reply , but I'm really confused where it went worng ,You said
`your consortium definition does not include the container agency` i defined the same orgs in CTBSOrdererGenesis and CTBSChannel. can you explain where am doing wrong.
jyellick (Fri, 09 Mar 2018 04:56:13 GMT):
@jaswanth Based on the `configtx.yaml` that you showed, the "Container Org" was not included in the CTBSOrdererGenesis
jaswanth (Fri, 09 Mar 2018 05:01:54 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=jYf72bpaMSdSiu5oy) @jyellick ```
Profiles:
CTBSOrdererGenesis:
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Consortiums:
SampleConsortium:
Organizations:
- *Containeragency
- *Truckagency
- *Rampagency
- *Customers
CTBSChannel:
Consortium: SampleConsortium
Application:
<<: *ApplicationDefaults
Organizations:
- *Containeragency
- *Truckagency
- *Rampagency
- *Customers
Organizations:
- &OrdererOrg
Name: OrdererOrg
ID: OrdererMSP
MSPDir: crypto-config/ordererOrganizations/example.com/msp
- &Containeragency
Name: ContaineragencyMSP
ID: ContaineragencyMSP
MSPDir: crypto-config/peerOrganizations/Containeragency.example.com/msp
AnchorPeers:
- Host: peer0.Containeragency.example.com
Port: 7051
- &Truckagency
Name: TruckagencyMSP
ID: TruckagencyMSP
MSPDir: crypto-config/peerOrganizations/Truckagency.example.com/msp
AnchorPeers:
- Host: peer0.Truckagency.example.com
Port: 7051
- &Rampagency
Name: RampagencyMSP
ID: RampagencyMSP
MSPDir: crypto-config/peerOrganizations/Rampagency.example.com/msp
AnchorPeers:
- Host: peer0.Rampagency.example.com
Port: 7051
- &Customers
Name: CustomersMSP
ID: CustomersMSP
MSPDir: crypto-config/peerOrganizations/Customers.example.com/msp
AnchorPeers:
- Host: peer0.Customers.example.com
Port: 7051
Orderer: &OrdererDefaults
OrdererType: solo
Addresses:
- orderer.example.com:7050
BatchTimeout: 2s
BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 512 KB
Kafka:
Brokers:
- 127.0.0.1:9092
Organizations:
Application: &ApplicationDefaults
Organizations:
```
jaswanth (Fri, 09 Mar 2018 05:01:54 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=jYf72bpaMSdSiu5oy) @jyellick ```
Profiles:
CTBSOrdererGenesis:
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Consortiums:
SampleConsortium:
Organizations:
- *Containeragency
- *Truckagency
- *Rampagency
- *Customers
CTBSChannel:
Consortium: SampleConsortium
Application:
<<: *ApplicationDefaults
Organizations:
- *Containeragency
- *Truckagency
- *Rampagency
- *Customers
Organizations:
- &OrdererOrg
Name: OrdererOrg
ID: OrdererMSP
MSPDir: crypto-config/ordererOrganizations/example.com/msp
- &Containeragency
Name: ContaineragencyMSP
ID: ContaineragencyMSP
MSPDir: crypto-config/peerOrganizations/Containeragency.example.com/msp
AnchorPeers:
- Host: peer0.Containeragency.example.com
Port: 7051
- &Truckagency
Name: TruckagencyMSP
ID: TruckagencyMSP
MSPDir: crypto-config/peerOrganizations/Truckagency.example.com/msp
AnchorPeers:
- Host: peer0.Truckagency.example.com
Port: 7051
- &Rampagency
Name: RampagencyMSP
ID: RampagencyMSP
MSPDir: crypto-config/peerOrganizations/Rampagency.example.com/msp
AnchorPeers:
- Host: peer0.Rampagency.example.com
Port: 7051
- &Customers
Name: CustomersMSP
ID: CustomersMSP
MSPDir: crypto-config/peerOrganizations/Customers.example.com/msp
AnchorPeers:
- Host: peer0.Customers.example.com
Port: 7051
Orderer: &OrdererDefaults
OrdererType: solo
Addresses:
- orderer.example.com:7050
BatchTimeout: 2s
BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 512 KB
Kafka:
Brokers:
- 127.0.0.1:9092
Organizations:
Application: &ApplicationDefaults
Organizations:
```
jaswanth (Fri, 09 Mar 2018 05:01:54 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=jYf72bpaMSdSiu5oy) @jyellick
this is my configtx.yaml file , can you please point out where iam doing wrong , i'm been struck with this for a long time ```
Profiles:
CTBSOrdererGenesis:
Orderer:
<<: *OrdererDefaults
Organizations:
- *OrdererOrg
Consortiums:
SampleConsortium:
Organizations:
- *Containeragency
- *Truckagency
- *Rampagency
- *Customers
CTBSChannel:
Consortium: SampleConsortium
Application:
<<: *ApplicationDefaults
Organizations:
- *Containeragency
- *Truckagency
- *Rampagency
- *Customers
Organizations:
- &OrdererOrg
Name: OrdererOrg
ID: OrdererMSP
MSPDir: crypto-config/ordererOrganizations/example.com/msp
- &Containeragency
Name: ContaineragencyMSP
ID: ContaineragencyMSP
MSPDir: crypto-config/peerOrganizations/Containeragency.example.com/msp
AnchorPeers:
- Host: peer0.Containeragency.example.com
Port: 7051
- &Truckagency
Name: TruckagencyMSP
ID: TruckagencyMSP
MSPDir: crypto-config/peerOrganizations/Truckagency.example.com/msp
AnchorPeers:
- Host: peer0.Truckagency.example.com
Port: 7051
- &Rampagency
Name: RampagencyMSP
ID: RampagencyMSP
MSPDir: crypto-config/peerOrganizations/Rampagency.example.com/msp
AnchorPeers:
- Host: peer0.Rampagency.example.com
Port: 7051
- &Customers
Name: CustomersMSP
ID: CustomersMSP
MSPDir: crypto-config/peerOrganizations/Customers.example.com/msp
AnchorPeers:
- Host: peer0.Customers.example.com
Port: 7051
Orderer: &OrdererDefaults
OrdererType: solo
Addresses:
- orderer.example.com:7050
BatchTimeout: 2s
BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 512 KB
Kafka:
Brokers:
- 127.0.0.1:9092
Organizations:
Application: &ApplicationDefaults
Organizations:
```
jyellick (Fri, 09 Mar 2018 06:48:28 GMT):
@jaswanth That file is different from the one I recall seeing. Are you certain you are bootstrapping with this file? You must remove your orderer ledger before you re-bootstrap
jaswanth (Fri, 09 Mar 2018 06:57:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=CgsHWbF36ngyEamNe) @jyellick these are the commands i followed , can you look at it
```
../bin/cryptogen generate --config=./crypto-config.yaml
export FABRIC_CFG_PATH=$PWD
../bin/configtxgen -profile CTBSOrdererGenesis -outputBlock ./channel-artifacts/genesis.block
export CHANNEL_NAME=mychannel
../bin/configtxgen -profile CTBSChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID $CHANNEL_NAME
../bin/configtxgen -profile CTBSChannel -outputAnchorPeersUpdate ./channel-artifacts/ContaineragencyMSPanchors.tx -channelID $CHANNEL_NAME -asOrg ContaineragencyMSP
../bin/configtxgen -profile CTBSChannel -outputAnchorPeersUpdate ./channel-artifacts/TruckagencyMSPanchors.tx -channelID $CHANNEL_NAME -asOrg TruckagencyMSP
../bin/configtxgen -profile CTBSChannel -outputAnchorPeersUpdate ./channel-artifacts/RampagencyMSPanchors.tx -channelID $CHANNEL_NAME -asOrg RampagencyMSP
../bin/configtxgen -profile CTBSChannel -outputAnchorPeersUpdate ./channel-artifacts/CustomersMSPanchors.tx -channelID $CHANNEL_NAME -asOrg CustomersMSP
CHANNEL_NAME=$CHANNEL_NAME TIMEOUT=10000 docker-compose -f docker-compose-cli.yaml up -d
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/Containeragency.example.com/users/Admin@Containeragency.example.com/msp
CORE_PEER_ADDRESS=peer0.Containeragency.example.com:7051
CORE_PEER_LOCALMSPID="ContaineragencyMSP"
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/Containeragency.example.com/peers/peer0.Containeragency.example.com/tls/ca.crt
docker exec -ti cli bash
peer channel create -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/channel.tx --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
```
jaswanth (Fri, 09 Mar 2018 06:57:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=CgsHWbF36ngyEamNe) @jyellick these are the commands i followed , can you look at it
```
../bin/cryptogen generate --config=./crypto-config.yaml
export FABRIC_CFG_PATH=$PWD
../bin/configtxgen -profile CTBSOrdererGenesis -outputBlock ./channel-artifacts/genesis.block
export CHANNEL_NAME=mychannel
../bin/configtxgen -profile CTBSChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID $CHANNEL_NAME
../bin/configtxgen -profile CTBSChannel -outputAnchorPeersUpdate ./channel-artifacts/ContaineragencyMSPanchors.tx -channelID $CHANNEL_NAME -asOrg ContaineragencyMSP
../bin/configtxgen -profile CTBSChannel -outputAnchorPeersUpdate ./channel-artifacts/TruckagencyMSPanchors.tx -channelID $CHANNEL_NAME -asOrg TruckagencyMSP
../bin/configtxgen -profile CTBSChannel -outputAnchorPeersUpdate ./channel-artifacts/RampagencyMSPanchors.tx -channelID $CHANNEL_NAME -asOrg RampagencyMSP
../bin/configtxgen -profile CTBSChannel -outputAnchorPeersUpdate ./channel-artifacts/CustomersMSPanchors.tx -channelID $CHANNEL_NAME -asOrg CustomersMSP
CHANNEL_NAME=$CHANNEL_NAME TIMEOUT=10000 docker-compose -f docker-compose-cli.yaml up -d
CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/Containeragency.example.com/users/Admin@Containeragency.example.com/msp
CORE_PEER_ADDRESS=peer0.Containeragency.example.com:7051
CORE_PEER_LOCALMSPID="ContaineragencyMSP"
CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/peerOrganizations/Containeragency.example.com/peers/peer0.Containeragency.example.com/tls/ca.crt
docker exec -ti cli bash
peer channel create -o orderer.example.com:7050 -c $CHANNEL_NAME -f ./channel-artifacts/channel.tx --tls $CORE_PEER_TLS_ENABLED --cafile /opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
```
i got error in the last command
jyellick (Fri, 09 Mar 2018 07:00:12 GMT):
@jaswanth Can you add a `docker-compose -f docker-compose-cli.yaml down --volumes --remove-orphans` prior to the up? (Note, please only do this if you are 100% okay with losing any data in your ledgers)
jaswanth (Fri, 09 Mar 2018 10:02:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=T4wKh5fjf834z9enz) @jyellick Tried it but no luck . Even when i change the consortium name to CTBSConsortium and did all the steps , then i got an error like ```
Rejecting broadcast of config message from 172.19.0.12:60704 because of error: Unknown consortium name: SampleConsortium
```
jaswanth (Fri, 09 Mar 2018 10:02:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=T4wKh5fjf834z9enz) @jyellick Tried it but no luck . Even when i change the consortium name to CTBSConsortium and did all the steps , then i got an error like ```Rejecting broadcast of config message from 172.19.0.12:60704 because of error: Unknown consortium name: SampleConsortium
``` in orderer.
jaswanth (Fri, 09 Mar 2018 10:02:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=T4wKh5fjf834z9enz) @jyellick Tried it but no luck . Even when i change the consortium name to CTBSConsortium and did all the steps , then i got an error like ```Rejecting broadcast of config message from 172.19.0.12:60704 because of error: Unknown consortium name: SampleConsortium
``` in orderer. i didnot see `sampleConsortium` anywhere in my code
jyellick (Fri, 09 Mar 2018 15:18:37 GMT):
@jaswanth The only place `SampleConsortium` is defined is in `configtx.yaml`
jyellick (Fri, 09 Mar 2018 15:19:31 GMT):
If you change it in that file, please make sure you change all instances, remove all previously generated artifacts, and do the `docker-compose -f docker-compose-cli.yaml down --volumes --remove-orphans` once more.
TobiasN (Mon, 12 Mar 2018 00:13:57 GMT):
Has joined the channel.
dijun (Mon, 12 Mar 2018 08:56:14 GMT):
Hi, I want to implement an alternative crypto scheme. I could , on BCCSP side implement a crypto plugin which I could load the crypto lib outside, while on MSP side, I will have to modify MSP, since it doesn’t support plugin mode.
So I wonder if MSP could designed in pluggable way as bccsp did in v1.1.
adc (Mon, 12 Mar 2018 10:12:43 GMT):
@dijun, it is a very good point. I think we need that as well
dijun (Mon, 12 Mar 2018 15:03:18 GMT):
So @adc ,I think there are two issues that we must face on。
1. If we define plugin as a msp type, how to determine which plugin should we use for a specific org, perhaps there are several plugins in the network that each org will use one.
2. And how can we distribute plugin binaries from channel config. Or maybe we just do this offline. It should also be noted that different platforms could use different plugin binaries which make things a bit more complex.
adc (Tue, 13 Mar 2018 08:47:39 GMT):
@dijun, very good points. Indeed one way to solve these issue is to resort to ledger to tell us the truth about which plugins a certain channel understands. For instance, on the ledger we might store the code as well. Design document need to be produced to find consensus :)
jspark84 (Tue, 13 Mar 2018 13:16:35 GMT):
Has joined the channel.
Jojy (Tue, 13 Mar 2018 22:40:34 GMT):
Has joined the channel.
iamdm (Wed, 14 Mar 2018 08:38:52 GMT):
Has joined the channel.
NiallC (Wed, 14 Mar 2018 10:08:34 GMT):
Has joined the channel.
Snixells (Wed, 14 Mar 2018 11:32:19 GMT):
Has joined the channel.
dokany (Wed, 14 Mar 2018 19:01:35 GMT):
Has joined the channel.
fkrzewinski (Fri, 16 Mar 2018 14:30:07 GMT):
Has joined the channel.
anrgbndhu (Mon, 19 Mar 2018 13:43:28 GMT):
Has joined the channel.
protip2 (Tue, 20 Mar 2018 04:44:29 GMT):
Has joined the channel.
CodeReaper (Tue, 20 Mar 2018 05:40:24 GMT):
Hi can anyone explain me the purpose of CryptoSuite_ECDSA_AES ?
adc (Tue, 20 Mar 2018 11:03:10 GMT):
are you referring to the fabric-sdk-node?
adc (Tue, 20 Mar 2018 11:03:10 GMT):
@CodeReaper, are you referring to the fabric-sdk-node?
MuhammadSalah (Tue, 20 Mar 2018 16:37:25 GMT):
Has joined the channel.
MuhammadSalah (Tue, 20 Mar 2018 16:40:59 GMT):
Hello everybody!
I would like to create a composer-runtime that encrypts its data on couchdb; is that possible somehow?
MuhammadSalah (Tue, 20 Mar 2018 16:41:21 GMT):
As well as on the blocks for sure.
ShikarSharma (Tue, 20 Mar 2018 22:42:51 GMT):
Has joined the channel.
hamza113 (Wed, 21 Mar 2018 05:31:13 GMT):
Has joined the channel.
martinvaller (Wed, 21 Mar 2018 10:11:09 GMT):
Has joined the channel.
MuhammadSalah (Wed, 21 Mar 2018 11:14:48 GMT):
Hello, I am trying to run enccc_example; and I have not been lucky
MuhammadSalah (Wed, 21 Mar 2018 11:15:06 GMT):
I am stuck with package vendoring.
MuhammadSalah (Wed, 21 Mar 2018 11:15:37 GMT):
One package of the utils.go; the errors package.
martinvaller (Wed, 21 Mar 2018 11:38:32 GMT):
Hello. I've some issues with tls and I've read this thread and stakoverflow but couldn't find the solution. Everything works well when running without tls. I can create channels, join peers, install chaincode, query and invoke it. As soon as I switch on tls, I can't even create a channel. I'm using following commands with different results below.
martinvaller (Wed, 21 Mar 2018 11:38:40 GMT):
`Command: "peer channel create -o srv-blockchain:7050 -c ch1 -t 50 -f /home/bc/bcnetwork/conf/channel-artifacts/ch1.tx --tls --cafile /home/bc/bcnetwork/conf/crypto-config/ordererOrganizations/ordererorg0/orderers/srv-blockchain.ordererorg0/msp/tlscacerts/tlsca.ordererorg0-cert.pem"
Peer: "Error: failed to create deliver client: orderer client failed to connect to srv-blockchain:7050: failed to create new connection: remote error: tls: bad certificate"
Orderer: "grpc: Server.Serve failed to complete security handshake from "10.31.4.53:46576": tls: client didn't provide a certificate"
`
martinvaller (Wed, 21 Mar 2018 11:38:40 GMT):
`Command: "peer channel create -o srv-blockchain:7050 -c ch1 -t 50 -f /home/bc/bcnetwork/conf/channel-artifacts/ch1.tx --tls --cafile /home/bc/bcnetwork/conf/crypto-config/ordererOrganizations/ordererorg0/orderers/srv-blockchain.ordererorg0/msp/tlscacerts/tlsca.ordererorg0-cert.pem"
Peer: "Error: failed to create deliver client: orderer client failed to connect to srv-blockchain:7050: failed to create new connection: remote error: tls: bad certificate"
Orderer: "grpc: Server.Serve failed to complete security handshake from "10.31.4.53:46576": tls: client didn't provide a certificate"`
martinvaller (Wed, 21 Mar 2018 11:38:40 GMT):
Command: "peer channel create -o srv-blockchain:7050 -c ch1 -t 50 -f /home/bc/bcnetwork/conf/channel-artifacts/ch1.tx --tls --cafile /home/bc/bcnetwork/conf/crypto-config/ordererOrganizations/ordererorg0/orderers/srv-blockchain.ordererorg0/msp/tlscacerts/tlsca.ordererorg0-cert.pem"
Peer: "Error: failed to create deliver client: orderer client failed to connect to srv-blockchain:7050: failed to create new connection: remote error: tls: bad certificate"
Orderer: "grpc: Server.Serve failed to complete security handshake from "10.31.4.53:46576": tls: client didn't provide a certificate"
martinvaller (Wed, 21 Mar 2018 11:39:25 GMT):
Command: "peer channel create -o srv-blockchain:7050 -c ch1 -t 50 -f /home/bc/bcnetwork/conf/channel-artifacts/ch1.tx --tls --cafile /home/bc/bcnetwork/conf/crypto-config/ordererOrganizations/ordererorg0/orderers/srv-blockchain.ordererorg0/msp/admincerts/Admin@ordererorg0-cert.pem"
Peer: "Error: failed to create deliver client: orderer client failed to connect to srv-blockchain:7050: failed to create new connection: x509: certificate signed by unknown authority"
Orderer: 2018-03-21 13:30:22.472 EET [grpc] Printf -> DEBU 20f grpc: Server.Serve failed to complete security handshake from "10.31.4.53:46572": remote error: tls: bad certificate
martinvaller (Wed, 21 Mar 2018 11:40:38 GMT):
Both of these files are present and the /etc/hosts mappings are correct. Also, the tls ca is copied to orderers msp/ca folder.
martinvaller (Wed, 21 Mar 2018 11:41:09 GMT):
I'm using version 1.1.0-rc1
IgorSim (Wed, 21 Mar 2018 14:18:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=Jp5jft9Sb79KFsySy) @martinvaller Is CORE_PEER_TLS_ROOTCERT_FILE set to TLS Root certificate of the organization where peer belongs to?
martinvaller (Wed, 21 Mar 2018 14:19:46 GMT):
Is it correct?
CORE_PEER_TLS_ROOTCERT_FILE=/home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/ca.crt
IgorSim (Wed, 21 Mar 2018 14:25:07 GMT):
I think not, that one is TLS of the peer, what you need is PEM file of the Root CA of ORg0, usually if you follow fabric examples its created under /data folder
IgorSim (Wed, 21 Mar 2018 14:26:11 GMT):
in the case of fabric-ca example where intermediate CA is used it is file located under, for example under /data/org0-ca-chain.pem
martinvaller (Wed, 21 Mar 2018 14:27:19 GMT):
I'm using the cryptogen tool that gives this crypto-config/... structure
FORFIRM (Wed, 21 Mar 2018 14:27:21 GMT):
Has joined the channel.
martinvaller (Wed, 21 Mar 2018 14:28:20 GMT):
I suppose the correct cert is located in crypto-config/ordererOrganizations/ordererorg0/ca
IgorSim (Wed, 21 Mar 2018 14:28:38 GMT):
yes, i think you're right
IgorSim (Wed, 21 Mar 2018 14:29:07 GMT):
sorry, i think you need under peerOrganizations/peerorg0/ca
IgorSim (Wed, 21 Mar 2018 14:31:49 GMT):
basically you need to prefix your command with: CORE_PEER_MSPCONFIGPATH=
IgorSim (Wed, 21 Mar 2018 14:32:32 GMT):
rest of the command you sent: ...-o srv-blockchain:7050 -c ch1 -t 50 -f /home/bc/bcnetwork/conf/channel-artifacts/ch1.tx --tls --cafile /home/bc/bcnetwork/conf/crypto-config/ordererOrganizations/ordererorg0/orderers/srv-blockchain.ordererorg0/msp/tlscacerts/tlsca.ordererorg0-cert.pem" i think it looks ok
martinvaller (Wed, 21 Mar 2018 14:38:37 GMT):
the error message is confusing ""grpc: Server.Serve failed to complete security handshake from "10.31.4.53:46576": tls: client didn't provide a certificate" Does it mean that no certificate was not sent at all or does it mean that it was incorrect certificate...
martinvaller (Wed, 21 Mar 2018 14:40:23 GMT):
also, as I understood, in case of tls "grpcs" should be used instead of "grpc". Does the "grpc" in the error message mean that it uses wrong protocol?
martinvaller (Wed, 21 Mar 2018 14:40:23 GMT):
also, as I understood, in case of tls, "grpcs" should be used instead of "grpc". Does the "grpc" in the error message mean that it uses wrong protocol?
crissi (Wed, 21 Mar 2018 16:46:02 GMT):
Has joined the channel.
nebsterboy (Thu, 22 Mar 2018 07:52:53 GMT):
Hi, I added a new signature scheme to the software-based BCCSP implementation. Now I ask myself what further steps are necessary to use this scheme in a fabric network. Do I have to modify the MSP implementation to use the new scheme or does the MSP implementation use the signature scheme depending on the key type used in the credentials? In the second case, am I right, that ensuring that the certificates are created with the new scheme is enough?
yacovm (Thu, 22 Mar 2018 09:31:59 GMT):
you need a way to store the keys in the MSP @nebsterboy
nebsterboy (Thu, 22 Mar 2018 09:33:10 GMT):
@yacovm how do I store a key in the MSP? I figured out that I need a KeyImporter to create an Identity object from a certificate.
yacovm (Thu, 22 Mar 2018 09:33:28 GMT):
you don't have to use x509 certificates...
yacovm (Thu, 22 Mar 2018 09:33:33 GMT):
you can implement your own MSP
nebsterboy (Thu, 22 Mar 2018 09:35:50 GMT):
ah okay, that's an option. Do you think this is less effort than extending the already existing one? (At the moment, I'm also not sure if it really has to be modified.)
yacovm (Thu, 22 Mar 2018 09:37:08 GMT):
well it depends
yacovm (Thu, 22 Mar 2018 09:37:24 GMT):
do you plan to put the public key inside the x509 cert?
nebsterboy (Thu, 22 Mar 2018 09:39:03 GMT):
I would say yes or are there other options for a working network at the end?
yacovm (Thu, 22 Mar 2018 09:42:29 GMT):
yes of course
yacovm (Thu, 22 Mar 2018 09:42:36 GMT):
you can put a certficate *and* a key alongside it
yacovm (Thu, 22 Mar 2018 09:42:43 GMT):
an MSP identity is just bytes
yacovm (Thu, 22 Mar 2018 09:42:52 GMT):
with 2 things:
yacovm (Thu, 22 Mar 2018 09:42:58 GMT):
1) MSP ID
2) Bytes
yacovm (Thu, 22 Mar 2018 09:44:31 GMT):
for bccsp-msp (the standard MSP),
yacovm (Thu, 22 Mar 2018 09:44:34 GMT):
the bytes is just the PEM
yacovm (Thu, 22 Mar 2018 09:44:45 GMT):
so you can instead - put 2 things- the PEM and the public key
yacovm (Thu, 22 Mar 2018 09:44:47 GMT):
makes sense?
nebsterboy (Thu, 22 Mar 2018 09:46:10 GMT):
okay, yes makes sense. What are the advantages in separating the PEM and the public key? If I understand the code right, at the moment the public key is obtained from the PEM, right?
yacovm (Thu, 22 Mar 2018 09:48:43 GMT):
the advantage of using the pem
yacovm (Thu, 22 Mar 2018 09:48:46 GMT):
is code re-use
yacovm (Thu, 22 Mar 2018 09:48:48 GMT):
for the MSP ;)
yacovm (Thu, 22 Mar 2018 09:48:57 GMT):
you just need to switch to use the other key
yacovm (Thu, 22 Mar 2018 09:49:17 GMT):
no?
yacovm (Thu, 22 Mar 2018 09:49:26 GMT):
oh actually you need the issuer to sign both
yacovm (Thu, 22 Mar 2018 09:49:30 GMT):
so it might be a bit complex
nebsterboy (Thu, 22 Mar 2018 09:54:54 GMT):
So far I thought about changing the key of the certificates and providing a corresponding KeyImporter. Since signing and verifying is related to the type of the key (when using the sw-bccsp), I was wondering if the existing bccsp-msp still works with the new signature scheme. Am I missing anything?
martinvaller (Thu, 22 Mar 2018 14:28:44 GMT):
Need some help with tls. I'm starting the orderer with the following parameter:
martinvaller (Thu, 22 Mar 2018 14:28:48 GMT):
`ORDERER_GENERAL_TLS_ROOTCAS=[
/home/bc/bcnetwork/conf/crypto-config/ordererOrganizations/ordererorg0/orderers/srv-blockchain.ordererorg0/tls/ca.crt,
/home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/ca.crt,/
home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org1/peers/srv-blockchain3.org1/tls/ca.crt]`
martinvaller (Thu, 22 Mar 2018 14:28:48 GMT):
ORDERER_GENERAL_TLS_ROOTCAS=[
/home/bc/bcnetwork/conf/crypto-config/ordererOrganizations/ordererorg0/orderers/srv-blockchain.ordererorg0/tls/ca.crt,
/home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/ca.crt,/
home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org1/peers/srv-blockchain3.org1/tls/ca.crt]
martinvaller (Thu, 22 Mar 2018 14:30:17 GMT):
The question I'm struggling with at the moment is, what should be the value of cafile: peer channel create -o srv-blockchain:7050 -c ch1 -t 50 -f /home/bc/bcnetwork/conf/channel-artifacts/ch1.tx --tls --cafile
martinvaller (Thu, 22 Mar 2018 14:30:17 GMT):
The question I'm struggling with at the moment is, what should be the value of cafile? peer channel create -o srv-blockchain:7050 -c ch1 -t 50 -f /home/bc/bcnetwork/conf/channel-artifacts/ch1.tx --tls --cafile
martinvaller (Thu, 22 Mar 2018 14:31:05 GMT):
The network consists of three parties srv-blockchain as orderer and srv-blockchain2 as peer and srv-blockchain3 as another peer
martinvaller (Thu, 22 Mar 2018 14:31:05 GMT):
The network consists of three parties: srv-blockchain as orderer and srv-blockchain2 as peer and srv-blockchain3 as another peer
martinvaller (Thu, 22 Mar 2018 14:33:14 GMT):
When I try to set the value to "/home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/server.crt " then I get from orderer the response "grpc: Server.Serve failed to complete security handshake from "10.31.4.53:46620": remote error: tls: bad certificate" and from the peer console "Error: failed to create deliver client: orderer client failed to connect to srv-blockchain:7050: failed to create new connection: x509: certificate signed by unknown authority"
martinvaller (Thu, 22 Mar 2018 14:33:14 GMT):
When I try to set the value to "/home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/server.crt " then I get from the orderer the response "grpc: Server.Serve failed to complete security handshake from "10.31.4.53:46620": remote error: tls: bad certificate" and from the peer console "Error: failed to create deliver client: orderer client failed to connect to srv-blockchain:7050: failed to create new connection: x509: certificate signed by unknown authority"
martinvaller (Thu, 22 Mar 2018 14:35:09 GMT):
The servert.crt has "Subject Alternative Names: srv-blockchain2.org0, srv-blockchain2, IP Address:10.31.4.51" which should be enough or should I define the CN also as an IP address
martinvaller (Thu, 22 Mar 2018 14:35:36 GMT):
I'm executing the command on the srv-blockchain2 machine
martinvaller (Thu, 22 Mar 2018 14:40:47 GMT):
As /home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/ca.crt is the issuer of the /home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/server.crt and is defined in orderer command line as ORDERER_GENERAL_TLS_ROOTCAS, then it looks like it should be enough or have I missed something?
martinvaller (Thu, 22 Mar 2018 19:30:27 GMT):
bcconf.zip
martinvaller (Thu, 22 Mar 2018 19:30:57 GMT):
Adding also conf files if somebody has time to take a look
Exci (Fri, 23 Mar 2018 10:05:28 GMT):
Has joined the channel.
mastersingh24 (Fri, 23 Mar 2018 13:35:22 GMT):
@martinvaller The `--cafile` parameter should be set the the root CA which issued the TLS certificate being used by your orderer
mastersingh24 (Fri, 23 Mar 2018 13:35:40 GMT):
My guess is that would be `/home/bc/bcnetwork/conf/crypto-config/ordererOrganizations/ordererorg0/orderers/srv-blockchain.ordererorg0/tls/ca.crt`
martinvaller (Fri, 23 Mar 2018 13:37:51 GMT):
Yes, but for some reason the keyfile and certfile are not taken into account automatically. When I define them explicitly, the tls related error disappear `--cafile ~/bcnetwork/conf/crypto-config/ordererOrganizations/ordererorg0/orderers/srv-blockchain.ordererorg0/tls/ca.crt --keyfile ~/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/server.key --certfile ~/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/server.crt`
mastersingh24 (Fri, 23 Mar 2018 13:39:53 GMT):
You should not need to set the `--keyfile` or `--certfile` unless you have mutual (client auth) TLS enabled
martinvaller (Fri, 23 Mar 2018 13:40:10 GMT):
yes, it is enabled
martinvaller (Fri, 23 Mar 2018 13:41:05 GMT):
Now I'm trying to solve the next error, related to creating a channel. Error message on peer console is ` Failed to reach implicit threshold of 1 sub-policies, required 1 remaining: permission denied` and on orderer console
martinvaller (Fri, 23 Mar 2018 13:41:05 GMT):
Now I'm trying to solve the next error, related to creating a channel. Error message on peer console is ` Failed to reach implicit threshold of 1 sub-policies, required 1 remaining: permission denied` and on orderer console `Principal deserialization failure (the supplied identity is not valid: x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "ca.org0")) `
martinvaller (Fri, 23 Mar 2018 13:42:04 GMT):
I'm using` CORE_PEER_MSPCONFIGPATH="/home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org0/users/Admin@org0/msp"`
martinvaller (Fri, 23 Mar 2018 13:42:04 GMT):
I'm using `CORE_PEER_MSPCONFIGPATH="/home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org0/users/Admin@org0/msp"`
martinvaller (Fri, 23 Mar 2018 14:03:20 GMT):
The certificate orderer tries to verify is Admin@org0 and from orderer logs I can see that
`MSP Org0MSP validating identity
Setting up the MSP manager (3 msps)
MSP manager setup complete, setup 3 msps`
martinvaller (Fri, 23 Mar 2018 14:03:20 GMT):
The certificate orderer tries to verify is Admin@org0 and from orderer logs I can see that
`MSP Org0MSP validating identity
Setting up the MSP manager (3 msps)
MSP manager setup complete, setup 3 msps`
martinvaller (Fri, 23 Mar 2018 14:03:20 GMT):
The certificate orderer tries to verify is Admin@org0 and from orderer logs I can see that
`MSP Org0MSP validating identity, Setting up the MSP manager (3 msps), MSP manager setup complete, setup 3 msps`
bourbonkidQ (Fri, 23 Mar 2018 16:35:27 GMT):
Has joined the channel.
sh777 (Sat, 24 Mar 2018 16:56:23 GMT):
Has joined the channel.
sh777 (Sat, 24 Mar 2018 17:12:20 GMT):
Hi There, I'm getting below error messages from all peers except the first one. I believe the error happens when a peer is connecting to another. How could I skip this cert check or is there another way I can workaround?
`2018-03-24 14:00:00.237 UTC [gossip/comm] sendToEndpoint -> WARN 1cc Failed obtaining connection for 172.16.4.142:7051, PKIid:[41 239 134 75 180 87 199 50 0 204 184 197 17 106 88 153 55 7 235 144 19 90 45 8 241 230 145 24 166 210 146 85] reason: x509: cannot validate certificate for 172.16.4.142 because it doesn't contain any IP SANs
2018-03-24 14:00:00.237 UTC [gossip/discovery] expireDeadMembers -> WARN 1cd Entering [[41 239 134 75 180 87 199 50 0 204 184 197 17 106 88 153 55 7 235 144 19 90 45 8 241 230 145 24 166 210 146 85]]
2018-03-24 14:00:00.237 UTC [gossip/discovery] expireDeadMembers -> WARN 1ce Closing connection to Endpoint: peer2:7051, InternalEndpoint: 172.16.4.142:7051, PKI-ID: [41 239 134 75 180 87 199 50 0 204 184 197 17 106 88 153 55 7 235 144 19 90 45 8 241 230 145 24 166 210 146 85], Metadata: []
2018-03-24 14:00:00.237 UTC [gossip/discovery] expireDeadMembers -> WARN 1cf Exiting
2018-03-24 14:00:00.237 UTC [gossip/comm] sendToEndpoint -> WARN 1d0 Failed obtaining connection for 172.16.3.114:7051, PKIid:[54 43 138 254 123 231 18 41 246 253 115 101 151 85 56 47 202 84 220 237 95 8 118 135 203 76 123 31 20 203 150 122] reason: x509: cannot validate certificate for 172.16.3.114 because it doesn't contain any IP SANs
2018-03-24 14:00:00.237 UTC [gossip/discovery] expireDeadMembers -> WARN 1d2 Entering [[54 43 138 254 123 231 18 41 246 253 115 101 151 85 56 47 202 84 220 237 95 8 118 135 203 76 123 31 20 203 150 122]]
2018-03-24 14:00:00.237 UTC [gossip/discovery] expireDeadMembers -> WARN 1d3 Closing connection to Endpoint: peer3:7051, InternalEndpoint: 172.16.3.114:7051, PKI-ID: [54 43 138 254 123 231 18 41 246 253 115 101 151 85 56 47 202 84 220 237 95 8 118 135 203 76 123 31 20 203 150 122], Metadata: []
2018-03-24 14:00:00.237 UTC [gossip/comm] sendToEndpoint -> WARN 1d1 Failed obtaining connection for 172.16.3.115:7051, PKIid:[149 31 175 182 230 244 157 34 252 11 211 245 61 235 132 205 157 127 93 81 113 240 87 254 176 168 31 32 149 159 230 133] reason: x509: cannot validate certificate for 172.16.3.115 because it doesn't contain any IP SANs
2018-03-24 14:00:00.237 UTC [gossip/discovery] expireDeadMembers -> WARN 1d4 Exiting`
sh777 (Sat, 24 Mar 2018 17:14:42 GMT):
``
abc
sh777 (Sat, 24 Mar 2018 17:19:57 GMT):
sorry about the format
sh777 (Sat, 24 Mar 2018 17:20:05 GMT):
```
2018-03-24 14:00:00.237 UTC [gossip/comm] sendToEndpoint -> WARN 1cc Failed obtaining connection for 172.16.4.142:7051, PKIid:[41 239 134 75 180 87 199 50 0 204 184 197 17 106 88 153 55 7 235 144 19 90 45 8 241 230 145 24 166 210 146 85] reason: x509: cannot validate certificate for 172.16.4.142 because it doesn't contain any IP SANs
2018-03-24 14:00:00.237 UTC [gossip/discovery] expireDeadMembers -> WARN 1cd Entering [[41 239 134 75 180 87 199 50 0 204 184 197 17 106 88 153 55 7 235 144 19 90 45 8 241 230 145 24 166 210 146 85]]
2018-03-24 14:00:00.237 UTC [gossip/discovery] expireDeadMembers -> WARN 1ce Closing connection to Endpoint: peer2:7051, InternalEndpoint: 172.16.4.142:7051, PKI-ID: [41 239 134 75 180 87 199 50 0 204 184 197 17 106 88 153 55 7 235 144 19 90 45 8 241 230 145 24 166 210 146 85], Metadata: []
2018-03-24 14:00:00.237 UTC [gossip/discovery] expireDeadMembers -> WARN 1cf Exiting
2018-03-24 14:00:00.237 UTC [gossip/comm] sendToEndpoint -> WARN 1d0 Failed obtaining connection for 172.16.3.114:7051, PKIid:[54 43 138 254 123 231 18 41 246 253 115 101 151 85 56 47 202 84 220 237 95 8 118 135 203 76 123 31 20 203 150 122] reason: x509: cannot validate certificate for 172.16.3.114 because it doesn't contain any IP SANs
2018-03-24 14:00:00.237 UTC [gossip/discovery] expireDeadMembers -> WARN 1d2 Entering [[54 43 138 254 123 231 18 41 246 253 115 101 151 85 56 47 202 84 220 237 95 8 118 135 203 76 123 31 20 203 150 122]]
2018-03-24 14:00:00.237 UTC [gossip/discovery] expireDeadMembers -> WARN 1d3 Closing connection to Endpoint: peer3:7051, InternalEndpoint: 172.16.3.114:7051, PKI-ID: [54 43 138 254 123 231 18 41 246 253 115 101 151 85 56 47 202 84 220 237 95 8 118 135 203 76 123 31 20 203 150 122], Metadata: []
2018-03-24 14:00:00.237 UTC [gossip/comm] sendToEndpoint -> WARN 1d1 Failed obtaining connection for 172.16.3.115:7051, PKIid:[149 31 175 182 230 244 157 34 252 11 211 245 61 235 132 205 157 127 93 81 113 240 87 254 176 168 31 32 149 159 230 133] reason: x509: cannot validate certificate for 172.16.3.115 because it doesn't contain any IP SANs
2018-03-24 14:00:00.237 UTC [gossip/discovery] expireDeadMembers -> WARN 1d4 Exiting
```
martinvaller (Sat, 24 Mar 2018 19:03:55 GMT):
@sh777 You could add the IP SANS when generating the certificates. I'm adding the ip-s to crypto-config.yaml as following:
` - Name: Org1
Domain: org1
Specs:
- Hostname: srv-blockchain3
# CommonName: 10.31.4.53
SANS:
- 10.31.4.53 `
martinvaller (Sat, 24 Mar 2018 19:03:55 GMT):
@sh777 You could add the IP SANS when generating the certificates. I'm adding the ip-s to crypto-config.yaml as following:
`- Name: Org1
Domain: org1
Specs:
- Hostname: srv-blockchain3
# CommonName: 10.31.4.53
SANS:
- 10.31.4.53 `
martinvaller (Sat, 24 Mar 2018 19:03:55 GMT):
@sh777 You could add the IP SANS when generating the certificates. I'm adding the ip-s to crypto-config.yaml as following:
`- Name: Org1
Domain: org1
Specs:
- Hostname: srv-blockchain3
# CommonName: 10.31.4.53
SANS:
- 10.31.4.53`
martinvaller (Sat, 24 Mar 2018 19:03:55 GMT):
@sh777 You could add the IP SANS when generating the certificates. I'm adding the ip-s to crypto-config.yaml as following:
`- Name: Org1
Domain: org1
Specs:
- Hostname: srv-blockchain3
SANS:
- 10.31.4.53`
martinvaller (Sat, 24 Mar 2018 19:03:55 GMT):
@sh777 You could add the IP SANS when generating the certificates. I'm adding the ip-s to crypto-config.yaml as following:
`- Name: Org1`
Domain: org1
Specs:
- Hostname: srv-blockchain3
SANS:
- 10.31.4.53`
martinvaller (Sat, 24 Mar 2018 19:03:55 GMT):
@sh777 You could add the IP SANS when generating the certificates. I'm adding the ip-s to crypto-config.yaml as following:
`- Name: Org1`
` Domain: org1`
` Specs:`
` - Hostname: srv-blockchain3`
` SANS:`
` - 10.31.4.53`
sh777 (Sun, 25 Mar 2018 03:48:35 GMT):
@martinvaller thanks for replying. I'm using k8s to manage peers. Therefore the ip address of these peers are not fixed. Is there anything I can do about it?
martinvaller (Sun, 25 Mar 2018 06:35:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=7G6AybsYKNstv48SZ) While upgrading from 1.0 to 1.1 I missed the ` AdminPrincipal: Role.ADMIN` in configtx.yaml and after adding this parameter the error disappeared.
martinvaller (Sun, 25 Mar 2018 13:50:12 GMT):
I was able to create a channel with the following command:
`peer channel create -o srv-blockchain:7050 -c ch1 -t 50 -f /home/bc/bcnetwork/conf/channel-artifacts/ch1.tx --tls --cafile ~/bcnetwork/conf/crypto-config/ordererOrganizations/ordererorg0/orderers/srv-blockchain.ordererorg0/tls/ca.crt --clientauth --keyfile ~/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/server.key --certfile ~/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/server.crt`
martinvaller (Sun, 25 Mar 2018 13:50:12 GMT):
I was able to create a channel with the following command: `peer channel create -o srv-blockchain:7050 -c ch1 -t 50 -f /home/bc/bcnetwork/conf/channel-artifacts/ch1.tx --tls --cafile ~/bcnetwork/conf/crypto-config/ordererOrganizations/ordererorg0/orderers/srv-blockchain.ordererorg0/tls/ca.crt --clientauth --keyfile ~/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/server.key --certfile ~/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/server.crt`
When I want to install the chaincode from the same machine with the command `peer chaincode install -n chaincode_example02 -v 1.0 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 --tls --cafile /home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/ca.crt --clientauth --keyfile /home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/server.kery --certfile /home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/server.crt` then I get the following error on peer `Server.Serve failed to complete security handshake from "127.0.0.1:46420": tls: first record does not look like a TLS handshake`
Whe I'm connecting to the srv-blockchain2 with openssl, then everything looks ok `openssl s_client -connect srv-blockchain2:7051 -CAfile /home/bc/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/ca.crt -cert ~/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/server.crt -key ~/bcnetwork/conf/crypto-config/peerOrganizations/org0/peers/srv-blockchain2.org0/tls/server.key`
Could someone give a hint what is wrong? The srv-blockchain2 certificate has `Subject Alternative Names: srv-blockchain2.org0, srv-blockchain2, IP Address:10.31.4.51, IP Address:127.0.0.1`.
hantzaras (Sun, 25 Mar 2018 14:20:48 GMT):
Has joined the channel.
sh777 (Sun, 25 Mar 2018 14:42:43 GMT):
@martinvaller have you set this on each peer?
```
- name: CORE_PEER_GOSSIP_SKIPHANDSHAKE
value: "true"
```
yacovm (Sun, 25 Mar 2018 15:09:05 GMT):
that thing doesn't do anything, @sh777
martinvaller (Sun, 25 Mar 2018 16:26:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=PAWtNLKDJKhFKyWDM) @sh777 Yes and I'm wondering whether the `peer channel list` uses at all the certificates to establish a tls connection. As I change the certificate and key values to non-existant files, the `peer channel list` command does not give an error that these files do not exist but still connects to peer, resulting with `Server.Serve failed to complete security handshake from "127.0.0.1:46420": tls: first record does not look like a TLS handshake`
martinvaller (Sun, 25 Mar 2018 17:43:35 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=bERvSSG8j66eezb8R)
It seems that it is not the meant to work at all: https://jira.hyperledger.org/browse/FAB-7630 This makes the maintenance of fabric network rather difficult. :-(
expherience (Mon, 26 Mar 2018 20:36:39 GMT):
Has joined the channel.
kingofsevens (Wed, 28 Mar 2018 06:11:22 GMT):
Has joined the channel.
KGiou (Wed, 28 Mar 2018 08:26:47 GMT):
Has joined the channel.
KOttoni (Wed, 28 Mar 2018 16:52:42 GMT):
Has joined the channel.
JiuZhuYou (Sat, 31 Mar 2018 10:39:31 GMT):
Has joined the channel.
huy.tranibm (Tue, 03 Apr 2018 05:07:59 GMT):
Has joined the channel.
huy.tranibm (Tue, 03 Apr 2018 05:09:32 GMT):
Hello everyone. Can someone help me decipher this error message. My query is able to return a status code of 200 along with the payload but the signature verification failed.
```[2018-04-03 05:07:13.754 UTC] [ERROR ] CryptoPrimitives - Cannot validate certificate. Error is: signature check failed
Certificate [0] Version: 3
SerialNumber: 637774061094025636436369095560695652744478705001
IssuerDN: C=US,ST=North Carolina,O=Hyperledger,OU=Fabric,CN=fabric-ca-server-org1CA
Start Date: Fri Mar 16 17:06:00 CDT 2018
Final Date: Wed Feb 13 00:11:00 CST 2019
SubjectDN: C=US,ST=North Carolina,O=Hyperledger,OU=client+OU=org1,CN=peer1
Public Key: EC Public Key [41:45:47:cb:24:45:ca:4b:c8:3e:b5:40:fa:56:22:eb:67:86:8a:e0]
X: e92172a3fd0329aec059e5f7cafa26657703b8358beae795ccb631f4a27ec2f4
Y: 25798abb5659c1220e888953c56b74f68d6d01a7b6c5f3858be79bb36339ce27
Signature Algorithm: SHA256WITHECDSA
Signature: 304402206d54942dad71ee6b1f5606f034f9c018
88405f8f80924752e6982c147b82998102203a96
a79f64c4d336e956ae8d7e6fbafcf1a2a55a0384
49f18e812e148336f1dc
Extensions:
critical(true) KeyUsage: 0x4
critical(true) BasicConstraints: isCa(false)
critical(false) 2.5.29.14 value = DER Octet String[20]
critical(false) 2.5.29.35 value = Sequence
Tagged [0] IMPLICIT
DER Octet String[20]
critical(false) 2.5.29.17 value = Sequence
Tagged [2] IMPLICIT
DER Octet String[0]
critical(false) 1.2.3.4.5.6.7.8.1 value = java.io.EOFException: DEF length 116 object truncated by 84```
the "1.2.3.4.5.6.7.8.1 value =" seems suspicious to me but i dont know how to read it. Thank you very much
Rumeel_Hussain (Tue, 03 Apr 2018 15:02:52 GMT):
Has joined the channel.
huy.tranibm (Tue, 03 Apr 2018 20:34:18 GMT):
Hello guys can someone help me figure out this. I've decoded the cert:
```huys-mbp-2:Desktop huytranibm$ keytool -printcert -file ibpEndorserCert.pem -v
Owner: CN=peer1d57, OU=client + OU=org1, O=Hyperledger, ST=North Carolina, C=US
Issuer: CN=fabric-ca-server-org1CA, OU=Fabric, O=Hyperledger, ST=North Carolina, C=US
Serial number: 791c69801442cba468a801a8c118f5c2678d9b38
Valid from: Fri Mar 30 10:19:00 CDT 2018 until: Tue Feb 26 17:24:00 CST 2019
Certificate fingerprints:
MD5: DE:A3:35:0D:11:19:A8:DC:2A:90:15:6C:21:A8:FB:2F
SHA1: 56:E0:E3:2E:FB:A1:F8:DE:0F:BB:15:3D:98:EA:76:51:32:A8:26:AB
SHA256: 83:80:23:FD:09:21:7D:AC:8B:7F:16:98:43:36:5D:28:F7:8C:75:2B:E9:11:5D:C3:EA:DC:42:E9:B1:D2:03:0E
Signature algorithm name: SHA256withECDSA
Version: 3
Extensions:
#1: ObjectId: 1.2.3.4.5.6.7.8.1 Criticality=false
0000: 7B 22 61 74 74 72 73 22 3A 7B 22 68 66 2E 41 66 ."attrs":."hf.Af
0010: 66 69 6C 69 61 74 69 6F 6E 22 3A 22 6F 72 67 31 filiation":"org1
0020: 22 2C 22 68 66 2E 45 6E 72 6F 6C 6C 6D 65 6E 74 ","hf.Enrollment
0030: 49 44 22 3A 22 70 65 65 72 31 64 35 37 22 2C 22 ID":"peer1d57","
0040: 68 66 2E 54 79 70 65 22 3A 22 63 6C 69 65 6E 74 hf.Type":"client
0050: 22 7D 7D "..
#2: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 66 3A 7C 1D 41 C9 B7 48 29 EC D7 3C D5 A7 35 D7 f:..A..H)..<..5.
0010: F4 04 58 1C ..X.
]
]
#3: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
]
#4: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Key_CertSign
]
#5: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName:
]
#6: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 8D 65 5A 1F ED E9 60 BE DB B9 D8 F2 DB F8 24 EC .eZ...`.......$.
0010: 38 94 7F 4C 8..L
]
]
```
huy.tranibm (Tue, 03 Apr 2018 20:35:26 GMT):
looks like my ObjectId: 1.2.3.4.5.6.7.8.1 is throwing the error ```java.io.EOFException: DEF length 116 object truncated by 84```, is there a maximum size to extensions?
RadW2020 (Wed, 04 Apr 2018 19:01:31 GMT):
Has joined the channel.
cbf (Thu, 05 Apr 2018 18:20:10 GMT):
@elli-androulaki @jyellick @JonathanLevi @aso https://gerrit.hyperledger.org/r/c/15707/ we can probably remove the -2s and progress this now that we're in 1.2
jyellick (Thu, 05 Apr 2018 18:22:02 GMT):
Good idea. As a note to the implementors, I know @sykesm is working on making the e2e a bit more re-usable, so it might be a good idea to coordinate with him. I'll add this as a note to the CR as well
sykesm (Thu, 05 Apr 2018 18:22:02 GMT):
Has joined the channel.
elli-androulaki (Thu, 05 Apr 2018 18:22:19 GMT):
+1!
elli-androulaki (Thu, 05 Apr 2018 18:22:26 GMT):
Adding @mdu
mdu (Thu, 05 Apr 2018 18:22:26 GMT):
Has joined the channel.
JonathanLevi (Thu, 05 Apr 2018 18:47:00 GMT):
Sure, that's for the test. I will remove my veto.
JonathanLevi (Thu, 05 Apr 2018 18:47:50 GMT):
Isn't IdMix available already in 1.1 (without needing to rebuild with the experimental flag) ?
JonathanLevi (Thu, 05 Apr 2018 18:48:30 GMT):
I think it was merged and did not get disabled. I can check with our guys, but that's what they told me.
yacovm (Thu, 05 Apr 2018 18:49:59 GMT):
IIRC the SDK support was never fully implemented, the only client side that was ever merged to v1.1 is peer CLI support
yacovm (Thu, 05 Apr 2018 18:50:17 GMT):
but @manu or @mdu would know for sure
yacovm (Thu, 05 Apr 2018 18:50:54 GMT):
also endorsing with idemix credentials is a bit tricky in v1.1
yacovm (Thu, 05 Apr 2018 18:51:25 GMT):
verifying is working, but endorsing means custom ESCC :sick:
jyellick (Thu, 05 Apr 2018 19:17:32 GMT):
Yes, the idemix MSP implementation was merged for v1.1
jyellick (Thu, 05 Apr 2018 19:17:45 GMT):
But, since there was no client support, we did not want to advertise an incomplete feature
jyellick (Thu, 05 Apr 2018 19:18:26 GMT):
So, when client support is merged in v1.2, we have a full story. And, if users wish to not upgrade their v1.1 channels to v1.2, they can still take advantage of idemix so long as they use the newer client versions.
SmartContract2018 (Thu, 05 Apr 2018 19:35:09 GMT):
Has joined the channel.
kkado (Sat, 07 Apr 2018 04:11:39 GMT):
Has joined the channel.
pb (Mon, 09 Apr 2018 11:02:58 GMT):
Has joined the channel.
pb (Mon, 09 Apr 2018 11:03:37 GMT):
Hi,
Can anyone please tell me how cryptogen generate works?
CodeReaper (Mon, 09 Apr 2018 11:49:48 GMT):
Hi, I'm trying to use the inbuilt encryption encryption library in chaincode for RSA using rsa keys(not even sure if it's allowed), but I cannot find any documentation or sample on the topic
CodeReaper (Mon, 09 Apr 2018 11:50:06 GMT):
Clipboard - April 9, 2018 5:20 PM
CodeReaper (Mon, 09 Apr 2018 11:50:24 GMT):
"the opts argument should be appropriate for algorithm used"? Where can I take a reference of this appropriate format?
yacovm (Mon, 09 Apr 2018 11:51:22 GMT):
@adc can you help him?
yacovm (Mon, 09 Apr 2018 11:51:22 GMT):
@adc / @aso can you help him?
CodeReaper (Mon, 09 Apr 2018 12:08:52 GMT):
I understand that PRNG is to be used instead of IV in asymmetric encryption, but I cannot find any way initialize rsa encrypter entity or any documentation which will lead up to it
adc (Mon, 09 Apr 2018 12:36:05 GMT):
@CodeReaper, yes, the options depend on the algorithm
adc (Mon, 09 Apr 2018 12:36:39 GMT):
fabric does not have any supporto for asymmetric encryption so far
adc (Mon, 09 Apr 2018 12:36:39 GMT):
fabric does not have any support for asymmetric encryption so far
adc (Mon, 09 Apr 2018 12:36:58 GMT):
that's the reason why you don't find it
CodeReaper (Mon, 09 Apr 2018 12:48:59 GMT):
@adc How can I make a user share an asset such that it its only visible to that user only?
CodeReaper (Mon, 09 Apr 2018 12:49:29 GMT):
State database of any peer shouldn't reveal the asset
CodeReaper (Mon, 09 Apr 2018 12:50:33 GMT):
Also symmetric key won't work because user A is passing asset to user B, so A is invoking
yacovm (Mon, 09 Apr 2018 12:53:04 GMT):
You need a PRF though, not a PRNG
adc (Mon, 09 Apr 2018 12:54:57 GMT):
@CodeReaper, leveraging asymmetric encryption is certainly an option. If you want to pursuit that one then you can use directly the rsa package (for example) in your chaincode
adc (Mon, 09 Apr 2018 12:54:57 GMT):
@CodeReaper, leveraging asymmetric encryption is certainly an option. If you want to pursuit that direction then you can use directly the rsa package (for example) in your chaincode
CodeReaper (Mon, 09 Apr 2018 12:58:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=B6e7TvWoLcco44irA) @adc rsa package doesn't give deterministic output because of the paddings present in it.
CodeReaper (Mon, 09 Apr 2018 12:59:58 GMT):
I'm trying to fork and change rsa and io so as to get deterministic out put taking the seed element from outside but have been failing so far
CodeReaper (Mon, 09 Apr 2018 12:59:58 GMT):
I'm trying to fork and change rsa and io so as to get deterministic output taking the seed element from outside but have been failing so far
CodeReaper (Mon, 09 Apr 2018 13:05:59 GMT):
Is there no other way to have data privacy in between users?
CodeReaper (Mon, 09 Apr 2018 13:06:44 GMT):
I looked at sideDB but its not granular enough and still not in production state
adc (Mon, 09 Apr 2018 13:31:36 GMT):
@CodeReaper, have you tried to pass a customized io.Reader to EncryptOAEP?
adc (Mon, 09 Apr 2018 13:32:22 GMT):
so what you could do is to have the client send, via transient, a seed and then you can use a PRF (SHA2) to produce randomness in a deterministic way
CodeReaper (Mon, 09 Apr 2018 13:35:40 GMT):
@adc doing exactly that. Can I share some code specs, I cannot make it work
adc (Mon, 09 Apr 2018 13:35:53 GMT):
please
jeffprestes (Mon, 09 Apr 2018 19:23:19 GMT):
Has joined the channel.
CodeReaper (Mon, 09 Apr 2018 22:07:04 GMT):
Anyone who can solve this- https://stackoverflow.com/questions/49742385/unable-to-decrypt-an-rsa-encryption-with-oaep-padding-with-a-custom-defined-seed
paul.sitoh (Tue, 10 Apr 2018 08:39:57 GMT):
Has joined the channel.
Actipierre (Tue, 10 Apr 2018 10:00:52 GMT):
Has joined the channel.
CodeReaper (Tue, 10 Apr 2018 12:13:03 GMT):
Hi, I have a question on the attributes of the entities. Can all the attributes be overridden at the time of enrollment or some can be fixed when registering?
mastersingh24 (Tue, 10 Apr 2018 13:25:22 GMT):
attribute cannot be overwritten at enrollment .... you can select which ones you want to have in your cert, but you can't change their value
mastersingh24 (Tue, 10 Apr 2018 13:25:50 GMT):
in v1.1, you can update the attributes of a user after registration as long as you have permission
pb (Wed, 11 Apr 2018 05:00:02 GMT):
User User_1 added by pb.
yxnl (Thu, 12 Apr 2018 15:08:32 GMT):
Has joined the channel.
jerry-zww (Thu, 12 Apr 2018 15:29:17 GMT):
Has joined the channel.
floatware (Thu, 12 Apr 2018 19:08:33 GMT):
Has joined the channel.
huy.tranibm (Fri, 13 Apr 2018 16:17:10 GMT):
Hello guys, I am getting this error with the peer's cert with 1.1 attribute features. any idea why the EOFException is happening?
```2018-04-13 11:14:40.012 ERROR 31050 --- [nio-8989-exec-2] o.h.f.sdk.security.CryptoPrimitives : Cannot validate certificate. Error is: signature check failed
Certificate [0] Version: 3
SerialNumber: 16287975114198633361461188947871007615147607371
IssuerDN: C=US,ST=North Carolina,O=Hyperledger,OU=Fabric,CN=fabric-ca-server-org1CA
Start Date: Wed Apr 11 10:44:00 CDT 2018
Final Date: Sun Mar 10 18:49:00 CDT 2019
SubjectDN: C=US,ST=North Carolina,O=Hyperledger,OU=client+OU=org1,CN=peer0ec3
Public Key: EC Public Key [de:fe:4b:34:bf:2f:9f:ea:06:dc:2f:15:fd:6d:07:0f:e4:0e:b0:1e]
X: f9a225e4c604bc65666767f9e8ff93c9d19775352770e63013e5dcd8c17e9a6b
Y: 1429627dcf37aa70674b78581c29a4bf5870649486357682ed294ad31c078c48
Signature Algorithm: SHA256WITHECDSA
Signature: 304402200fe689074692343ae80572243a23bc69
b4ff5431a5e0fbc9a95cb0f1065bff7402205459
54b5131d9d03bad721eafcefd99caae6997d6568
93c047c0666b5f112925
Extensions:
critical(true) KeyUsage: 0x4
critical(true) BasicConstraints: isCa(false)
critical(false) 2.5.29.14 value = DER Octet String[20]
critical(false) 2.5.29.35 value = Sequence
Tagged [0] IMPLICIT
DER Octet String[20]
critical(false) 2.5.29.17 value = Sequence
Tagged [2] IMPLICIT
DER Octet String[0]
critical(false) 1.2.3.4.5.6.7.8.1 value = java.io.EOFException: DEF length 116 object truncated by 84
```
huy.tranibm (Fri, 13 Apr 2018 16:18:05 GMT):
here is the cert printed out using keytool -printcert
```huys-mbp-2:Fabric-verify-test huytranibm$ keytool -printcert -v -file ibpendorsorCert.pem
Owner: CN=peer0ec3, OU=client + OU=org1, O=Hyperledger, ST=North Carolina, C=US
Issuer: CN=fabric-ca-server-org1CA, OU=Fabric, O=Hyperledger, ST=North Carolina, C=US
Serial number: 2da60c8d52aecf0cbe1b89dfda05b15b2f4854b
Valid from: Wed Apr 11 10:44:00 CDT 2018 until: Sun Mar 10 18:49:00 CDT 2019
Certificate fingerprints:
MD5: D7:C3:FD:7C:76:73:09:A3:2F:7E:41:2E:2E:DB:DC:9E
SHA1: 7C:F0:6B:26:B3:57:AA:1D:26:E3:C4:67:A4:20:AE:42:60:41:F6:70
SHA256: 16:57:3D:A8:B0:8D:C7:9E:7A:42:35:F2:4A:67:F8:9C:49:3B:A4:B6:72:0D:D9:58:37:F3:92:A3:CB:44:AE:41
Signature algorithm name: SHA256withECDSA
Version: 3
Extensions:
#1: ObjectId: 1.2.3.4.5.6.7.8.1 Criticality=false
0000: 7B 22 61 74 74 72 73 22 3A 7B 22 68 66 2E 41 66 ."attrs":."hf.Af
0010: 66 69 6C 69 61 74 69 6F 6E 22 3A 22 6F 72 67 31 filiation":"org1
0020: 22 2C 22 68 66 2E 45 6E 72 6F 6C 6C 6D 65 6E 74 ","hf.Enrollment
0030: 49 44 22 3A 22 70 65 65 72 30 65 63 33 22 2C 22 ID":"peer0ec3","
0040: 68 66 2E 54 79 70 65 22 3A 22 63 6C 69 65 6E 74 hf.Type":"client
0050: 22 7D 7D "..
#2: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: FA 3C 17 92 B4 80 E9 39 A5 63 CE 07 00 4F 44 B1 .<.....9.c...OD.
0010: 60 5A 76 B0 `Zv.
]
]
#3: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
]
#4: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
Key_CertSign
]
#5: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName:
]
#6: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: F9 32 B2 81 E3 82 B5 48 52 4B 88 D8 BB F0 E6 12 .2.....HRK......
0010: B0 B6 F1 DE ....
]
]
```
huy.tranibm (Fri, 13 Apr 2018 16:18:09 GMT):
thank you
huy.tranibm (Fri, 13 Apr 2018 16:18:38 GMT):
also is it ok for this peer's cert to be of type hf.type=client, should it be hf.type=peer?
sklymenko (Fri, 13 Apr 2018 17:54:36 GMT):
Has joined the channel.
Ashish (Sat, 14 Apr 2018 17:50:29 GMT):
Hi, When we execute cryptogen, we are creating a big bunch of files. Just wondering whether we have an explanation for each folder / file anywhere?
Ashish (Sat, 14 Apr 2018 17:50:55 GMT):
I know that some of these files are not used or may be redundant.
Ashish (Sat, 14 Apr 2018 17:51:45 GMT):
./ordererOrganizations: Orderer
./ordererOrganizations/Orderer: tlsca ca orderers msp users
./ordererOrganizations/Orderer/tlsca: tlsca.Orderer-cert.pem ca2a06a41f435dfcc706dc01daad5d3cb7daaa135345899c0f694c0699e3f94d_sk
./ordererOrganizations/Orderer/ca: 40bbf5bd5371e3f85804e4efe53ab521d59129ef06780cd4dc2def029a0bfff5_sk ca.Orderer-cert.pem
./ordererOrganizations/Orderer/orderers: orderer.Orderer
./ordererOrganizations/Orderer/orderers/orderer.Orderer: msp tls
./ordererOrganizations/Orderer/orderers/orderer.Orderer/msp: signcerts cacerts keystore admincerts tlscacerts
./ordererOrganizations/Orderer/orderers/orderer.Orderer/msp/signcerts: orderer.Orderer-cert.pem
./ordererOrganizations/Orderer/orderers/orderer.Orderer/msp/cacerts: ca.Orderer-cert.pem
./ordererOrganizations/Orderer/orderers/orderer.Orderer/msp/keystore: fed28f680ebdd39ab59df56efa79f819cc9e08cec33dfb6e51272bf4609a4178_sk
./ordererOrganizations/Orderer/orderers/orderer.Orderer/msp/admincerts: Admin@Orderer-cert.pem
./ordererOrganizations/Orderer/orderers/orderer.Orderer/msp/tlscacerts: tlsca.Orderer-cert.pem
./ordererOrganizations/Orderer/orderers/orderer.Orderer/tls: server.crt ca.crt server.key
./ordererOrganizations/Orderer/msp: cacerts admincerts tlscacerts
./ordererOrganizations/Orderer/msp/cacerts: ca.Orderer-cert.pem
./ordererOrganizations/Orderer/msp/admincerts: Admin@Orderer-cert.pem
./ordererOrganizations/Orderer/msp/tlscacerts: tlsca.Orderer-cert.pem
./ordererOrganizations/Orderer/users: Admin@Orderer
./ordererOrganizations/Orderer/users/Admin@Orderer: msp tls
./ordererOrganizations/Orderer/users/Admin@Orderer/msp: signcerts cacerts keystore admincerts tlscacerts
./ordererOrganizations/Orderer/users/Admin@Orderer/msp/signcerts: Admin@Orderer-cert.pem
./ordererOrganizations/Orderer/users/Admin@Orderer/msp/cacerts: ca.Orderer-cert.pem
./ordererOrganizations/Orderer/users/Admin@Orderer/msp/keystore: 1703c0da4a42a511bf1a7109d31398a5e63ebcbd91530f44bcf55e91aaeb67c1_sk
./ordererOrganizations/Orderer/users/Admin@Orderer/msp/admincerts: Admin@Orderer-cert.pem
./ordererOrganizations/Orderer/users/Admin@Orderer/msp/tlscacerts: tlsca.Orderer-cert.pem
./ordererOrganizations/Orderer/users/Admin@Orderer/tls: server.crt ca.crt server.key
Ashish (Sat, 14 Apr 2018 17:51:45 GMT):
./ordererOrganizations: Orderer
./ordererOrganizations/Orderer: tlsca ca orderers msp users
./ordererOrganizations/Orderer/tlsca: tlsca.Orderer-cert.pem ca2a06a41f435dfcc706dc01daad5d3cb7daaa135345899c0f694c0699e3f94d_sk
./ordererOrganizations/Orderer/ca: 40bbf5bd5371e3f85804e4efe53ab521d59129ef06780cd4dc2def029a0bfff5_sk ca.Orderer-cert.pem
./ordererOrganizations/Orderer/orderers: orderer.Orderer
./ordererOrganizations/Orderer/orderers/orderer.Orderer: msp tls
./ordererOrganizations/Orderer/orderers/orderer.Orderer/msp: signcerts cacerts keystore admincerts tlscacerts
./ordererOrganizations/Orderer/orderers/orderer.Orderer/msp/signcerts: orderer.Orderer-cert.pem
./ordererOrganizations/Orderer/orderers/orderer.Orderer/msp/cacerts: ca.Orderer-cert.pem
./ordererOrganizations/Orderer/orderers/orderer.Orderer/msp/keystore: fed28f680ebdd39ab59df56efa79f819cc9e08cec33dfb6e51272bf4609a4178_sk
./ordererOrganizations/Orderer/orderers/orderer.Orderer/msp/admincerts: Admin@Orderer-cert.pem
./ordererOrganizations/Orderer/orderers/orderer.Orderer/msp/tlscacerts: tlsca.Orderer-cert.pem
./ordererOrganizations/Orderer/orderers/orderer.Orderer/tls: server.crt ca.crt server.key
./ordererOrganizations/Orderer/msp: cacerts admincerts tlscacerts
./ordererOrganizations/Orderer/msp/cacerts: ca.Orderer-cert.pem
./ordererOrganizations/Orderer/msp/admincerts: Admin@Orderer-cert.pem
./ordererOrganizations/Orderer/msp/tlscacerts: tlsca.Orderer-cert.pem
./ordererOrganizations/Orderer/users: Admin@Orderer
./ordererOrganizations/Orderer/users/Admin@Orderer: msp tls
./ordererOrganizations/Orderer/users/Admin@Orderer/msp: signcerts cacerts keystore admincerts tlscacerts
./ordererOrganizations/Orderer/users/Admin@Orderer/msp/signcerts: Admin@Orderer-cert.pem
./ordererOrganizations/Orderer/users/Admin@Orderer/msp/cacerts: ca.Orderer-cert.pem
./ordererOrganizations/Orderer/users/Admin@Orderer/msp/keystore: 1703c0da4a42a511bf1a7109d31398a5e63ebcbd91530f44bcf55e91aaeb67c1_sk
./ordererOrganizations/Orderer/users/Admin@Orderer/msp/admincerts: Admin@Orderer-cert.pem
./ordererOrganizations/Orderer/users/Admin@Orderer/msp/tlscacerts: tlsca.Orderer-cert.pem
./ordererOrganizations/Orderer/users/Admin@Orderer/tls: server.crt ca.crt server.key
Ashish (Sat, 14 Apr 2018 17:52:27 GMT):
This is just the orderer.
huy.tranibm (Sat, 14 Apr 2018 20:32:01 GMT):
@Ashish its just certs/keys, please understand asymmetric and symmetric encryption.
bdu 5 (Sat, 14 Apr 2018 20:59:04 GMT):
Has joined the channel.
mozkarakoc (Sun, 15 Apr 2018 13:01:35 GMT):
Has joined the channel.
mozkarakoc (Sun, 15 Apr 2018 13:17:42 GMT):
hi, how can i prevent an enrolled user from invoking some chaincodes? with msp or in chaincode?
yacovm (Sun, 15 Apr 2018 13:18:59 GMT):
You can either code in the chaincode
yacovm (Sun, 15 Apr 2018 13:19:06 GMT):
or create and install an auth handler @mozkarakoc
yacovm (Sun, 15 Apr 2018 13:19:30 GMT):
(auth filter)
yacovm (Sun, 15 Apr 2018 13:20:23 GMT):
https://github.com/hyperledger/fabric/blob/release-1.1/sampleconfig/core.yaml#L345-L367
yacovm (Sun, 15 Apr 2018 13:20:26 GMT):
check the above link
mozkarakoc (Sun, 15 Apr 2018 13:25:35 GMT):
I think auth filter is advanced level. :) @yacovm I need easier tutorial about it.
in chaincode, how can I get the identity role that invoking the chaincode
yacovm (Sun, 15 Apr 2018 13:25:53 GMT):
there is a library `cid`
yacovm (Sun, 15 Apr 2018 13:25:55 GMT):
google it
mozkarakoc (Sun, 15 Apr 2018 14:27:27 GMT):
@yacovm I found a good tutorial for `cid` in medium, thanks! one more thing about auth filter and decorators, if I want to create auth handler, should I rebuild fabric with source? Can i use it with docker?
mozkarakoc (Sun, 15 Apr 2018 14:27:27 GMT):
@yacovm I found a good tutorial for `cid` in medium post, thanks! one more thing about auth filter and decorators, if I want to create auth handler, should I rebuild fabric with source? Can i use it with docker?
yacovm (Sun, 15 Apr 2018 14:28:15 GMT):
you don't have to
yacovm (Sun, 15 Apr 2018 14:28:19 GMT):
you can compile it as a plugin
yacovm (Sun, 15 Apr 2018 14:28:24 GMT):
and then put it in the folder
yacovm (Sun, 15 Apr 2018 14:28:36 GMT):
look at the comments in the `core.yaml` in the link i posted
mozkarakoc (Sun, 15 Apr 2018 14:37:20 GMT):
ok, got it now. thanks again
Ashish (Sun, 15 Apr 2018 15:40:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=nj67xPwcTDjxKd2i8) @huy.tranibm I know that. But have you taken a look at the number of files inside a peer? or orderer? There are so many. If these folders are getting generated, there has to be an explanation for each folder - each file. i.e, if we go about these folders to be used by general users. They will ask questions
sunnrunner (Sun, 15 Apr 2018 19:07:08 GMT):
Has joined the channel.
raccoonrat (Mon, 16 Apr 2018 02:11:41 GMT):
Has joined the channel.
SaraEmily (Mon, 16 Apr 2018 09:49:49 GMT):
Has joined the channel.
huy.tranibm (Mon, 16 Apr 2018 15:24:58 GMT):
@Ashish your right there seems to be much confusion between certs for msp and tls and it would save a lot of time. I think its assumed that people will look through the docker-compose.yaml and figure it out on their own, but yes some explanation would save a lot of time.
fmkhan.rubel (Wed, 18 Apr 2018 19:08:32 GMT):
Has joined the channel.
Titret (Thu, 19 Apr 2018 00:51:48 GMT):
Has joined the channel.
IanBradbury_Rex (Thu, 19 Apr 2018 14:04:15 GMT):
Has joined the channel.
IanBradbury_Rex (Thu, 19 Apr 2018 14:07:33 GMT):
Hello. I have a concern - best described with this question.
What happens when a private blockchain certificate expires?```
Here's the scenario. Private blockchain - built on the Hyperledger Fabric technology. At start up you created certificate authorities for each of the network participant organisations and certificates for all of the peers etc.
Sometime later..... these certificates start to expire.
Q : What happens then?
Q : How are the certificates managed and renewed?
Q : How does that affect the blockchain?
If someone has a great link they can share or even a simple answer that would be brilliant.
IanBradbury_Rex (Thu, 19 Apr 2018 14:08:08 GMT):
Hello. I have a concern - best described with this question.
What happens when a private blockchain certificate expires?
Here's the scenario. Private blockchain - built on the Hyperledger Fabric technology. At start up you created certificate authorities for each of the network participant organisations and certificates for all of the peers etc.
Sometime later..... these certificates start to expire.
Q : What happens then?
Q : How are the certificates managed and renewed?
Q : How does that affect the blockchain?
If someone has a great link they can share or even a simple answer that woudl be brilliant.
gatakka (Thu, 19 Apr 2018 14:19:19 GMT):
@IanBradbury_Rex it is simple, you can create a new certificate using old one. This is supported by FabricCA. But if you create a new certificates the result will be the same. Certificate management is responsibility of the client. You can renew the certificates before they expire. By default the livetime of a cert is 10 years, but you can change this value. This will not affect the blockchain in any way. The old data signed with expired certificates is still there and can be validated, because this certificates sign the data, they do not encrypt the data. Even after 100 years you will be able to verify that this transaction was signed by valid certificate from valid Org
gatakka (Thu, 19 Apr 2018 14:19:19 GMT):
@IanBradbury_Rex it is simple, you can create a new certificate using old one. This is supported by FabricCA. But if you create a new certificates the result will be the same. Certificate management is responsibility of the client. You can renew the certificates before they expire. By default the livetime of a cert is 10 years, but you can change this value. This will not affect the blockchain in any way. The old data signed with certificated that, at this point in time are expired, is still there and can be validated, because this certificates sign the data, they do not encrypt the data. Even after 100 years you will be able to verify that this transaction was signed by valid certificate from valid Org
gatakka (Thu, 19 Apr 2018 14:19:19 GMT):
@IanBradbury_Rex it is simple, you can create a new certificate using old one. This is supported by FabricCA. But if you create a new certificates the result will be the same. Certificate management is responsibility of the client. You can renew the certificates before they expire. By default the livetime of a cert is 10 years, but you can change this value. This will not affect the blockchain in any way. The old data signed with certificated that, at current point in time are expired, is still there and can be validated, because this certificates sign the data, they do not encrypt the data. Even after 100 years you will be able to verify that this transaction was signed by valid certificate from valid Org
gatakka (Thu, 19 Apr 2018 14:20:18 GMT):
If you are talking about data encryption, in general case this is done using symmetric cryptography, and there is no expiration there.
gatakka (Thu, 19 Apr 2018 14:22:31 GMT):
So in general, nothing bad will happen. The worst thing to happen is that new requests will be rejected if certificate expire, and you just create a new valid one.
IanBradbury_Rex (Thu, 19 Apr 2018 14:26:16 GMT):
Thanks @gatakka - that puts my mind at ease.
jmason900 (Thu, 19 Apr 2018 15:24:32 GMT):
Has joined the channel.
toesterdahl (Sun, 22 Apr 2018 20:38:44 GMT):
Has joined the channel.
harsha (Mon, 23 Apr 2018 03:38:56 GMT):
Has joined the channel.
hosemose (Tue, 24 Apr 2018 04:59:26 GMT):
Has joined the channel.
techalchemist (Wed, 25 Apr 2018 10:50:40 GMT):
Has joined the channel.
MikeGardiner (Wed, 25 Apr 2018 15:08:43 GMT):
@gatakka, @IanBradbury_Rex , There is a case where you can end up losing encrypted data. If you encrypt your data with an AES key and intend to share it with other users the normal thing to do in the Elliptic Curve world would actually be, not to create a data encryption key, but rather to create an ephemeral EC key which is then used under an ECIES scheme (Elliptic Curve Integrated Encryption Scheme) to arrive at a data encryption key. If your recipient loses or changes their private key rather than obtaining a new certificate with the same old key then they would no longer be able to derive that data encryption key anymore.
So in the case that you might be doing data encryption you will want to look at what sort of key retention would be required. I'm not aware of any such feature built into fabric, but am just letting you know that there can be cases of data loss if you generate a new key/cert and don't retain old keys.
LoveshHarchandani_1 (Wed, 25 Apr 2018 15:15:38 GMT):
Has joined the channel.
DarshanBc (Thu, 26 Apr 2018 06:41:35 GMT):
Hi I am getting this error ```2018-04-26 06:40:54.559 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
Error: got unexpected status: FORBIDDEN -- Failed to reach implicit threshold of 1 sub-policies, required 1 remaining: permission denied
```
DarshanBc (Thu, 26 Apr 2018 06:41:48 GMT):
not abler tro create channel
DarshanBc (Thu, 26 Apr 2018 06:57:30 GMT):
I also get this ```=================== WARNING ===================
Local fabric binaries and docker images are
out of sync. This may cause problems.
===============================================
```
mastersingh24 (Thu, 26 Apr 2018 13:27:05 GMT):
@DarshanBc - what exactly are you running?
DarshanBc (Thu, 26 Apr 2018 14:00:14 GMT):
@mastersingh24 that error got resolved thank you
DarshanBc (Thu, 26 Apr 2018 14:00:55 GMT):
but I am trying to add another organization and I am getting this error while runniing ./efyn generate
DarshanBc (Thu, 26 Apr 2018 14:00:57 GMT):
```Error: got unexpected status: BAD_REQUEST -- error authorizing update: error validating DeltaSet: policy for [Group] /Channel/Application not satisfied: Failed to reach implicit threshold of 2 sub-policies, required 1 remaining```
DarshanBc (Thu, 26 Apr 2018 14:01:25 GMT):
this is happening when second org has to sign
shiyj (Thu, 26 Apr 2018 16:29:09 GMT):
Has joined the channel.
DarshanBc (Fri, 27 Apr 2018 13:07:08 GMT):
Hi I am adding new org I am getting this error
```Error: failed to create deliver client: orderer client failed to connect to orderer.example.com:7050: failed to create new connection: context deadline exceeded```
while doing this `peer channel fetch 0 mychannel.block -o orderer.example.com:7050 -c $CHANNEL_NAME --tls --cafile $ORDERER_CA`
chainsaw (Fri, 27 Apr 2018 15:50:39 GMT):
Has joined the channel.
gatakka (Fri, 27 Apr 2018 18:37:45 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=dkJ6SjGDakDYLmLHK)
Yes, you are right, but question was for digital signatures used to sign the blocks.
gatakka (Fri, 27 Apr 2018 18:37:45 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=dkJ6SjGDakDYLmLHK)
Yes, you are right, but question was for digital signatures used to sign the blocks. You can always verify them, no expiration. And they can be veryfied using the certificate chain, not one specific certificate.
lvndry (Tue, 01 May 2018 19:17:45 GMT):
Has joined the channel.
neharprodduturi (Wed, 02 May 2018 05:17:05 GMT):
Has joined the channel.
MikeGardiner (Wed, 02 May 2018 14:22:20 GMT):
@gatakka, there must be some level of awareness of expiration, and revocation. Otherwise if your key is compromised then it can be used maliciously. If that compromise is after the expiration, or after it's been revoked then the transaction should be identified as fraudulent before being accepted
A 10 year default is also way too long given an impending crypto transition for quantum, and the trend towards frequent rotation of credentials/secrets to reduce their value.
kevin-s-wang (Thu, 03 May 2018 02:35:27 GMT):
Has joined the channel.
sbaxter (Fri, 04 May 2018 12:16:02 GMT):
Has joined the channel.
maverick193 (Fri, 04 May 2018 13:50:13 GMT):
Has joined the channel.
rselvakct (Sat, 05 May 2018 18:37:14 GMT):
Has joined the channel.
JeroenDePrest (Tue, 08 May 2018 11:28:02 GMT):
I have a pretty specific question. We are trying to encrypt our data on the chain code but we don’t want to lose our mango queries to query inside an object in CouchDB. Anyone have any ideas? We looked at encCC but here we then loose our mango queries so this is not really an option. Another option we thought about was that we could use Vault from HashiCorp to manage the encryption keys and then encrypt the values but not the keys and then also encrypt the query in the same way to still be able to do the mango queries. If anyone has a better idea feel free explain it.
Starseven (Tue, 08 May 2018 11:52:31 GMT):
Has joined the channel.
hrt031293 (Tue, 08 May 2018 12:31:16 GMT):
Has joined the channel.
john_whitton (Tue, 08 May 2018 17:51:36 GMT):
Has joined the channel.
akshaylawange001 (Wed, 09 May 2018 19:37:11 GMT):
Has joined the channel.
SubhraMazumdar (Thu, 10 May 2018 17:09:25 GMT):
Has joined the channel.
SubhraMazumdar (Fri, 11 May 2018 14:59:07 GMT):
@jyellick
SubhraMazumdar (Fri, 11 May 2018 14:59:21 GMT):
there is some proposal regarding privacy preserving endorsement
SubhraMazumdar (Fri, 11 May 2018 14:59:56 GMT):
How will one define endorsement policy in that case ? Using pseudonym derived from idemix ?
SubhraMazumdar (Mon, 14 May 2018 05:04:27 GMT):
@Jan.Camenisch How is Idemix going to prevent same person impersonating as two different entities while signing (handle the problem of double signing) ?
Jan.Camenisch (Mon, 14 May 2018 05:04:27 GMT):
Has joined the channel.
SubhraMazumdar (Mon, 14 May 2018 05:04:35 GMT):
In Hyperledger context
SubhraMazumdar (Mon, 14 May 2018 05:05:26 GMT):
@elli-androulaki
manu (Mon, 14 May 2018 07:46:41 GMT):
@SubhraMazumdar There will be a 'principal' to check whether the signature is anonymous or not, and you can write your policy accordingly (see https://gerrit.hyperledger.org/r/#/c/16693/)
yacovm (Mon, 14 May 2018 07:52:11 GMT):
I think what he means is how can you enforce a policy that is signed by multiple members of the same organization (for instance). @manu
yacovm (Mon, 14 May 2018 07:52:19 GMT):
I think you can't.... from obvious reasons
manu (Mon, 14 May 2018 07:54:50 GMT):
I see. For now we envision idemix being used by clients only, so not for endorsements, but in the future we could also use idemix for endorsement and then there are some things we can do, like anonymously endorsing while guaranteeing that a certain amount of distinct members endorsed it.
yacovm (Mon, 14 May 2018 07:56:03 GMT):
> like anonymously endorsing while guaranteeing that a certain amount of distinct members endorsed it.
oh, really?
how? With attributes?
yacovm (Mon, 14 May 2018 07:56:38 GMT):
Does that mean you do something like a combined signature?
manu (Mon, 14 May 2018 08:03:28 GMT):
you could add a 'scope-exclusive' pseudonym. For a given scope s, every user can only create one such pseudonym, so if you see two distinct scope-exclusive pseudonyms for the same scope, you know that they are two different signers. But at the same time, for a different scope s', signatures are entirely unlinkable
yacovm (Mon, 14 May 2018 08:04:39 GMT):
but the scope I guess is generated at runtime, and the peers would need to know the scope before signing, no?
yacovm (Mon, 14 May 2018 08:04:57 GMT):
I guess the client generates some random string and passes this as input to the peer's signing ?
yacovm (Mon, 14 May 2018 08:17:27 GMT):
@manu ^
manu (Mon, 14 May 2018 08:18:49 GMT):
I don't think you even need that. You could let the scope be whatever the peers are endorsing, that should be unique right?
yacovm (Mon, 14 May 2018 08:19:22 GMT):
but then can't a peer choose 2 scopes?
yacovm (Mon, 14 May 2018 08:19:40 GMT):
oh you mean the payload to sign
manu (Mon, 14 May 2018 08:19:43 GMT):
exactly
yacovm (Mon, 14 May 2018 08:20:09 GMT):
learned something cool. Thanks!
SubhraMazumdar (Mon, 14 May 2018 08:54:34 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=Wgyn5Epv83m7Gb9FW) @manu If the signer is anonymous given if he or she takes help of idemix to do that, how does one ensure breaking of unlinkability in case of dispute ?
manu (Mon, 14 May 2018 08:57:22 GMT):
thats a good question. We're planning to have one or multiple auditors that are able to retrieve the real identity of the signer from an idemix signature
SubhraMazumdar (Mon, 14 May 2018 08:58:17 GMT):
But given that each user generates its own secret key, can you elaborate as in how auditors gonna put a check on that ?
SubhraMazumdar (Mon, 14 May 2018 08:58:22 GMT):
@manu
manu (Mon, 14 May 2018 09:00:07 GMT):
So in the idemix credential that a user obtains, there is a number of attributes. One of them will be its enrollment identity, by which he is known to the CA. When making an idemix signature a user then encrypts his enrollment id such that an auditor can decrypt it. He must also prove in zero-knowledge that he did this correctly, such that he cannot cheat and avoid auditing
SubhraMazumdar (Mon, 14 May 2018 09:03:21 GMT):
So by that you mean the Ecert is know to CA and so send his encrypted Ecert (with encrypted key of auditor) which must send definitely for audit purpose. Hence this auditor must be able to figure out any sort of malpractice. Am I right in interpreting @manu ?
versus (Mon, 14 May 2018 09:03:57 GMT):
Has joined the channel.
SubhraMazumdar (Mon, 14 May 2018 09:04:07 GMT):
So somehow auditor is in control of all transactions happening and it has knowledge of everything
SubhraMazumdar (Mon, 14 May 2018 09:05:07 GMT):
I am talking from endorsement point of view ..retaining endorser privacy
SubhraMazumdar (Mon, 14 May 2018 09:23:31 GMT):
@manu can you elaborate on the work done over here ?
SubhraMazumdar (Mon, 14 May 2018 09:23:32 GMT):
https://gerrit.hyperledger.org/r/#/c/16693/
SubhraMazumdar (Mon, 14 May 2018 09:23:49 GMT):
What is the purpose of MSP principal for anonymity ?
manu (Mon, 14 May 2018 10:52:59 GMT):
You don't send the entire ecert, just the identifier in it, but other then that I think you're interpreting it correctly. If something goes wrong, for example a transaction is endorsed that should not be endorsed, then the auditor can find the identity of the endorser. So indeed, in that scenario the endorser is not anonymous towards the auditor, but you could have multiple auditors such that every endorser could choose one auditor it trusts, and we don't get a single auditor that can see everything.
The MSP principal for anonymity gives a standard way to check whether a signature is anonymous or not, because as you said, anonymous signatures don't necessarily work for any endorsement policy. This way we can prevent idemix signatures from being used for such policies (until we have the scope-exclusive pseudonyms that i described above)
SubhraMazumdar (Mon, 14 May 2018 15:53:01 GMT):
Ok so currently are you thinking about implementing anonymous endorsement in your policy @manu ?
manu (Mon, 14 May 2018 15:58:26 GMT):
well not right now, our priority is first getting everything ready for clients to sign with idemix, having anonymous endorsement is a lower priority
SubhraMazumdar (Mon, 14 May 2018 15:59:09 GMT):
Ok
SubhraMazumdar (Mon, 14 May 2018 16:00:39 GMT):
In which version of fabric is idemix feature going to be integrated @manu ?
manu (Mon, 14 May 2018 16:01:15 GMT):
for clients 1.2
SubhraMazumdar (Mon, 14 May 2018 16:02:10 GMT):
Ok. Thanks a lot @manu . Glad to know about the developments and future roadmap of hyperledger fabric
SubhraMazumdar (Mon, 14 May 2018 16:03:45 GMT):
so when can we expect the release of 1.2 version ?
jrosmith (Mon, 14 May 2018 17:07:17 GMT):
@SubhraMazumdar end of june
umapm113 (Wed, 16 May 2018 05:52:55 GMT):
Has joined the channel.
phanikumar (Sun, 20 May 2018 20:14:48 GMT):
Has joined the channel.
JulesMiller (Mon, 21 May 2018 01:42:03 GMT):
Has joined the channel.
dimaxgl (Mon, 21 May 2018 14:41:11 GMT):
Has joined the channel.
acuestareig (Thu, 24 May 2018 15:27:22 GMT):
Has joined the channel.
Maria (Fri, 25 May 2018 14:12:05 GMT):
Has joined the channel.
manu (Fri, 25 May 2018 14:16:31 GMT):
So @JonathanLevi, is there any way you can help us speed up getting the idemix java-sdk CRs in?
Maria (Fri, 25 May 2018 14:20:31 GMT):
We are happy to provide a detailed report or walk you through things if you want....
Maria (Fri, 25 May 2018 14:20:31 GMT):
@JonathanLevi , We are happy to provide a detailed report or walk you through things if you want....
JonathanLevi (Fri, 25 May 2018 14:26:04 GMT):
I am not sure. I am not a maintainer of that project anymore.
Maria (Fri, 25 May 2018 14:26:17 GMT):
I also asked Gari to review them
JonathanLevi (Fri, 25 May 2018 14:26:32 GMT):
The Java wrappers are pretty straight forward.
JonathanLevi (Fri, 25 May 2018 14:27:00 GMT):
We simply follow that User.java... does not seem that complicated to me.
Maria (Fri, 25 May 2018 14:28:03 GMT):
yes, indeed :)
JonathanLevi (Fri, 25 May 2018 14:28:06 GMT):
But I need to be able to "play with the code" in order to provide meaningful feedback. At the moment it is all split across different components.
JonathanLevi (Fri, 25 May 2018 14:28:33 GMT):
Why is this stuff not reviewed/merged?
Maria (Fri, 25 May 2018 14:28:37 GMT):
Keith and Saad are putting all 3 components together
JonathanLevi (Fri, 25 May 2018 14:29:01 GMT):
Yes, I am following closely the fabric-ca stuff.
Maria (Fri, 25 May 2018 14:29:06 GMT):
in the e2e test (getting creds from CA by the SDK and submit a transaction using it and then verify it)
JonathanLevi (Fri, 25 May 2018 14:29:14 GMT):
But I need a way to "consume" these.
JonathanLevi (Fri, 25 May 2018 14:29:25 GMT):
Yes, exactly.
Maria (Fri, 25 May 2018 14:29:52 GMT):
this test showed a few inconsistencies on how things were stored/encoded... we fixed almost everything now
JonathanLevi (Fri, 25 May 2018 14:29:54 GMT):
Need to get the long term crypto stuff on Enrollemnt and then to generate the proofs locally
JonathanLevi (Fri, 25 May 2018 14:30:29 GMT):
OK
JonathanLevi (Fri, 25 May 2018 14:30:50 GMT):
I am pretty familiar with the ZK scheme you use...
JonathanLevi (Fri, 25 May 2018 14:31:05 GMT):
But we need to get the workflow going.
Maria (Fri, 25 May 2018 14:31:16 GMT):
only revocation pubic key on the CA side needs to be adapted and then all should work
JonathanLevi (Fri, 25 May 2018 14:31:43 GMT):
Sorry I have "lost it" during the scrum today ;-)
Maria (Fri, 25 May 2018 14:31:59 GMT):
we understand! and we appreciate the help :)
JonathanLevi (Fri, 25 May 2018 14:32:15 GMT):
There was obviously a bottleneck here that I have highlighted well in advance!
Maria (Fri, 25 May 2018 14:34:05 GMT):
yes, indeed.. but at least now things are moving... it would be nice to catch up on the sdk side as well as for other components
Maria (Fri, 25 May 2018 14:34:05 GMT):
yes, indeed. but at least now things are moving. it would be nice to catch up on the sdk side as well as for other components
Maria (Fri, 25 May 2018 14:39:30 GMT):
it would be nice if Gari @mastersingh24 could have a look at the SDK CRs... I sent a detailed overview on slack and on scrum channel...
Maria (Fri, 25 May 2018 14:39:30 GMT):
it would be nice if Gari @mastersingh24 could have a look at the SDK CRs. I sent a detailed overview on slack and on scrum channel.
dave.enyeart (Fri, 25 May 2018 14:55:53 GMT):
And I've highlighted the CRs over in #fabric-pr-review
nebsterboy (Mon, 28 May 2018 11:48:55 GMT):
Hey, I found in the documentation that ECDSA keys are the only supported key type for signing at the moment. Any hints about how to add support for other types of key, e.g. RSA?
I tried the BYFN sample with provided RSA keys and received an error: "...endorser client channel: endorser client failed to connect to peer0.org1.example.com:7051: failed to create new connection: context deadline exceeded"
adc (Mon, 28 May 2018 12:46:08 GMT):
@rickr, please, have a look at https://gerrit.hyperledger.org/r/#/c/22117/ I have changed the code towards your request. The change-set has merge conflicts but I will address later cause there are change-sets in the stack that need to be finished first. Thanks for your time.
nagap (Tue, 29 May 2018 20:56:36 GMT):
Has joined the channel.
karmicway (Tue, 29 May 2018 21:36:17 GMT):
Has joined the channel.
hendry19901990 (Tue, 29 May 2018 22:54:18 GMT):
Has joined the channel.
yljgo (Wed, 30 May 2018 03:17:39 GMT):
Has joined the channel.
jwaup (Wed, 30 May 2018 13:56:33 GMT):
Has joined the channel.
Maria (Wed, 30 May 2018 15:27:34 GMT):
Hi @JonathanLevi just wanted to let you know that e2e test works now (testing sdk <-> ca, sdk <-> fabric core) - we will update the CRs asap. Regarding the docs - I am in touch with Joe and Pam to update what we have already : https://hyperledger-fabric.readthedocs.io/en/master/idemix.html
https://hyperledger-fabric.readthedocs.io/en/master/idemixgen.html
Maria (Wed, 30 May 2018 15:27:34 GMT):
Hi Jonathan @JonathanLevi just wanted to let you know that e2e test works now (testing sdk <-> ca, sdk <-> fabric core) - we will update the CRs asap. Regarding the docs - I am in touch with Joe and Pam to update what we have already : https://hyperledger-fabric.readthedocs.io/en/master/idemix.html
https://hyperledger-fabric.readthedocs.io/en/master/idemixgen.html
rogerwilcos (Wed, 30 May 2018 23:17:20 GMT):
Has joined the channel.
IgorSim (Thu, 31 May 2018 06:25:40 GMT):
Hi, i'm looking at decoded block that contains one transaction which was endorsed by one peer and committed to the ledger. I see in endorsement section this(i omit the values for brevity):
"endorsements": [{
"endorser": "...........",
"signature": "..........."
}
How these values (endorser and signature) are calculated?
BBurgDave (Thu, 31 May 2018 20:28:45 GMT):
Has joined the channel.
harika.n (Fri, 01 Jun 2018 10:35:19 GMT):
Has joined the channel.
Aswath8687 (Fri, 01 Jun 2018 20:12:25 GMT):
Has joined the channel.
jcwarfield (Sun, 03 Jun 2018 20:43:58 GMT):
Has joined the channel.
mastersingh24 (Mon, 04 Jun 2018 13:51:10 GMT):
@IgorSim - as you hopefully know, the transaction flow is as follows:
1) Client sends endorsement requests to 1 or more peers
2) Peers send back signed endorsement responses (the signature is detached but each peer signs the actual response payload)
3) Client packages up response and signatures and sends to the orderer
4) The orderer batches transactions and delivers blocks to the peers
So the array or endrosements contains the endorser (which is the X509 certificate bytes in the case of the default MSP) and the signature (which is the signature over the ProposalResponsePayload)
rangak (Thu, 07 Jun 2018 14:02:43 GMT):
Has joined the channel.
abraham (Fri, 08 Jun 2018 04:21:01 GMT):
Has joined the channel.
aKesav (Fri, 08 Jun 2018 07:46:04 GMT):
Has joined the channel.
shsedghi (Wed, 13 Jun 2018 15:23:46 GMT):
Has joined the channel.
paulananth (Fri, 15 Jun 2018 12:16:24 GMT):
Has joined the channel.
rangak (Sun, 17 Jun 2018 03:05:46 GMT):
@cbf Congrats on your announcement of ZKAT (aka privacy preserving asset transfer) at Consensus last month. I am writing to enquire whether details in addition to ```https://www.ibm.com/developerworks/cloud/library/cl-blockchain-private-confidential-transactions-hyperledger-fabric-zero-knowledge-proof/index.html``` have been published, such as code from your consensus demo or a more technical description of your zkat implementation, describing the audit feature implementation etc.
SubhraMazumdar (Sun, 17 Jun 2018 07:53:50 GMT):
I am currently developing a signature application and thus simulating the transaction flow steps in Fabric . What is the payload size that one must consider in order to do so ?
SubhraMazumdar (Sun, 17 Jun 2018 07:54:31 GMT):
@mastersingh24
DuncanMuhoro (Sun, 17 Jun 2018 10:59:28 GMT):
Has joined the channel.
mastersingh24 (Sun, 17 Jun 2018 20:46:04 GMT):
@SubhraMazumdar - depends on what you are trying to measure ... if you expect your payloads to be relatively small (e.g. a function call with a few parameters) then just use byte or kilobyte sized messages. Assuming bandwidth is not an issue, size will not make much difference when talking about small messages.
nebsterboy (Tue, 19 Jun 2018 07:48:24 GMT):
Hi, is there a way to exchange the TLS implementation used by hyperledger fabric?
ashutosh_kumar (Tue, 19 Jun 2018 13:59:42 GMT):
@nebsterboy , can you please elaborate ?
ashutosh_kumar (Tue, 19 Jun 2018 14:00:10 GMT):
you mean replacing by some other implementation ?
nebsterboy (Wed, 20 Jun 2018 06:27:50 GMT):
@ashutosh_kumar yes, exactly. Assuming I want to use an TLS implementation that supports Post-Quantum Crypto. Is it easy to extend the current system? Am I right that hyperledger relies on the golang crypto/tls package as the TLS implementation?
ashutosh_kumar (Wed, 20 Jun 2018 13:54:41 GMT):
you are right @nebsterboy , hyperledger relies on golang tls package for TLS implementation. We do not have BYOP(Bring your own provider)
nebsterboy (Wed, 20 Jun 2018 13:55:37 GMT):
This means, it is necessary to extend the golang tls package in order to provide additional cipher suites?
ashutosh_kumar (Wed, 20 Jun 2018 13:58:06 GMT):
Not necessarily. If some implementation implements cipher suite that you are after , we can use that instead of golang tls package.
ashutosh_kumar (Wed, 20 Jun 2018 13:58:59 GMT):
support for cipher suite is bigger problem to solve.
nebsterboy (Wed, 20 Jun 2018 17:26:44 GMT):
okay. Is there a central point where the golang tls package is specified as tls implementation so that this can be changed easily?
greve (Thu, 21 Jun 2018 06:25:50 GMT):
Has joined the channel.
nvxtien (Fri, 22 Jun 2018 11:25:37 GMT):
Has joined the channel.
Tony (Wed, 27 Jun 2018 08:39:28 GMT):
Has joined the channel.
Tony (Wed, 27 Jun 2018 11:27:29 GMT):
Hi , How to encrypt data and store it in chaincode, I have to also decrypt the data in chaincode to calculate? There are TWO METHODS CryptoSuit_ESDSA_AES and CryptoSuit_PKCS11, which one I have to use? I have a single channel application. Here I have to encrypt data before any transactions.
Tony (Wed, 27 Jun 2018 11:32:16 GMT):
I am using 1.1 version
ashutosh_kumar (Wed, 27 Jun 2018 15:27:34 GMT):
@Tony , are you using node sdk ?
ashutosh_kumar (Wed, 27 Jun 2018 15:32:52 GMT):
you use CryptoSuit_PKCS11 for HSMs.
ashutosh_kumar (Wed, 27 Jun 2018 15:33:25 GMT):
for software based solution , you should use CryptoSuit_ESDSA_AES.
Tony (Thu, 28 Jun 2018 05:23:37 GMT):
@ashutosh_kumar yes I am using node sdk, for CryptoSuit_ESDSA_AES for encrypt and decrypt function it showing yet to implement, https://fabric-sdk-node.github.io/CryptoSuite_ECDSA_AES.html
aatkddny (Thu, 28 Jun 2018 13:03:56 GMT):
Has joined the channel.
aatkddny (Thu, 28 Jun 2018 13:08:01 GMT):
I have a - hopefully simple - question about the identity mixer.
If I understood what I read (which is debatable) it appears that the identities within an MSP are anonymized.
So if I had two orgs, each with their own CA, each of which uses a mixer it appears that it is still be possible to tell which org a TX is from.
Is that correct or have I got hold of the wrong end of the stick here?
aatkddny (Thu, 28 Jun 2018 13:08:01 GMT):
I have a - hopefully simple - question about the identity mixer.
If I understood what I read (which is debatable) it appears that the identities within an MSP are anonymized.
So if I had two orgs, each with their own CA, each of which uses a mixer it appears that it is still possible to tell which org a TX is from.
Is that correct or have I got hold of the wrong end of the stick here?
manu (Thu, 28 Jun 2018 13:10:55 GMT):
Correct, so you should issue all idemix identities from a single CA if want the identities from the different orgs to be indistinguishable. In the future, we could imagine implementing https://dl.acm.org/citation.cfm?id=3134025 to have anonymity even with multiple CAs.
aatkddny (Thu, 28 Jun 2018 13:12:04 GMT):
Unfortunately with real (competing) orgs that's not likely to happen. But now I can figure out how to explain why it's not a panacea at least. Thanks for the help.
yacovm (Thu, 28 Jun 2018 13:13:18 GMT):
But @manu I thought that the org-level anonymization was on the roadmap... wasn't it?
yacovm (Thu, 28 Jun 2018 13:13:27 GMT):
Isn't it a matter of time?
manu (Thu, 28 Jun 2018 13:14:02 GMT):
yes there are plans to implement that paper I linked but I don't expect that to be done very soon
yacovm (Thu, 28 Jun 2018 13:14:32 GMT):
@aatkddny ^
aatkddny (Thu, 28 Jun 2018 13:14:47 GMT):
Then I can't change my design to a permissioned chain. So I'm back to channel proliferation.
aatkddny (Thu, 28 Jun 2018 13:14:47 GMT):
Then I can't change my design to a permissioned chain. So I'm back to channel proliferation. Pity.
aatkddny (Thu, 28 Jun 2018 13:14:47 GMT):
Then I can't change my design to a permissioned chain. So I'm back to channel proliferation. Pity.
Plus I'd need to wait until it hit BMX.
alkopnin (Thu, 28 Jun 2018 13:19:27 GMT):
Has joined the channel.
Tony (Thu, 28 Jun 2018 14:32:04 GMT):
I am using node sdk, for CryptoSuit_ESDSA_AES for encrypt and decrypt function it showing yet to implement, https://fabric-sdk-node.github.io/CryptoSuite_ECDSA_AES.html, then how to encrypt data and store it in chaincode for software based solution?
mondraymond (Thu, 28 Jun 2018 16:34:44 GMT):
Has joined the channel.
ashutosh_kumar (Thu, 28 Jun 2018 20:30:45 GMT):
@Tony , so , your application will do both operation : Encryption and Decryption ?
ashutosh_kumar (Thu, 28 Jun 2018 21:01:07 GMT):
As a best practice , you should keep reference to data on Blockchain and put real data off Blockchain.
ashutosh_kumar (Thu, 28 Jun 2018 21:01:07 GMT):
As a best practice , you should keep reference to data on Blockchain and put real data off Blockchain in encrypted form.
aatkddny (Fri, 29 Jun 2018 00:25:40 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=T7RTJMBqyBo72kybf)
So what's the *best practice* here?
So you are supposed to distribute this data to all the parties that are entitled to a copy of it?
Or are you back to a trusted third party to hold and furnish the data?
And if so then what's the point of the blockchain? If it doesn't disintermediate why have it?
aatkddny (Fri, 29 Jun 2018 00:25:40 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=T7RTJMBqyBo72kybf)
So what's the *best practice* here?
Is one supposed to distribute this data to all the parties that are entitled to a copy of it?
And if so what mechanism would be better than a distributed ledger?
Or are you back to a trusted third party to hold and furnish the data?
And if so then what's the point of the blockchain? If it doesn't disintermediate why have it?
pankajcheema (Fri, 29 Jun 2018 02:10:40 GMT):
Has joined the channel.
RealDeanZhao (Fri, 29 Jun 2018 10:40:53 GMT):
Has joined the channel.
yacovm (Fri, 29 Jun 2018 10:42:03 GMT):
@aatkddny I think Ash means data that is really really fat
yacovm (Fri, 29 Jun 2018 10:42:29 GMT):
if you have data that its size is managable
yacovm (Fri, 29 Jun 2018 10:42:53 GMT):
then you can just put it inside the blockchain like you want, and perhaps as private data with application level salt
yacovm (Fri, 29 Jun 2018 10:43:01 GMT):
so that the hashes won't be invertable
yacovm (Fri, 29 Jun 2018 10:44:03 GMT):
now.... as for your other question yesterday - I am wondering - in your use case, why actually can't you just give users one big MSP
yacovm (Fri, 29 Jun 2018 10:44:06 GMT):
and make that an idemix MSP
yacovm (Fri, 29 Jun 2018 10:44:24 GMT):
and the rest of the orgs would be orgs with only peers and they'll use x509 certificates
yacovm (Fri, 29 Jun 2018 10:44:32 GMT):
is that a no-no in your use case?
aatkddny (Fri, 29 Jun 2018 12:00:03 GMT):
Imagine two competing orgs.
Each has a fabric instance in their own cloud infrastructure.
Each manages their own access by hooking up their CA server to their own internal AD (using LDAP or some home grown glue code) to automate management.
Try getting them to agree to merge that so someone else handles identity.
Then expand that problem to many competitors.
Yes in theory we could federate access through something like Ping and hash org/user, but that's a hack. And getting buy in won't be a simple task.
Not having read the whole document I'm also not sure whether it's possible to search for all transactions by a user if they are anonymized. Which in an audit for potential malfeasance would be - shall we say - desirable. But that's a secondary concern. The ability to anonymize which two of n organizations in a multi-organization channel are transacting is what drove my question.
yacovm (Fri, 29 Jun 2018 12:01:55 GMT):
I think for auditing there is a way - @manu ^
yacovm (Fri, 29 Jun 2018 12:02:26 GMT):
so when you say each has a fabric instance- what do you mean?
yacovm (Fri, 29 Jun 2018 12:02:39 GMT):
each organization has its own peers or also an orderer instance? @aatkddny
aatkddny (Fri, 29 Jun 2018 12:03:26 GMT):
Probably not an orderer - unless we figure out how to permission management such that they can't enroll new members. But yes they'll have their own peers.
aatkddny (Fri, 29 Jun 2018 12:03:26 GMT):
Probably not an orderer - unless we figure out how to permission management such that they can't enroll new members. But yes they'll have their own peers.
aatkddny (Fri, 29 Jun 2018 12:03:26 GMT):
Probably not an orderer - unless we figure out how to permission management such that they can't enroll new members and how to direct traffic so not all orderers see all Tx. But yes they'll have their own peers.
yacovm (Fri, 29 Jun 2018 12:05:17 GMT):
Once we have raft - based orderer we could easily do the orderer part ^
yacovm (Fri, 29 Jun 2018 12:06:33 GMT):
I still don't understand, to be honest... why do you _ have _ to issue all the user credentials from the CAs of the companies?
yacovm (Fri, 29 Jun 2018 12:06:40 GMT):
can't you make a single CA for only users?
yacovm (Fri, 29 Jun 2018 12:06:50 GMT):
and have it hosted by the same company that hosts the orderer?
yacovm (Fri, 29 Jun 2018 12:07:34 GMT):
if you trust the orderer not to fork your blockchain by cutting different orgs to different peers, can't you trust it for user issuance? (I'm asking, no idea what is your assumptions)
yacovm (Fri, 29 Jun 2018 12:09:34 GMT):
> The ability to anonymize which two of n organizations in a multi-organization channel are transacting is what drove my question.
can you elaborate on what you mean by anonymize ? you're not allowed to see who endorsed the transaction?
aatkddny (Fri, 29 Jun 2018 12:10:02 GMT):
I'll answer the last first - the other one may get TLDR.
yacovm (Fri, 29 Jun 2018 12:10:27 GMT):
do what you want... I'm only trying to help
aatkddny (Fri, 29 Jun 2018 12:12:39 GMT):
Hypothetical for emphasis - IBM wouldn't like it known by Oracle that they were talking to buy (say) some software startup called X-Drive.
If we record transaction details without obscuring that IBM are talking to X-Drive and Oracle find out, do some DD and then decide they want in and make a better offer IBM aren't going to be very happy.
Extend that analogy to our use case.
aatkddny (Fri, 29 Jun 2018 12:12:39 GMT):
Hypothetical for emphasis - IBM wouldn't like it known by Oracle that they were talking to buy (say) some software startup called X-Drive.
If we record transaction details without obscuring that IBM are talking to X-Drive and Oracle find out, do some DD and then decide they want in and make a better offer IBM aren't going to be very happy.
That analogy extends nicely into our use case.
yacovm (Fri, 29 Jun 2018 12:14:24 GMT):
well but in that case - can't you just have only a single chaincode to endorse - either on X-Drive or IBM's peer?
yacovm (Fri, 29 Jun 2018 12:15:02 GMT):
then, you can make IBM and X-drive be in a private data collection
yacovm (Fri, 29 Jun 2018 12:15:28 GMT):
anyone looking at the public blockchain, only sees that the endorsement is from either IBM or X-Drive, and doesn't see the content
aatkddny (Fri, 29 Jun 2018 12:18:56 GMT):
The first one - I'm trying to distill the problem.
Our clients want to manage authentication. They tend to be large organizations with their own internal IT systems. Mostly AD based. They want to control all aspects of identity management whenever possible. Our regular systems federate for authentication and only manage authorization internally. Hiving a portion of that off to something 1. Controlled by another and 2. Shared isn't seen as desirable.
aatkddny (Fri, 29 Jun 2018 12:20:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=MBBy8TtSsWkuhd7pA)
That turns a channel proliferation problem into a chaincode proliferation one. Given the problems I've seen standing multiple chaincode instances up in cloud providers I'll stick with the channel problem I know.
yacovm (Fri, 29 Jun 2018 12:21:13 GMT):
you are correct on the last comment
aatkddny (Fri, 29 Jun 2018 12:21:43 GMT):
BTDT. Srsly...
yacovm (Fri, 29 Jun 2018 12:21:59 GMT):
so are you going to use (n choose 2) channels?
aatkddny (Fri, 29 Jun 2018 12:23:17 GMT):
I have no choice until the org level stuff goes GA. Then I can revisit. That still leaves me with the "can HL manage a lot of channels problem" but I can kick that can down the road a bit.
yacovm (Fri, 29 Jun 2018 12:23:35 GMT):
I can just give you a formula
yacovm (Fri, 29 Jun 2018 12:23:42 GMT):
you input your stuff in the formula and get an answer
aatkddny (Fri, 29 Jun 2018 12:24:44 GMT):
for scaling out you mean?
yacovm (Fri, 29 Jun 2018 12:24:49 GMT):
yes
yacovm (Fri, 29 Jun 2018 12:26:33 GMT):
Basically, memory-wise - lets assume that a given peer is member of `k` channels, and each channel has blocks that are on average `B` bytes size.
So, that peer stores in its memory an upper bound of `peer.gossip.maxBlockCountToStore` `*` `k` `*` `B`
https://github.com/hyperledger/fabric/blob/release-1.1/sampleconfig/core.yaml#L161
yacovm (Fri, 29 Jun 2018 12:28:12 GMT):
there are other caches in the memory of the peer but I think that's the biggest one
aatkddny (Fri, 29 Jun 2018 12:28:22 GMT):
No wonder my docker instance is struggling.
yacovm (Fri, 29 Jun 2018 12:28:55 GMT):
oh actually there is another one, but it is only relevant for leader peers - and it might be twice the size of `maxBlockCountToStore` by default
yacovm (Fri, 29 Jun 2018 12:29:04 GMT):
but half of it is a re-use of a reference
yacovm (Fri, 29 Jun 2018 12:29:17 GMT):
so it's still the same asymptotically
aatkddny (Fri, 29 Jun 2018 12:29:34 GMT):
And that's with 20 or so channels rather than the 10k or so we project as an upper bound. Is there a consequence to cutting `maxBlockCountToStore`
yacovm (Fri, 29 Jun 2018 12:29:59 GMT):
how many peers do you have in each org?
aatkddny (Fri, 29 Jun 2018 12:30:00 GMT):
Better - can it be reconfigured dynamically.
aatkddny (Fri, 29 Jun 2018 12:30:06 GMT):
2
aatkddny (Fri, 29 Jun 2018 12:30:14 GMT):
The minimum for failover.
yacovm (Fri, 29 Jun 2018 12:30:28 GMT):
if it's 2 then set it to like 2 or something
yacovm (Fri, 29 Jun 2018 12:30:44 GMT):
as long as yours peers are always in sync
yacovm (Fri, 29 Jun 2018 12:30:48 GMT):
it should work
aatkddny (Fri, 29 Jun 2018 12:31:02 GMT):
hypothectically if this was running in BMX can it be client configured?
aatkddny (Fri, 29 Jun 2018 12:31:02 GMT):
hypothetically if this was running in BMX can it be client configured?
yacovm (Fri, 29 Jun 2018 12:31:04 GMT):
no dynamic reconfig
yacovm (Fri, 29 Jun 2018 12:31:30 GMT):
I don't think so
aatkddny (Fri, 29 Jun 2018 12:31:36 GMT):
ugh
yacovm (Fri, 29 Jun 2018 12:31:40 GMT):
but if you have only 2 peers i don't see why you can't do that
yacovm (Fri, 29 Jun 2018 12:31:40 GMT):
but if you have only 2 peers i don't see why you can't do that (decrease it by a lot)
aatkddny (Fri, 29 Jun 2018 12:33:49 GMT):
so that's for peer to peer gossip inside an org? multiple orgs - each with 2 peers - doesn't affect the number
yacovm (Fri, 29 Jun 2018 12:34:12 GMT):
there is no gossip of blocks outside of orgs, sadly. I'd like to add it in v1.3
yacovm (Fri, 29 Jun 2018 12:34:41 GMT):
there is a different point-to-point sync between orgs
yacovm (Fri, 29 Jun 2018 12:34:46 GMT):
but it's much slower
yacovm (Fri, 29 Jun 2018 12:35:28 GMT):
but another issue you'll have is....
yacovm (Fri, 29 Jun 2018 12:35:34 GMT):
if you have a zillion channels....
yacovm (Fri, 29 Jun 2018 12:35:42 GMT):
that's a zillion gRPC connections
yacovm (Fri, 29 Jun 2018 12:35:47 GMT):
from each org
yacovm (Fri, 29 Jun 2018 12:35:52 GMT):
to the orderers ;)
yacovm (Fri, 29 Jun 2018 12:36:14 GMT):
so you'll need to scale out the orderers too
yacovm (Fri, 29 Jun 2018 12:37:08 GMT):
but it all depends also on the throughput i guess
aatkddny (Fri, 29 Jun 2018 12:37:10 GMT):
wait - each channel has a grpc connection to the orderer? i thought that was one per peer and then a butt load from peer:chaincode container.
yacovm (Fri, 29 Jun 2018 12:37:26 GMT):
so, it goes like this:
yacovm (Fri, 29 Jun 2018 12:37:36 GMT):
for each channel, for each org, there is a designated peer leader
yacovm (Fri, 29 Jun 2018 12:37:49 GMT):
that peer creates a gRPC connection to some orderer instance
yacovm (Fri, 29 Jun 2018 12:38:20 GMT):
so if you have `k` channels and lets say 2 orgs in each channel as you said - that's `2k` connections
aatkddny (Fri, 29 Jun 2018 12:40:38 GMT):
a connection per channel. that has to be to combat some throughput limitation otherwise it seems incredibly wasteful.
yacovm (Fri, 29 Jun 2018 12:41:20 GMT):
it's not as easy as you think....
yacovm (Fri, 29 Jun 2018 12:41:26 GMT):
each channel has its own TLS root CAs
yacovm (Fri, 29 Jun 2018 12:41:45 GMT):
you can't just combine them and then multiplex the connections
yacovm (Fri, 29 Jun 2018 12:41:45 GMT):
you can't just combine them and then multiplex the connection
yacovm (Fri, 29 Jun 2018 12:41:53 GMT):
otherwise you're exposed to attacks
aatkddny (Fri, 29 Jun 2018 12:45:19 GMT):
each channel has its own TLS? I thought - clearly wrongly - you established the link peer-orderer using the crypto for those only. i assumed you'd publish - orderer side - only to the peers links that have access to that channel. shows what assuming does.
aatkddny (Fri, 29 Jun 2018 12:45:19 GMT):
each channel has its own TLS? I thought - clearly wrongly - you established the link peer-orderer using the crypto for those only. i assumed you'd publish - orderer side - only to the established peer links that have access to that channel. shows what assuming does.
yacovm (Fri, 29 Jun 2018 12:46:10 GMT):
a channel has an entire configuration of all security stuff
yacovm (Fri, 29 Jun 2018 12:46:27 GMT):
i'll give you an example
yacovm (Fri, 29 Jun 2018 12:47:04 GMT):
if you have a channel `C1` it may be used by orderers of orgs `O1, O2, O3` but at the same time, a channel `C2` might be used by orderers of orgs `O2, O3, O4`
yacovm (Fri, 29 Jun 2018 12:47:21 GMT):
clearly, `O4` isn't in the TLS CA certificate of the channel `C1`
yacovm (Fri, 29 Jun 2018 12:48:07 GMT):
therefore if you create a connection from a peer to the orderers of channel `C1` you have to explicitly tell the TLS certificate pool to only trust TLS certificates issued by TLS CAs of `O1, O2, O3`
aatkddny (Fri, 29 Jun 2018 12:50:09 GMT):
i see where you are going with this.
aatkddny (Fri, 29 Jun 2018 12:51:08 GMT):
yuck. so there's an upper bound in the peer to channels
yacovm (Fri, 29 Jun 2018 12:51:10 GMT):
we can optimize... in the future
yacovm (Fri, 29 Jun 2018 12:51:23 GMT):
but the problem is that currently - the orderer endpoints are configured in the config block globally
yacovm (Fri, 29 Jun 2018 12:51:26 GMT):
and not per channel
yacovm (Fri, 29 Jun 2018 12:51:55 GMT):
once we move that to be per channel then we can just optimize and create the TLS connection with a single root TLS CA certificate set - of that org
yacovm (Fri, 29 Jun 2018 12:51:59 GMT):
and then it'll be solved :)
yacovm (Fri, 29 Jun 2018 12:52:15 GMT):
There is a JIRA for that and I hope we'll do it in v1.3
aatkddny (Fri, 29 Jun 2018 12:52:42 GMT):
just so long as it isn't a breaking change. :D
yacovm (Fri, 29 Jun 2018 12:53:02 GMT):
you have nothing to worry about
aatkddny (Fri, 29 Jun 2018 12:53:32 GMT):
are you kidding - it took me a day to get the 1.1 -> 1.2 jump working inside a fresh fabric.
yacovm (Fri, 29 Jun 2018 12:53:32 GMT):
.... from this aspect
yacovm (Fri, 29 Jun 2018 12:54:09 GMT):
why? what was the problem?
yacovm (Fri, 29 Jun 2018 12:54:21 GMT):
and please don't do that....
yacovm (Fri, 29 Jun 2018 12:54:28 GMT):
don't upgrade production before GA is released
yacovm (Fri, 29 Jun 2018 12:54:38 GMT):
there is a reason it's RC-1 and not GA
aatkddny (Fri, 29 Jun 2018 12:54:42 GMT):
we template everything so i can stand up a fabric dynamically. the changes to configtx were breaking.
aatkddny (Fri, 29 Jun 2018 12:54:42 GMT):
we template everything so i can stand up a fabric dynamically. the changes to configtx were breaking.
aatkddny (Fri, 29 Jun 2018 12:54:42 GMT):
we template everything so i can stand up a fabric dynamically. the changes to configtx were breaking. moving the capabilities around in particular istr.
aatkddny (Fri, 29 Jun 2018 12:54:42 GMT):
we template everything so i can stand up a fabric dynamically. the changes to configtx were breaking. moving the capabilities around in particular istr caused configtxgen to puke.
aatkddny (Fri, 29 Jun 2018 12:54:42 GMT):
we template everything so i can stand up a fabric dynamically. the changes to configtx were breaking. moving the capabilities around in particular istr caused configtxgen to puke.
aatkddny (Fri, 29 Jun 2018 12:55:02 GMT):
this was non prod - to try out the side db stuff.
aatkddny (Fri, 29 Jun 2018 12:55:02 GMT):
this was non prod - to try out the side db stuff.
IgorSim (Fri, 29 Jun 2018 13:01:38 GMT):
@aatkddny we're also contemplating upgrading to 1.2-rc1 , can you pls share your findings, what kind of breaking changes did you encounter?
aatkddny (Fri, 29 Jun 2018 13:03:17 GMT):
these are templates. to get it to work i had to comment out stuff.
```
Genesis:
# Capabilities:
# <<: *ChannelCapabilities
Orderer:
<<: *OrdererDefaults
Organizations:
- *Orderer
# Capabilities:
# <<: *OrdererCapabilities
Consortiums:
AllMember-Consortium:
Organizations:
{ORGANIZATIONS}
Application:
<<: *ApplicationDefaults
Organizations:
- *Orderer
# Capabilities:
# <<: *ChannelCapabilities
```
aatkddny (Fri, 29 Jun 2018 13:04:03 GMT):
There's a tom of new stuff in the new configTx. most looks boilerplate and can be added.
aatkddny (Fri, 29 Jun 2018 13:04:03 GMT):
There's a ton of new stuff in the new configTx. most looks boilerplate and can be added.
aatkddny (Fri, 29 Jun 2018 13:04:52 GMT):
Also this lot is all different iirc.
```
################################################################################
#
# CHANNEL
#
# This section defines the values to encode into a config transaction or
# genesis block for channel related parameters.
#
################################################################################
Channel: &ChannelDefaults
# Policies defines the set of policies at this level of the config tree
# For Channel policies, their canonical path is
# /Channel/
aatkddny (Fri, 29 Jun 2018 13:05:31 GMT):
Anyway getting it to work with my templates took a while, and my 1.1 configtx was incompatible.
IgorSim (Fri, 29 Jun 2018 13:05:47 GMT):
ok, tnx a lot for heads up
aatkddny (Fri, 29 Jun 2018 13:06:10 GMT):
GL
sigma67 (Sun, 01 Jul 2018 19:50:14 GMT):
Has joined the channel.
knagware9 (Tue, 03 Jul 2018 08:47:07 GMT):
Has joined the channel.
suchith.arodi (Tue, 03 Jul 2018 18:20:58 GMT):
Has joined the channel.
merth (Thu, 05 Jul 2018 18:53:34 GMT):
Has joined the channel.
Telijas (Mon, 09 Jul 2018 13:55:32 GMT):
Has joined the channel.
Asch (Tue, 10 Jul 2018 07:28:09 GMT):
Has joined the channel.
NoLimitHoldem (Wed, 11 Jul 2018 06:16:26 GMT):
Has joined the channel.
jayeshjawale95 (Wed, 11 Jul 2018 07:29:51 GMT):
Has joined the channel.
fossbender (Wed, 11 Jul 2018 20:20:19 GMT):
Has joined the channel.
BhaskarNarayan (Thu, 12 Jul 2018 09:22:33 GMT):
Has joined the channel.
Sreesha (Fri, 13 Jul 2018 05:17:07 GMT):
Has joined the channel.
jiulama (Sat, 14 Jul 2018 07:11:06 GMT):
Has joined the channel.
louisliu2048 (Tue, 17 Jul 2018 06:02:25 GMT):
Has joined the channel.
Sreesha (Wed, 18 Jul 2018 09:47:44 GMT):
Hi everyone.Has anyone tried generating certificates using fabric-ca rather than cryptogen and using them to run balance-transfer
For me the orderer is rejecting the channel creation request.
Can anyone help ,me
NilsPe (Wed, 18 Jul 2018 16:02:26 GMT):
Has joined the channel.
NilsPe (Wed, 18 Jul 2018 16:09:48 GMT):
Hi, I am trying to invoke chaincode using a certificate which was created using fabric-ca. The peers reject the TxProposal saying
`the identity must be a client, a peer or an orderer identity to be valid, not a combination of them. OUs: [[0xc427fe7b00]], MSP: [MyMSP]
`
When I parse the certificate manually with third party software, it shows just one OU called "user". Why do I get this weird HEX string in the error message? Can anyone help me out please? The error is thrown here in the source code: https://github.com/hyperledger/fabric-sdk-go/blob/master/internal/github.com/hyperledger/fabric/msp/mspimplvalidate.go#L206
NilsPe (Wed, 18 Jul 2018 16:09:48 GMT):
Hi, I am trying to invoke chaincode using a certificate which was created using fabric-ca. The peers reject the TxProposal saying
`the identity must be a client, a peer or an orderer identity to be valid, not a combination of them. OUs: [[0xc427fe7b00]], MSP: [MyMSP]`
When I parse the certificate manually with third party software, it shows just one OU called "user". Why do I get this weird HEX string in the error message? Can anyone help me out please? The error is thrown here in the source code: https://github.com/hyperledger/fabric-sdk-go/blob/master/internal/github.com/hyperledger/fabric/msp/mspimplvalidate.go#L206
NilsPe (Wed, 18 Jul 2018 16:23:22 GMT):
Looking into the code, this error is supposed to return bogus OUs. At least I can see that just one OU is detected.
ashutosh_kumar (Wed, 18 Jul 2018 16:32:50 GMT):
you need to get cert from fabric ca as setting OU to peer.
NilsPe (Wed, 18 Jul 2018 16:43:37 GMT):
Thanks for your answer. Does it really need to read "peer" even though I want a certificate for a user (doing txs..)?
NilsPe (Wed, 18 Jul 2018 17:07:29 GMT):
Okay, found it. I had the mistake even in my first post. The default OU for users is not "user" but "client". After issuing "client" certificates it works. I feel this needs some more documentation... Cheers
ashutosh_kumar (Wed, 18 Jul 2018 18:15:11 GMT):
glad that it worked.Cheers.
vietanh (Thu, 19 Jul 2018 09:15:45 GMT):
Has joined the channel.
SandeepPerugu (Thu, 19 Jul 2018 09:49:45 GMT):
Has joined the channel.
aatkddny (Mon, 23 Jul 2018 14:03:06 GMT):
`2018-07-23 09:59:31.357 EDT [common/tools/configtxgen/encoder] NewOrdererOrgGroup -> WARN 002 Default policy emission is deprecated, please include policy specificiations for the orderer org group OrdererMSP in configtx.yaml`
Not 100% sure exactly what this warning means. Is it that the orderermsp here doesn't have all that `Policies` boilerplate, or something else.
rbole (Wed, 25 Jul 2018 05:05:35 GMT):
Has joined the channel.
chuojiang (Wed, 25 Jul 2018 07:33:05 GMT):
Has joined the channel.
SadhviNayak (Wed, 25 Jul 2018 11:39:04 GMT):
Has joined the channel.
bourbonkidQ (Fri, 27 Jul 2018 09:49:54 GMT):
Is there any difference between "peer channel fetch 0" and "peer channel fetch config" ? Because the genesis.block look to contain all the configuration necessary but it's look that i cannot use the genesis.block with the configtxlator
sean (Sun, 29 Jul 2018 13:00:20 GMT):
Has joined the channel.
sean (Sun, 29 Jul 2018 13:04:15 GMT):
I'm getting this error when calling `peer channel create`: `the identity is a member of a different MSP (expected org1, got org1MSP)`
Other than the `configtx.yaml` and docker-compose files (`CORE_PEER_LOCALMSPID=`), where else is the MSP ID set?
sean (Sun, 29 Jul 2018 13:04:15 GMT):
I'm getting this error when calling `peer channel create`: `the identity is a member of a different MSP (expected org1, got org1MSP)`
Other than the `configtx.yaml` and docker-compose files ( `CORE_PEER_LOCALMSPID=` ), where else is the MSP ID set?
jg507 (Tue, 31 Jul 2018 21:15:25 GMT):
Has joined the channel.
ascatox (Wed, 01 Aug 2018 07:48:50 GMT):
I'm getting this error ` UNKNOWN: access denied: channel [] creator org [Org1MSP]`, I'm trying to invoke the chaincode with a new identity
praveen.j (Wed, 01 Aug 2018 14:39:10 GMT):
Has joined the channel.
zmaro (Fri, 03 Aug 2018 15:17:23 GMT):
Has joined the channel.
pankajanand26 (Fri, 03 Aug 2018 15:33:20 GMT):
Has joined the channel.
akshay.sood (Sat, 04 Aug 2018 06:47:00 GMT):
Has joined the channel.
manoj485 (Mon, 06 Aug 2018 09:53:46 GMT):
Has joined the channel.
manoj485 (Mon, 06 Aug 2018 09:53:52 GMT):
Hi , I need to create publickey when user registered and need send it to user, then user needs create privatekey it is possible in hyperledger? if possible how?
ashutosh_kumar (Mon, 06 Aug 2018 13:57:35 GMT):
@manoj485 , your requirement is not met directly with Fabric , however , you can use some tool like openssl to meet your end goal.
manoj485 (Tue, 07 Aug 2018 06:21:50 GMT):
Thank u@ashutosh_kumar
manoj485 (Thu, 09 Aug 2018 06:48:36 GMT):
How can i get block-hash in hyperledger
sean (Thu, 09 Aug 2018 19:56:01 GMT):
FYI, as I've worked through Fabric, I've had a lot of questions regarding crypto material & the MSP structure. This page has some MSP trees that might help understand the bigger picture:
https://github.com/TangoJ-Labs/fabric-production-tutorials/blob/master/CRYPTO.md
RockyRacer (Mon, 13 Aug 2018 12:50:45 GMT):
Has joined the channel.
RockyRacer (Mon, 13 Aug 2018 13:53:47 GMT):
Hi, I'm upgrading from 1.1 > 1.2
I have updated my _configtx.yaml_ according to the provided example file
but I get : `config update generation failure: cannot define a new channel with no Consortium value`
RockyRacer (Mon, 13 Aug 2018 13:53:47 GMT):
Hi, I'm upgrading from 1.1 > 1.2
I have updated my _configtx.yaml_ according to the provided sample file
but I get : `config update generation failure: cannot define a new channel with no Consortium value`
RockyRacer (Mon, 13 Aug 2018 13:54:32 GMT):
The provided example does not include a `Consortium` under Channel configuration, do I have to put one ?
RockyRacer (Mon, 13 Aug 2018 13:54:32 GMT):
The provided example does not include a `Consortium` keyword under `Channel` configuration, do I have to put one ?
RockyRacer (Mon, 13 Aug 2018 13:56:10 GMT):
If I add `Consortium: SampleConsortium` the channel creation works, but I wonder why it is not specified in the sample file
pankaj9310 (Mon, 13 Aug 2018 14:47:44 GMT):
Has joined the channel.
mastersingh24 (Fri, 17 Aug 2018 18:59:17 GMT):
@RockyRacer - which profile does not have a consortium defined?
RockyRacer (Mon, 20 Aug 2018 06:52:52 GMT):
The sample _configtx_ file for 1.2 -> https://github.com/hyperledger/fabric/blob/release-1.2/sampleconfig/configtx.yaml
RockyRacer (Mon, 20 Aug 2018 06:53:57 GMT):
The Channel configuration includes `Policies` and `Capabilities`, bit no `Consortium` keyword, and it seems it is required
RockyRacer (Mon, 20 Aug 2018 06:53:57 GMT):
The `Channel` configuration includes `Policies` and `Capabilities`, bit no `Consortium` keyword, and it seems it is required
RockyRacer (Mon, 20 Aug 2018 06:53:57 GMT):
The `Channel` configuration (line 304) includes `Policies` and `Capabilities`, bit no `Consortium` keyword, and it seems it is required
RockyRacer (Mon, 20 Aug 2018 06:53:57 GMT):
The `Channel` configuration (line 304) includes `Policies` and `Capabilities`, but no `Consortium` keyword, and it seems it is required
RockyRacer (Mon, 20 Aug 2018 06:55:20 GMT):
Adding `Consortium: SampleConsortium` make it works, I wonder why it is not in the sample file
mastersingh24 (Mon, 20 Aug 2018 08:59:37 GMT):
@RockyRacer Something seems odd here ... which profile are you trying to use?
RockyRacer (Mon, 20 Aug 2018 09:42:10 GMT):
It is slightly adapted to my needs, but is very close to the SampleSingleMSPKafka
RockyRacer (Mon, 20 Aug 2018 09:43:45 GMT):
configtx.txt
mastersingh24 (Mon, 20 Aug 2018 11:41:03 GMT):
and which version of `configtxgen` are you using?
RockyRacer (Mon, 20 Aug 2018 11:51:14 GMT):
1.2.0
bdjidi (Tue, 21 Aug 2018 22:47:53 GMT):
Has joined the channel.
mrjdomingus (Thu, 23 Aug 2018 11:00:43 GMT):
Has joined the channel.
Bhanu (Fri, 24 Aug 2018 16:51:15 GMT):
Has joined the channel.
qiangjiyi (Tue, 28 Aug 2018 02:10:09 GMT):
Has joined the channel.
donsonZhang (Wed, 29 Aug 2018 02:08:30 GMT):
Has joined the channel.
AbhinayB (Wed, 29 Aug 2018 05:09:28 GMT):
Has joined the channel.
Maryam1011 (Wed, 29 Aug 2018 07:06:02 GMT):
Has joined the channel.
mharris (Thu, 30 Aug 2018 09:46:28 GMT):
Has joined the channel.
jdfigure (Thu, 30 Aug 2018 17:41:01 GMT):
Has joined the channel.
albert.lacambra (Thu, 30 Aug 2018 18:47:26 GMT):
Has joined the channel.
albert.lacambra (Thu, 30 Aug 2018 19:22:10 GMT):
hi
albert.lacambra (Thu, 30 Aug 2018 19:22:24 GMT):
can someone exactly tell me what adminprincipal: role.admin/member means?
albert.lacambra (Thu, 30 Aug 2018 19:23:03 GMT):
is refering to which role should have the principal to be recognized as an admin on the peer or something like that?
dileban (Fri, 31 Aug 2018 04:27:21 GMT):
Today `cryptogen` doesn't support generating crypto material for custom user names (and instead takes a count). Support for this could be particularly useful for demos, or at least make demos look more meaningful. Is there any reason I should not add a task for this on Jira?
albert.lacambra (Sat, 01 Sep 2018 16:15:18 GMT):
I am making some polcies testing and I have no way to get transactions done if is not with a member identity. When I create policies where an admin must sign I always get an ENDORSEMENT_POLICY_FAILURE response
albert.lacambra (Sat, 01 Sep 2018 16:16:01 GMT):
when using an identity {"role": {"name": "admin", "mspId": "correctMSP"}}
albert.lacambra (Sat, 01 Sep 2018 16:17:33 GMT):
I use the admin user, meaning crypto under the folder ./crypto-config/peerOrganizations/lacambra.tech/users/Admin@lacambra.tech/msp/
albert.lacambra (Sat, 01 Sep 2018 16:18:21 GMT):
more specific.crypto-config/peerOrganizations/lacambra.tech/users/Admin@lacambra.tech/msp/signcerts/Admin@lacambra.tech-cert.pem
and
./crypto-config/peerOrganizations/lacambra.tech/users/Admin@lacambra.tech/msp/keystore/a2d875a88ea11db219d3edc1d82b5161c697f2c8875ddea62b9f60d5afe740d0_sk
albert.lacambra (Sat, 01 Sep 2018 16:18:38 GMT):
is that correct? I am using the java sdk
albert.lacambra (Sat, 01 Sep 2018 16:26:04 GMT):
version of fabric is 1.1.1
mastersingh24 (Sun, 02 Sep 2018 14:26:19 GMT):
@albert.lacambra - Why would you want to have endorsement policies which use Admins? That's not really the purpose of the Admin role.
albert.lacambra (Sun, 02 Sep 2018 16:13:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=w97pibf4h9WXHGdEX) @mastersingh24 @mastersingh24 well, is more about testing. The original org1, org2 examples accepts a sinature of member or one for admins and several docs speaks about the order how the polcies should be set (first admin and then member since admin is also a mebmer)
albert.lacambra (Sun, 02 Sep 2018 16:13:54 GMT):
I just wanted to see exactly how the whole configuration works to have full control on it and not rely on example configs
albert.lacambra (Sun, 02 Sep 2018 16:14:53 GMT):
However, given at the current point I have the feeling that CC polcies should be just set to PEER that are those who actually signs the endorsments
albert.lacambra (Sun, 02 Sep 2018 16:15:48 GMT):
what I would like to know now is which other actions should be taken now by admins and clients. The admin role is currently the one used to install / instantiate and upgrade chaincode
albert.lacambra (Sun, 02 Sep 2018 16:17:25 GMT):
which other administrative tasks can be done by him? what kind of actions can take a principal with role client? where is this ehole configurable? I have received today some answer of Yacov Manevich on the newsletter and I am reading agina the membership documents.
albert.lacambra (Sun, 02 Sep 2018 16:18:23 GMT):
to me is clear how validation works, but not that clear how do I configure stuff and which are the expected actions to be done by each role
albert.lacambra (Sun, 02 Sep 2018 16:18:33 GMT):
maybe is just like that:
albert.lacambra (Sun, 02 Sep 2018 16:18:45 GMT):
ADMIN role: manage chaincode
albert.lacambra (Sun, 02 Sep 2018 16:18:57 GMT):
PEER role: signs endorsments
albert.lacambra (Sun, 02 Sep 2018 16:19:09 GMT):
CLIENT role: send proposals to peer
albert.lacambra (Sun, 02 Sep 2018 16:19:30 GMT):
MEMBER role: should be maybe obsolete?
albert.lacambra (Sun, 02 Sep 2018 16:19:40 GMT):
thanks for your time :)
mastersingh24 (Sun, 02 Sep 2018 16:46:50 GMT):
Some of this depends on the version you are on and of course the capabilities which you have enabled on a per channel basis.
But assuming you start with v1.2 and later, then in general you'd likely use the NodeOUIdentifier feature of MSPs and use Admin, Peer and Client roles. Your endorsement policies would use the Peer role, clients would use the Client role and of course admins would use Admin. But things can get a bit tricky in setting up the channel policies such that you have MSPs which include Peer and Client roles in your channel access policies
SubhraMazumdar (Tue, 04 Sep 2018 08:51:22 GMT):
https://github.c om/hyperledger-labs/z-mix
SubhraMazumdar (Tue, 04 Sep 2018 08:51:22 GMT):
https://github.c om/hyperledger-labs/z-mix
SubhraMazumdar (Tue, 04 Sep 2018 08:51:41 GMT):
can anyone explain how does this work ? Any supporting paper or well written documentation ?
SubhraMazumdar (Tue, 04 Sep 2018 08:52:22 GMT):
@mastersingh24 @Jan.Camenisch @manu @Angel_IBM
Angel_IBM (Tue, 04 Sep 2018 08:52:23 GMT):
Has joined the channel.
SubhraMazumdar (Tue, 04 Sep 2018 08:52:46 GMT):
https://github.com/hyperledger-labs/z-mix
jorgego (Thu, 06 Sep 2018 17:22:44 GMT):
Has joined the channel.
vtech (Mon, 10 Sep 2018 12:01:29 GMT):
Has joined the channel.
albert.lacambra (Tue, 11 Sep 2018 17:30:25 GMT):
Thanks @mastersingh24 . I was using fabric 1.1. I think that could be my main issue. However concepts are much clear now. I think I have just missed the jump btw. versions
moficodes (Tue, 11 Sep 2018 18:19:20 GMT):
Has joined the channel.
qsmen (Wed, 12 Sep 2018 02:13:51 GMT):
hi experts here, there is a idemixer directory in sourcecode, but there is no description in release doc. why?
qsmen (Wed, 12 Sep 2018 02:14:10 GMT):
idemixer is still under development?
luomin (Wed, 12 Sep 2018 02:16:46 GMT):
Has joined the channel.
scott-long (Wed, 12 Sep 2018 03:42:37 GMT):
Has joined the channel.
baohua (Wed, 12 Sep 2018 07:12:05 GMT):
Has joined the channel.
richzhao (Thu, 13 Sep 2018 03:56:19 GMT):
Has joined the channel.
mastersingh24 (Thu, 13 Sep 2018 10:20:15 GMT):
@qsmen - correct ...it will be documented in the 1.3 release
JaydipMakadia (Thu, 13 Sep 2018 13:09:54 GMT):
Has joined the channel.
Rantwijk (Thu, 13 Sep 2018 13:17:19 GMT):
Has joined the channel.
gravity (Thu, 13 Sep 2018 20:25:41 GMT):
Has joined the channel.
gravity (Thu, 13 Sep 2018 20:26:23 GMT):
hi all
is there any way to create new peer admin if I lost certificate and _sk file for the previous one?
yacovm (Thu, 13 Sep 2018 20:35:51 GMT):
@gravity yeah you just need to issue a new certificate and private key
yacovm (Thu, 13 Sep 2018 20:36:01 GMT):
and then add the certificate to the peer's file system under `msp/admins`
yacovm (Thu, 13 Sep 2018 20:36:18 GMT):
but.... it might be also good to issue a CRL update to revoke that certificate
yacovm (Thu, 13 Sep 2018 20:36:25 GMT):
unless it expired
qsmen (Fri, 14 Sep 2018 07:07:04 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=wDQGXoERffrEnNPx5) @mastersingh24 Thank you,
tahaf10 (Fri, 14 Sep 2018 07:27:31 GMT):
Has joined the channel.
gravity (Fri, 14 Sep 2018 07:55:17 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=KMrqPt9udwatkmx65) @yacovm can I issue this pair (certificate and private key) using fabric ca?
yacovm (Fri, 14 Sep 2018 08:21:59 GMT):
Yes i think
Jgnuid (Mon, 17 Sep 2018 15:11:54 GMT):
Has joined the channel.
gravity (Tue, 18 Sep 2018 09:28:10 GMT):
@yacovm Hi
really need your help
I'm playing with the `fabric-ca` from fabric-samples
therein scripts ad admin user (which is used to create channels and install chaincodes) is registered on ca server and later enrolled to create a channel and here everything works well
but when I', trying to enroll this admin on ca with the same credentials using fabric-sdk, I'm told that identity is not an admin. but if I manually load cert and a keystore files from disks and create an enrollment object - everything is fine.
as for me, this is not very handy to load cert and a keystore file directly from disk and it would be better to enroll admin on ca when it's needed
is there any way to do this? am I missing something?
yacovm (Tue, 18 Sep 2018 09:49:20 GMT):
ask in #fabric-ca
yacovm (Tue, 18 Sep 2018 09:49:25 GMT):
I'm not a CA expert
gravity (Tue, 18 Sep 2018 09:49:54 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=J8GCcMwyXWhYFRfoL) @yacovm ah, thanks
imadahmad_ict (Tue, 18 Sep 2018 17:25:01 GMT):
Has joined the channel.
imadahmad_ict (Tue, 18 Sep 2018 17:25:10 GMT):
Hi everyone\
luckydogchina (Wed, 19 Sep 2018 02:17:31 GMT):
Has joined the channel.
Ryan2 (Wed, 19 Sep 2018 02:33:49 GMT):
Has joined the channel.
Shyam_Pratap_Singh (Thu, 20 Sep 2018 06:24:24 GMT):
Has joined the channel.
qsmen (Fri, 21 Sep 2018 08:27:26 GMT):
@mastersingh24 , transactions in fabric are based on account, not utxo. There is no privacy at all. With idemixer, client can transaction anonymously? Thank you.
mastersingh24 (Fri, 21 Sep 2018 08:48:48 GMT):
@qsmen - by using Identity Mixer, clients can create pseudo-anonymous and unlinkable identities
qsmen (Fri, 21 Sep 2018 08:52:40 GMT):
ok, that is great. Thank you, thanks to idemixer team
PrakharShukla (Mon, 24 Sep 2018 19:18:18 GMT):
Has joined the channel.
ZC_Cuebiq (Fri, 28 Sep 2018 12:37:34 GMT):
Has joined the channel.
zacpl (Fri, 28 Sep 2018 18:36:12 GMT):
Has joined the channel.
krabradosty (Sun, 30 Sep 2018 12:37:31 GMT):
Has joined the channel.
krabradosty (Sun, 30 Sep 2018 13:02:39 GMT):
Hello. Am I right that a peer retrieves attribute `hf.Type` from signer certificate during validating endorsement policies? But cryptogen doesn't add any attribute to peers certificates by default. And if my endorsement policy says "any peer from organization 1", all transactions will fail. Can I add this attribute with cryptogen?
mastersingh24 (Sun, 30 Sep 2018 13:45:33 GMT):
@krabradosty - the peer does not do anything with the attributes created by Fabric CA as they are not required.
mastersingh24 (Sun, 30 Sep 2018 13:46:17 GMT):
Put another way, MSPs and policies have nothing to do with the attributes created by the Fabric CA as the Fabric CA is not required for operation
mastersingh24 (Sun, 30 Sep 2018 13:47:05 GMT):
Have a read through https://hyperledger-fabric.readthedocs.io/en/release-1.2/membership/membership.html
krabradosty (Sun, 30 Sep 2018 13:57:03 GMT):
@mastersingh24 It that case how do peers during validating endorsement policy distinguish signature of peers from any other members (client, admin)?
mastersingh24 (Sun, 30 Sep 2018 17:30:05 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=WQbFzRDifgXGCvqLS) @krabradosty You need to use the NodeOU identifiers capability - https://hyperledger-fabric.readthedocs.io/en/release-1.2/msp.html#identity-classification
If you are using the Fabric CA, then it does actually add an `OU={hf.type}` in the issued certificates.
If you are using `cryptogen`, you can do this by setting `EnableNodeOUs=true` in your config file
asaningmaxchain123 (Mon, 01 Oct 2018 06:00:17 GMT):
Has joined the channel.
asaningmaxchain123 (Mon, 01 Oct 2018 06:02:09 GMT):
@mastersingh24 for the bccsp plugin,it support golang ? now i write the plugin bccsp and it generate a gm.a static lib,so how can i take it work?
mastersingh24 (Mon, 01 Oct 2018 09:16:00 GMT):
@asaningmaxchain123 - did you build using `go build -buildmode=plugin ...`
asaningmaxchain123 (Mon, 01 Oct 2018 09:48:33 GMT):
should add `-buildmode=plugin` tag ?
asaningmaxchain123 (Mon, 01 Oct 2018 09:50:52 GMT):
Clipboard - October 1, 2018 5:50 PM
mastersingh24 (Mon, 01 Oct 2018 09:51:51 GMT):
take a look at https://github.com/hyperledger/fabric/tree/release-1.2/examples/plugins/bccsp
mastersingh24 (Mon, 01 Oct 2018 09:52:02 GMT):
you have to have a "main" package
asaningmaxchain123 (Mon, 01 Oct 2018 09:54:07 GMT):
what should i do in the main function
asaningmaxchain123 (Mon, 01 Oct 2018 09:54:15 GMT):
Clipboard - October 1, 2018 5:54 PM
asaningmaxchain123 (Mon, 01 Oct 2018 09:54:25 GMT):
empty body
mastersingh24 (Mon, 01 Oct 2018 09:55:28 GMT):
you don't need the `func main()` ... you just need to have a `main` package
asaningmaxchain123 (Mon, 01 Oct 2018 09:56:26 GMT):
Clipboard - October 1, 2018 5:56 PM
asaningmaxchain123 (Mon, 01 Oct 2018 09:56:57 GMT):
are you sure,the ide gives me error tips
mastersingh24 (Mon, 01 Oct 2018 09:58:02 GMT):
yeah ... the IDE probably does not consider plugin buildmode
mastersingh24 (Mon, 01 Oct 2018 09:58:24 GMT):
the sample I posted above works fine ... and no `main()` function
asaningmaxchain123 (Mon, 01 Oct 2018 09:59:26 GMT):
ok,i ignore it
asaningmaxchain123 (Mon, 01 Oct 2018 09:59:54 GMT):
it generate the *.a static lib,so how to config it
asaningmaxchain123 (Mon, 01 Oct 2018 10:00:16 GMT):
Clipboard - October 1, 2018 6:00 PM
asaningmaxchain123 (Mon, 01 Oct 2018 10:00:39 GMT):
can you provide a `plugin config` example
asaningmaxchain123 (Mon, 01 Oct 2018 10:24:19 GMT):
in the fabric-ca, i config it with `bccsp:
default: PLUGIN
plugin:
hash: SHA2
security: 256
filekeystore:
# The directory used for the software file-based keystore
keystore: msp/keystore`
asaningmaxchain123 (Mon, 01 Oct 2018 10:24:19 GMT):
in the fabric-ca, i config it with ```bccsp:
default: PLUGIN
plugin:
hash: SHA2
security: 256
filekeystore:
# The directory used for the software file-based keystore
keystore: msp/keystore```
asaningmaxchain123 (Tue, 02 Oct 2018 03:08:29 GMT):
@mastersingh24 i have config it success,
Bartb0 (Tue, 02 Oct 2018 10:51:46 GMT):
Has joined the channel.
Baha-sk (Tue, 02 Oct 2018 19:10:16 GMT):
Has joined the channel.
AltifBrown (Tue, 02 Oct 2018 23:09:18 GMT):
Has joined the channel.
MaddaliPadmaja (Wed, 03 Oct 2018 07:13:25 GMT):
Has joined the channel.
qiangqinqq (Sat, 06 Oct 2018 07:35:02 GMT):
Has joined the channel.
Legiit (Mon, 08 Oct 2018 11:14:14 GMT):
Has joined the channel.
NageshCR (Tue, 09 Oct 2018 02:44:17 GMT):
Has joined the channel.
SubhraMazumdar (Thu, 11 Oct 2018 18:13:55 GMT):
Is it possible to incorporate RSA based signature scheme in Fabric given that only ECDSA is supported ?
SubhraMazumdar (Thu, 11 Oct 2018 18:15:04 GMT):
@mastersingh24 @manu @Jan.Camenisch @adc
mastersingh24 (Thu, 11 Oct 2018 18:17:48 GMT):
theoretically it might work, but we've never tested it at all
ashutosh_kumar (Thu, 11 Oct 2018 19:17:31 GMT):
@SubhraMazumdar , RSA is not supported on PKCS11 , but is supported on Software.
SubhraMazumdar (Fri, 12 Oct 2018 05:53:18 GMT):
@mastersingh24 if I want to integrate a module in Fabric based on RSA signature , how should I go about working on it ?
MohammadObaid (Fri, 12 Oct 2018 07:36:22 GMT):
Has joined the channel.
ashutosh_kumar (Fri, 12 Oct 2018 13:12:47 GMT):
@SubhraMazumdar , you want support for signing and verification ? Are you looking for code snippet/examples etc ?
mastersingh24 (Fri, 12 Oct 2018 20:12:01 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=gKDtpqGcgdj6jPGhE) @SubhraMazumdar most of the code is there is the bccsp package .... but I'd question why use RSA?
SumanPapanaboina (Sun, 14 Oct 2018 15:36:46 GMT):
Has joined the channel.
SubhraMazumdar (Sun, 14 Oct 2018 19:02:25 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=hwT4ggRwZfLomWuiq) @ashutosh_kumar yes that would be of great help..I want to know how can we integrate any module into Hypeledger Fabric if we want to add more functionality ? My scheme is RSA based and since it is not supported, shall I change it to an ECDSA based scheme ?
yacovm (Sun, 14 Oct 2018 19:07:26 GMT):
@SubhraMazumdar what does your scheme do?
yacovm (Sun, 14 Oct 2018 19:07:30 GMT):
out of curiousity
yacovm (Sun, 14 Oct 2018 19:07:30 GMT):
out of curiosity
SubhraMazumdar (Sun, 14 Oct 2018 19:12:11 GMT):
A linkable ring signature which can be used by endorsers while they are endorsing the transaction
SubhraMazumdar (Sun, 14 Oct 2018 19:12:28 GMT):
@yacovm
yacovm (Sun, 14 Oct 2018 19:13:58 GMT):
why would you want a *linkable* ring signature?
yacovm (Sun, 14 Oct 2018 19:14:02 GMT):
:thinking:
yacovm (Sun, 14 Oct 2018 19:14:17 GMT):
to speed things up?
SubhraMazumdar (Sun, 14 Oct 2018 19:14:42 GMT):
The motivation for this is that I see that in some cases it would make sense if validators were not aware who endorsed a transaction..and to prevent any double signing, I zeroed in on linkable ring signature scheme
yacovm (Sun, 14 Oct 2018 19:15:49 GMT):
but, if you use the x509 based MSP then the public keys are derived from linkable certificates no?
SubhraMazumdar (Sun, 14 Oct 2018 19:16:57 GMT):
Can you clarify ? I didnt get the point on linkable certificates relation with linkable ring signature ?
yacovm (Sun, 14 Oct 2018 19:20:57 GMT):
hmmm, how do you know the endorser's public key is related to fabric
yacovm (Sun, 14 Oct 2018 19:21:02 GMT):
and that the client didn't make it up?
SubhraMazumdar (Sun, 14 Oct 2018 19:24:19 GMT):
Is that possible ? Client cannot demand endorsement from any arbitrary entity who is not part of the channel in Fabric...an endorsement policy is specified at channel instantiation phase (can add dynamically now as stated in v1.3)
yacovm (Sun, 14 Oct 2018 19:25:02 GMT):
You have a ring signature, right?
SubhraMazumdar (Sun, 14 Oct 2018 19:25:07 GMT):
yes
yacovm (Sun, 14 Oct 2018 19:25:12 GMT):
do you agree that to verify the signature you need the public keys of the ring?
SubhraMazumdar (Sun, 14 Oct 2018 19:25:18 GMT):
yes true
yacovm (Sun, 14 Oct 2018 19:25:28 GMT):
so the public keys, they reside in an x509 certificate
yacovm (Sun, 14 Oct 2018 19:25:34 GMT):
but it's linkable
SubhraMazumdar (Sun, 14 Oct 2018 19:26:00 GMT):
yes
yacovm (Sun, 14 Oct 2018 19:26:13 GMT):
wait, hold on - you're saying that the peers would know the public key list upfront?
yacovm (Sun, 14 Oct 2018 19:26:26 GMT):
so that they won't need the certificates inside the endorsement?
SubhraMazumdar (Sun, 14 Oct 2018 19:26:53 GMT):
yes my list of endorsers is known to everyone..it can be done some x% of total decide to vote...which x% vote that remains hidden
yacovm (Sun, 14 Oct 2018 19:27:07 GMT):
how is it known to everyone?
yacovm (Sun, 14 Oct 2018 19:27:12 GMT):
is it hardcoded or something?
yacovm (Sun, 14 Oct 2018 19:27:34 GMT):
is this a research project?
SubhraMazumdar (Sun, 14 Oct 2018 19:27:55 GMT):
Sorry for using the term everyone...while i set up the channel...endorsement set is fixed
yacovm (Sun, 14 Oct 2018 19:28:26 GMT):
yeah obviously it's by everyone in the channel and not by everyone in the US or everyone in Asia
yacovm (Sun, 14 Oct 2018 19:28:40 GMT):
I'm asking how
yacovm (Sun, 14 Oct 2018 19:31:37 GMT):
?
SubhraMazumdar (Sun, 14 Oct 2018 19:35:35 GMT):
It is a part of my dissertation work done for my post graduate course
SubhraMazumdar (Sun, 14 Oct 2018 19:35:44 GMT):
But I could not make much progress on it
yacovm (Sun, 14 Oct 2018 19:35:53 GMT):
ahhh i see
yacovm (Sun, 14 Oct 2018 19:36:01 GMT):
well it can be done
SubhraMazumdar (Sun, 14 Oct 2018 19:36:27 GMT):
Shall I post the details on JIRA ?
yacovm (Sun, 14 Oct 2018 19:36:34 GMT):
yeah sure...
yacovm (Sun, 14 Oct 2018 19:36:47 GMT):
you can tag me (same username as here) and I can comment a few ideas
SubhraMazumdar (Sun, 14 Oct 2018 19:37:04 GMT):
Sure...thanks for the help :)
ashutosh_kumar (Mon, 15 Oct 2018 01:08:15 GMT):
@SubhraMazumdar , Ring signature are asymptotic in nature and mostly based on factorization , so why are you basing your solution based on the above ?
ashutosh_kumar (Mon, 15 Oct 2018 01:09:07 GMT):
Group theoretic based zero knowledge proof seems better option to me where you need to find a generator of group.
ashutosh_kumar (Mon, 15 Oct 2018 01:11:26 GMT):
There are number of variants of Zero Knowledge proof implementation and it seemed to be more secured compared to Ring Signature per literature.
SubhraMazumdar (Mon, 15 Oct 2018 06:22:14 GMT):
I am doing so by issuing a signature of knowledge of an endorser's secret key, and public key
SubhraMazumdar (Mon, 15 Oct 2018 07:21:04 GMT):
https://jira.hyperledger.org/browse/FAB-12455
SubhraMazumdar (Mon, 15 Oct 2018 07:21:11 GMT):
I have posted my issue over here
SubhraMazumdar (Mon, 15 Oct 2018 07:21:11 GMT):
I have posted the problem statement and what I intend to do over here
AnirudhC (Wed, 17 Oct 2018 06:15:37 GMT):
Has joined the channel.
AnirudhC (Wed, 17 Oct 2018 06:15:51 GMT):
Hi, Is it possible to store keystore , certificates, credetialStore, MSP etc to store in Vault (Hashicorp vault) and access them from Vault while setting up HL fabric network?
ashutosh_kumar (Wed, 17 Oct 2018 06:30:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=QG2ehL5cL2DrpjS6f) @AnirudhC It is not supported at this moment.
AnirudhC (Thu, 18 Oct 2018 11:49:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=pMxdWAD6u9SrjFEWT) @ashutosh_kumar Can you please suggest secure way to store keystore , certificates, credetialStore?
kh.nguyen (Fri, 19 Oct 2018 00:19:30 GMT):
Has joined the channel.
AndrewNRise (Fri, 19 Oct 2018 08:18:14 GMT):
Has joined the channel.
Legiit (Fri, 19 Oct 2018 11:13:09 GMT):
can we use the enrollment privateKeyPEM and signedCertPEM to sign transactions offline?
I returns a access denied error
Legiit (Fri, 19 Oct 2018 11:13:09 GMT):
can we use the enrollment privateKeyPEM and signedCertPEM to sign transactions offline?
It returns a access denied error
Legiit (Fri, 19 Oct 2018 11:13:09 GMT):
can we use the enrollment privateKeyPEM and signedCertPEM to sign transactions offline?
It returns an access denied error
Legiit (Fri, 19 Oct 2018 11:15:36 GMT):
I don't really understand the difference between the KeyValueStore versus the CryptoSuite/Wallet and the KeyStore
Legiit (Fri, 19 Oct 2018 11:15:38 GMT):
Which is used for what
WouterVanHecke (Fri, 19 Oct 2018 18:49:25 GMT):
Has joined the channel.
AnirudhC (Mon, 22 Oct 2018 05:51:21 GMT):
Hi, Can anyone please suggest secure way to store keystore , certificates and credetialStore?
ping40 (Tue, 23 Oct 2018 06:32:54 GMT):
Has joined the channel.
mastersingh24 (Tue, 23 Oct 2018 12:01:25 GMT):
You can always use PKCS11 with an HSM.
Else not really sure what you are looking for? You can also lock down file permissions, encrypt your directory, etc.
ashutosh_kumar (Tue, 23 Oct 2018 22:41:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=hLkSiRPW8KRDeCRQt) @AnirudhC KeyStore is secure whether it is pkcs12 or Java Key store. You can put your private key and signer certs there. Like @mastersingh24 said , you can use HSM as an alternative. You can do field level and disk level encryption also. A lots of choices.
ashutosh_kumar (Tue, 23 Oct 2018 22:54:39 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=eDRP978FJdor44rx3) @AnirudhC I suggested below how to store your keys , certs etc securely. Hashicorp and Fabric is not integrated at this moment and there is no plug-in points as well. So , you need to manually , via CLI or API , put your private key and certs in the Hashicorp vault.
ashutosh_kumar (Tue, 23 Oct 2018 22:54:39 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=eDRP978FJdor44rx3) @AnirudhC I suggested above how to store your keys , certs etc securely. Hashicorp and Fabric is not integrated at this moment and there is no plug-in points as well. So , you need to manually , via CLI or API , put your private key and certs in the Hashicorp vault.
DuPeng (Wed, 24 Oct 2018 02:04:24 GMT):
Has joined the channel.
vtech (Wed, 24 Oct 2018 06:44:21 GMT):
Hi,
I have enabled the softhsm using fabric-client and softhsm2 is provisioned. But when trying to up the network it is switching back to default SW option as PKCS11 is not picked up. Can somebody please review and help here. Below is the debug logs:
```
Attempting to fetch system channel 'e2e-orderer-syschan' ...61 secs
2018-10-24 06:14:42.907 UTC [viperutil] unmarshalJSON -> DEBU 001 Unmarshal JSON: value is not a string:
vtech (Wed, 24 Oct 2018 06:44:21 GMT):
Hi,
I have enabled the softhsm using fabric-client and softhsm2 is provisioned. But when trying to up the network it is switching back to default SW option as PKCS11 is not picked up. Can somebody please review and help here. Below is the debug logs:
```
Attempting to fetch system channel 'e2e-orderer-syschan' ...61 secs
2018-10-24 06:14:42.907 UTC [viperutil] unmarshalJSON -> DEBU 001 Unmarshal JSON: value is not a string:
GuillaumeTong (Wed, 24 Oct 2018 10:11:26 GMT):
Has joined the channel.
ashutosh_kumar (Wed, 24 Oct 2018 17:34:05 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=i9DkpCFTmgrHw9Qao) @vtech you need to configure softHsm on the fabric or the server where Fabric is running. I assume , you have done that.
ashutosh_kumar (Wed, 24 Oct 2018 17:34:32 GMT):
Also , try to get latest fabric code base , if possible.
cagdast (Thu, 25 Oct 2018 07:41:51 GMT):
Has joined the channel.
vtech (Thu, 25 Oct 2018 10:03:54 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=biS3ZnRWutCQufPwz) @ashutosh_kumar Thanks.. will try with latest version.
scottz (Mon, 29 Oct 2018 21:25:46 GMT):
Has left the channel.
AbhinayB (Tue, 30 Oct 2018 04:13:24 GMT):
Hi!
Where do the certificates get stored when new users are created using a fabric CA server?
mastersingh24 (Tue, 30 Oct 2018 10:03:25 GMT):
@AbhinayB - Private keys are always stored local to the client which enrolls. Where it is stored depends on which method you use to enroll, i.e. fabric-ca-client, one of the SDKs or by using the Fabric CA APIs directly. When the client enrolls, a copy of the public key is stored in the Fabric CA database but is also sent to the client in the response to the enroll call and then stored locally alongside the private key
AbhinayB (Tue, 30 Oct 2018 10:10:35 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=5AJMEQzw7gERMG2es) @mastersingh24 I've used java SDK but couldn't find a location where the private keys and public keys are stored. Using the fabric-ca-client, I was able to locate them locally but couldn't see it in the case of java SDK. Can you help me?
IgarashiTakashi (Thu, 01 Nov 2018 13:47:04 GMT):
Has joined the channel.
Jgnuid (Sat, 03 Nov 2018 00:29:34 GMT):
@mastersingh24 , just out of curiosity: why the fabric-ca-server sends the public key to the client if the client generated the private key and thus knows the public key?
mastersingh24 (Sat, 03 Nov 2018 13:13:28 GMT):
@Jgnuid - Fabric CA sends back a X.509 certificate not just a plain EC public key
davidkhala (Tue, 06 Nov 2018 02:42:55 GMT):
Has joined the channel.
awes0menessInc (Tue, 06 Nov 2018 03:36:21 GMT):
Has joined the channel.
demonkm (Tue, 06 Nov 2018 07:35:07 GMT):
Has joined the channel.
yoheiueda (Wed, 07 Nov 2018 01:20:45 GMT):
Has joined the channel.
enriquebusti (Wed, 07 Nov 2018 12:01:06 GMT):
Has joined the channel.
dijun (Fri, 09 Nov 2018 09:45:29 GMT):
Hi all
I made a patch for China standard crypto support in fabric. You can apply the patch in your project if you want to get this feature.
Note that this is only support for release version(1.1.x / 1.2.x / 1.3.x), otherwise you should fix the conflict when you apply this patch.
Customized cryptogen is alse provided, called cryptogensm. make cryptogensm in your project to make use of it.
Feel free to try it at https://github.com/flyinox/fabric-sm-patch
Because of the deep coupling with x509 which will be modified to support China crypto standards, making a patch is a good tradeoff to work with.
So I wonder if that is possible to add this patch file to fabric, so everyone who want to get use of it can simply apply it. In this way, anyone not interesting with it can be barely affected.
Any feedback or suggestion will be appreciated.
JonasM (Wed, 14 Nov 2018 15:43:53 GMT):
Has joined the channel.
githubcpc (Thu, 15 Nov 2018 00:41:29 GMT):
Has joined the channel.
h4995974 (Thu, 15 Nov 2018 22:03:11 GMT):
Has joined the channel.
h4995974 (Thu, 15 Nov 2018 22:03:13 GMT):
Hello everyone.
We're receiving the following error when trying to spin up peers inside a kubernetes pods. `2018-11-15 21:52:25.172 UTC [gossip/gossip] handleMessage -> WARN 01f Message GossipMessage: tag:EMPTY alive_msg:
BellaAdams (Sat, 17 Nov 2018 00:45:44 GMT):
Has joined the channel.
huxiangdong (Tue, 20 Nov 2018 00:32:06 GMT):
Has joined the channel.
tinywell (Wed, 21 Nov 2018 02:14:23 GMT):
Has joined the channel.
qsmen (Wed, 21 Nov 2018 07:32:06 GMT):
hi experts, consider additive homogeneous encryption scheme， like Paillier scheme. How do endorsers check if a user's balance is bigger than zero when the balance is encrypted? if no check, when more money than the balance is tranfered, the balance may be negative, say -a, that means the balance will be very big ,say (n-a). How to check if the balance is legal?
bh4rtp (Wed, 21 Nov 2018 09:06:40 GMT):
hi, i enabled softhsm for fabric-ca. how can i use pkcs11 with node sdk client?
yacovm (Wed, 21 Nov 2018 09:51:11 GMT):
@qsmen you mean homomorphic , not homogenous... right?
qsmen (Thu, 22 Nov 2018 00:44:36 GMT):
sorry, yes, homomorphic
qsmen (Thu, 22 Nov 2018 00:46:08 GMT):
@yacovm
yacovm (Thu, 22 Nov 2018 00:47:26 GMT):
@qsmen I was under the impression that in homomorphic encryption
yacovm (Thu, 22 Nov 2018 00:47:34 GMT):
you cannot check anything if you don't have the private key
yacovm (Thu, 22 Nov 2018 00:47:42 GMT):
otherwise it breaks semantic security of the scheme
yacovm (Thu, 22 Nov 2018 00:47:42 GMT):
otherwise it breaks semantic security of the scheme (anything you can compute about the plaintext with the ciphertext, you can compute without the ciphertext)
yacovm (Thu, 22 Nov 2018 00:47:44 GMT):
no?
qsmen (Thu, 22 Nov 2018 00:50:13 GMT):
yes, I have the just impression as you have
qsmen (Thu, 22 Nov 2018 00:50:58 GMT):
but huawei company implemented a version that can check if the banance is above 0 without decryption
qsmen (Thu, 22 Nov 2018 00:50:58 GMT):
but huawei company implemented a version that can check if the banance is above 0 without decryption
yacovm (Thu, 22 Nov 2018 00:52:11 GMT):
can you give more info?
yacovm (Thu, 22 Nov 2018 00:52:33 GMT):
I guess maybe they use punctureable encryption or something
yacovm (Thu, 22 Nov 2018 00:53:48 GMT):
I don't really know that stuff though
qsmen (Thu, 22 Nov 2018 01:00:02 GMT):
https://support.huaweicloud.com/devg-bcs/bcs_devg_0023.html, but it is writtten in Chinese.
Chaincode端无法验证该用户的真实金额，只能验证该金额是大于0的范围。
qsmen (Thu, 22 Nov 2018 01:00:41 GMT):
it is translated into : chaincode can not check the real balance, but only can check if it is above 0
qsmen (Thu, 22 Nov 2018 01:00:41 GMT):
it is translated into : chaincode can not check the real balance, but only can check if it is above 0
qsmen (Thu, 22 Nov 2018 01:02:35 GMT):
They use ecdsa to implement homomorphic encrytion
qsmen (Thu, 22 Nov 2018 01:04:16 GMT):
It would be better if a person from huawei be here and explain how.
qsmen (Thu, 22 Nov 2018 01:04:16 GMT):
It would be better if a person from huawei be here and explain how.
qsmen (Thu, 22 Nov 2018 01:37:39 GMT):
maybe some zero knowledger proof above balance is used as parameter to chaincode, so chaincode can check the balance is above 0?
qsmen (Thu, 22 Nov 2018 01:37:39 GMT):
maybe some zero knowledger proof on balance is used as parameter to chaincode, so chaincode can check the balance is above 0?
qsmen (Thu, 22 Nov 2018 03:13:52 GMT):
if following the zero knowledger proof method, how to proceed?
qsmen (Thu, 22 Nov 2018 03:15:26 GMT):
no paper is found on the use of ecdsa as homomorphic encryption.
yacovm (Thu, 22 Nov 2018 10:39:24 GMT):
@adc
yacovm (Thu, 22 Nov 2018 10:39:28 GMT):
what is your opinion?
qsmen (Fri, 23 Nov 2018 01:05:41 GMT):
https://cointelegraph.com/news/ing-creates-wall-street-friendly-blockchain-solution, this link provide the Zero-knowledge range proof. I think Huawei may take this method too, not HE method.
qsmen (Fri, 23 Nov 2018 01:05:41 GMT):
https://cointelegraph.com/news/ing-creates-wall-street-friendly-blockchain-solution, this link provide the Zero-knowledge range proof. I think Huawei may take this method too,
qsmen (Fri, 23 Nov 2018 01:05:41 GMT):
https://cointelegraph.com/news/ing-creates-wall-street-friendly-blockchain-solution, this link provide the Zero-knowledge range proof.
Unni_1994 (Fri, 23 Nov 2018 10:30:02 GMT):
Has joined the channel.
sanket1211 (Mon, 26 Nov 2018 07:30:21 GMT):
Has joined the channel.
ashutosh_kumar (Mon, 26 Nov 2018 15:04:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=PpSzkZ7QtuBxGYJqk) @bh4rtp Node sdk has its own pkcs11 implementation. You might want to look into Node SDK doc. Let me know , if you need any help.
joaquimpedrooliveira (Tue, 27 Nov 2018 13:34:31 GMT):
Has left the channel.
TopJohn (Fri, 30 Nov 2018 02:10:09 GMT):
Has joined the channel.
mastersingh24 (Fri, 30 Nov 2018 17:31:35 GMT):
@qsmen - take a look at https://elementsproject.org/features/confidential-transactions/investigation
mastersingh24 (Fri, 30 Nov 2018 17:32:31 GMT):
It explains a partially homomorphic system using eliiptic curves, a Pedersen commitment scheme and of course range proofs
wangheng (Mon, 03 Dec 2018 02:25:56 GMT):
Has joined the channel.
qsmen (Tue, 04 Dec 2018 06:19:27 GMT):
thank you, I will read it.
qsmen (Tue, 04 Dec 2018 06:46:22 GMT):
Ecient Proofs that a Committed Number Lies in an Interval is a good paper too. what is the exact paper on Perdersen commitment? Thanks.
mastersingh24 (Tue, 04 Dec 2018 14:25:20 GMT):
there's a short section on Pedersen commitment's in here: https://cs.nyu.edu/courses/spring12/CSCI-GA.3210-001/lect/lecture14.pdf
ashutosh_kumar (Tue, 04 Dec 2018 14:55:06 GMT):
thanks @mastersingh24 , I'll also read the paper. Hopefully , I'll be able to understand something. :wink:
arjitkhullar (Wed, 05 Dec 2018 00:02:06 GMT):
Has joined the channel.
Pradeep_Pentakota (Wed, 05 Dec 2018 01:40:01 GMT):
Has joined the channel.
pujabhattad (Wed, 05 Dec 2018 12:19:39 GMT):
Has joined the channel.
javapriyan (Sun, 09 Dec 2018 17:22:50 GMT):
Has joined the channel.
dbmath (Tue, 11 Dec 2018 20:51:12 GMT):
Has joined the channel.
edwardlee (Thu, 13 Dec 2018 14:55:54 GMT):
Has joined the channel.
GuillaumeTong (Mon, 17 Dec 2018 10:39:20 GMT):
Has left the channel.
mervecankus (Mon, 17 Dec 2018 12:34:38 GMT):
Has joined the channel.
avestaa (Mon, 17 Dec 2018 18:16:10 GMT):
Has joined the channel.
gsgx (Tue, 18 Dec 2018 18:34:33 GMT):
Has joined the channel.
thakkarparth007 (Wed, 19 Dec 2018 07:38:24 GMT):
Not sure if this is the right place to ask this, so redirect me if required.
In a Fabric deployment, is it possible/does it make sense for this: 3 peers exist in a channel with MSPID's OrgA, OrgB, OrgC, and I want a client of some OrgD to be able to invoke transactions in this.
Essentially, to be a client in a network, does the client's org have to run a peer?
yacovm (Wed, 19 Dec 2018 11:49:16 GMT):
@thakkarparth007 of course it makes sense....
yacovm (Wed, 19 Dec 2018 11:49:26 GMT):
it's actually the recommended use case, I'd say
yacovm (Wed, 19 Dec 2018 11:49:31 GMT):
that clients have their own MSP and CA
yacovm (Wed, 19 Dec 2018 11:50:12 GMT):
Think about it - if you're a customer of a bank, you have credentials to enter the bank, but not to enter the bank's administrative systems
IgorSim (Wed, 19 Dec 2018 14:40:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=Jxmvv6bufdaXjF6of) @yacovm @yacovm But, theoretically, clients of OrgD (i guess that translates to enrolled users with CA from OrgD) should be able to transact with network even if OrgD doesn't have peer, as long as OrgD is part of the network (MSP is defined and is part of channel configuration). Is that correct?
IgorSim (Wed, 19 Dec 2018 14:40:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=Jxmvv6bufdaXjF6of) @yacovm But, theoretically, clients of OrgD (i guess that translates to enrolled users with CA from OrgD) should be able to transact with network even if OrgD doesn't have peer, as long as OrgD is part of the network (MSP is defined and is part of channel configuration). Is that correct?
yacovm (Wed, 19 Dec 2018 14:41:03 GMT):
@IgorSim yeah of course
IgorSim (Wed, 19 Dec 2018 14:42:17 GMT):
ok, tnx
thakkarparth007 (Wed, 19 Dec 2018 15:56:52 GMT):
Got it, thanks @yacovm
akshay.sood (Thu, 20 Dec 2018 08:41:23 GMT):
Hi Guys
akshay.sood (Thu, 20 Dec 2018 08:41:24 GMT):
Anyone knows how to generate certificates without using cryptogen? Is there any way to achieve that or is that even possible to generate certificates for org directly without using cryptogen? I know it becomes very easy to generate those crypto using cryptogen but I was looking for an alternate way
yacovm (Thu, 20 Dec 2018 08:42:10 GMT):
https://www.ibm.com/support/knowledgecenter/en/SSWHYP_4.0.0/com.ibm.apimgmt.cmc.doc/task_apionprem_gernerate_self_signed_openSSL.html
akshay.sood (Thu, 20 Dec 2018 08:56:22 GMT):
thanks @yacovm
httran88 (Thu, 20 Dec 2018 15:41:40 GMT):
Has joined the channel.
httran88 (Thu, 20 Dec 2018 15:41:56 GMT):
Hello, can signingIdentity ID be used as uuid?
httran88 (Thu, 20 Dec 2018 15:42:02 GMT):
or as addresses?
lightcap (Thu, 20 Dec 2018 16:38:22 GMT):
Has joined the channel.
seokm0 (Fri, 21 Dec 2018 02:25:06 GMT):
Has joined the channel.
mervecankus (Fri, 21 Dec 2018 10:19:36 GMT):
Hi! I would like to use homomorphic encryption with Hyperledger. Is there any way that I can use HELib (https://github.com/shaih/HElib)? Can I use it like a plug in?
yacovm (Fri, 21 Dec 2018 11:49:38 GMT):
@mervecankus you mean in the chaincode?
yacovm (Fri, 21 Dec 2018 11:49:44 GMT):
or on the client side?
mervecankus (Fri, 21 Dec 2018 11:57:23 GMT):
@yacovm in the chaincode
yacovm (Fri, 21 Dec 2018 11:57:55 GMT):
then you need somehow to include your HElib stuff in the chaincode when you package it
yacovm (Fri, 21 Dec 2018 11:58:01 GMT):
i think that ideally
yacovm (Fri, 21 Dec 2018 11:58:09 GMT):
you will just compile locally the `.a` file
yacovm (Fri, 21 Dec 2018 11:58:24 GMT):
and then you can call the C++ code from Go
yacovm (Fri, 21 Dec 2018 11:58:47 GMT):
in the chaincode
merq (Sat, 22 Dec 2018 03:44:25 GMT):
Has joined the channel.
mervecankus (Tue, 25 Dec 2018 15:53:05 GMT):
thank you @yacovm
yacovm (Tue, 25 Dec 2018 15:53:25 GMT):
sure
ashokkj (Fri, 28 Dec 2018 09:38:01 GMT):
Has joined the channel.
PavanDurgadsimi (Sun, 30 Dec 2018 08:50:11 GMT):
Has joined the channel.
CryBtoS (Wed, 09 Jan 2019 12:44:21 GMT):
Has joined the channel.
CryBtoS (Wed, 09 Jan 2019 12:57:22 GMT):
Hey, I added a new signature scheme by providing a new Signer and Verifier. So far I seems to work. However, the scheme is stateful and so that I now want to update the key after a signing operation.
I found out that the fileBasedKeyStore provide a storing method for keys. I though about giving a reference to a fileBaseKeyStore within the SignerOpts to the Sign-method of my new Signer.
Can somebody tell me where these SignerOpts are set?
Or is there a better way to update the private key?
dev-d (Thu, 10 Jan 2019 16:21:22 GMT):
Has joined the channel.
qsmen (Sat, 12 Jan 2019 09:05:58 GMT):
hi，experts here, it is said the bulletproof in Elements blockchain project is more smaller, more efficient.
qsmen (Sat, 12 Jan 2019 09:05:58 GMT):
hi，experts here, it is said the bulletproof in Elements blockchain project is more smaller, more efficient. could some say something about it? could we use it in fabric?
qsmen (Sat, 12 Jan 2019 09:05:58 GMT):
hi，experts here, it is said the bulletproof in Elements blockchain project is more smaller, more efficient. could someone say something about it? could we use it in fabric?
yacovm (Sat, 12 Jan 2019 09:07:11 GMT):
what project??
qsmen (Sat, 12 Jan 2019 09:07:36 GMT):
Elements
yacovm (Sat, 12 Jan 2019 09:07:39 GMT):
link?
qsmen (Sat, 12 Jan 2019 09:07:55 GMT):
https://elementsproject.org/features
qsmen (Sat, 12 Jan 2019 09:10:46 GMT):
it is base on Pedersen’s commitment. what is the difference between it and Fujisaki-Okamoto Commitment?
yacovm (Sat, 12 Jan 2019 09:11:30 GMT):
I never heard of the second one
qsmen (Sat, 12 Jan 2019 09:12:58 GMT):
the second is mentioned in paper "Efficient Proofs that a Committed Number Lies in an Interval"
qsmen (Sat, 12 Jan 2019 09:13:56 GMT):
by Boudot in 1999, in eurocrypt 99
yacovm (Sat, 12 Jan 2019 09:14:57 GMT):
I didn't look into the paper, but - isn't that just a range proof?
yacovm (Sat, 12 Jan 2019 09:15:16 GMT):
you can do that in ZK with sigma protocols, no?
yacovm (Sat, 12 Jan 2019 09:16:22 GMT):
oh i see they describe several ways
qsmen (Sat, 12 Jan 2019 09:16:26 GMT):
https://eprint.iacr.org/2017/1066, this is the bulletproof
yacovm (Sat, 12 Jan 2019 09:19:53 GMT):
so yes, the FO commitment does look like Pedersen to me too
yacovm (Sat, 12 Jan 2019 09:20:06 GMT):
maybe @adc can say something more intelligent
yacovm (Sat, 12 Jan 2019 09:25:12 GMT):
oh i see now-
> they enable proving that a committed value is in a range using only 2log2(n)+9 group and field elements, where n is the bit length of the range.
This is indeed much shorter than the standard range proofs that are linear in the bit size
qsmen (Sat, 12 Jan 2019 09:28:59 GMT):
still support homomorphic encryption?
yacovm (Sat, 12 Jan 2019 09:31:27 GMT):
?
qsmen (Sat, 12 Jan 2019 10:53:19 GMT):
so it can support the normal transactions in ciphertext
qsmen (Sat, 12 Jan 2019 11:10:54 GMT):
The bulletproof is based on Perderson committment, should be related to ECC. Because it can be used in transaction in Elements blockchain project, it should support additive homomorphic encryption. However, I never know a homomorphic encryption based on ECC.
qsmen (Sat, 12 Jan 2019 11:33:56 GMT):
what puzzled me is that several blockchain projects based on fabric use Paillier as the encryption algorithm
AVetter (Mon, 14 Jan 2019 08:06:17 GMT):
Has joined the channel.
ashutosh_kumar (Mon, 14 Jan 2019 15:13:16 GMT):
@qsmen , Pailier is based on homomorphic encryption and multiplicative homomorphism is possible due to biliner maps. The group corresponding to Bilinear map might be part of ECC finite field , so that might be connection between homomorphic encryption and ECC.
qsmen (Tue, 15 Jan 2019 02:08:34 GMT):
Thank you, Kumar. That is very directive.
lovesh (Wed, 16 Jan 2019 14:21:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=4k4Nqmkgg5WQqtFr9) @qsmen Pedersen commitment can be done without ECC too. Besides range proof, you can use bulletproofs to prove arbitrary statements too, eg. I can commit to a value and prove that the value committed to is greater than 5 and less than 10. This has applications in anonymous credentials.
AVetter (Thu, 17 Jan 2019 09:09:43 GMT):
The fabric-shim-crypto node module uses a random IV if none is provided ( https://github.com/hyperledger/fabric-chaincode-node/blob/release-1.4/fabric-shim-crypto/lib/enc-sign.js#L42 ). But does this not make the chaincode execution non deterministic and therefore the transaction can not be endorsed?
mastersingh24 (Thu, 17 Jan 2019 14:13:27 GMT):
You are correct ... this only works in the single endorser case (i.e. development). Otherwise you must pass the IV in via transient parameter
rdbmsdata78 (Fri, 18 Jan 2019 00:39:15 GMT):
Has joined the channel.
AVetter (Fri, 18 Jan 2019 14:03:24 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=w3TB94z3FNv3YMmMo) @mastersingh24 Good, thank you!
aseemrb (Mon, 21 Jan 2019 23:23:55 GMT):
Has joined the channel.
ycarmel (Tue, 22 Jan 2019 08:39:20 GMT):
Has joined the channel.
alokkv (Tue, 22 Jan 2019 17:11:41 GMT):
Has joined the channel.
Jamie (Tue, 22 Jan 2019 17:12:59 GMT):
Has joined the channel.
incarose (Wed, 23 Jan 2019 00:23:01 GMT):
Has joined the channel.
binhn (Sat, 26 Jan 2019 16:50:06 GMT):
Has left the channel.
lip-inagora (Mon, 28 Jan 2019 00:21:51 GMT):
Has joined the channel.
CryBtoS (Mon, 28 Jan 2019 07:22:14 GMT):
Hey, is there a way to update a peer private key file?
yacovm (Mon, 28 Jan 2019 08:19:02 GMT):
replace the file and restart the peer
edisinovcic (Mon, 28 Jan 2019 13:16:22 GMT):
Has joined the channel.
satyarth1 (Tue, 29 Jan 2019 07:29:14 GMT):
Has joined the channel.
satyarth1 (Tue, 29 Jan 2019 07:29:31 GMT):
Screenshot from 2019-01-29 10-41-55.png
mastersingh24 (Tue, 29 Jan 2019 09:46:58 GMT):
@satyarth1 - we'd have to see more info from the peer logs ... you should be able to see the logs in the console although you'll have to scroll back
mastersingh24 (Tue, 29 Jan 2019 09:47:36 GMT):
You can also try to dump the logs from the peer container using docker log s command as well
bdjidi (Wed, 30 Jan 2019 20:12:13 GMT):
Has left the channel.
gravity (Thu, 31 Jan 2019 15:19:11 GMT):
hi @yacovm
what is the recommended expiration time for the certificates for peers and orderers? is it a good practice to leave expiry time 1 year and re-enroll them before they expire?
and what it takes to re-enroll a peer whet it's certificate gets expired?
thanks in advance
yacovm (Thu, 31 Jan 2019 15:28:28 GMT):
the practice is up to the CA and the policies
yacovm (Thu, 31 Jan 2019 15:28:43 GMT):
some vendors rotate once per 3 months
yacovm (Thu, 31 Jan 2019 15:29:03 GMT):
you need to restart the node to make it load a new TLS certificate
yacovm (Thu, 31 Jan 2019 15:29:27 GMT):
in the future *maybe* you'll be able to do that while it is online
gravity (Thu, 31 Jan 2019 15:30:40 GMT):
@yacovm is it the same for an enrollment certificate?
yacovm (Thu, 31 Jan 2019 15:31:19 GMT):
I guess for both
yacovm (Thu, 31 Jan 2019 15:31:25 GMT):
oh wait
yacovm (Thu, 31 Jan 2019 15:31:36 GMT):
I was talking about dynamically updating the TLS cert
yacovm (Thu, 31 Jan 2019 15:31:46 GMT):
the endorllement is going to be harder to dynamically update
gravity (Thu, 31 Jan 2019 15:34:31 GMT):
@yacovm
so for now, to re-enroll a peer (or orderer), we should issue `reenroll` using `fabric-ca-client`, place new certificate to the msp directory and restart a peer (or orderer), right?
yacovm (Thu, 31 Jan 2019 15:39:51 GMT):
i don't know fabric-CA client :)
gravity (Thu, 31 Jan 2019 15:42:44 GMT):
@yacovm
I mean, that the general idea of updating enrollment certificates is the same compared to tls certificates, isn't it?
or should I better ask this question in #fabric-ca ?
yacovm (Thu, 31 Jan 2019 15:43:06 GMT):
ask there
gravity (Thu, 31 Jan 2019 15:43:31 GMT):
got it, thanks
DavidP (Fri, 01 Feb 2019 14:55:24 GMT):
Has joined the channel.
pasimoes (Sat, 02 Feb 2019 00:58:21 GMT):
Has joined the channel.
Legiit (Mon, 04 Feb 2019 07:43:05 GMT):
Hey guys! How can we prevent the need for the crypto-config folder to be present for the fabric-client SDK and instead go through the fabric-ca for these certs?
I can assume we don't want all certificates in 1 place on the server
ashutosh_kumar (Tue, 05 Feb 2019 15:41:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=Dw6B8BqnA2y7jjfuK) @Legiit Can you explain little bit more ?
knagware9 (Wed, 06 Feb 2019 06:40:53 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=myhtD4XbtELjksjMY) @ashutosh_kumar use this https://www.cnblogs.com/llongst/p/9786024.html
Legiit (Wed, 06 Feb 2019 07:42:24 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=myhtD4XbtELjksjMY) I am sorry, I think this question is better suited for #fabric-ca
But I'll rephrase it anyways, for development we have a crypto-config folder with all certificates. This is not done for production and therefor we should get the certificates from the CA instead. The question is how you switch from using the crypto-config to the fabric-ca
mastersingh24 (Thu, 07 Feb 2019 09:56:59 GMT):
@Legiit - Have a look at
- https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html#how-to-generate-msp-certificates-and-their-signing-keys to understand the local MSP structure and what is required for peer and ordering nodes
- https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/users-guide.html#enrolling-a-peer-identity shows how to use the fabric-ca-client to obtain the base information needed for the local MSPs
- https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html#channel-msp-setup explains what is needed in the "org msp" folders used in channel creation
The "trickiest" thing to deal with is making sure that you register and enroll and "org admin" as you'll need to add the org admin's public cert into the `admincerts` folder of your local and org MSPs
Legiit (Thu, 07 Feb 2019 12:14:52 GMT):
So there's no possibility for the network to boot and register themselves on their own? Or do it through the node-sdk? @mastersingh24
mastersingh24 (Thu, 07 Feb 2019 13:09:17 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=MZBbimuE9MkuWySMH) @Legiit Correct ... we intentionally do not tie Fabric nodes to Fabric CA because you are free to generate the crypto material in any manner you like
Legiit (Thu, 07 Feb 2019 13:40:00 GMT):
but we can do it through the SDK? @mastersingh24
Jonra1993 (Thu, 07 Feb 2019 14:34:20 GMT):
Has joined the channel.
satyarth1 (Fri, 08 Feb 2019 05:28:34 GMT):
hello members my query is, which fabric sdk i preferred for developing api's in golang
mastersingh24 (Sun, 10 Feb 2019 12:50:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=YXkaebEofLDZ3uv5v) @Legiit You can ... but why would you do that? Seems like extra overhead for something that is basically done once?
Legiit (Mon, 11 Feb 2019 08:52:05 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=82XdJt2iWpnEYKftE) we are basically trying to boot a network with 1 "start script" which would be able to dynamically add networks
So it should be able o
Legiit (Mon, 11 Feb 2019 08:52:05 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=82XdJt2iWpnEYKftE)
How would that 1 time enrollment look like? Just through the CLI by entering the CA? Or where is this basically invoked, just a bash script or something.
we are basically trying to boot a network with 1 "start script" which would be able to dynamically add networks
So it should be able to enroll peers/orderers etc on the netwerk. Is this done the same way as enrolling a user?
Legiit (Mon, 11 Feb 2019 08:52:05 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=82XdJt2iWpnEYKftE)
How would that 1 time enrollment look like? Just through the CLI by entering the CA? Or where is this basically invoked, just a bash script or something.
Besides that, we are basically trying to boot a network with 1 "start script" which would be able to dynamically add networks
So it should be able to enroll peers/orderers etc on the netwerk. Is this done the same way as enrolling a user?
levanto (Mon, 11 Feb 2019 14:04:15 GMT):
Has joined the channel.
jlcs (Tue, 12 Feb 2019 11:50:16 GMT):
Has joined the channel.
eddie.allen (Tue, 12 Feb 2019 14:44:31 GMT):
Has left the channel.
glennd (Wed, 13 Feb 2019 14:01:42 GMT):
Has joined the channel.
mastersingh24 (Sun, 17 Feb 2019 13:20:01 GMT):
Enrolling peer(s) and orderer(s) is the same as enrolling a user ... although for peers you may want to select role=peer
Legiit (Mon, 18 Feb 2019 10:21:18 GMT):
I get this error when executing the cryptogen file in a docker image `./cryptogen: cannot execute binary file`
I did download the binaries for linux using `wget https://nexus.hyperledger.org/content/repositories/releases/org/hyperledger/fabric/hyperledger-fabric/linux-amd64-1.4.0/hyperledger-fabric-linux-amd64-1.4.0.tar.gz && tar xzf hyperledger-fabric-linux-amd64-1.4.0.tar.gz` but the error remains
WouterVanHecke (Mon, 18 Feb 2019 10:21:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=bCbxJzBadx2QvQk46) @Legiit I'm wondering the same thing...
Jgnuid (Mon, 18 Feb 2019 11:57:25 GMT):
What will happen in some years when the CA certs of orgs expire? Does expiration is ignore in orderers and peers? Or should I make channel reconfigs in all the channels of the CA?
Sreesha (Wed, 20 Feb 2019 10:40:48 GMT):
ed25519 key and x509 certificate same?@smithbk
Sreesha (Wed, 20 Feb 2019 10:41:04 GMT):
@smithbk
ashutosh_kumar (Thu, 21 Feb 2019 14:40:56 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=AZrptSqzee3WnbiLu) @Sreesha ed25519 is signature algorithm whereas x509 is certificate which wraps public key. Totally different entities which cannot be compared.
braduf (Thu, 21 Feb 2019 22:50:48 GMT):
Has joined the channel.
Sreesha (Fri, 22 Feb 2019 04:35:23 GMT):
@ashutosh_kumar actually i wanted to know whether we can reuse the MSP generated in hyperledger indy in fabric
mastersingh24 (Fri, 22 Feb 2019 11:19:51 GMT):
not at this time ...
akshay.sood (Tue, 26 Feb 2019 11:50:53 GMT):
Hi Experts
Can we update the attributes in x509 later?
akshay.sood (Tue, 26 Feb 2019 11:51:01 GMT):
Suppose a user is registered and enrolled with attributes
is it possible to change these attribute values later?
for example storing ph_no, address and role in attribute
is it possible to update these things later?
akshay.sood (Tue, 26 Feb 2019 11:51:01 GMT):
Suppose a user is registered and enrolled with attributes
is it possible to change these attribute values later?
for example storing ph_no, address and role in attribute
ashutosh_kumar (Wed, 27 Feb 2019 15:00:18 GMT):
No , you need to reenroll.
gade (Fri, 01 Mar 2019 13:04:57 GMT):
Has joined the channel.
Estebanrestrepo (Fri, 01 Mar 2019 19:38:31 GMT):
Has joined the channel.
KyunghoKim (Tue, 12 Mar 2019 03:08:12 GMT):
Has joined the channel.
RealDeanZhao (Fri, 15 Mar 2019 07:42:16 GMT):
Has left the channel.
abedsau (Mon, 18 Mar 2019 21:22:10 GMT):
Has joined the channel.
yanli133 (Mon, 25 Mar 2019 06:52:46 GMT):
Has joined the channel.
Antimttr (Fri, 29 Mar 2019 18:02:39 GMT):
Has joined the channel.
Antimttr (Fri, 29 Mar 2019 18:05:13 GMT):
@adc Hello, I was refered to you by @dave.enyeart as you are the lead of the idemix project. I have a developer who has a PHD in math who works with my firm and we were thinking about contributing the Nodejs implementation of idemix to the project. I was wondering what the procedure for allowing her to contribute is?
mastersingh24 (Sat, 30 Mar 2019 08:28:59 GMT):
Hi @Antimttr - in order to contribute, you don't need anything more than an LFID and of course I assume your company will give her permission to contribute to open source.
mastersingh24 (Sat, 30 Mar 2019 08:31:13 GMT):
In terms of producing a NodeJS implementation of IdeMix, it would go in the Node SDK project ....
So if you / she can create a JIRA (not sure if there is one already) and provide a basic sketch of the implementation, that's really all that would be needed (other than starting work on the code) ;)
Antimttr (Sat, 30 Mar 2019 21:11:13 GMT):
@mastersingh24 hi, yes there is one i think https://jira.hyperledger.org/browse/FABN-689
Antimttr (Sat, 30 Mar 2019 21:12:14 GMT):
how would we provide the sketch? just post it in comments?
dave.enyeart (Sun, 31 Mar 2019 02:29:37 GMT):
@Antimttr Yes you can update the jira Description with an outline of your implementation thoughts. If longer than a page or so you could alternatively write down your design thoughts in a google doc and put the link in the jira Description. That will also allow for inline comments and discussion. Thanks for the help!
sunit.versatile (Mon, 01 Apr 2019 08:30:53 GMT):
Has joined the channel.
awattez (Mon, 01 Apr 2019 16:12:56 GMT):
Hi all, i would like to configure a perfect isolation in configtx.yml in order to be sure that ADMIN of ORG1 install chaincode and members of ORG1 instantiate chaincode but they can't operate on ORG2 peer etc. (perfect isolation with MSP). I try to follow this page : https://hyperledger-fabric.readthedocs.io/en/release-1.4/policies.html but honestly is not so simple.
Is there any sample or complete test for this use case ?
awattez (Mon, 01 Apr 2019 16:12:56 GMT):
Hi all, i would like to configure a perfect isolation in configtx.yml in order to be sure that ADMIN of ORG1 install chaincode on peer of ORG1 and members of ORG1 instantiate chaincode on peer of ORG1 but they can't operate on ORG2 peer etc. (perfect isolation with MSP). I try to follow this page : https://hyperledger-fabric.readthedocs.io/en/release-1.4/policies.html but honestly is not so simple.
Is there any sample or complete test for this use case ?
awattez (Mon, 01 Apr 2019 16:12:56 GMT):
Hi all, i would like to configure a perfect isolation in configtx.yml in order to be sure that ADMIN of ORG1 install chaincode on peer of ORG1 and members of ORG1 instantiate chaincode on peer of ORG1 but they have not the write to operate on ORG2 peer etc. (perfect isolation with MSP). I try to follow this page : https://hyperledger-fabric.readthedocs.io/en/release-1.4/policies.html but honestly is not so simple.
Is there any sample or complete test for this use case ?
awattez (Mon, 01 Apr 2019 16:12:56 GMT):
Hi all, i would like to configure a perfect isolation in configtx.yml in order to be sure that ADMIN of ORG1 install chaincode on peer of ORG1 and members of ORG1 instantiate chaincode on peer of ORG1 but they have not the right to operate on ORG2 peer etc. (perfect isolation with MSP). I try to follow this page : https://hyperledger-fabric.readthedocs.io/en/release-1.4/policies.html but honestly is not so simple.
Is there any sample or complete test for this use case ?
mastersingh24 (Tue, 02 Apr 2019 09:18:06 GMT):
@awattez -
- You must be an admin of the peer in order to install chaincode. Peer admin(s) is/are defined in the peer's local MSP (i.e. the admin public cert(s) is/are placed in the admincerts folder of the local MSP).
- Instantiating chaincode is scoped at the channel level. You must be an admin of an org which is a member of the channel. There is no way to prevent an admin of one org from invoking an instantiate operation on another org's peer (assuming that org is also part of the channel).
mwall (Tue, 02 Apr 2019 15:25:32 GMT):
Has joined the channel.
awattez (Tue, 02 Apr 2019 16:48:03 GMT):
@mastersingh24 thx
That's what I thought when i read -> https://hyperledger-fabric.readthedocs.io/en/release-1.4/access_control.html
charki (Fri, 05 Apr 2019 15:00:15 GMT):
Has joined the channel.
Antimttr (Fri, 05 Apr 2019 21:32:02 GMT):
```
├── ordererOrganizations
│ └── example.com
│ ├── ca
│ │ ├── 0d46ccf0e9436c1bc3b6e2bf80cdb202c4943604f95c72ee0ff839d3ec300719_sk
│ │ └── ca.example.com-cert.pem
│ ├── msp
│ │ ├── admincerts
│ │ │ └── Admin@example.com-cert.pem
│ │ ├── cacerts
│ │ │ └── ca.example.com-cert.pem
│ │ └── tlscacerts
│ │ └── tlsca.example.com-cert.pem
│ ├── orderers
│ │ └── orderer.example.com
``` Why is example.com considered an "ordering organization" in the msp configuration artifacts? The actual organizations are org1.example.com and org2.example,com, example.com is not a valid organization.
mastersingh24 (Sat, 06 Apr 2019 11:05:13 GMT):
@Antimttr - Why do you say it's not a valid organization? Because of the naming of the orderer domain?
The real point was to show that the orderer organization such be entirely separate from peer organizations
Koushik (Mon, 08 Apr 2019 16:32:17 GMT):
Has joined the channel.
Antimttr (Mon, 08 Apr 2019 21:42:03 GMT):
@mastersingh24 because, how is, from the config artifacts, a client supposed to know which orderer organization to use for a particular peer organization
Antimttr (Mon, 08 Apr 2019 21:42:23 GMT):
just seems convoluted that you would have an orderer org completely dissasociated from peer orgs
Antimttr (Mon, 08 Apr 2019 21:44:43 GMT):
Example: say you have peer orgs: ibm.com and microsoft.com which your client is managing. Then lets have dell.com and hp.com being orderer orgs. Now the client has 4 disparate organziations with no obvious connection between them. Should microsoft.com use dell.com or hp.com as its orderer?
josephnicholas (Tue, 09 Apr 2019 06:01:59 GMT):
Has joined the channel.
qsmen (Tue, 09 Apr 2019 07:12:40 GMT):
Hi experts here, if dapp sends a proposal to endorsers, dapp should sign the proposal. would the dapp certificate be sent to the endorsers too?
qsmen (Tue, 09 Apr 2019 08:53:52 GMT):
in signedproposal, the creator is the dapp user certificate.
mastersingh24 (Thu, 11 Apr 2019 13:58:59 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=hxLaMkub5iGt9E7Qv) @qsmen Yes ... it would be in the `Creator` field
qsmen (Fri, 12 Apr 2019 03:02:56 GMT):
Thank you, Mastersingh24.
rhall9090 (Fri, 12 Apr 2019 18:47:39 GMT):
Has joined the channel.
Antimttr (Sun, 14 Apr 2019 16:12:13 GMT):
@mastersingh24 @adc @dave.enyeart Hi, I have an initial draft of the idemix for nodejs sdk ready to post. How can I get a jira account to make a comment on https://jira.hyperledger.org/browse/FABN-689 ? I tried logging in with my linux foundation credentials but those did not work. Please advise, thanks.
Antimttr (Sun, 14 Apr 2019 16:12:13 GMT):
@mastersingh24 @adc @dave.enyeart Hi, I have an initial draft of the idemix for nodejs sdk design document ready to post. How can I get a jira account to make a comment on https://jira.hyperledger.org/browse/FABN-689 ? I tried logging in with my linux foundation credentials but those did not work. Please advise, thanks.
Antimttr (Sun, 14 Apr 2019 16:27:58 GMT):
ok i think i got it now, was able to login
Antimttr (Sun, 14 Apr 2019 16:28:06 GMT):
had to create a new account for some reason
Antimttr (Sun, 14 Apr 2019 16:30:14 GMT):
@dave.enyeart about how long should we wait for comments before beginning implementation?
Antimttr (Sun, 14 Apr 2019 16:32:27 GMT):
or is there some sort of design approval process that it needs to go through?
balamcyril (Thu, 18 Apr 2019 13:00:53 GMT):
Has joined the channel.
balamcyril (Thu, 18 Apr 2019 13:03:37 GMT):
Hello, i'm looking for a diagram showing how identity mixer is use in MSP on fabric. The official document is not clear about it
levanto (Wed, 24 Apr 2019 07:33:33 GMT):
```
cannot use signingIdentity (type "vendor/github.com/hyperledger/fabric/msp".SigningIdentity) as type "vendor/github.com/hyperledger/fabric/token".SigningIdentity in argument to client.NewClient:
"vendor/github.com/hyperledger/fabric/msp".SigningIdentity does not implement "vendor/github.com/hyperledger/fabric/token".SigningIdentity (wrong type for GetPublicVersion method)
have GetPublicVersion() "vendor/github.com/hyperledger/fabric/msp".Identity
want GetPublicVersion() "vendor/github.com/hyperledger/fabric/token".Identitygo
```
levanto (Wed, 24 Apr 2019 07:33:37 GMT):
Hello, i do have a question.
I am looking at the token package from fabric core master branch. In trying to create a new tokenClient, i am having trouble getting the SigningIdentity required as a parameter in the newClient function. Anyone who can help?
Let me send a snippet.
levanto (Wed, 24 Apr 2019 07:33:57 GMT):
The reason why i use the msp.SigningIdentity is because i use the GetSigningIdentity method provided in the same package. However, seems the newClient method needs the token.SigningIdentity type. Help.
How can i make msp.SigningIdentity interface implement the token.SigningIdentity?
pdintchev (Sat, 27 Apr 2019 17:40:25 GMT):
Has joined the channel.
awattez (Sun, 28 Apr 2019 17:44:29 GMT):
Hi everybody! Is it possible to find any example of a configtx.yml crypto-config.yml or cryptogen documentation which implement one organization multiple MSP for a channel configuration ?
awattez (Sun, 28 Apr 2019 17:44:52 GMT):
Each time we have one organization -> one MSP
awattez (Sun, 28 Apr 2019 17:45:44 GMT):
Is it possible to generate multiple MSP for one organization and configure channel setup with that
mastersingh24 (Sun, 28 Apr 2019 18:42:21 GMT):
@awattez - each MSP is separate and identified by MSPID. If a single entity ("org") decides to have two different MSPs, there is no method to tie them to a single org; they will just appear as two different orgs within the channel config
awattez (Sun, 28 Apr 2019 20:15:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=26AKddWJ7C8ueNC2Q) @mastersingh24 @mastersingh24 thanks. No array definition for MSP no problem.
awattez (Sun, 28 Apr 2019 20:15:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=26AKddWJ7C8ueNC2Q) @mastersingh24 thanks. No array definition for MSP no problem.
casstait (Thu, 09 May 2019 01:37:59 GMT):
Has joined the channel.
casstait (Thu, 09 May 2019 01:38:00 GMT):
Is there anyone that could guide me on how to update a client side application using the java fabric SDK connect to an IBP enterprise service when Mutual TLS is enabled?
casstait (Thu, 09 May 2019 06:14:32 GMT):
For example, when mutual TLS is disabled on the IBP service, the code currently written works as expected, however when mutual TLS is enabled on the IBP service, I receive an error: Response: {"result":"","errors":[{"code":0,"message":"Registration of 'casstest' failed in affiliation validation: : scode: 401, local code: 44, local msg: Caller does not have authority to act on affiliation 'PeerOrg1', remote code: 20, remote msg: Authorization failure"} ],"messages":[],"success":false}. I used the following tutorial as a guide: https://developer.ibm.com/tutorials/hyperledger-fabric-java-sdk-for-tls-enabled-fabric-network/.
1. Does the client application generate the private key and it then enroll the certificate to the CA? OR
2. Do you submit a request to the x-tlsCAName in a connection profile that returns a cert/key?
levanto (Fri, 10 May 2019 08:47:35 GMT):
can the prover peer still become a commiting peer?
yacovm (Fri, 10 May 2019 10:22:37 GMT):
Yes
levanto (Fri, 10 May 2019 11:10:58 GMT):
okay.
On running the issue function.. I am getting this error however
levanto (Fri, 10 May 2019 11:11:17 GMT):
Screenshot 2019-05-10 at 14.10.14.png
levanto (Fri, 10 May 2019 11:11:55 GMT):
`rpc error: code = Unimplemented desc = unknown service token.Prover"`
levanto (Fri, 10 May 2019 11:12:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=dijYQ294tfimJ2rCQ) what could cause this
levanto (Fri, 10 May 2019 11:35:41 GMT):
this was a trivial problem.
used mspInstance.GetDefaultSigningIdentity() function
levanto (Sat, 11 May 2019 10:59:59 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-crypto?msg=dijYQ294tfimJ2rCQ) unknown service token.Prover
levanto (Sat, 11 May 2019 11:00:24 GMT):
still asking on this
qsmen (Tue, 14 May 2019 07:58:09 GMT):
it is said that fabric will/ already provide zkath(zeroknowledge asset transfer h...). Would you please give some detailed information on it? Thank you.
knagware9 (Wed, 15 May 2019 07:56:10 GMT):
yes, you can check Idemix implementation, Java SDK have API too
qsmen (Wed, 15 May 2019 08:59:28 GMT):
oh, it is related to idemixer. Thank you.
knagware9 (Wed, 15 May 2019 10:43:13 GMT):
yes
sejalpawar (Thu, 16 May 2019 07:22:00 GMT):
Has joined the channel.
sejalpawar (Thu, 16 May 2019 07:29:27 GMT):
What's the status of the auditor functionality of idemix?
dev-d (Sat, 18 May 2019 06:11:57 GMT):
byfn
circlespainter (Sat, 18 May 2019 07:35:25 GMT):
Has joined the channel.
Dan (Fri, 24 May 2019 13:54:15 GMT):
Has joined the channel.
balamcyril (Fri, 24 May 2019 14:20:46 GMT):
Hello, i want to know how unlinkability and anonymity is provide by using Idemix Credential since CA and MSP have acces to client information?
levanto (Mon, 27 May 2019 07:51:19 GMT):
fixed this.
My channel had no Fabtoken capability
mastersingh24 (Mon, 27 May 2019 11:00:28 GMT):
A couple of things:
- IdeMix credentials CAN be tied back to the issuer (but that won't reveal the actual "identity")
- While the CA issues an IdeMix "enrollment" credential (which can be linked back to the identity), this credential is actually not used to submit transactions. What actually happens is that the client generates a fresh credential from the enrollment credential and uses that to submit transactions.
mastersingh24 (Mon, 27 May 2019 11:00:28 GMT):
A couple of things:
- IdeMix credentials CAN be tied back to the issuer (but that won't reveal the actual "identity")
- While the CA issues an IdeMix "enrollment" credential (which can be linked back to the identity), this credential is actually not used to submit transactions. What actually happens is that the client generates a zero-knowledge proof of possession of the enrollment credential and uses that to submit transactions (by signing them)
balamcyril (Mon, 27 May 2019 13:23:56 GMT):
In fabric-sdk-java implementation of this algorithm, i don't see when the user is generate a fresh credential before sending the transaction to the peer or orderer.
mastersingh24 (Mon, 27 May 2019 14:21:29 GMT):
I modified by answer a bit to make it more clear ... the scheme uses BLS signatures with zero-knowledge proofs of possession of the credential / attributes without actually revealing the credential itself
mastersingh24 (Mon, 27 May 2019 14:22:24 GMT):
the proofs are un-linkable as a new proof is generated each time
Antimttr (Tue, 28 May 2019 18:25:48 GMT):
Will cryptogen also generate tls certificates?
Antimttr (Tue, 28 May 2019 18:26:06 GMT):
or do those always have to be generated by hand
yacovm (Tue, 28 May 2019 20:33:49 GMT):
also creates them, yes.
Dan (Wed, 29 May 2019 19:29:00 GMT):
just curious what key is used for the bls signature? is it a fresh key each time and that accompanies a fresh proof? if this is documented somewhere feel free just to point me at that.
sejalpawar (Thu, 30 May 2019 13:03:26 GMT):
Has left the channel.
risc (Sat, 01 Jun 2019 02:51:59 GMT):
Has joined the channel.
aatkddny (Wed, 19 Jun 2019 00:12:09 GMT):
cryptogen question. hopefully this is simple and i just don't know what i'm doing.
trying to generate crypto for a raft based setup in k8s. we've been running without it using kafka- it's an internal one for testing.
i have a simple single org listed below
```
# ---------------------------------------------------------------------------
# "OrdererOrgs" - Definition of organization(s) managing the orderer nodes
# ---------------------------------------------------------------------------
OrdererOrgs:
- Name: sampleorg
Domain: sampleorg
Specs:
- Hostname: raft0
- Hostname: raft1
- Hostname: raft2
PeerOrgs:
# ---------------------------------------------------------------------------
# sampleorg configuration certificates
# ---------------------------------------------------------------------------
- Name: sampleorg
Domain: sampleorg
Template:
Count: 2
Users:
Count: 1
```
everything is peachy until i try to start a peer when the logs give me this:
```
2019-06-18 23:57:54.691 UTC [grpc] createTransport -> DEBU 029 grpc: addrConn.createTransport failed to connect to {peer0-sampleorg:7051 0
BrajeshKumar (Wed, 19 Jun 2019 08:57:08 GMT):
Has joined the channel.
aatkddny (Wed, 19 Jun 2019 13:23:38 GMT):
trying to get 1.4.1 working with raft. that involves exploring certificates - which i've avoided like the plague till now. mostly because my understanding of the process is - to be charitable - limited.
this is all internal. using cryptogen to create some self-signed certs. these seem to be of the form `host.domain`
the problem is that my deployments use `host-domain` for the name and so when i fire up a peer i get stuff like this:
```
2019-06-18 23:57:54.691 UTC [grpc] createTransport ->
DEBU 029 grpc: addrConn.createTransport failed to connect to {peer0-sampleorg:7051 0
mastersingh24 (Thu, 20 Jun 2019 14:15:47 GMT):
```
OrdererOrgs:
# ---------------------------------------------------------------------------
# Orderer
# ---------------------------------------------------------------------------
- Name: Orderer
Domain: ordererorg
# ---------------------------------------------------------------------------
# "Specs" - See PeerOrgs below for complete description
# ---------------------------------------------------------------------------
Specs:
- Hostname: orderer
SANS:
- "localhost"
- "127.0.0.1"
```
mastersingh24 (Thu, 20 Jun 2019 14:15:47 GMT):
```
OrdererOrgs:
# ---------------------------------------------------------------------------
# Orderer
# ---------------------------------------------------------------------------
- Name: Orderer
Domain: ordererorg
# ---------------------------------------------------------------------------
# "Specs" - See PeerOrgs below for complete description
# ---------------------------------------------------------------------------
Specs:
- Hostname: orderer
SANS:
- "{{.Hostname}}-{{.Domain}}"
PeerOrgs:
- Name: SampleOrg
Domain: sampleorg
Template:
Count: 1
SANS:
- "{{.Hostname}}-{{.Domain}}"
Users:
Count: 1
```
mastersingh24 (Thu, 20 Jun 2019 14:21:37 GMT):
Create your own `crypto-config.yaml` and pass it to cryptogen:
```
OrdererOrgs:
# ---------------------------------------------------------------------------
# Orderer
# ---------------------------------------------------------------------------
- Name: Orderer
Domain: ordererorg
# ---------------------------------------------------------------------------
# "Specs" - See PeerOrgs below for complete description
# ---------------------------------------------------------------------------
Specs:
- Hostname: orderer
SANS:
- "{{.Hostname}}-{{.Domain}}"
PeerOrgs:
- Name: SampleOrg
Domain: sampleorg
Template:
Count: 1
SANS:
- "{{.Hostname}}-{{.Domain}}"
Users:
Count: 1
```
aatkddny (Thu, 20 Jun 2019 14:23:33 GMT):
Thanks Gari. I was halfway through scripting this with openssl. I'd done orderers and was starting with peers. This will save me a bunch of effort.
aatkddny (Thu, 20 Jun 2019 14:23:33 GMT):
Thanks Gari. I was halfway through scripting this with bash and openssl. I'd done orderers and was starting with peers. This will save me a bunch of effort.
mastersingh24 (Thu, 20 Jun 2019 14:24:35 GMT):
hopefully it works ;)
aatkddny (Thu, 20 Jun 2019 14:47:42 GMT):
Doesn't appear to do what I expected.
Issuer CN is still ca.xxx
Signed CNs are still peerN.xxx and raftN.xxx rather than -xxx. Pity
mastersingh24 (Thu, 20 Jun 2019 14:48:05 GMT):
checks the SANs
mastersingh24 (Thu, 20 Jun 2019 14:48:17 GMT):
I did not change the CN
mastersingh24 (Thu, 20 Jun 2019 14:50:23 GMT):
```
```
mastersingh24 (Thu, 20 Jun 2019 14:50:26 GMT):
garis-mbp:fabric gsingh$ openssl x509 -noout -text -in crypto-config/peerOrganizations/sampleorg/peers/peer0.sampleorg/tls/server.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
9b:19:8b:f8:ee:b7:48:36:19:21:0d:e4:65:03:85:70
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=California, L=San Francisco, O=sampleorg, CN=tlsca.sampleorg
Validity
Not Before: Jun 20 14:44:00 2019 GMT
Not After : Jun 17 14:44:00 2029 GMT
Subject: C=US, ST=California, L=San Francisco, CN=peer0.sampleorg
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:14:7a:e7:77:9d:69:32:07:38:40:e5:e2:df:2f:
5b:ac:31:f8:5c:1e:84:af:50:35:74:b9:b6:22:4c:
e6:21:05:14:f0:5b:6e:5c:69:af:f0:50:af:b6:8e:
57:37:72:17:db:88:78:f7:9f:c7:4b:f2:a9:bc:28:
d4:6d:13:03:ff
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Authority Key Identifier:
keyid:EF:63:CF:F0:A0:C6:84:3A:AF:99:FF:63:F8:49:61:BE:2E:E3:45:A9:E0:B0:1E:3B:F6:19:33:68:D4:B0:CD:EE
X509v3 Subject Alternative Name:
DNS:peer0.sampleorg, DNS:peer0, DNS:peer0-sampleorg, DNS:peer0.sampleorg, DNS:peer0, DNS:peer0-sampleorg, DNS:peer0.sampleorg, DNS:peer0, DNS:peer0-sampleorg
Signature Algorithm: ecdsa-with-SHA256
30:44:02:20:66:c6:5c:ac:0a:b1:34:fe:9a:59:ed:80:7f:20:
fa:e7:e6:a4:65:50:41:cd:bd:95:2f:80:68:9e:2e:b4:27:92:
02:20:2f:1e:f3:a1:1f:65:6c:9f:fe:50:24:02:95:fb:f6:b0:
f8:59:6e:06:41:72:50:71:86:e3:c7:bc:06:1d:15:78
```
```
mastersingh24 (Thu, 20 Jun 2019 14:50:26 GMT):
garis-mbp:fabric gsingh$ openssl x509 -noout -text -in crypto-config/peerOrganizations/sampleorg/peers/peer0.sampleorg/tls/server.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
9b:19:8b:f8:ee:b7:48:36:19:21:0d:e4:65:03:85:70
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=California, L=San Francisco, O=sampleorg, CN=tlsca.sampleorg
Validity
Not Before: Jun 20 14:44:00 2019 GMT
Not After : Jun 17 14:44:00 2029 GMT
Subject: C=US, ST=California, L=San Francisco, CN=peer0.sampleorg
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:14:7a:e7:77:9d:69:32:07:38:40:e5:e2:df:2f:
5b:ac:31:f8:5c:1e:84:af:50:35:74:b9:b6:22:4c:
e6:21:05:14:f0:5b:6e:5c:69:af:f0:50:af:b6:8e:
57:37:72:17:db:88:78:f7:9f:c7:4b:f2:a9:bc:28:
d4:6d:13:03:ff
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Authority Key Identifier:
keyid:EF:63:CF:F0:A0:C6:84:3A:AF:99:FF:63:F8:49:61:BE:2E:E3:45:A9:E0:B0:1E:3B:F6:19:33:68:D4:B0:CD:EE
X509v3 Subject Alternative Name:
DNS:peer0.sampleorg, DNS:peer0, DNS:peer0-sampleorg, DNS:peer0.sampleorg, DNS:peer0, DNS:peer0-sampleorg, DNS:peer0.sampleorg, DNS:peer0, DNS:peer0-sampleorg
Signature Algorithm: ecdsa-with-SHA256
30:44:02:20:66:c6:5c:ac:0a:b1:34:fe:9a:59:ed:80:7f:20:
fa:e7:e6:a4:65:50:41:cd:bd:95:2f:80:68:9e:2e:b4:27:92:
02:20:2f:1e:f3:a1:1f:65:6c:9f:fe:50:24:02:95:fb:f6:b0:
f8:59:6e:06:41:72:50:71:86:e3:c7:bc:06:1d:15:78
```
mastersingh24 (Thu, 20 Jun 2019 14:50:54 GMT):
Look at the `X509v3 Subject Alternative Name` section
mastersingh24 (Thu, 20 Jun 2019 14:52:18 GMT):
```
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
9b:19:8b:f8:ee:b7:48:36:19:21:0d:e4:65:03:85:70
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=California, L=San Francisco, O=sampleorg, CN=tlsca.sampleorg
Validity
Not Before: Jun 20 14:44:00 2019 GMT
Not After : Jun 17 14:44:00 2029 GMT
Subject: C=US, ST=California, L=San Francisco, CN=peer0.sampleorg
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:14:7a:e7:77:9d:69:32:07:38:40:e5:e2:df:2f:
5b:ac:31:f8:5c:1e:84:af:50:35:74:b9:b6:22:4c:
e6:21:05:14:f0:5b:6e:5c:69:af:f0:50:af:b6:8e:
57:37:72:17:db:88:78:f7:9f:c7:4b:f2:a9:bc:28:
d4:6d:13:03:ff
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Authority Key Identifier:
keyid:EF:63:CF:F0:A0:C6:84:3A:AF:99:FF:63:F8:49:61:BE:2E:E3:45:A9:E0:B0:1E:3B:F6:19:33:68:D4:B0:CD:EE
X509v3 Subject Alternative Name:
DNS:peer0.sampleorg, DNS:peer0, DNS:peer0-sampleorg, DNS:peer0.sampleorg, DNS:peer0, DNS:peer0-sampleorg, DNS:peer0.sampleorg, DNS:peer0, DNS:peer0-sampleorg
Signature Algorithm: ecdsa-with-SHA256
30:44:02:20:66:c6:5c:ac:0a:b1:34:fe:9a:59:ed:80:7f:20:
fa:e7:e6:a4:65:50:41:cd:bd:95:2f:80:68:9e:2e:b4:27:92:
02:20:2f:1e:f3:a1:1f:65:6c:9f:fe:50:24:02:95:fb:f6:b0:
f8:59:6e:06:41:72:50:71:86:e3:c7:bc:06:1d:15:78
```
aatkddny (Thu, 20 Jun 2019 14:53:33 GMT):
There's no SAN in my output - that might be why I'm looking at it so blankly.
mastersingh24 (Thu, 20 Jun 2019 15:03:37 GMT):
`openssl x509 -noout -text -in crypto-config/peerOrganizations/sampleorg/peers/peer0.sampleorg/tls/server.crt`
mastersingh24 (Thu, 20 Jun 2019 15:03:53 GMT):
```
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
39:54:ee:63:52:7c:4a:6b:e9:94:02:43:62:d1:5c:2d
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=California, L=San Francisco, O=sampleorg, CN=tlsca.sampleorg
Validity
Not Before: Jun 20 14:58:00 2019 GMT
Not After : Jun 17 14:58:00 2029 GMT
Subject: C=US, ST=California, L=San Francisco, CN=peer0.sampleorg
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:34:04:5a:5d:c5:2d:b9:25:52:88:00:51:8c:61:
9e:63:52:cf:ff:21:cc:c7:c1:c2:ba:b0:c6:84:bd:
c3:16:65:7c:13:cb:ac:26:f2:f7:6c:ca:77:7f:b8:
42:68:f2:0d:29:3d:97:e1:df:19:0f:18:24:aa:f6:
1c:37:f5:6b:9a
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Authority Key Identifier:
keyid:34:C8:1F:75:4F:1A:E6:ED:6E:9A:02:9A:7F:D9:F0:86:43:4E:1A:F1:F8:97:FB:B9:8A:CA:00:A7:25:79:F6:6E
X509v3 Subject Alternative Name:
DNS:peer0.sampleorg, DNS:peer0, DNS:localhost, DNS:peer0-sampleorg
Signature Algorithm: ecdsa-with-SHA256
30:44:02:20:1b:c2:10:bb:6d:c1:dd:73:1d:a2:cd:10:38:d4:
28:e0:79:c9:dd:f5:e3:a9:41:e1:47:a2:36:46:9e:5a:a2:f8:
02:20:68:1a:16:95:a9:dc:59:a0:74:72:e9:f8:7c:a2:9a:cd:
3c:26:6b:15:4f:38:9b:c3:c5:3a:b8:65:c7:76:04:45
```
aatkddny (Thu, 20 Jun 2019 15:12:47 GMT):
Interesting.
I was looking at {ORG}/ca/ca-{ORG}-cert.pem and .../tlsca/tlsca.{ORG}-cert.pem as well as {ORG}/peers/peer0.{ORG}/msp/cacerts/ca.{ORG}-cert.pem.
It's absent in all cases there but present in the server.crt at your path.
Which explains the mismatch at least. It also seems my thought that the certs were copied from there was totally wrong.
mastersingh24 (Thu, 20 Jun 2019 15:29:53 GMT):
Yeah ... the `tls` folder for each node (peer, orderer) has the actual certificates that should be used for TLS
mrudav.shukla (Thu, 27 Jun 2019 16:27:27 GMT):
Has joined the channel.
ihormudryy (Fri, 28 Jun 2019 09:33:53 GMT):
Has joined the channel.
qsmen (Thu, 04 Jul 2019 03:16:46 GMT):
how to solve "no subject alternative dns name matching org1.example.com". by google or baidu, the solution to the error above is to close the tls. If enabling tls, how to solve it? Thank you.
qsmen (Thu, 04 Jul 2019 09:16:47 GMT):
another question: if fabric network tls is enabled already, is it possible to disable the applicaiton tls?
mastersingh24 (Fri, 05 Jul 2019 09:33:26 GMT):
If TLS is enabled, then the peer and orderer endpoints will all require TLS and your clients / applications will need to connect via TLS as well
qsmen (Thu, 11 Jul 2019 01:26:54 GMT):
ok
qsmen (Thu, 11 Jul 2019 01:26:54 GMT):
I see. Thank you
Estebanrestrepo (Thu, 11 Jul 2019 23:43:08 GMT):
Why when I invoke "Enroll user" I get an object with null role?
Like this:
{
"name": "user1",
"mspid": "Org1MSP",
"roles": null,
"affiliation": "",
"enrollmentSecret": "",
"enrollment": {
"signingIdentity": "3ed2fa17330f9f556a72a60d9c7c2469c9b43e819b4f7fb581f0953f7c28c8a1",
"identity": {
"certificate": "-----BEGIN CERTIFICATE-----\nMIICkzCCAjmgAwIBAgIUVPqrdeWEsG1C8d3X45tOLVhBmtkwCgYIKoZIzj0EAwIw\ndzELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNh\nbiBGcmFuY2lzY28xGzAZBgNVBAoTEm9yZzEucHJvdG90aXBvLmNvbTEeMBwGA1UE\nAxMVY2Eub3JnMS5wcm90b3RpcG8uY29tMB4XDTE5MDcxMDE5NTcwMFoXDTIwMDcw\nOTIwMDIwMFowQjEwMA0GA1UECxMGY2xpZW50MAsGA1UECxMEb3JnMTASBgNVBAsT\nC2RlcGFydG1lbnQxMQ4wDAYDVQQDEwV1c2VyMTBZMBMGByqGSM49AgEGCCqGSM49\nAwEHA0IABFACsaY1Hcfws/m5HQ54q64JY7MNNcPg94/0yY6r3zUvyWGdTuW1phPG\nXjG0QSVaap40FWZOrKLwPguuxDVt/6+jgdcwgdQwDgYDVR0PAQH/BAQDAgeAMAwG\nA1UdEwEB/wQCMAAwHQYDVR0OBBYEFKKHpc6yRAms11nEG2v2ypKKZkoWMCsGA1Ud\nIwQkMCKAINjXCCYk9052pRkBcnFECNHx54+G0VI7b7vlt/A+rwz8MGgGCCoDBAUG\nBwgBBFx7ImF0dHJzIjp7ImhmLkFmZmlsaWF0aW9uIjoib3JnMS5kZXBhcnRtZW50\nMSIsImhmLkVucm9sbG1lbnRJRCI6InVzZXIxIiwiaGYuVHlwZSI6ImNsaWVudCJ9\nfTAKBggqhkjOPQQDAgNIADBFAiEAiUHHbtEae4BdQyvgRx7iDTs2bbOZmc6jcTzG\nRvIac9kCIFfTj6LrW+YrPkq35vyjEQx7Cj1RLVFM3j1VkgEqy/zN\n-----END CERTIFICATE-----\n"
}
}
}
alexx (Mon, 15 Jul 2019 03:22:46 GMT):
Has joined the channel.
nwyee (Fri, 26 Jul 2019 09:37:07 GMT):
Has joined the channel.
gatakka (Tue, 30 Jul 2019 17:10:03 GMT):
Hello, what is the procedure to update admin certificates AFTER they are expired. Currently I'm in this situation, and I'm unable to make config update, to upgrade chaincode or any other admin task
yacovm (Tue, 30 Jul 2019 17:48:26 GMT):
oh boy....
yacovm (Tue, 30 Jul 2019 17:48:35 GMT):
I don't think there is one
gatakka (Tue, 30 Jul 2019 17:54:48 GMT):
then what is the purpose of the admin certificate in MSP folder?
yacovm (Tue, 30 Jul 2019 17:56:41 GMT):
you have channel MSPs, and local MSP
yacovm (Tue, 30 Jul 2019 17:56:49 GMT):
the local MSP authenticates channel-less operations
gatakka (Tue, 30 Jul 2019 17:57:09 GMT):
i see
gatakka (Tue, 30 Jul 2019 17:57:10 GMT):
thank you
gatakka (Tue, 30 Jul 2019 17:57:38 GMT):
this is a edge case, but is very dangerous, it will be good to be highlighted in the documentation
yacovm (Tue, 30 Jul 2019 18:03:12 GMT):
@gatakka - for Raft TLS certificates, I put a warning a week before in the logs that complains that they are about to expire
yacovm (Tue, 30 Jul 2019 18:03:24 GMT):
maybe we should/can do a similar thing for admin certs :thinking_face:
yacovm (Tue, 30 Jul 2019 18:03:32 GMT):
or for CA certs too
gatakka (Tue, 30 Jul 2019 18:03:42 GMT):
will be very very helpful :)
gatakka (Tue, 30 Jul 2019 18:04:10 GMT):
imagine a production blockchain with 1 bilion blocks, and you are locked :)
gatakka (Tue, 30 Jul 2019 18:04:32 GMT):
thank you for your help
yacovm (Tue, 30 Jul 2019 18:04:51 GMT):
can you open a JIRA please?
yacovm (Tue, 30 Jul 2019 18:04:54 GMT):
http://jira.hyperledger.org/
yacovm (Tue, 30 Jul 2019 18:04:56 GMT):
and tag me
gatakka (Tue, 30 Jul 2019 18:04:58 GMT):
yes, I will
yacovm (Tue, 30 Jul 2019 18:05:01 GMT):
cool tnx
ashutosh_kumar (Tue, 30 Jul 2019 21:53:45 GMT):
Certificate Management should take place outside of Fabric and putting certificate expiration warning in Fabric logs is not that reliable solution IMO.
arsulegai (Tue, 06 Aug 2019 05:02:28 GMT):
Has joined the channel.
huxd (Tue, 06 Aug 2019 05:46:23 GMT):
Has joined the channel.
conanoc (Mon, 12 Aug 2019 03:18:06 GMT):
Has joined the channel.
conanoc (Mon, 12 Aug 2019 03:18:06 GMT):
I'm not sure this is the right channel but I recently filed a bug, actually a feature request, and no body is reviewing that issue. Is there any thing I have to do in addition?
https://jira.hyperledger.org/browse/FAB-16146
conanoc (Tue, 13 Aug 2019 01:32:27 GMT):
got an answer. There were already similar issues I could not find.
kaos77 (Thu, 15 Aug 2019 15:43:52 GMT):
Has joined the channel.
kaos77 (Thu, 15 Aug 2019 15:43:53 GMT):
Hello,
i need to change scheme of signing a transaction (and validation too), changing bccsp interface (SDK Go) can do it? Any document for that?
hyperlearner (Mon, 19 Aug 2019 05:33:15 GMT):
Has joined the channel.
hyperlearner (Mon, 19 Aug 2019 05:33:17 GMT):
Hi ,
I reading about Idemix and have some doubts.Hope you could help.Thanks in advance.
1) How is the basic transaction flow different from using the Idemix MSP?
2) How is the identity and integrity of a transaction ensured in case of Idemix MSP?
3) client/idemix MSP signing and verification part:What is the input to the Idemix MSP credential verification
part? Where and how is it done?
galaxystar (Tue, 20 Aug 2019 01:21:53 GMT):
Has joined the channel.
kaos77 (Tue, 20 Aug 2019 13:17:42 GMT):
I need to change the signature scheme (ECDSA to Schnorr blind signature), how can I do it??
ashutosh_kumar (Tue, 20 Aug 2019 19:38:14 GMT):
What is your use case ? What the rational behind using Schnorr Signature ? Schnorr is also based on Elliptic Curve Cryptography. Fabric does not support Schnorr Signature by itself , although there is support for Blind Signture in Fabric.
yacovm (Tue, 20 Aug 2019 19:40:49 GMT):
where do we have blind signatures in Fabric?
ashutosh_kumar (Tue, 20 Aug 2019 19:41:05 GMT):
idemix.
ashutosh_kumar (Tue, 20 Aug 2019 19:42:22 GMT):
Blind Signature is very loose term and one can have its own interpretation.
ashutosh_kumar (Tue, 20 Aug 2019 19:43:02 GMT):
That is the reason , one has to be careful in using Blind Signature.
yacovm (Tue, 20 Aug 2019 19:43:07 GMT):
i thought blind signature is that you sign not knowing what you sign?
yacovm (Tue, 20 Aug 2019 19:43:19 GMT):
and then the other party un-blinds it to get a valid signature
ashutosh_kumar (Tue, 20 Aug 2019 19:58:46 GMT):
Blinding can be on signing parameter also, not necessarily only on content of message. Usually , it is implemented using Challenge Response model.
ashutosh_kumar (Tue, 20 Aug 2019 19:58:46 GMT):
Blinding can be on signing/key parameter also, not necessarily only on content of message. Usually , it is implemented using Challenge Response model.
hyperlearner (Wed, 21 Aug 2019 07:38:12 GMT):
When is a credential verified and when is an idemix signature verified?
hyperlearner (Wed, 21 Aug 2019 07:38:12 GMT):
When is an idemix credential verified and when is an idemix signature(zkp?) verified?
kaos77 (Wed, 21 Aug 2019 13:17:58 GMT):
it's for research reasons
kaos77 (Wed, 21 Aug 2019 13:19:24 GMT):
some answer?
jeffanon (Sat, 24 Aug 2019 23:36:56 GMT):
Has joined the channel.
sarapaul (Sun, 25 Aug 2019 22:12:43 GMT):
Has joined the channel.
priti_kumari (Tue, 27 Aug 2019 15:16:42 GMT):
Has joined the channel.
soumyanayak (Sat, 31 Aug 2019 06:16:07 GMT):
Has joined the channel.
soumyanayak (Sat, 31 Aug 2019 06:17:22 GMT):
hi Team ,
Fabric- v1.4.3
Cannot run peer because error when setting up MSP of type bccsp from directory /var/hyperledger/crypto/org1/admin/msp: administrators must be declared when no admin ou classification is set
Any idea for the above error. msp exists in admin folder.
soumyanayak (Sat, 31 Aug 2019 06:17:22 GMT):
hi Team ,
Fabric- v1.4.3
*Cannot run peer because error when setting up MSP of type bccsp from directory /var/hyperledger/crypto/org1/admin/msp: administrators must be declared when no admin ou classification is set*
Any idea for the above error. msp exists in admin folder.
lovesh (Wed, 04 Sep 2019 16:23:38 GMT):
Hello. Does Fabric have needs (and plans) for delegatable anonymous credentials? Has anyone considered this CCS 17 paper https://acmccs.github.io/papers/p683-camenischA.pdf?
yacovm (Wed, 04 Sep 2019 16:37:15 GMT):
@lovesh do you mean to hide the issuer of the identity ?
lovesh (Wed, 04 Sep 2019 16:41:32 GMT):
The identity of the **intermediate issuers from the verifier**, yes.
lovesh (Wed, 04 Sep 2019 16:42:16 GMT):
The identity of the **intermediate issuers from the verifier**, yes.
yacovm (Wed, 04 Sep 2019 16:43:59 GMT):
So I would ask @adc or @elli-androulaki if there are plans for implementing this in the context of idemix. As I'm sure you're well aware, all these NIZKs are done via Fabric's idemix support.
lovesh (Wed, 04 Sep 2019 16:47:02 GMT):
There is an implementation of this that might beome part of Hyperledger Ursa . And then Idemix should be able to consume it. Here is the implementation https://github.com/lovesh/signature-schemes/tree/delegatable/delg_cred_cdd
lovesh (Wed, 04 Sep 2019 16:47:34 GMT):
I plan to propose this implementation in form of a PR to Ursa
yacovm (Wed, 04 Sep 2019 16:48:23 GMT):
cool, thanks for the reference
lovesh (Wed, 04 Sep 2019 16:49:05 GMT):
I am looking for some reviewers for this
generak (Sun, 15 Sep 2019 11:43:43 GMT):
Has joined the channel.
nleut (Wed, 18 Sep 2019 15:59:44 GMT):
Has joined the channel.
indirajith (Mon, 30 Sep 2019 09:35:02 GMT):
Hi all, I am encountering the following errors while bootstrapping orderer nodes. # Start -> PANI 003 Failed validating bootstrap block: initializing channelconfig failed: could not create channel Orderer sub-group config: setting up the MSP manager failed: admin 0 is invalid: The identity is not valid under this MSP [org2MSP]: could not validate identity's OUs: the identity must be a client, a peer or an orderer identity to be valid, not a combination of them. OUs: [[0xc0004e23c0]], MSP: [org2MSP]
I have checked for the OU in the x509 cert files that, they all have either admin or admin cert, peer for peer cert and orderer for orderer node's cert. I don't know what I am missing.
indirajith (Mon, 30 Sep 2019 09:35:02 GMT):
Hi all, I am encountering the following errors while bootstrapping orderer nodes.
# Start -> PANI 003 Failed validating bootstrap block: initializing channelconfig failed: could not create channel Orderer sub-group config: setting up the MSP manager failed: admin 0 is invalid: The identity is not valid under this MSP [org2MSP]: could not validate identity's OUs: the identity must be a client, a peer or an orderer identity to be valid, not a combination of them. OUs: [[0xc0004e23c0]], MSP: [org2MSP]
I have checked for the OU in the x509 cert files that, they all have either admin or admin cert, peer for peer cert and orderer for orderer node's cert. I don't know what I am missing.
indirajith (Mon, 30 Sep 2019 09:35:02 GMT):
Hi all, I am encountering the following errors while bootstrapping orderer nodes.
## Start -> PANI 003 Failed validating bootstrap block: initializing channelconfig failed: could not create channel Orderer sub-group config: setting up the MSP manager failed: admin 0 is invalid: The identity is not valid under this MSP [org2MSP]: could not validate identity's OUs: the identity must be a client, a peer or an orderer identity to be valid, not a combination of them. OUs: [[0xc0004e23c0]], MSP: [org2MSP]
I have checked for the OU in the x509 cert files that, they all have either admin or admin cert, peer for peer cert and orderer for orderer node's cert. I don't know what I am missing.
indirajith (Mon, 30 Sep 2019 09:35:02 GMT):
Hi all, I am encountering the following errors while bootstrapping orderer nodes.
** Start -> PANI 003 Failed validating bootstrap block: initializing channelconfig failed: could not create channel Orderer sub-group config: setting up the MSP manager failed: admin 0 is invalid: The identity is not valid under this MSP [org2MSP]: could not validate identity's OUs: the identity must be a client, a peer or an orderer identity to be valid, not a combination of them. OUs: [[0xc0004e23c0]], MSP: [org2MSP] **
I have checked for the OU in the x509 cert files that, they all have either admin or admin cert, peer for peer cert and orderer for orderer node's cert. I don't know what I am missing.
indirajith (Mon, 30 Sep 2019 10:42:56 GMT):
I have the admin cert provided to 'admin' OU. is this creating the problem, as the error states, identity must be a client, a peer, or an orderer to be valid. Should we issue an admin cert with orderer OU?
indirajith (Mon, 30 Sep 2019 10:44:24 GMT):
Do we need to have seperate admins for peers and orderers other than the org's admin?
soumyanayak (Thu, 03 Oct 2019 05:51:03 GMT):
Were you able to resolve this issue?
indirajith (Thu, 03 Oct 2019 08:46:46 GMT):
Yes, I overcame this problem by changing the profile sectionand recreating the genesis block. But could not figureout the actual problem in the previous configtx.yaml file.
soumyanayak (Thu, 03 Oct 2019 08:47:47 GMT):
if you don't mind can you post both the old one and the current modififed one configtx.yaml
soumyanayak (Thu, 03 Oct 2019 08:49:03 GMT):
i assume you have created orderers as part of individual org right rather than creating a logical separate org only for orderers?
indirajith (Thu, 03 Oct 2019 09:02:06 GMT):
Yes, I have orderers as part of orgs. I will share the new one and I just overwritten the old file while copying the new one :expressionless:
indirajith (Thu, 03 Oct 2019 09:02:25 GMT):
by mistake
soumyanayak (Thu, 03 Oct 2019 09:03:30 GMT):
so org admins were enough to take care the further tasks right ?
indirajith (Thu, 03 Oct 2019 09:05:49 GMT):
yeah org admins are enough, but I am still not sure whether having node admins is the best practice. But at first it would be messy to have lot of certs. And my profile section and orderer sections are based on your confixtx file.
indirajith (Thu, 03 Oct 2019 09:07:19 GMT):
configtx.txt
soumyanayak (Thu, 03 Oct 2019 09:07:31 GMT):
this is the new one right?
indirajith (Thu, 03 Oct 2019 09:09:14 GMT):
yep, this is the new one. In my configuration I have given read permission to several roles just to make sure it works as orderers, peers, clients have different roles and needs read and write access. Then I realised it is better to have different logical org for orderers so that we can have more control over the permissions.
soumyanayak (Thu, 03 Oct 2019 09:12:10 GMT):
yeah that's what Jyellick was telling about to have a separate logical org only for orderers to have more control . but i was thinking in real time it would be the individual orgs having their own orderers as who would be the logical org
indirajith (Thu, 03 Oct 2019 09:19:20 GMT):
Yes. First I still need to get better understanding of how permission works in practice. With the current knowledge, in the current scenario I have to open all the permissions to all the roles just to make sure I don't deny anything from reading or writing at different stages. For example, When it comes to Orderer org, we only need to think about orderers and give single set of permissions for orderer activities. and we can have different set of permissions for peers and clients. If we have all components like orderers, peers, clients in a single org (even though they belong to the same org) the readers, writers we specify are organisation wide where as different nodes needs different set of readers and writers.
indirajith (Thu, 03 Oct 2019 09:20:37 GMT):
I hope I have explained what I wanted to explain.
indirajith (Thu, 03 Oct 2019 09:21:40 GMT):
Yes. First I still need to get better understanding of how permission works in practice. With the current knowledge, in the current scenario I have to open all the permissions to all the roles just to make sure I don't deny anything from reading or writing at different stages. For example, When it comes to Orderer org, we only need to think about orderers and give single set of permissions for orderer activities. and we can have different set of permissions for peers and clients. If we have all components like orderers, peers, clients in a single org (even though they belong to the same org) the readers, writers we specify are organisation wide where as different nodes needs different set of readers and writers.
indirajith (Thu, 03 Oct 2019 09:21:58 GMT):
I hope I have explained what I wanted to explain.
soumyanayak (Thu, 03 Oct 2019 09:24:01 GMT):
yes its more on the policies thing where we want to impose on different components in the network
indirajith (Thu, 03 Oct 2019 09:30:24 GMT):
yes. I also have one more doubt. In the docs, we need to specify which orderer node is part of what channel. But from your previous configtx the application channels doesn't even have orderer org. How does it work?
soumyanayak (Thu, 03 Oct 2019 09:47:08 GMT):
it is a part of genesis block definition under profile section
but for individual different channels having distinct set of orderers i am working on that -- will update you
indirajith (Thu, 03 Oct 2019 09:50:47 GMT):
Thanks Soumya
Koushik (Thu, 10 Oct 2019 22:26:00 GMT):
Hi Guys, I am in a perplexed dilemma, I have a running production env with cryptogen generated certs for PeerOrg and OrdererOrg. I want to migrate the peer certs with Fabric-CA generated certs without creating a new channel and new genesis.block is it possible?
mastersingh24 (Fri, 11 Oct 2019 10:49:56 GMT):
You can start fabric-ca-server using an existing root signing key pair. cryptogen outputs the root key pair in the `ca` directory for each organization
hyperlearner (Tue, 15 Oct 2019 05:20:14 GMT):
Hi guys,
In the function GetAttributesFromIdemix() from https://github.com/hyperledger/fabric/blob/93d94f8b6434dd54e7b70738ff7137d046a9ca96/core/chaincode/shim/ext/attrmgr/attrmgr.go#L137
hyperlearner (Tue, 15 Oct 2019 05:20:14 GMT):
Hi guys,
In the function GetAttributesFromIdemix() from https://github.com/hyperledger/fabric/blob/93d94f8b6434dd54e7b70738ff7137d046a9ca96/core/chaincode/shim/ext/attrmgr/attrmgr.go#L137
from where does the client get loaded before it comes here? does the peer store the identities in any of its own storage(like state database)?
My understanding is that the creator (be it idemix or x509 type) passes his identity(byte[]) and from the identity bytes the creator passes, the function unmarshalls, gets the attributes and returns it back.
indirajith (Tue, 15 Oct 2019 11:52:17 GMT):
Hi @mastersingh24 , sorry for the cross posting. Thank you for your answer in this stackoverflow https://stackoverflow.com/questions/58279511/how-to-distinguish-client-and-peer-certificate-generated-by-cryptogen-in-hyper/58282441 . I could not comment there so asking here. The MSP OU admin is for the entire organisation or for the entire unit within that CA, right? My doubts are: We have node certficates, for example: peer and orderer certificate for peer and orderer node. Do we also have something like admin for a peer or a set of peers? Because, to my knowledge the admin is for the org not for a particular peer or orderer. I would like to get more knowledge on this.
Second and a different doubt: When proposing a config change or something in a channel how to meet the signature requirement for endorsements? Do we have to sign the transaction with one admin and copy that file into another org's peer out of the band manually and sign it by the second org's admin?
mastersingh24 (Tue, 15 Oct 2019 19:52:25 GMT):
It is possible to use NodeOUs to define separate admins for individual peers (you can simply set a different OU identifier in the local MSP of each peer) but generally you would not do that.
Orderers don't really have the concept of an admin for the orderer node ... it's the orderer organization. And it's generally recommended that you use separate orgs to manage your peer(s) and orderer(s).
For config changes ... correct ... if you need multiple signatures you will need to pass the config update transaction out of band to collect signatures (of course there are several vendors offerings which provides this capability as well)
twoneks (Fri, 18 Oct 2019 10:09:46 GMT):
Has joined the channel.
twoneks (Fri, 18 Oct 2019 10:09:47 GMT):
Hi guys some help here please!!! https://stackoverflow.com/questions/58437455/hyperledger-fabric-custom-policy-during-channel-creation
sandman (Wed, 23 Oct 2019 05:46:33 GMT):
Has joined the channel.
sandman (Wed, 23 Oct 2019 05:46:35 GMT):
Hello, while generating tls certificate from fabric-ca, how to set tls-ca cert to have "CA: True" attribute set. This parameter is set in certificates generated by cryptogen.
soumyanayak (Wed, 23 Oct 2019 07:10:25 GMT):
Saw your post - better raise a JIRA issue and post here the details
Sai_S 1 (Fri, 25 Oct 2019 13:25:43 GMT):
Has joined the channel.
Koushik (Tue, 29 Oct 2019 21:25:45 GMT):
Hi Master Singhs
Koushik (Tue, 29 Oct 2019 21:27:10 GMT):
Hi @mastersingh24 ,
I am getting this error when updating the channel configuration with the msp generated by fabric-ca using the root cert generated by cryptogen. Just to recall my objective, I am trying to replace the cryptogen generated certs with fabric-ca generated certs for the Peer Org called "Example".
```shell
"Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'invoice-channel': error authorizing update: error validating DeltaSet: policy for [Value] /Channel/Application/ExampleMSP/MSP not satisfied: signature set did not satisfy policy"
```
The following are the steps I took,
1.) Generated Peer certs using the root cert generated by cryptogen.
2.) Change the file path from cryptogen generated MSP to Fabric-CA generated MSP
OLD Declaration:
``` yaml
- &Example
Name: ExampleMSP
ID: ExampleMSP
MSPDir: crypto-config/peerOrganizations/stp.example.com/msp
AnchorPeers:
- Host: peer0.stp.example.com/msp
```
NEW Declaration:
``` yaml
- &Example
Name: ExampleMSP
ID: ExampleMSP
MSPDir: crypto-config/peerOrganizations/stp.example.com/msp
AnchorPeers:
- Host: peer0.stp.example.com/msp
```
3.) Update the channel Configuration
```shell
export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
export CHANNEL_NAME=example-channel
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
jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"ExampleMSP":.[1]}}}}}' config.json Example.json > modified_config.json
configtxlator proto_encode --input config.json --type common.Config --output config.pb
configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb
configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output Example_update.pb
configtxlator proto_decode --input Example_update.pb --type common.ConfigUpdate | jq . > Example_update.json
echo '{"payload":{"header":{"channel_header":{"channel_id":"example-channel", "type":2}},"data":{"config_update":'"$(cat Example_update.json)"'}}}' | jq . > Example_update_in_envelope.json
configtxlator proto_encode --input Example_update_in_envelope.json --type common.Envelope --output Example_update_in_envelope.pb
peer channel signconfigtx -f Example_update_in_envelope.pb
peer channel update -f Example_update_in_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA
# Get the error after the "peer channel update" command
```
Koushik (Tue, 29 Oct 2019 21:28:40 GMT):
any suggestions would be helpful been stuck on this for a week?
Koushik (Tue, 29 Oct 2019 23:52:06 GMT):
Hi @mastersingh24,
I am getting this error when updating the channel configuration with the msp generated by fabric-ca. Just to recall my objective, I am trying to replace the cryptogen generated certs with fabric-ca generated certs for the Peer Org called "Example".
I am getting an error when updating the channel configuration with the msp generated by fabric-ca(The error is stated below). I would be grateful for any advice or suggestions, been stuck on this for weeks.
```shell
"Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'invoice-channel': error authorizing update: error validating DeltaSet: policy for [Value] /Channel/Application/ExampleMSP/MSP not satisfied: signature set did not satisfy policy"
```
The following are the steps I took,
1.) Generated Peer certs using the root cert generated by cryptogen.
2.) Change the file path from cryptogen generated MSP to Fabric-CA generated MSP
OLD Declaration:
``` yaml
- &Example
Name: ExampleMSP
ID: ExampleMSP
MSPDir: crypto-config/peerOrganizations/stp.example.com/msp
AnchorPeers:
- Host: peer0.stp.example.com
```
NEW Declaration:
``` yaml
- &Example
Name: ExampleMSP
ID: ExampleMSP
MSPDir: /opt/stp-network/hyperledger/stp.example.com/msp
AnchorPeers:
- Host: peer0.stp.example.com
```
3.) Update the channel Configuration
Extracted new channel artifacts taking in account of the new declaration for the MSP.
```shell
configtxgen -printOrg ExampleMSP > ./channel-artifacts/Example.json
```
Commands executed in side the CLI Container:
```shell
export ORDERER_CA=/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/orderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
export CHANNEL_NAME=example-channel
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
jq -s '.[0] * {"channel_group":{"groups":{"Application":{"groups": {"ExampleMSP":.[1]}}}}}' config.json Example.json > modified_config.json
configtxlator proto_encode --input config.json --type common.Config --output config.pb
configtxlator proto_encode --input modified_config.json --type common.Config --output modified_config.pb
configtxlator compute_update --channel_id $CHANNEL_NAME --original config.pb --updated modified_config.pb --output Example_update.pb
configtxlator proto_decode --input Example_update.pb --type common.ConfigUpdate | jq . > Example_update.json
echo '{"payload":{"header":{"channel_header":{"channel_id":"example-channel", "type":2}},"data":{"config_update":'"$(cat Example_update.json)"'}}}' | jq . > Example_update_in_envelope.json
configtxlator proto_encode --input Example_update_in_envelope.json --type common.Envelope --output Example_update_in_envelope.pb
peer channel signconfigtx -f Example_update_in_envelope.pb
peer channel update -f Example_update_in_envelope.pb -c $CHANNEL_NAME -o orderer.example.com:7050 --tls --cafile $ORDERER_CA
# Get the error after the "peer channel update" command
```
Koushik (Thu, 31 Oct 2019 16:02:16 GMT):
Hi, Sorry for cross posting, but I been stuck on this for a while. I am trying to switch cryptogen generated certs with fabric-ca generated certs.
Koushik (Thu, 31 Oct 2019 16:05:10 GMT):
I have followed the method 1.) Generate new fabric-ca certs using the root cert that was generated by cryptogen 2.) replace the CORE_PEER_MSP CONFIGPATH, other env variables in the docker-compose.yaml file, 3.) update the channel configuration with the new certs
Koushik (Thu, 31 Oct 2019 16:05:31 GMT):
Link to Stack-Overflow https://stackoverflow.com/questions/58634471/replacing-cryptogen-generated-certs-with-fabric-ca
Koushik (Thu, 31 Oct 2019 16:06:21 GMT):
I am getting a error when updating the peer channel update ""Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'example-channel': error authorizing update: error validating DeltaSet: policy for [Value] /Channel/Application/ExampleMSP/MSP not satisfied: signature set did not satisfy policy""
Adryx86 (Mon, 04 Nov 2019 13:58:35 GMT):
Has joined the channel.
Adryx86 (Mon, 04 Nov 2019 14:04:07 GMT):
Hi guys.. I found this closed bug on Hyperledger Jira: https://jira.hyperledger.org/browse/FAB-16783?workflowName=FAB%3A+Bug+Workflow&stepId=8
How can i get the cryptogen version with that fix applied ? it seems nobody builded and deployed on nexus the 1.4.4 version of binaries.
Thanks
SamYuan1990 (Tue, 05 Nov 2019 05:04:30 GMT):
Has joined the channel.
Adryx86 (Tue, 05 Nov 2019 08:18:54 GMT):
I tried also using version 2.0.0-alpha.. The Admin cert of the orderer MSP has been generated without the OU subject attribute.. the Admin of a org has been generated with OU=client.. what's going on? I'm confused..
mastersingh24 (Thu, 07 Nov 2019 10:17:02 GMT):
1.4.4 has not been released
mastersingh24 (Thu, 07 Nov 2019 10:17:20 GMT):
The alpha is very old
caduellery (Tue, 12 Nov 2019 18:58:12 GMT):
Has joined the channel.
caduellery (Tue, 12 Nov 2019 19:25:24 GMT):
Hello all. We are willing to use certificates issued by a trusted CA, however our trusted CA has a RSA chain. They said they could still issue ECDSA certificates signed by their RSA chain. Would Fabric accept/work with this cenario?
yacovm (Tue, 12 Nov 2019 19:28:28 GMT):
@caduellery only for TLS
yacovm (Tue, 12 Nov 2019 19:29:17 GMT):
Fabric nodes (orderers, peers) cannot accept RSA signatures of enrollment CAs
caduellery (Tue, 12 Nov 2019 19:34:57 GMT):
ok, I understand that for TLS we can use RSA certificates. However, the case is the use of ECDSA certificates issued by an RSA CA ... in this case the certificates used by nodes (peers, orderers) would be of type ECDSA, but their chain would be of type RSA ... would that be possible?
yacovm (Tue, 12 Nov 2019 20:15:41 GMT):
no
DilipManjunatha (Wed, 13 Nov 2019 13:08:17 GMT):
Has joined the channel.
caduellery (Wed, 13 Nov 2019 17:59:19 GMT):
:thumbsup:
braduf (Wed, 04 Dec 2019 21:09:29 GMT):
Hi all, we have been trying to use a PKI service of AWS called ACM-PCA, to be able to use the cid library in the chaincode we have been trying to add attributes to the certificates through the extra x.509 extension with object identifier "1.2.3.4.5.6.7.8.1" like fabric-ca adds them. But we have noticed that this AWS service doesn't support CSR's with extra extensions.
Are there other ways to add these attributes? Or can someone recommend other PKI cloud services to use for enrollment certificates for production and where we can add these extensions to use the attributes in the chaincode?
Thanks in advance!
indirajith (Thu, 05 Dec 2019 10:30:34 GMT):
Hi all. I am getting the following error and could not go any further as the orderers are not forming quorum due to TLS bad certificate. ``` 2019-12-05 10:22:51.416 UTC [orderer.consensus.etcdraft] confirmSuspicion -> ERRO 28bf0 Failed pulling the last config block: retry attempts exhausted channel=orderersyschannel node=2
2019-12-05 10:22:52.474 UTC [core.comm] ServerHandshake -> ERRO 28bf1 TLS handshake failed with error remote error: tls: bad certificate server=Orderer remoteaddress=192.168.176.103:49600
```
Is there a way or procedure to debug this problem? How to pin point why this is bad certificate but all the certs are correct when I check it.
indirajith (Thu, 05 Dec 2019 10:31:06 GMT):
I use names not IP in certificate SAN
indirajith (Thu, 05 Dec 2019 10:39:36 GMT):
I also get the following error ``` failed to create new connection: connection error: desc = "transport: error while dialing: dial tcp 192.168.176.105:7050: connect: connection refused"
2019-12-05 10:22:46.416 UTC [orderer.common.cluster.puller] func1 -> WARN 28bdb Received error of type 'failed to create new connection: connection error: desc = "transport: error while dialing: dial tcp 192
.168.176.105:7050: connect: connection refused"' from {ord1-org2.inuit.local:7050 ```
mastersingh24 (Thu, 05 Dec 2019 15:14:16 GMT):
this is usually client TLS error
braduf (Fri, 06 Dec 2019 15:18:20 GMT):
Someone that can help me out here or give some recommendations on PKI services that work well with Fabric and all its functionalities, please?
braduf (Fri, 06 Dec 2019 19:36:42 GMT):
The problem we are facing is that the security and cloud areas of the company want to use a PKI as a service instead of setting up one themselves...
braduf (Fri, 06 Dec 2019 19:36:42 GMT):
The problem we are facing is that the security and cloud areas of the company want to use a PKI as a service instead of setting up and maintaining one themselves...
braduf (Tue, 10 Dec 2019 14:22:49 GMT):
Hi all, is it recommended to use fabric-ca in production or to use other CA/PKI services?
mastersingh24 (Tue, 10 Dec 2019 18:41:40 GMT):
Not sure what you mean by "recommended" ... it can be used for production but you can of course use other CAs as mandated by say your company policy.
If you want to take advantage to the various node and identity roles in your channel and endorsement policy, it's definitely easier to do do with the Fabric CA as it will issues certificates with an OU matching the role/type, but of course this can be done via proper CSRs with other CAs as well.
For TLS, personally I prefer using other CAs, but Fabric CA is fine for that as well
cmgabriel (Wed, 11 Dec 2019 14:58:49 GMT):
Is configuring LDAP an option for you?
mastersingh24 (Wed, 11 Dec 2019 18:53:26 GMT):
what are you trying to do with attributes?
braduf (Wed, 11 Dec 2019 19:09:25 GMT):
We want to use the chaincode cid library to be able to give certain permissions to certain users (certificates). For example, if not all users of an organization should be able to issue certain tokens, we can add an "issue=true" attribute in the certificate and retrieve and check for the attribute in the chaincode using the cid library...
braduf (Wed, 11 Dec 2019 19:10:45 GMT):
But an LDAP doesn't replace a PKI, or does it also issue certificates?
braduf (Wed, 11 Dec 2019 19:12:14 GMT):
And we could use an existing LDAP, but we should still need a PKI, no? Or does an LDAP also has capabilities to issue certificates normally?
braduf (Wed, 11 Dec 2019 19:14:57 GMT):
Thanks for your answer, I think it would indeed be the easiest to convince the security people to run fabric-ca for the enrollment certs and use an existing TLS PKI for tls certs. Thanks a lot!
mastersingh24 (Wed, 11 Dec 2019 19:58:05 GMT):
If you have to use an external CA, you might want to try using an "OU" in the DN for your users. You can't use CID, but it's trivial to extract OUs from the X509 certificate in your chaincode
braduf (Wed, 11 Dec 2019 20:37:17 GMT):
Ok, thanks, that could work. Extra extensions are usually not suported by external CA's then?
mastersingh24 (Wed, 11 Dec 2019 20:38:00 GMT):
most definitely unknown OIDs (which is what our extension is).
mastersingh24 (Wed, 11 Dec 2019 20:38:00 GMT):
most definitely unknown OIDs (which is what our extension is) are not supported
braduf (Wed, 11 Dec 2019 20:41:00 GMT):
Ok, got it! Thanks a lot for the possible solutions and explanations! And do you know if there exists some known OID or standard X509 attributes where Fabric could implement this instead of in the custom OID it uses now, so we could make a request in JIRA perhaps to think about changing this in future versions...
mastersingh24 (Wed, 11 Dec 2019 20:45:38 GMT):
you could try to use one of the extensions defined in PKCS#9 and then change the OID in the CID code to match ... the only one that comes to mind is http://oidref.com/2.5.29.9
braduf (Wed, 11 Dec 2019 20:51:29 GMT):
Great! I will try it out.
andreevym (Wed, 25 Dec 2019 17:06:36 GMT):
Has joined the channel.
konda.kalyan (Thu, 26 Dec 2019 05:56:31 GMT):
Has joined the channel.
georges (Fri, 03 Jan 2020 15:00:07 GMT):
Has joined the channel.
georges (Fri, 03 Jan 2020 15:00:09 GMT):
hello
mrudav.shukla (Fri, 03 Jan 2020 15:59:57 GMT):
Has anyone been able to spinup the CA with LetsEncrypt cert? In my case its not able to persist keyUsage and basicConstraints values that I provided in CSR. And is there any other open source public ca that could be used for generating ecdsa based certs for testing purpose other than openssl?
yacovm (Fri, 03 Jan 2020 16:02:01 GMT):
fabric-CA ?
mrudav.shukla (Fri, 03 Jan 2020 16:49:24 GMT):
Yes. I'm trying to get a public-ca root cert for my fabric CA.
mrudav.shukla (Fri, 03 Jan 2020 16:49:24 GMT):
@yacovm : Yes. I'm trying to get a public-ca root cert for my fabric CA.
mastersingh24 (Fri, 03 Jan 2020 20:08:32 GMT):
Can you explain exactly what you are trying to do?
Third-party CAs such as Verisign, LetsEncrypt, etc are not going to issue you an intermediate root CA you can use with Fabric CA for signing certificates.
mastersingh24 (Fri, 03 Jan 2020 20:10:00 GMT):
LetsEncrypt only issues SSL/TLS certificates. It will not issue intermediate root certificates and it will not issue key usages other than those required by SSL/TLS
mrudav.shukla (Sat, 04 Jan 2020 04:55:00 GMT):
Ok. I might be getting it wrong. Consider two Organisations on a fabric network OrgA and OrgB. OrgA has two CAs one for Encryption and the other for Authentication.
When I start the CA server (any of it) I have two options:
1. Directly submit the start command: In which case it will create its own root-ca cert
2. Initialise it first, provide a root CA cert in the config file and then start the CA.
I am trying to do #2.
mrudav.shukla (Sat, 04 Jan 2020 04:55:00 GMT):
Ok. I might be getting it wrong. Consider two Organisations on a fabric network OrgA and OrgB. OrgA has two CAs one for Encryption and the other for Authentication.
When I start the CA server (any of it) I have two options:
1. Directly submit the start command: In which case it will create its own root-ca cert
2. Initialize it first, provide a root CA cert and CA key in the config file and then start the CA.
I am trying to do #2.
mrudav.shukla (Sat, 04 Jan 2020 04:56:06 GMT):
In #1 it creates a self signed certificate. And in #2 the CA server's certificate is signed by the public third party.
mrudav.shukla (Sat, 04 Jan 2020 05:02:23 GMT):
Is #2 required? Or can we just go ahead with #1?
metadata (Sat, 04 Jan 2020 05:30:10 GMT):
Has joined the channel.
pouya (Sun, 05 Jan 2020 12:33:19 GMT):
Has joined the channel.
braduf (Mon, 06 Jan 2020 05:47:07 GMT):
@mastersingh24 Based on our conversation and your proposed solutions here I created a pull request for the cid library to have a function to check for a certain OU value in the certificate. Like you said it is trivial extracting the OUs from the cert, but I think it is still a small handy function to have in the cid library to not need to repeat the code in every chaincode or manage another package for it. Could you review my PR when you have some time, please? https://github.com/hyperledger/fabric-chaincode-go/pull/17
Thanks a lot!
braduf (Mon, 06 Jan 2020 05:47:07 GMT):
@mastersingh24 Based on our conversation and your proposed solutions here I created a pull request for the cid library to have a function to check for a certain OU value in the certificate. Like you said it is trivial extracting the OUs from the cert, but I think it is still a small handy function to have in the cid library to not need to repeat the code in every chaincode or manage another package for it. And other people can be having the same CA restrictions, so for them it is also useful.
Could you review my PR when you have some time, please? https://github.com/hyperledger/fabric-chaincode-go/pull/17
Thanks a lot!
braduf (Mon, 06 Jan 2020 05:47:07 GMT):
@mastersingh24 Based on our conversation and your proposed solutions here I created a pull request for the cid library to have a function to check for a certain OU value in the certificate. Like you said it is trivial extracting the OUs from the cert, but I think it is still a small handy function to have in the cid library to not need to repeat the code in every chaincode or manage another package for it. And other people can be having the same CA restrictions, so for them it is also useful.
Could you review my PR when you have some time, please? https://github.com/hyperledger/fabric-chaincode-go/pull/17
https://jira.hyperledger.org/browse/FABCG-12<
Thanks a lot!
braduf (Mon, 06 Jan 2020 05:47:07 GMT):
@mastersingh24 Based on our conversation and your proposed solutions here I created a pull request for the cid library to have a function to check for a certain OU value in the certificate. Like you said it is trivial extracting the OUs from the cert, but I think it is still a small handy function to have in the cid library to not need to repeat the code in every chaincode or manage another package for it. And other people can be having the same CA restrictions, so for them it is also useful.
Could you review my PR when you have some time, please? https://github.com/hyperledger/fabric-chaincode-go/pull/17
https://jira.hyperledger.org/browse/FABCG-12
Thanks a lot!
georges (Mon, 06 Jan 2020 08:53:33 GMT):
hello
mrudav.shukla (Mon, 06 Jan 2020 15:08:04 GMT):
Ok. So I am sure I’ve got it wrong. Root Certificates being the top of the chain would need to be self signed. If I get a certificate from established public-ca that would make my ca an intermediate ca. And this would be out of scope and might not be needed at all since Fabric is a permissioned-network and all the root CAs involved in the network would be known beforehand. Please correct me if I’m still getting it wrong.
Reference 1: https://security.stackexchange.com/questions/168564/what-is-the-difference-between-a-self-signed-root-certificate-and-a-root-certifi
Reference 2: https://en.wikipedia.org/wiki/Root_certificate
Reference 3: https://hyperledger-fabric.readthedocs.io/en/release-1.4/identity/identity.html
Reference 4: https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html#fabric-ca-server
mrudav.shukla (Mon, 06 Jan 2020 15:08:04 GMT):
Ok. So I am sure I’ve got it wrong. Root Certificates being the top of the chain would need to be self signed. If I get a certificate from established public-ca that would make my ca an intermediate ca. And this would be out of scope and might not be needed at all since Fabric is a permissioned-network and all the root CAs involved in the network would be known beforehand. Please correct me if I’m still getting it wrong.
Reference 1: https://security.stackexchange.com/questions/168564/what-is-the-difference-between-a-self-signed-root-certificate-and-a-root-certifi
Reference 2: https://en.wikipedia.org/wiki/Root_certificate
Reference 3: https://hyperledger-fabric.readthedocs.io/en/release-1.4/identity/identity.html
Reference 4: https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html#fabric-ca-server Reference 5: https://www.thesslstore.com/blog/root-certificates-intermediate/
mastersingh24 (Mon, 06 Jan 2020 15:41:05 GMT):
> If I get a certificate from established public-ca that would make my ca an intermediate ca
This statement is true but highly unlikely that this will happen ... unless your company is already doing this ...
You could acquire your TLS certificates (not root but actual certificates) from a public CA (e.g. Verising, DigiCert, Lets Encrypt, etc)
mastersingh24 (Mon, 06 Jan 2020 15:42:03 GMT):
For enrollment certificates, it makes sense to have your own top-level root certificate (which indeed means it would be self-signed)
mrudav.shukla (Mon, 06 Jan 2020 15:57:00 GMT):
Yup. Totally makes sense. Thanks for clearing out.
smithbk (Thu, 09 Jan 2020 20:23:37 GMT):
Has left the channel.
indirajith (Fri, 10 Jan 2020 12:59:18 GMT):
Hi all. I am experienceing the following error when instantiating chaincode. It says bad certificate for the chaincode server evn though we don't assign any certificate to the chaincode server manually.
``` 2020-01-10 12:54:23.354 UTC [container] lockContainer -> DEBU 389c1 got container (ccex-1.0) lock
2020-01-10 12:54:23.354 UTC [container] unlockContainer -> DEBU 389c2 container lock deleted(ccex-1.0)
2020-01-10 12:54:23.400 UTC [core.comm] ServerHandshake -> ERRO 389c3 TLS handshake failed with error remote error: tls: bad certificate server=ChaincodeServer remoteaddress=172.28.0.7:53286
2020-01-10 12:54:23.400 UTC [grpc] handleRawConn -> DEBU 389c4 grpc: Server.Serve failed to complete security handshake from "172.28.0.7:53286": remote error: tls: bad certificate
```
indirajith (Fri, 10 Jan 2020 12:59:18 GMT):
Hi all. I am experienceing the following error when instantiating chaincode. It says bad certificate for the chaincode server evn though we don't assign any certificate to the chaincode server manually.
``` 2020-01-10 12:54:23.354 UTC [container] lockContainer -> DEBU 389c1 got container (ccex-1.0) lock
2020-01-10 12:54:23.354 UTC [container] unlockContainer -> DEBU 389c2 container lock deleted(ccex-1.0)
2020-01-10 12:54:23.400 UTC [core.comm] ServerHandshake -> ERRO 389c3 TLS handshake failed with error remote error: tls: bad certificate server=ChaincodeServer remoteaddress=172.28.0.7:53286
2020-01-10 12:54:23.400 UTC [grpc] handleRawConn -> DEBU 389c4 grpc: Server.Serve failed to complete security handshake from "172.28.0.7:53286": remote error: tls: bad certificate
```
Can anyone shed some light on where to look for this?
indirajith (Fri, 10 Jan 2020 12:59:18 GMT):
Hi all. I am experienceing the following error when instantiating chaincode. It says bad certificate for the chaincode server evn though we don't assign any certificate to the chaincode server manually.
``` 2020-01-10 12:54:23.354 UTC [container] lockContainer -> DEBU 389c1 got container (ccex-1.0) lock
2020-01-10 12:54:23.354 UTC [container] unlockContainer -> DEBU 389c2 container lock deleted(ccex-1.0)
2020-01-10 12:54:23.400 UTC [core.comm] ServerHandshake -> ERRO 389c3 TLS handshake failed with error remote error: tls: bad certificate server=ChaincodeServer remoteaddress=172.28.0.7:53286
2020-01-10 12:54:23.400 UTC [grpc] handleRawConn -> DEBU 389c4 grpc: Server.Serve failed to complete security handshake from "172.28.0.7:53286": remote error: tls: bad certificate
```
`the problem is eloborately explained in the following link: https://stackoverflow.com/questions/59644657/hyperledger-fabric-chaincode-instantiation-fail
Can anyone shed some light on where to look for this?
mrudav.shukla (Fri, 17 Jan 2020 08:04:53 GMT):
I have a CA container running within Pod in an amazon EKS cluster. I am exposing this using service type load balancer. It has TLS enabled. Now, since this pod is exposed using amazon’s load balancer, this load balancer will need to have an SSL cert. My question is, should this SSL cert be the certificate of the CA and be explicitly imported into amazon’s ACM or this load balancer would have a different SSL cert?
david_dornseifer (Fri, 17 Jan 2020 10:04:56 GMT):
Has joined the channel.
mastersingh24 (Fri, 17 Jan 2020 10:58:57 GMT):
It really does not matter in the case of the CA. You just need to make sure that you provide CA clients with the appropriate crypto material (meaning the root/intermediate certificate which issues the TLS cert for the load balancer)
mrudav.shukla (Sat, 18 Jan 2020 03:16:06 GMT):
Since the admin identity is bootstrapped when we start the CA server, what would be the way to pass the CSR while bootstrapping? Asking this because, while I am able to bootstrap the CA with self-signed certificate with proper Certificate Subject, the Certificate Subject of the admin, retrieved after enrolling the admin using fabric ca client, does not match with that of the CA's.
mrudav.shukla (Sat, 18 Jan 2020 03:53:42 GMT):
I believe we should be able to send a CSR for admin while enrolling.
mrudav.shukla (Sun, 19 Jan 2020 16:28:33 GMT):
I am creating three org network which has 2 normal organisations and 1 orderer organisation. I am using raft ordering service with 3 nodes. Apart from this each organisation has two certificate authorities, one for transport certs and other for enrolment certs. I’ve registered and enrolled organisation admin and 2 peers for each of the two organisations. Registered 1 admin and 3 orderer peers in orderer organisation. Next, I started the peers for both the organisations with necessary files and environment variables embedded in its docker image.
After this, I collected certs necessary for generating genesis block and channel creating transaction. These are admincerts, cacerts and tlscacerts. Next, I generated genesis block and channel creation using configtxgen and started all the three raft nodes. I transferred channel transaction to the peers container and tried creating the channel. However, I get this following error:
`error validating channel creation transaction for new channel ’testchannel’, could not succesfully apply update to template configuration: error authorizing update: error validating DeltaSet: policy for [Group] /Channel/Application not satisfied: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Admins' sub-policies to be satisfied
`
Referred to this answer on SO: https://stackoverflow.com/a/57662645/4110629 and it seems #3 ordering logs matches to mine. I checked the identity within admincerts folder of the peer with openssl command and it does show OU as admin. Additionally, attribute within the certificate shows admin type as well. Also, went into this organisation’s opened fabric-ca-server.db in sqlite shell and checked the identity. It shows admin as well.
This problem is common for either of the two organisations peer.
Is there anything I missing here?
mrudav.shukla (Mon, 20 Jan 2020 05:16:03 GMT):
Got the error. It was a silly mistake. When doing admin operations, I had to set msp config path of the admin rather than that of peer msp. Normally, we do this by creating a cli container and setting the admin msp path in it. Here, I was directly using the peer rather than cli container to create the channel.
mrudav.shukla (Mon, 20 Jan 2020 05:16:03 GMT):
Got the error. It was a silly mistake. When doing admin operations, I had to set msp config path of the admin rather than that of peer msp. Normally, we do this by creating a cli container and setting the admin msp path in it. Here, I was directly using the peer rather than cli container to create the channel. And this would also mean that every time I'll have to reset peer msp config path after admin operations. So if we're not using the cli container and rather using peer container to do the admin tasks, are there any other repercussions apart from switching the msp config path?
lzaouche (Tue, 28 Jan 2020 09:17:26 GMT):
Has joined the channel.
Antimttr (Thu, 30 Jan 2020 17:30:09 GMT):
Do their exist any guides on performing each of the steps cryptogen would perform in a production network to generate all of the crypto material?
Antimttr (Thu, 30 Jan 2020 17:32:03 GMT):
I think i have a general list of steps from discussions in here last year:
```
1. Generate CA key and x509 Cert
2. Generate TLS Key and cert (assuming TLS in use)
3. Create a new docker instance using certs
4. Run docker fabric-ca
5. Generate enrollment for peers
6. Generate enrollment for admin
```
Antimttr (Thu, 30 Jan 2020 17:35:51 GMT):
steps 1&2 being performed w/openssl and steps 5&6 being performed with fabric-ca-client
Antimttr (Thu, 30 Jan 2020 18:29:39 GMT):
Is it possible to also use fabric-ca-server to perform steps 1 and 2? or is this unneccissary?
Antimttr (Thu, 30 Jan 2020 23:21:28 GMT):
great article on bootstraping your own root ca: https://medium.com/ibm-garage/using-3rd-party-root-cas-in-hyperledger-fabric-3cafa91d1260
braduf (Tue, 04 Feb 2020 13:41:06 GMT):
Hi all, we have a question about using TLS. We know that for the digital identities in Fabric eliptic curve should be used, but is the same true for the TLS communication or can we use RSA for it?
ashutosh_kumar (Tue, 04 Feb 2020 14:41:34 GMT):
you can use RSA TLS.
indirajith (Sun, 16 Feb 2020 18:50:53 GMT):
Can anyone help me fix the following error with NodeOUs? https://stackoverflow.com/questions/60249580/hyperledger-fabric-nodeous-not-activated-cannot-tell-apart-identities
ahmedsajid (Thu, 20 Feb 2020 20:28:08 GMT):
Hi. I created https://jira.hyperledger.org/browse/FAB-17517
Would like to have input from maintainers.
braduf (Mon, 24 Feb 2020 21:51:01 GMT):
Hi all, when using client side TLS and a fully qualified path of the file that contains the certificate chain of the CA that issued TLS server certificate is required, what is the structure and content of this file exactly?
In the case of having a root and an intermediate CA, does the file just need to contain both certificates? And if yes, does the order of the certificates matter or doesn't it matter if the intermediate ca cert is first or the root ca cert?
-----BEGIN CERTIFICATE-----
xxxxxxxx...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
xxxxxxx....
-----END CERTIFICATE-----
braduf (Mon, 24 Feb 2020 21:51:01 GMT):
Hi all, when using client side TLS and a fully qualified path of the file that contains the certificate chain of the CA that issued TLS server certificate is required (General.TLS.RootCAs, General.TLS.ClientRootCAs), what is the structure and content of this file exactly?
In the case of having a root and an intermediate CA, does the file just need to contain both certificates? And if yes, does the order of the certificates matter or doesn't it matter if the intermediate ca cert is first or the root ca cert?
-----BEGIN CERTIFICATE-----
xxxxxxxx...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
xxxxxxx....
-----END CERTIFICATE-----
braduf (Mon, 24 Feb 2020 21:51:01 GMT):
Hi all, when using client side TLS and a fully qualified path of the file that contains the certificate chain of the CA that issued TLS server certificate is required (General.TLS.RootCAs, General.TLS.ClientRootCAs), what is the structure and content of this file exactly?
In the case of having a root and an intermediate CA, does the file just needs to contain both certificates? And if yes, does the order of the certificates matter or doesn't it matter if the intermediate ca cert is first or the root ca cert?
-----BEGIN CERTIFICATE-----
xxxxxxxx...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
xxxxxxx....
-----END CERTIFICATE-----
Antimttr (Wed, 26 Feb 2020 19:50:23 GMT):
i think it does matter
Antimttr (Wed, 26 Feb 2020 19:50:56 GMT):
https://medium.com/ibm-garage/using-3rd-party-root-cas-in-hyperledger-fabric-3cafa91d1260
Antimttr (Wed, 26 Feb 2020 19:51:13 GMT):
that article goes over making the chain cert by hand, basically you do the ica first then the rca second
georges (Mon, 02 Mar 2020 08:22:58 GMT):
heyy
Antimttr (Wed, 04 Mar 2020 22:10:33 GMT):
how do you give an anchor peer another peer organization's TLSCA certificate so teh anchors can create TLS connections amonst themselves?
Antimttr (Wed, 04 Mar 2020 22:10:33 GMT):
how do you give an anchor peer another peer organization's TLSCA certificate so teh anchors can create TLS connections amongst themselves?
Antimttr (Wed, 04 Mar 2020 22:11:08 GMT):
right now my anchor peer in org2 is trying to connect to my anchor peer in org1 and is getting rejected: Err :connection error: desc = "transport: authentication handshake failed: x509: certificate signed by unknown authority". Reconnecting...
Antimttr (Wed, 04 Mar 2020 22:11:08 GMT):
right now my anchor peer in org2 is trying to connect to my anchor peer in org1 and is getting rejected: `Err :connection error: desc = "transport: authentication handshake failed: x509: certificate signed by unknown authority". Reconnecting...`
Antimttr (Wed, 04 Mar 2020 22:11:44 GMT):
but unlike the orderer there is no place in the peer configurations to put tlsca root org certificates
Antimttr (Wed, 04 Mar 2020 22:12:22 GMT):
in the orderer you use ORDERER_GENERAL_TLS_ROOTCAS
Antimttr (Wed, 04 Mar 2020 22:12:31 GMT):
does this exist for peers as well?
Antimttr (Wed, 04 Mar 2020 22:14:00 GMT):
keep in mind each organization has its own tlsca certificate
Antimttr (Wed, 04 Mar 2020 22:16:04 GMT):
hmm looking at the tls page i did find CORE_PEER_TLS_CLIENTROOTCAS_FILES
Antimttr (Wed, 04 Mar 2020 22:16:18 GMT):
i guess ill give that show
Antimttr (Wed, 04 Mar 2020 22:16:19 GMT):
shot
Antimttr (Wed, 04 Mar 2020 22:19:28 GMT):
hmm
Antimttr (Wed, 04 Mar 2020 22:19:32 GMT):
according to this: https://stackoverflow.com/questions/55193288/hyperledger-fabric-how-to-specify-more-than-1-ca-in-the-core-peer-tls-clientroo
Antimttr (Wed, 04 Mar 2020 22:20:15 GMT):
you're supposed to get the other org's tlsca cert from the channel config block? but that doesnt make sense since it wasnt part of the information i gave in configtx.yaml
Antimttr (Wed, 04 Mar 2020 22:20:26 GMT):
it only used the org msp not the org tlsmsp
Antimttr (Wed, 04 Mar 2020 22:20:51 GMT):
can anyone confirm my assumptions? thanks
tennenjl (Tue, 10 Mar 2020 23:03:37 GMT):
Hi, I have Fabric deployed in an Azure cloud with nginx ingress front ending my fabric services. When I try to access the fabric ca using curl or via a browser calling the https://hostname/cainfo endpoint with --insecure flag for curl, the request receives data back from the ca server. When I run the fabcar enrollAdmin sample using a connection profile to point it to my Ingress CA Server endpoint, the request fails with `Error: [FabricCAClientService.js]: Failed to enroll admin, error:%o message=Calling enrollment endpoint failed with error [Error: connect ETIMEDOUT 1.2.3.4:7054], stack=Error: Calling enrollment endpoint failed with error [Error: connect ETIMEDOUT 1.2.3.4:7054]`. Where 1.2.3.4 = the Ingress public ip address. The Ingress controller is listening on ports 80 and 443 and I have my ingress yaml annotated with `nginx.ingress.kubernetes.io/ssl-passthrough: 'true'`. I am not sure why it is returning with the ingress exposed IP Addr with the service and container port (7054). Thanks for any tips on what I may be doing wrong.
Antimttr (Wed, 11 Mar 2020 18:23:02 GMT):
Hi quick question, what components of fabric actually read the config.yaml file present in local MSPs?
Antimttr (Wed, 11 Mar 2020 21:04:06 GMT):
does anyone know of documentation for config.yaml thats stuck in the MPS? I am wondering how I use chaincerts in such a file.
Antimttr (Wed, 11 Mar 2020 21:04:15 GMT):
Example from first-network: ```
NodeOUs:
Enable: true
ClientOUIdentifier:
Certificate: cacerts/ca.org1.example.com-cert.pem
OrganizationalUnitIdentifier: client
PeerOUIdentifier:
Certificate: cacerts/ca.org1.example.com-cert.pem
OrganizationalUnitIdentifier: peer
```
Antimttr (Wed, 11 Mar 2020 21:05:22 GMT):
so with this there is a CACert specified.. but what if we're using an ICA? The chain cert isnt found in the MSP its in my organization's CA directory
Antimttr (Wed, 11 Mar 2020 21:05:48 GMT):
or would is there a way to specify both CAcert and Intermediatecert?
yacovm (Wed, 11 Mar 2020 21:54:01 GMT):
@Antimttr I would guess this is for the "leaf" CA, meaning the last i-CA in the chain
yacovm (Wed, 11 Mar 2020 21:54:30 GMT):
think about it - given an MSP and any CA certificate, we can locate it by any graph traversal algorithm
yacovm (Wed, 11 Mar 2020 21:55:06 GMT):
and in Fabric, only "leaf" CAs can issue node certificates
yacovm (Wed, 11 Mar 2020 21:55:25 GMT):
so any certificate that is related to an OU needs to be a leaf one, I would think
yacovm (Wed, 11 Mar 2020 21:55:37 GMT):
I could be wrong, but I am too lazy to check the code at this point
yacovm (Wed, 11 Mar 2020 21:56:56 GMT):
it's somewhere in https://github.com/hyperledger/fabric/blob/master/msp/mspimplvalidate.go#L172
Antimttr (Wed, 11 Mar 2020 21:58:18 GMT):
so i think what you're saying is it doesn't matter if i have a chain cert, all i need to do is specify the cert of the CA which issued the identity
Antimttr (Wed, 11 Mar 2020 21:58:50 GMT):
which works for me since its a lot more straight forward
Antimttr (Wed, 11 Mar 2020 21:59:39 GMT):
do you know of any default config.yaml which specifies nodeOUs?
Antimttr (Wed, 11 Mar 2020 21:59:58 GMT):
@BrettLogan mentioned that even if you dont include one in your local MSP one is still used by default
BrettLogan (Wed, 11 Mar 2020 21:59:59 GMT):
Has joined the channel.
Antimttr (Wed, 11 Mar 2020 22:01:01 GMT):
this is all coming up because after we talked yetserday I went ahead and rebooted the network, and i updated the configtx.yaml of my channel included a bunch of the policies I found in the first-network configtx.yaml
Antimttr (Wed, 11 Mar 2020 22:01:40 GMT):
and when I joined the channel with org1's peers they all failed because the orderer claimed it didn't know who they were by MSP
Antimttr (Wed, 11 Mar 2020 22:02:10 GMT):
and I got a bunch of this in my peer log: ` for channel mychannel : implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied`
Antimttr (Wed, 11 Mar 2020 22:03:08 GMT):
in my orderer log i got a bunch of this: ```
2020-03-10 22:07:14.297 UTC [orderer.common.msgprocessor] Apply -> DEBU 1c85 SigFilter evaluation failed: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied, policyName: /Channel/Readers, ConsensusState: STATE_NORMAL
2020-03-10 22:07:14.297 UTC [common.deliver] deliverBlocks -> WARN 1c86 [channel: mychannel] Client authorization revoked for deliver request from 3.X.72.X:45588: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied: permission denied
2020-03-10 22:07:14.297 UTC [orderer.common.server] func1 -> DEBU 1c87 Closing Deliver stream
```
Antimttr (Wed, 11 Mar 2020 22:03:19 GMT):
but then i read some SO about these errors being begnign
Antimttr (Wed, 11 Mar 2020 22:03:19 GMT):
but then i read some SO about these errors being benign
Antimttr (Wed, 11 Mar 2020 22:03:51 GMT):
```
2020-03-10 22:07:14.296 UTC [policies] Evaluate -> DEBU 1c4b == Evaluating *policies.implicitMetaPolicy Policy /Channel/Readers ==
2020-03-10 22:07:14.296 UTC [policies] Evaluate -> DEBU 1c4c This is an implicit meta policy, it will trigger other policy evaluations, whose failures may be benign
2020-03-10 22:07:14.296 UTC [policies] Evaluate -> DEBU 1c4d == Evaluating *policies.implicitMetaPolicy Policy /Channel/Orderer/Readers ==
2020-03-10 22:07:14.296 UTC [policies] Evaluate -> DEBU 1c4e This is an implicit meta policy, it will trigger other policy evaluations, whose failures may be benign
2020-03-10 22:07:14.296 UTC [policies] Evaluate -> DEBU 1c4f == Evaluating *cauthdsl.policy Policy /Channel/Orderer/OrdererMSP/Readers ==
```
Antimttr (Wed, 11 Mar 2020 22:04:40 GMT):
but still its a bunch of warnings and errors in my peer log which wasn't happening before I added the channel policies: ```
2020-03-10 22:09:04.302 UTC [blocksProvider] DeliverBlocks -> ERRO 0ce [mychannel] Got error &{FORBIDDEN}
2020-03-10 22:09:04.414 UTC [blocksProvider] DeliverBlocks -> ERRO 0cf [mychannel] Got error &{FORBIDDEN}
2020-03-10 22:09:04.626 UTC [blocksProvider] DeliverBlocks -> ERRO 0d0 [mychannel] Got error &{FORBIDDEN}
2020-03-10 22:09:05.036 UTC [blocksProvider] DeliverBlocks -> ERRO 0d1 [mychannel] Got error &{FORBIDDEN}
2020-03-10 22:09:05.847 UTC [blocksProvider] DeliverBlocks -> ERRO 0d2 [mychannel] Got error &{FORBIDDEN}
2020-03-10 22:09:07.457 UTC [blocksProvider] DeliverBlocks -> ERRO 0d3 [mychannel] Got error &{FORBIDDEN
```
Antimttr (Wed, 11 Mar 2020 22:05:11 GMT):
then eventually the block provider shuts down
Antimttr (Wed, 11 Mar 2020 22:05:54 GMT):
now when i started digging into the NodeOU's I discovered that the guide i was using to generate my crypto material: https://hyperledger-fabric-ca.readthedocs.io/en/latest/operations_guide.html
Antimttr (Wed, 11 Mar 2020 22:05:59 GMT):
didn't use any nodeou's
Antimttr (Wed, 11 Mar 2020 22:06:04 GMT):
i guess it was too old or something?
Antimttr (Wed, 11 Mar 2020 22:06:26 GMT):
so basically i didnt have any config.yaml files anywhere in my MSP structure
Antimttr (Wed, 11 Mar 2020 22:07:11 GMT):
so I assume there is some default going on but even like my admin signing cert specifies an OU=user
Antimttr (Wed, 11 Mar 2020 22:07:24 GMT):
which is counter intuitive but its in line with the guide I followed:
Antimttr (Wed, 11 Mar 2020 22:08:04 GMT):
for instance this is from fabric-ca op guide, the part where it registers the admin identity for org1: ```
export FABRIC_CA_CLIENT_TLS_CERTFILES=/tmp/hyperledger/org1/ca/crypto/ca-cert.pem
export FABRIC_CA_CLIENT_HOME=/tmp/hyperledger/org1/ca/admin
fabric-ca-client enroll -d -u https://rca-org1-admin:rca-org1-adminpw@0.0.0.0:7054
fabric-ca-client register -d --id.name peer1-org1 --id.secret peer1PW --id.type peer -u https://0.0.0.0:7054
fabric-ca-client register -d --id.name peer2-org1 --id.secret peer2PW --id.type peer -u https://0.0.0.0:7054
fabric-ca-client register -d --id.name admin-org1 --id.secret org1AdminPW --id.type user -u https://0.0.0.0:7054
fabric-ca-client register -d --id.name user-org1 --id.secret org1UserPW --id.type user -u https://0.0.0.0:7054
```
Antimttr (Wed, 11 Mar 2020 22:08:17 GMT):
you can see here it's specifying --id.type user
Antimttr (Wed, 11 Mar 2020 22:08:29 GMT):
and when I eventually enrolled the admin it ended up having an OU=user
Antimttr (Wed, 11 Mar 2020 22:08:38 GMT):
which isn't one of the NodeOU types I've seen anywhere
Antimttr (Wed, 11 Mar 2020 22:08:44 GMT):
but apparently those are just labels
Antimttr (Wed, 11 Mar 2020 22:08:51 GMT):
but is it part of the default?
yacovm (Wed, 11 Mar 2020 22:12:48 GMT):
I think you just did something wrong with the docker stuff
Antimttr (Wed, 11 Mar 2020 22:13:42 GMT):
i can show you my docker.yaml if you'd like, that I didnt change yesterday after we talked but there might be something there
Antimttr (Wed, 11 Mar 2020 22:13:42 GMT):
i can show you my docker-compose.yaml if you'd like, that I didnt change yesterday after we talked but there might be something there
yacovm (Wed, 11 Mar 2020 22:14:45 GMT):
sorry but i'm too busy :/
yacovm (Wed, 11 Mar 2020 22:15:04 GMT):
hey at least i respond sometimes on RocketChat
Antimttr (Wed, 11 Mar 2020 22:15:22 GMT):
did rickr leave IBM? i enver see him talk anymore :/
yacovm (Wed, 11 Mar 2020 22:15:37 GMT):
he was moved to another project
Antimttr (Wed, 11 Mar 2020 22:15:40 GMT):
d'oh
Antimttr (Thu, 12 Mar 2020 15:48:05 GMT):
So following the Fabric-ca Ops guide they have you use the following attributes for registering an Orderer admin: `{"abac.init":"true","admin":"true","hf.Affiliation":"","hf.EnrollmentID":"admin-orderer","hf.Type":"admin"}}`
Antimttr (Thu, 12 Mar 2020 15:48:18 GMT):
my question is, should these attributes also be used in registering admins for peer organizations?
Abhishekkishor (Thu, 12 Mar 2020 19:24:59 GMT):
Has joined the channel.
gokulalex (Fri, 20 Mar 2020 12:08:52 GMT):
Has joined the channel.
aberwag (Tue, 24 Mar 2020 08:09:01 GMT):
Has joined the channel.
przemyslaw.sanecki (Thu, 26 Mar 2020 14:00:04 GMT):
Has joined the channel.
matanyahu (Mon, 06 Apr 2020 17:48:19 GMT):
Has left the channel.
metadata (Fri, 10 Apr 2020 20:59:28 GMT):
Hello All, I need some help with below issue.
https://chat.hyperledger.org/channel/fabric-ca?msg=hFXxpqMTd6oBhb6R9
joaquimpedrooliveira (Fri, 17 Apr 2020 15:12:38 GMT):
Has joined the channel.
caduellery (Fri, 17 Apr 2020 15:27:46 GMT):
Hi all! Does Fabric support ECDSA certificates with brainpool curves? The key was generated with `openssl ecparam -name brainpoolP512r1 -genkey -noout -out` and the certificate was signed with ecdsa-with-SHA256. We are getting "Failed to initialize local MSP: getCertFromPem error: failed to parse x509 cert: x509: failed to parse ECDSA parameters as named curve" and are in doubt if the real cause is the brainpool curve of the key...
ashutosh_kumar (Fri, 17 Apr 2020 20:29:28 GMT):
brainpool curve is not supported . So , that might be the issue\.
caduellery (Fri, 17 Apr 2020 21:20:56 GMT):
thanks, @ashutosh_kumar
ashutosh_kumar (Fri, 17 Apr 2020 23:06:28 GMT):
I am trying to determine difference between Brainpool and NIST Curve. I'll come back to you with more question(s) and/or refined answer.
ashutosh_kumar (Fri, 17 Apr 2020 23:06:28 GMT):
I am trying to determine difference between Brainpool and NIST Curves. I'll come back to you with more question(s) and/or refined answer.
ashutosh_kumar (Fri, 17 Apr 2020 23:40:02 GMT):
I replied to your question on Hyperledger Fabric Mailing list. This was my reply : Fabric out of the box Elliptic Curve support is based on golang support and golang support NIST Curves. The difference between NIST Curve and Brainpool curves are domain parameters.Domain parameters for NIST Curves and Brainpool curves are different , hence Brainpool curve will not work in Fabric.
caduellery (Mon, 20 Apr 2020 12:05:47 GMT):
thank you, @ashutosh_kumar ! what a pity there is no support yet...
ashutosh_kumar (Mon, 20 Apr 2020 19:22:43 GMT):
Sorry , I could not be of any help._
InRu (Tue, 12 May 2020 11:22:21 GMT):
Has joined the channel.
conanoc (Tue, 19 May 2020 10:04:15 GMT):
Has left the channel.
cryptopatrick (Tue, 26 May 2020 19:57:35 GMT):
Has joined the channel.
AshishMalik (Fri, 05 Jun 2020 05:51:44 GMT):
Has joined the channel.
FarhanShafiq (Tue, 09 Jun 2020 07:22:18 GMT):
Has joined the channel.
marcdk (Mon, 06 Jul 2020 05:29:35 GMT):
Has joined the channel.
ever-upwards (Tue, 07 Jul 2020 11:33:52 GMT):
Has joined the channel.
spore-engineering (Wed, 08 Jul 2020 23:20:09 GMT):
Has joined the channel.
braduf (Thu, 09 Jul 2020 14:44:43 GMT):
Hi all, we are looking on how to store private keys from the peers and orderer and I would like to know if there is any significant latency difference between having the keystore on the peer itself or having the keys in an HSM in the same cloud provider as the peers?
Thanks in advance for any information or any experience that can be shared with using HSM for the private keys of the Fabric components.
ashutosh_kumar (Thu, 09 Jul 2020 15:12:28 GMT):
All cloud provider implements Network HSM , hence there is latency for sure. You need to work with your Cloud HSM provider for latency optimization.
ashutosh_kumar (Thu, 09 Jul 2020 15:13:01 GMT):
There are lots of moving parts here and nobody can box it out.
davidkhala (Wed, 19 Aug 2020 11:29:45 GMT):
Is here a good place to discuss national crypto standards for fabric?
yacovm (Wed, 19 Aug 2020 15:14:20 GMT):
mailing list @davidkhala
yacovm (Wed, 19 Aug 2020 15:14:35 GMT):
but I have a feeling you want to discuss *international* standards
davidkhala (Thu, 20 Aug 2020 06:20:27 GMT):
@yacovm you are correct :laughing:
davidkhala (Thu, 20 Aug 2020 06:26:44 GMT):
Has left the channel.
czar0 (Fri, 09 Oct 2020 11:10:37 GMT):
Has joined the channel.
sandhya-rayaprolu (Wed, 14 Oct 2020 19:34:15 GMT):
Has joined the channel.
sandhya-rayaprolu (Wed, 14 Oct 2020 19:34:15 GMT):
I posted this #fabric-questions but this maybe a more relevant channel.
https://chat.hyperledger.org/channel/fabric-questions?msg=cAWDR2bcTXgizPRsY
ashutosh_kumar (Wed, 14 Oct 2020 22:53:24 GMT):
HSM is being used in field.
BrettLogan (Thu, 15 Oct 2020 01:02:03 GMT):
Actually both of these are required to even get you close to FIPS certification.
BrettLogan (Thu, 15 Oct 2020 01:02:03 GMT):
Actually both of these are required to even get you close to FIPS compliance.
BrettLogan (Thu, 15 Oct 2020 01:02:51 GMT):
2 is very straight forward, compile Fabric against Go with Boring Crypto
BrettLogan (Thu, 15 Oct 2020 01:04:58 GMT):
You can pull the boring crypto tarballs from Google's official repo: https://go-boringcrypto.storage.googleapis.com/go${GO_VER}.src.tar.gz
BrettLogan (Thu, 15 Oct 2020 01:04:58 GMT):
You can pull the boring crypto tarballs from Google's official repo: https://go-boringcrypto.storage.googleapis.com/go
BrettLogan (Thu, 15 Oct 2020 01:04:58 GMT):
You can pull the boring crypto tarballs from Google's official repo: https://go-boringcrypto.storage.googleapis.com/go1.14.7.src.tar.gz
BrettLogan (Thu, 15 Oct 2020 01:06:09 GMT):
But all of this still isn't going to get you full FIPS certification. There are still some operations, like TLS operations that are still not compliant. The only way to solve this one is to use something like RedHat's UBI images with their FIPS certified openssl libraries
BrettLogan (Thu, 15 Oct 2020 01:06:09 GMT):
But all of this still isn't going to get you full FIPS certification. There are still some operations, like TLS operations that are still not compliant. The only way to solve this one is to use something like RedHat's UBI images with their FIPS certified libraries baked into them
BrettLogan (Thu, 15 Oct 2020 01:06:09 GMT):
But all of this still isn't going to get you to FIPS compliance. There are still some operations, like TLS operations that are still not compliant. The only way to solve this one is to use something like RedHat's UBI images with their FIPS certified libraries baked into them
sandhya-rayaprolu (Thu, 15 Oct 2020 15:09:35 GMT):
Thank you
robmurgai (Thu, 15 Oct 2020 15:56:11 GMT):
Has joined the channel.
troyronda (Wed, 28 Oct 2020 17:42:08 GMT):
Has left the channel.
tomappleyard (Wed, 11 Nov 2020 13:57:12 GMT):
Has joined the channel.
tomappleyard (Wed, 11 Nov 2020 14:01:37 GMT):
Hey All, can anyone point me towards any resources on how BCCSP works and how I might go about extending it? (or writing an alternative? I notice in the core.yaml example - https://github.com/hyperledger/fabric/blob/release-2.2/sampleconfig/core.yaml#L297 there seems to be talk of a default BCCSP provider, how would I swap this out?)
tomappleyard (Mon, 16 Nov 2020 17:58:41 GMT):
So there's an answer attached to this - see, https://chat.hyperledger.org/channel/fabric-ca?msg=YhqbxzuXtiDFkQkgy (similar question)
Roger (Thu, 07 Jan 2021 07:26:32 GMT):
Has left the channel.
braduf (Tue, 23 Feb 2021 15:08:34 GMT):
Hi all, we are encountering some problems when trying to use AWS CloudHSM with Fabric. We have a CloudHSM cluster set up, built the peer and orderer images from the source with the pkcs11 tag and have configured the orderer.yaml and core.yaml files to use the PKCS11 crypto provider with the label and CryptoUser:CryptoUserPassword as pin. The CloudHSM client is installed and configured and the CloudHSM pkcs11 library is installed and mounted to the container, so everything seems ok, but it doesn't seem to work. The error we get is:
```
�[31m2021-02-22 11:43:49.159 -05 0004 ERRO�[0m [main] �[31;1mInitCmd�[0m -> Cannot run peer because error when setting up MSP of type bccsp from directory /msp: could not initialize BCCSP Factories: Failed initializing PKCS11.BCCSP: Could not initialize BCCSP PKCS11 [pkcs11: instantiation failed for /opt/cloudhsm/lib/libcloudhsm_pkcs11.so]
```
Does anyone know what could be wrong or if for AWS CloudHSM the configurations should be different from the configurations for SoftHSM?
Thanks a lot in advance!
BrettLogan (Tue, 23 Feb 2021 16:56:54 GMT):
What version of Fabric are you using?
braduf (Tue, 23 Feb 2021 17:15:13 GMT):
Hi @BrettLogan , thanks for taking the time to look into this and respond.
We are using v2.3.0
BrettLogan (Tue, 23 Feb 2021 17:16:58 GMT):
can you enable debug logging, the more granular PKCS11 logging is available in 2.3.0
braduf (Tue, 23 Feb 2021 17:18:31 GMT):
I got the FABRIC_LOGGING_SPEC on DEBUG already, is there another parameter for PKCS11 logs?
BrettLogan (Tue, 23 Feb 2021 17:19:46 GMT):
There is nothing preceding that message?
BrettLogan (Tue, 23 Feb 2021 17:19:59 GMT):
Let me run the HSM tests and remind myself what I am looking for
braduf (Tue, 23 Feb 2021 17:21:01 GMT):
pkcs11-logs.png
braduf (Tue, 23 Feb 2021 17:21:58 GMT):
"Before using BCCSP, please call InitFactories()."
braduf (Tue, 23 Feb 2021 17:22:52 GMT):
Is that helpful or should I look for another message?
BrettLogan (Tue, 23 Feb 2021 17:22:58 GMT):
That message is expected
braduf (Tue, 23 Feb 2021 17:23:21 GMT):
Ok, I will look some more above in the logs
BrettLogan (Tue, 23 Feb 2021 17:23:41 GMT):
Are you dumping the AWS HSM Client logs to your log utility?
BrettLogan (Tue, 23 Feb 2021 17:23:45 GMT):
They are at `/opt/cloudhsm/run/cloudhsm_client.log`
BrettLogan (Tue, 23 Feb 2021 17:24:14 GMT):
`/opt/cloudhsm/run/cloudhsm_client.log`
braduf (Tue, 23 Feb 2021 17:24:14 GMT):
good idea, we are not doing that yet I think
braduf (Tue, 23 Feb 2021 17:24:32 GMT):
I will look into that and let you know if we find something there
BrettLogan (Tue, 23 Feb 2021 17:24:40 GMT):
That would be the next place we would go if we were debugging this
braduf (Tue, 23 Feb 2021 17:24:57 GMT):
Great tip!
braduf (Tue, 23 Feb 2021 17:25:10 GMT):
Thanks a lot, we will look there first
BrettLogan (Tue, 23 Feb 2021 17:25:29 GMT):
Unfortunately most of the logging in PKCS11 is held by the client fully and the error reported back to our library is really vague
BrettLogan (Tue, 23 Feb 2021 17:25:40 GMT):
If you find an error there and I can be of help let me know
braduf (Tue, 23 Feb 2021 17:35:01 GMT):
Ok, let's hope we can figure it out with the logs there, thanks a lot for guiding us there and I will let you know how it goes.
braduf (Tue, 23 Feb 2021 17:35:01 GMT):
Ok great, let's hope we can figure it out with the logs there, thanks a lot for guiding us there and I will let you know how it goes.
braduf (Tue, 23 Feb 2021 23:02:14 GMT):
Hi @BrettLogan , in the logs of the HSM client, we are not seeing anything more than the client authorizing and then after 15 minuts it seems there is a connection shutdown, probably because of inactivity I think.
```
-- Logs begin at Tue 2021-02-23 20:31:14 UTC. --
Feb 23 22:07:41 ip-10-104-198-158.ec2.internal cloudhsm_client[7772]: 2021-02-23T22:07:41Z liquidSecurity INF: e2e_handle_client_request: Got Authorize session response
Feb 23 22:07:41 ip-10-104-198-158.ec2.internal cloudhsm_client[7772]: 2021-02-23T22:07:41Z liquidSecurity INF: get_partition_info: Get pHSM Info using e2e mgmtch
Feb 23 22:07:41 ip-10-104-198-158.ec2.internal cloudhsm_client[7772]: 2021-02-23T22:07:41Z liquidSecurity INF: e2e_handle_client_request: Authorize session SUCCESS
Feb 23 22:07:41 ip-10-104-198-158.ec2.internal cloudhsm_client[7772]: 2021-02-23T22:07:41Z liquidSecurity INF: e2e_handle_client_request: Got Partition Info
Feb 23 22:07:41 ip-10-104-198-158.ec2.internal cloudhsm_client[7772]: 2021-02-23T22:07:41Z liquidSecurity INF: e2e_handle_client_request: GetPartitionInfo success 0 : HSM Return: SUCCESS
Feb 23 22:07:41 ip-10-104-198-158.ec2.internal cloudhsm_client[7772]: 2021-02-23T22:07:41Z liquidSecurity INF: e2e_handle_client_request: HSM FIPS STATE 2
Feb 23 22:22:42 ip-10-104-198-158.ec2.internal cloudhsm_client[7772]: 2021-02-23T22:22:42Z liquidSecurity INF: cvm_liquidsecurity_daemon_connshutdown: releasing conn:0x7feb300054c0, s_data:0x22c8c20
Feb 23 22:22:42 ip-10-104-198-158.ec2.internal cloudhsm_client[7772]: 2021-02-23T22:22:42Z liquidSecurity INF: cvm_liquidsecurity_daemon_connshutdown: conn:0x7feb300054c0, n_conn_down:1, n_conn:0
Feb 23 22:22:42 ip-10-104-198-158.ec2.internal cloudhsm_client[7772]: 2021-02-23T22:22:42Z liquidSecurity INF: cvm_liquidsecurity_daemon_connshutdown: releasing conn:0x22c8ee0, s_data:0x22c8c20
Feb 23 22:22:42 ip-10-104-198-158.ec2.internal cloudhsm_client[7772]: 2021-02-23T22:22:42Z liquidSecurity INF: cvm_liquidsecurity_daemon_connshutdown: conn:0x22c8ee0, n_conn_down:0, n_conn:0
```
So I think Fabric is not even getting to the HSM client.
We were investigating some more PR's (https://github.com/hyperledger/fabric/pull/364) that were done in Fabric concerning AWS CloudHSM, and we see that in v1.4 `AltId' got added to the bccsp parameters especially to solve something with AWS CloudHSM and in the docs there is also a section explaining this in v1.4:
```
If you are using AWS HSM there is an additional step required:
Add the parameter, AltId to the pkcs11 section of the bccsp block. When AWS HSM is being used, this parameter is used to assign a unique value for the Subject Key Identifier (SKI). Create a long secure string outside of Fabric and assign it to the AltId parameter. For example:
```
But from what I can see this was merged to v1.4 alone (and not to master and so never got into v2.x either. So I am wondering if v2.3 is even able to work with AWS CloudHSM... Do you know anything about this?
BrettLogan (Wed, 24 Feb 2021 10:03:18 GMT):
We added this functionality specifically for AWS, as AWS doesn't directly support the PKCS11_COPY command, though I thought it landed in all releases. Once I get in front of my computer this morning I'll take a look
braduf (Wed, 24 Feb 2021 15:40:23 GMT):
Screen Shot 2021-02-24 at 10.40.10 AM.png
braduf (Wed, 24 Feb 2021 15:40:29 GMT):
@BrettLogan thanks a lot! From what I can see it didn't got into master, only in the 1.4 release.
braduf (Fri, 26 Feb 2021 17:31:09 GMT):
Hi @BrettLogan, I hope you are doing great, I am working to do a PR to include the fix for AWS CloudHSM into master now. But we tried to get v1.4 work with our HSM and we get the same error, without seeing any logs from the HSM client telling us something, it looks like Fabric is just not recognizing the pkcs11 library.
Romern (Wed, 07 Apr 2021 12:57:54 GMT):
Has joined the channel.
Ku_LEA (Thu, 08 Apr 2021 01:46:18 GMT):
Has joined the channel.
Ku_LEA (Thu, 08 Apr 2021 01:46:19 GMT):
hi all, I have a peculiar idea. I am trying to use a group signature rather than ecdsa-with-sha256 for the cryptograhpic algorithm used for CA-issued certificates.
Can the crypto algorithm be modified in the fabric? If possible, I would be very grateful if you let me know where to modify and build the fabric.
ashutosh_kumar (Thu, 08 Apr 2021 01:58:07 GMT):
Group Signature is not supported in Fabric.
RobertBetschinger (Fri, 28 May 2021 10:21:00 GMT):
Has joined the channel.
Shweta1 (Mon, 31 May 2021 13:14:23 GMT):
Has joined the channel.
jimthematrix (Mon, 07 Jun 2021 16:01:19 GMT):
Has left the channel.
robinrob (Thu, 09 Sep 2021 21:53:17 GMT):
Has left the channel.
bardia (Fri, 01 Oct 2021 10:12:19 GMT):
Has joined the channel.
baxihemant (Mon, 11 Oct 2021 01:13:36 GMT):
Has joined the channel.
dan13 (Sat, 30 Oct 2021 00:38:46 GMT):
Has joined the channel.
bardia (Mon, 08 Nov 2021 06:24:44 GMT):
How can I get the *password* *attempts* problem in golang?
When I login 10 times unsuccessfully, I can no longer login 11 times with the correct specifications
Gives the following message
failed to enroll user: enroll failed: enroll failed: Response from server: Error Code: 73 - Incorrect password entered 10 times, max incorrect password limit of 10 reached
bardia (Tue, 07 Dec 2021 06:05:31 GMT):
How can I increase the number of deploy in the chain code version?
bardia (Fri, 17 Dec 2021 06:12:10 GMT):
How to change affiliation name on ca-server HLF?
bardia (Thu, 20 Jan 2022 08:31:03 GMT):
Has left the channel.
sudarsan.immadi (Thu, 24 Feb 2022 11:12:18 GMT):
Has joined the channel.
sudarsan.immadi (Thu, 24 Feb 2022 11:12:18 GMT):
hi
rjones (Wed, 23 Mar 2022 17:35:15 GMT):
rjones (Wed, 23 Mar 2022 17:35:15 GMT):
rjones (Wed, 23 Mar 2022 17:35:15 GMT):
