On 25.2.2014 20:22, Simo Sorce wrote:
On Tue, 2014-02-25 at 13:22 -0500, Rob Crittenden wrote:
Jan Cholasta wrote:
On 25.2.2014 17:36, Ludwig Krispenz wrote:
On 02/25/2014 05:12 PM, Simo Sorce wrote:
On Tue, 2014-02-25 at 16:18 +0100, 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.
Ah sorry, I hadn't looked at that one yet.
It helps quite a bit.
So are the class, key_type, id, label, token, 'sign' the only values we
should really care to split off ?
They are all metadata related to PKCS#11 operation. I don't think you
can easily encode them in PKCS#8 or certificate blob, so they actually
need to be split off. You can find the full list of them in the PKCS#11
spec (link below).
Can you describe what are these values ?
What is class ? Why is it important, and how does it differ from
key_type ?
What is the token ? What is 'sign' ?
Feel free to give references to specific documents to read up about
these attributes.
I'm a newcomer to this area and am orienting myself at this doc:
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf
and looking into opendnssec andsofthsm code.
I use mainly
<ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf>, as
2.30 is a draft ATM.
It explains CKA_SIGN as:
"TheCKA_SIGN attribute of the signature key, whic h indicates whether
the key supports signatures with appendix, must be CK_TRUE."
I cannot tell if this will be needed, just can make up an attribute and
allow it in an objectclass :-)
OpenDNSSEC puts it in public key objects it generates, so it's needed at
least for the sake of it.
Actually, I think we should support all of the metadata attributes, so
that our PKCS#11 module is reasonably generic and not tailored to needs
of a specific consumer.
We could hardcode some of these values but it will very likely cause
problems later. It seems simple enough to just define schema for all of
them and store them, except perhaps in the cases where they are easily
derived. If we, for example, store the prime numbers and exponents, they
need to be protected as carefully as the private key.
This is something I meant to discuss too, how do we protect them ?
Clearly we have ACIs but I am wondering if we want to encrypt them with
keys not immediately or easily available via LDAP ?
It's kind of catastrofic if they get inadvertently exposed like if
someone does a ldapsearch as "Directory Manager", which is one of the
reasons why we encrypt kerberos key material before storing it into the
db.
PKCS#8 allows encryption, I guess we can use that. There needs to be
some metadata on how to decrypt the blob though, so that the PKCS#11
module can actually decrypt it when necessary.
Simo.
--
Jan Cholasta
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
