On 25.2.2014 14:52, Petr Spacek wrote:
On 25.2.2014 13:47, Jan Cholasta wrote:
here is a draft of the PKCS#11 design:
<http://www.freeipa.org/page/V3/PKCS11_in_LDAP>.
I don't understand the purpose of cn=crypto suffix. I thought that
PKCS#11 module will have to search for token with given TOKEN_ID or
LABEL anyway, right? Do I miss something?
That's just a base DN for LDAP searches I came up with, it has no
particular meaning.
Where the token will be placed if someobody generates new key via
PKCS#11? How it will determine the right sub-tree?
In order to generate a key, you must have an open session (see
C_GenerateKeyPair). When you open a session, you must specify slot ID
(see C_OpenSession). This is where the association takes place.
I would rather see keys stored under user account:
uid=admin,cn=users,cn=accounts,dc=ipa,dc=example
Do you mean storing private keys in a single attribute in user's entry?
We wouldn't be able to store per-key metadata that way.
If you mean storing private keys in entries under user's entry, there is
nothing similar in our current schema, so I thought we just don't do
that (there probably is a reason for that).
(Anyway, we don't need to solve this right away, DNSSEC and CA
certificates are what matters now.)
I like this approach because it allows you to manipulate with the user
account easily without paying special attention to dangling references etc.
References are managed automatically by the referint plugin.
Key storage under service account like:
krbprincipalname=DNS/[email protected],cn=services,cn=accounts,dc=ipa,dc=example
doesn't solve problem with shared keys in DNS tree... I can imagine that
objects in LDAP have TOKEN_ID and LABEL attributes indexed and the
PKCS#11 module will do full sub-tree search for particular ID or LABEL
value, so the key can be always found.
The objects need to be associated with a particular token somehow.
Having them in a token-specific sub-tree seems like the easiest way to
do it to me.
On the other side, it would require special handling for replica
deletion etc.
Petr^2 Spacek
On 24.2.2014 13:11, Ludwig Krispenz wrote:
Hi,
here is a draft to start discussion. Lt me know if it is the right
direction and what you're missing.
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema
IMO we don't need attribute types for key components
(ipaPkcs11publicExponent,
ipaPkcs11modulus, ipaPkcs11privateExponent, ipaPkcs11prime1,
ipaPkcs11prime2)
at all. As I said before, I don't think we need such granularity in
LDAP and
it would limit us to RSA only (unless we add attribute types for every
other
key type). We can store both private keys and public keys in single
attribute
as a DER blob (I would name the attributes ipaPkcs11privateKeyValue
instead of
ipaPkcs8privateKey for private keys, ipaPkcs11publicKeyValue for
public keys,
there already is ipaPkcs11certificateValue for certificates).
OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, CKA_DECRYPT,
CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE when
generating new
key pairs, and the PKCS#11 spec says that keys generated on a token
should
have CKA_LOCAL and CKA_KEY_GEN_MECHANISM set, so I think we should have
attribute types for all of them.
Ludwig
On 02/18/2014 03:17 PM, Jan Cholasta wrote:
Hi,
On 18.2.2014 14:02, Ludwig Krispenz wrote:
Hi,
yesterday jan asked me about the status of the schema and if it
would be
ready for certificate storage an dthat puzzled me a bit and showed
that
I still do not really understand what you want to store in LDAP.
Two me there are two very different approaches.
1] LDAP as store for high level objects like certs and keys
For certs and related stuff there is rfc4523 and the schema for ldif
exists. For keys we would decide if the key is stored in PKCS#8 format
or as bind keypairs and define a key attribute and that's it. we could
export keys with softhsm, (eventually convert them) and add to
ldap, in
the long term solution the PKCS#11 replacemnt would need to manage
these
high level objects
I think RFC 4523 is not the right schema in this case, as it is suited
for PKIs rather than generic cryptographic data storage. For example,
RFC 4523 distinguishes between CA and end entity certificates, but in
PKCS#11 there are just certificates without any semantics attached to
them.
2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted. SoftHsm has
one component Softdatabase with an API, which more or less passes sets
of attributes (attributes defined by PKCS#11) and then stores it as
records in sql where each record has a keytype and opaque blob of
data.
If that is what is wanted the decision would be how fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?
One-to-one mapping of attributes from PKCS#11 to LDAP would be the
most straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we can
use a single attribute containing PKCS#8 encoded private key rather
than using one attribute per private key component.
I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate objects.
So, I would say it should be something between high-level and
low-level.
Honza
--
Jan Cholasta
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
