Closed SamYuan1990 closed 9 months ago
hi @bestbeforetoday , if no further comments, then I prefer merge as it is.
Will merge as it is at end of this weekend.
Reading certificates only from files perfectly suits the fabric-admin-sdk test code, but it might be restrictive for actual end users. What if they have a PEM-encoded certificate in memory, perhaps extracted from some JSON or accessed by another API? These utilities provide no value in that case. Perhaps a function to load a certificate from []byte (similar to the one for private keys) would be more helpful?
Some unit tests would have been nice.
is there any api or existing SDK can we use directly?
is there any api or existing SDK can we use directly?
fabric-gateway's identity package provides some similar capability but might not do everything you want for the admin SDK. The current implementation actually only deals with unencrypted PKCS #8 format private keys. For more complex cases, like encrypted private keys, the standard Go packages would need to be used. There is already a NewPrivateKeySigningIdentity(mspID string, certificate *x509.Certificate, privateKey crypto.PrivateKey)
function exposed by the admin SDK's identity package so maybe just helpers to make it easier to read a Certificate and PrivateKey are enough?
Everything can be done with the standard Go packages but it is also reasonable to provide utilities to reduce the work required in client code for typical scenarios. I think any public API needs to consider all the typical scenarios (like already have the PEM in memory as a []byte
, perhaps read from JSON or retrieved using some other API), not just what is needed for the admin SDK tests. If it's too specific to the tests, it might be better just staying as internal test code and not exposed as a public API that then needs to be supported.
is there any api or existing SDK can we use directly?
fabric-gateway's identity package provides some similar capability but might not do everything you want for the admin SDK. The current implementation actually only deals with unencrypted PKCS #8 format private keys. For more complex cases, like encrypted private keys, the standard Go packages would need to be used. There is already a
NewPrivateKeySigningIdentity(mspID string, certificate *x509.Certificate, privateKey crypto.PrivateKey)
function exposed by the admin SDK's identity package so maybe just helpers to make it easier to read a Certificate and PrivateKey are enough?Everything can be done with the standard Go packages but it is also reasonable to provide utilities to reduce the work required in client code for typical scenarios. I think any public API needs to consider all the typical scenarios (like already have the PEM in memory as a
[]byte
, perhaps read from JSON or retrieved using some other API), not just what is needed for the admin SDK tests. If it's too specific to the tests, it might be better just staying as internal test code and not exposed as a public API that then needs to be supported.
let's ask user to use following function to build up their own MSP as signer to sign the data.
IMO, as there 25519 or HSM...
hence, we can as user to reuse identity.GetCertificate
to get cert from a path. and use GetecdsaPrivateKey
if ... load ecdsa private key from path.
if user wanted, he/she can use NewPrivateKeySigningIdentity
with interface supported to generate he/she's own MSP?
cert2, _, err := identity.GetCertificate(SignCert)
Expect(err).NotTo(HaveOccurred())
priv2, err := identity.GetecdsaPrivateKey(PrivKeyPath)
Expect(err).NotTo(HaveOccurred())
org2MSP, err := identity.NewPrivateKeySigningIdentity(org2MspID, cert2, priv2)
Expect(err).NotTo(HaveOccurred())
enhance msp and network creation function to make it able to reuse from external as fabric cli.