|
On 12/11/2013 1:35 PM, Thomas Watson
wrote:
> From: Scott Lewis
<slewis@xxxxxxxxxxxxx>
>
> Hi Tom,
>
>> On 12/11/2013 5:47 AM, Thomas Watson wrote:
>> We may be able to put
org.eclipse.osgi.service.security package in
>> supplemental, but would it be possible to have
others supply a
>> different fragment that implements ECFTrustManager
in another way?
>
> Possibly. Could you explain what you have in mind?
>
>> Even if we move the
org.eclipse.osgi.service.security API to the
>> supplement bundle you would still need an
implementation of
>> TrustEngine to plug into ECFTrustManager.
>
> Yes...where (what bundle) is the equinox TrustEngine
implementation(s)?
>
A TrustEngine which is backed by a keystore
is implemented by the Equinox framework [1]. By default the
framework registers a TrustEngine that is backed by the CA
certs usually provided by the VM installation, but the
framework can be configured to use a different keystore if
desired. I'm not sure if in your ssl scenarios some other
entity is also registering a TrustEngine service.
No, no ECF code is currently registering a
TrustEngine service.
My thought was that some other fragment
could be implemented that provides an alternative
implementation of ECFTrustManager that simply looks at the
CA certs keystore themselves instead of using a TrustEngine
service to do that work for them.
I see. Another alternative: if the TrustEngine service interface
(only) were added to the supplemental, I (or contributors/consumers)
could look into providing a non-Equinox TrustEngine implementation
as part of ECF's ssl support.
Thanks,
Scott
|
