Fwiw: if it doesn't go in now then it won't ever be in the certified base implementation so it might be worth querying if never having it is preferable. 16.10 is the last certified base implementation.
--------------------- Noah Harlan Sent from a portable device Typos are courtesy of big thumbs > On Oct 24, 2016, at 5:07 PM, Kevin Kane via Allseen-core > <[email protected]> wrote: > > It’s an API change, which is no small thing. I think you have to argue the > need for it is compelling enough to allow it at this late point in the > release cycle. > > From: George Tang [mailto:[email protected]] > Sent: Monday, October 24, 2016 12:49 PM > To: Kevin Kane <[email protected]> > Cc: allseen-core <[email protected]> > Subject: RE: [Allseen-core] ER_PERMISSION_DENIED > > I'm fine with this. Would this be a problem since it's a code freeze? > > > On Oct 24, 2016 1:48 PM, "Kevin Kane" <[email protected]> wrote: > Ah, that’s a good point. > > This may be an artifact of unit test code previously using bus attachments to > sign certificates and manifests as a convenient way to generate and use > public/private key pairs. The SecurityApplicationProxy methods are designed > to work with XML strings, but they require providing the signing key as a > parameter. > > I think you’ve identified a gap in the API. Personally I think it’s poor > design for a security manager to use a bus attachment as a key container, but > the convenience of doing so (as opposed to implementing some external storage > method for keys) seems to be too compelling. > > The solution could be to add overloads to C++ PermissionConfigurator’s > SignManifest method to allow it to operate on XML strings, the same way > SecurityApplicationProxy’s do, and then exposing those through to the Java > layer. We generally want to move to XML-using APIs. What do you think? > > > From: George Tang [mailto:[email protected]] > Sent: Monday, October 24, 2016 11:45 AM > To: Kevin Kane <[email protected]> > Cc: allseen-core <[email protected]> > Subject: Re: [Allseen-core] ER_PERMISSION_DENIED > > I didn't expose this function to the Java side, because that would expose the > manifest datatype. There didn't seem to be a sign manifest for string. Is the > solution exposing a java one specifically with a string manifest parameter, > doing the conversions in the JNI layer, and returning a string? > > I have taken a look a XmlManifestConverter, and I don't it is public, so I > don't think I would be able to use existing infrastructure to do this. > > On Mon, Oct 24, 2016 at 1:26 PM, Kevin Kane <[email protected]> wrote: > PermissionConfigurator also has a SignManifest method for this purpose. > > From: George Tang [mailto:[email protected]] > Sent: Monday, October 24, 2016 11:19 AM > > To: Kevin Kane <[email protected]> > Cc: allseen-core <[email protected]> > Subject: Re: [Allseen-core] ER_PERMISSION_DENIED > > When the certificates are signed with the generated private key instead of by > PermissionConfigurator.sign from the bus attachment, calling claim will give > me an ER_INVALID_CERTIFICATE. > > Since CredentialAccessor isn't public, the security manager sample shouldn't > be able to get the bus private key either. I'm curious if the security > manager uses the bus's permission configurators to sign the certificate. and > how it gets the private key to sign the manifest. > > On Mon, Oct 24, 2016 at 12:37 PM, Kevin Kane <[email protected]> wrote: > The manifest needs to be signed with the same private key that signed the > certificate. > > From: George Tang [mailto:[email protected]] > Sent: Monday, October 24, 2016 10:20 AM > > To: Kevin Kane <[email protected]> > Cc: allseen-core <[email protected]> > Subject: Re: [Allseen-core] ER_PERMISSION_DENIED > > After adding the SecureConnection call on the bus attachments, there is a > SendManifests call. However, another error before the reset > ER_PERMISSION_DENIED, manifest signature failed to verify. Since I am signing > the manifests with a generated private key and not the bus's private key from > credential accessor, are there any fields in the certificate that I need to > change to the generated public key? Do I need to sign the certificates with > the generated private key too instead of with the bus's permission > configurator? I have attached the new log. > > Thanks, > George > > On Mon, Oct 24, 2016 at 10:35 AM, Kevin Kane <[email protected]> wrote: > Is your test also calling SecureConnection(true) on the bus attachment after > Claim so that the ECDSA session is established? Otherwise the manager bus > will try to continue with the existing ECHDE_NULL session and the method > calls will fail. > > From: George Tang [mailto:[email protected]] > Sent: Saturday, October 22, 2016 9:38 AM > To: Kevin Kane <[email protected]> > Cc: allseen-core <[email protected]> > Subject: Re: [Allseen-core] ER_PERMISSION_DENIED > > Hi Kevin, > > The logs contain a call to installMembership on the manager bus. Are there > any other reasons for not having a sendMemberships call? When writing these > tests I could not use credential accessor to get the guid of the bus to set > the IssuerCN, and I could not use it to get the bus privatekey to sign the > manifest. So I generated a random private key and a random guid instead. > > Thanks, > George > > On Fri, Oct 21, 2016 at 10:20 AM, Kevin Kane <[email protected]> wrote: > I don’t see any calls to SendMemberships in the trace. This suggests your > security manager bus attachment hasn’t been provisioned with an admin group > membership certificate, since later the PERMISSION_MGMT source shows the peer > does not match against the ACL for WITH_MEMBERSHP, which should match. Can > you make sure your setup generates and installs an admin group membership > certificate onto the bus attachment from which you make the Reset call? > > From: [email protected] > [mailto:[email protected]] On Behalf Of George > Tang > Sent: Thursday, October 20, 2016 9:09 PM > To: allseen-core <[email protected]> > Subject: [Allseen-core] ER_PERMISSION_DENIED > > Hi all, > > I am getting this error ER_PERMISSION_DENIED, when calling reset in Java. I > have a feeling that some value of CertificateX509 is not being set correctly, > but I don't know which value. I have the logs for a successful call to reset > from the core sample test SecurityClaimApplicationTest.cc (testlog). I also > have logs the call to reset from the Java bindings that fails (antlog). It > would be great if someone experienced in security and certificates could take > a look. > > Thanks, > George > > > > > _______________________________________________ > Allseen-core mailing list > [email protected] > https://lists.allseenalliance.org/mailman/listinfo/allseen-core
_______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
