On 5.3.2014 14:21, Simo Sorce wrote:
On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote:
On 5.3.2014 08:48, Jan Cholasta wrote:
On 5.3.2014 05:10, Simo Sorce wrote:
On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote:
Remote means that there is a PKCS#11 library that can be loaded into a
process and would remotely connect to a central server via
LDAP/REST/whatever. My point is that library should be light weight
and always talk to a local service like SSSD rather than have a remote
interface. In this case SSSD on the server can talk to the vault or
IPA LDAP directly and all consumers would use PKCS#11 interface
exposed by SSSD
Something like this...
Yes this is the setting we are discussing, the actual specific
discussion is how SSSD gets the information.
Honza proposed to use a PKCS#11-like schema to store data in LDAP given
DNS will need something similar, however the more we wandered into the
discussion the more I got convinced the Vault is probably a better place
to store this material than the LDAP tree itself at least for prvate
keys.
I only proposed something that would work for my needs (i.e. storing
certificates and associated trust policy) and would be ready for 4.0. Can you
say the same thing about the vault?
I agree with Honza. I think that proposed LDAP schema is perfectly fits the
purpose *for public* information like certificates and public keys.
And I agree with you and Honza as well that the proposal is ok for
*public* information.
For public key material only though I am not sure a pkcs#11 schema will
necessarily be useful. It might, but we do not use it for public SSH
keys. And we also already have schema for public User or Servers X509
certs.
Support for SSH public keys was implemented like 2 years ago, way before any
talk about the vault or PKCS#11 even started. As for certs, the proposed
schema works on top of RFC 4523, which is the cert schema you mention.
We need to define something for DNS public keys, but they are already
published in DNS Records too if I am not wrong, would that be sufficient
as a storage for the public part ? I am assuming the private keys are
No, we need full PKCS#11 for OpenDNSSEC at least.
Well, you need a pkcs#11 library interface, the backing store could be anything,
but I do see the advantage of using a common schema so that SSSD can retrieve
data
to present through that interface in a simplified and consistent way.
Note that PKCS#11 in SSSD will give us generic mechanism for process/key
separation (it is practically the same thing GSS-Proxy, just general purpose).
This comes 'for free' if we implement PKCS#11 so please stop searching for
workarounds :-)
I am not looking for workarounds for the interface between SSSD and
consuming libraries. I am trying to evaluate what we could use this
schema for before jumping into it.
stored in the Vault and they can be files in the format used by bind ?
BIND files are very hackish and we need to do PKCS#11->BIND files conversion
anyway because OpenDNSSEC supports only PKCS#11 and nothing else.
I plan to use PKCS#11 directly from BIND so we can drop the format conversion
code and rely on pure PKCS#11 instead of bunch of hacks scripts.
Ok.
So the information would be scattered in different places, using different
formats and accessed using different protocols? I'm fine with that, but it is
way beyond my original idea, so please let whoever is in charge of the vault
implement the PKCS#11 module themselves.
Honza, clearly if something different is proposed work will be split
between those that need to implement it in various ways, this will
simply require to separate the pkcs#11 module into 2 parts, a 'feeder'
that implements the pkcs#11 interface and a pluggable 'gatherer' that
implements retrieval for specific stuff. No worries there.
Sounds good. (But I must admit I was a little bit scared for a moment :-)
- IMHO public information should be stored in LDAP schema as proposed.
- I agree that Vault is the right choice to store secrets.
- I propose to combine these two: Store public information in LDAP and store
private keys in PKCS#8 blob as a secret in Vault.
- This LDAP+Vault combo can be accessible over PKCS#11 interface.
- Note that this will work even without vault if you want to store public
information only (like CA certs and NSS trust objects).
Works for me.
+1
The only problem is that we need to use REST API from SSSD. Plain LDAP is
already implemented in SSSD so it requires less code. I guess that we will
need something like libipavault library...
We'll need a helper process unless we can find a fully async library to
deal with the vault. Authentication to the vault over REST-like APIs
will also be an interesting problem ...
Simo.
--
Jan Cholasta
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
