To explain a bit more about the certificates...

The connections to the policy service and OpenSSO must be secured
anyway. Usually, the SSL/TLS connections are established only using a
server certificate -- which makes sense as it is usually the
user/client who needs to be certain whom they talk to (like, is it
really your bank, or rather a fishing site). For OpenSSO that must be
all that we need, because the client/user has to provide either
user/pass credentials or a valid token for the connection to be
meaningful to them (that is, to authenticate, or check for proper
authorization).

For the policy service however, we would also like to check whom the
policy service itself is talking to -- that is, who requests the
policy to be registered. And here come the client (in SSL context)
certificates. So, the service at serviceA.opentox.org would have a
client certificate issued to "serviceA.opentox.org" (unsurprisingly).
Mind you, a certificate could be issued for multiple domain names, so
that is not a problem if needed. Also, it could in fact be the same
certificate used in server role as well; there is an extendedKeyUsage
attribute in the certificate that could be set to clientAuth,
serverAuth or both. And we need such server certificate for each
service anyway, so all that is necessary is to issue it with the
clientAuth option set as well.

Truth is, we could also use this principle (using both server and
client certificates to establish the SSL/TLS session) when the
services talk to each other. That would add another layer of security,
because the connections would be checked bidirectionally -- not only
the client service will know it's talking to the correct "server"
service, but also the latter will be certain that it's not accepting a
request from an imposter.

Now, obviously, self-signed certificates wouldn't be much effective in
these scenarios -- you generally shouldn't trust them, and even if you
do know they are valid, you have to add them to your "trusted" list
one by one. Getting certificates from an "official authority" is
probably the easiest solution to the problem (considering that there
are one or two free services even), but a "privately-run" one might be
more flexible and more secure. The reason is that you would issue
certificates not just to anyone (where you only check whether they do
own the domain they request certificates for), but only to people you
know to have legitimate need to use the OT infrastructure. Indeed, I
suspect that if OT is used by some large pharma corporations, they
would do exactly this -- and not trust third party certificate
authority.

Running a CA is not that difficult, really, though for it to be truly
secure a few practices must be strictly followed (like having a
dedicated machine used to sign the certificates, and keeping it in a
_physically_ secure location, usually not connected to any network at
all). In fact, even at the moment I'm serving as the chief manager of
the Bulgarian academic certification authority, which is accredited by
EUGridPMA/IGTF and which was effectively created by me, so I'm
speaking from first-hand experience.

Cheers,
Luchesar


On Mon, Jun 28, 2010 at 22:54, Luchesar V. ILIEV
<luchesar.iliev at gmail.com> wrote:
> On Mon, Jun 28, 2010 at 22:27, Luchesar V. ILIEV
> <luchesar.iliev at gmail.com> wrote:
>> [...snip...]
>>
>> In other words, if the service gets a request for the resource above
>> from an address, which reverse-resolves to, say, badguy.aol.com, then
>> the policy service will reject the request straight away.
>
> That was ambiguous, sorry. Should have read instead:
>
> In other words, if the _policy_ service gets a _policy_creation_
> request for the resource above from an address that reverse-resolves
> to, say, badguy.aol.com, then the policy service will reject the
> request straight away (because badguy.aol.com !=
> serviceA.opentox.org).
>
> L.
>
> P.S. And, in the case of SSL/TLS, it would read:
>
> In other words, if the _policy_ service gets a _policy_creation_
> request for the resource above via a secure connection where the
> client certificate has been issued to badguy.aol.com, then the policy
> service will reject the request straight away (because badguy.aol.com
> != serviceA.opentox.org).
>
> Of course, if the bad guy doesn't present valid certificate in the
> first place (that is, issued by a trusted certification authority),
> then no connection would happen at all.
>