You are correct that the ability to sign manifests with the private key stored in a bus attachment is currently not possible in the Java layer.
This does not require exposing CredentialAccessor to accomplish, however. CredentialAccessor is also not exposed publicly in the C++ API; it is internal only and in my opinion should remain that way. George has a pending change to add the necessary functionality for signing manifests in XML format both to the C++ and Java layers: https://git.allseenalliance.org/gerrit/9185 The additions to PermissionConfigurator.h and PermissionConfigurator.cc in this change provide the desired functionality without exposing CredentialAccessor. From: Paul Sigurdson [mailto:[email protected]] Sent: Wednesday, October 26, 2016 11:29 AM To: Kevin Kane <[email protected]> Cc: George Tang <[email protected]>; allseen-core <[email protected]> Subject: Re: [Allseen-core] API change Hi, I wanted to ask about use of CredentialAccessor. For example, it looks like the C++ unit tests (PermissionMgmtTestHelper) get access to the private key via code like this... CredentialAccessor ca(issuerBus); ECCPrivateKey privateKey; QStatus status = ca.GetDSAPrivateKey(privateKey); So via the CredentialAccessor. And then use this private key when calling SecurityApplicationProxy.signManifest(CertificateX509 identityCertificate, ECCPrivateKey privateKey, String unsignedManifestXml) Am I wrong in assuming that if CredentialAccessor is not exposed to the Java-binding, that this effectively means that java won't be able to call this signManifest() method. And leaves java with just the PermissionConfigurator signManifest() method. I was wondering if not having SecurityApplicationProxy.signManifest() usable in java-binding might mean loss of some use cases / capability? Thanks, Paul On Oct 25, 2016, at 10:29 AM, Kevin Kane via Allseen-core <[email protected]<mailto:[email protected]>> wrote: It should be possible to call the XmlManifestConverter from inside the JNI code, to do the conversion between XML and Manifest object there, before calling the C++ API. We did something like this for the C API in alljoyn_c\src\SecurityApplicationProxy.cc<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsecurityapplicationproxy.cc%2F&data=02%7C01%7Ckkane%40microsoft.com%7C7fad3dd225c84e34a74d08d3fdcdecee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636131033291856270&sdata=bcNAf19jWil3y2W48xzLb4JBoyolJsR6ncXcOpQK0aA%3D&reserved=0>. This is another option if we don't want to add an XML-using API to C++. Regardless, since it seems natural to use a bus attachment as a key container in a security manager, and we already have APIs for signing certificates with the bus attachment's private key, I think it makes sense to expose similar functionality for manifests in the Java layer. I also agree with not exposing CredentialAccessor. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of George Tang Sent: Monday, October 24, 2016 10:35 PM To: allseen-core <[email protected]<mailto:[email protected]>> Subject: [Allseen-core] API change Hi, I have discussed with Kevin Kane an API change to core. I would like to add another version of ComputeThumbprintAndSignManifest to PermissionConfigurator that takes a xml string instead of a manifest object. XmlManifestConverter is not public, so it may not be conventionally accessible from the Java bindings. I could use include "../../../alljoyn_core/src/XmlManifestConverter.cc<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fxmlmanifestconverter.cc%2F&data=02%7C01%7Ckkane%40microsoft.com%7C7fad3dd225c84e34a74d08d3fdcdecee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636131033291856270&sdata=Oj7HGo4BvpLOlqA%2Blaw%2Bcr5Cxmt2PkFrMBk3QX60NSM%3D&reserved=0>" but I'm sure this is not good practice. This issue blocks the java bindings from being able to call Reset, StartManagement, EndManagement successfully. Another solution that doesn't change the c++ API would be making a public function in java to get the busAttachment's private Key. This would be inconsistent with the c++ bindings in that c++ doesn't expose this. I haven't started work on it, but from my investigation, I think it will take me 8 additional hours not including the code review process. _______________________________________________ Allseen-core mailing list [email protected]<mailto:[email protected]> https://lists.allseenalliance.org/mailman/listinfo/allseen-core<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.allseenalliance.org%2Fmailman%2Flistinfo%2Fallseen-core&data=02%7C01%7Ckkane%40microsoft.com%7C7fad3dd225c84e34a74d08d3fdcdecee%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636131033291856270&sdata=Zo2N46Rj1%2B9yayDYivwl6n%2ByiMg60F492qk%2B%2BTgKGwc%3D&reserved=0>
_______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
