On 25.2.2014 16:42, Rob Crittenden wrote:
Jan Cholasta wrote:
On 25.2.2014 16:11, Simo Sorce wrote:
On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:
On 25.2.2014 15:11, Simo Sorce wrote:
On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:
Any reason why we should follow in detail what softshm does ?
because I did't know what is really needed. If you want to have a
pkcs11
module, which stores data in ldap, I though it should have all the
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
CKA_EXTRACTABLE,
so there is at least one requirement for fine grained attributes.
Does OpenDNSSEC store them as separate entities and need access to
them
independently ?
AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP
schema
doesn't matter as long as our PKCS#11 module can derive all values
defined by
standard.
Honza, you did investigate OpenDNSSEC integration, please add some
details if
you can.
Or is this internal use that can be satisfied by unpacking a blob in
OpenDNSSEC ?
What does bind9 uses ? Petr, can you provide example key files ?
Private+public keys stored in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html
Private keys stored in HSM and public keys in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html
(I.e. some values in .private file are replaced by PKCS#11 label.)
Ok it seem clear to me we do not need to spell out a lot of values when
using pkcs#11 as bind doesn't need them in the key files. So I assume it
can query the pkcs#11 module to find what it needs.
I would use these key files as a sort of guide to understand what we
need in LDAP. I would try to put in a single blob as much as we can that
we do not explicitly need by a client querying LDAP directly.
I think in order to nail down exactly what we need, at this point, we
require some example use cases and queries the various clients would
perform with spelled out what they are looking for to identify or
manipulate keys.
Simo.
See "How applications interact with PKCS#11" at
<http://www.freeipa.org/page/V3/PKCS11_in_LDAP>. Tl;dr: applications
don't search for keys by key data, but by metadata, so like I said in
the other thread, key data can be in a single blob, but metadata should
be in separate attributes.
Splitting hairs, I think that one can search based on the cert DER which
I guess represents the public key. You mean search by private key?
Public keys in PKCS#11 are represented by a set of attributes (e.g.
CKA_MODULUS, CKA_MODULUS_BITS and CKA_PUBLIC_EXPONENT for RSA public
keys), I meant search by values of some of them.
How do you plan to generate the CKA_ID? IIRC it needs to be unique per
token and since this will be rather dynamically available. I think it's
just a set of bytes so maybe a UUID is adequate.
That's a possibility. OpenDNSSEC puts 16 random bytes in CKA_ID.
I think you're on the right path defining these as discrete attributes.
IMHO it will be worth submitting this as an RFC once the schema design
is complete. So I wonder if the 'ipa' string should be dropped from the
proposed schema. I guess that would also require specifying the other
CKA values for other key types (e.g. DSA and DH).
In the schema ipaPkcs11prim1 is missing an 'e' I think and the comment
should be CKA_PRIME_1.
rob
--
Jan Cholasta
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
