<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 02/25/2014 05:12 PM, Simo Sorce
wrote:<br>
</div>
<blockquote
cite="mid:1393344759.18299.45.camel@willson.li.ssimo.org"
type="cite">
<pre wrap="">On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 25.2.2014 16:11, Simo Sorce wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 25.2.2014 15:11, Simo Sorce wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Any reason why we should follow in detail what softshm does ?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Does OpenDNSSEC store them as separate entities and need access to them
independently ?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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 ?
</pre>
</blockquote>
<pre wrap="">
Private+public keys stored in files:
<a class="moz-txt-link-freetext" href="https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html">https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html</a>
Private keys stored in HSM and public keys in files:
<a class="moz-txt-link-freetext" href="https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html">https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html</a>
(I.e. some values in .private file are replaced by PKCS#11 label.)
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
See "How applications interact with PKCS#11" at
<a class="moz-txt-link-rfc2396E" href="http://www.freeipa.org/page/V3/PKCS11_in_LDAP"><http://www.freeipa.org/page/V3/PKCS11_in_LDAP></a>. 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.
</pre>
</blockquote>
<pre wrap="">
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 ?
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.</pre>
</blockquote>
I'm a newcomer to this area and am orienting myself at this doc:
<a class="moz-txt-link-freetext" href="ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf">ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf</a><br>
and looking into opendnssec andsofthsm code.<br>
<br>
It explains CKA_SIGN as:<br>
<div dir="ltr" style="font-size: 12.3333px; font-family: serif;
left: 92.5px; top: 664.52px; transform: scale(0.814712, 1);
transform-origin: 0% 0% 0px;" data-font-name="Times"
data-canvas-width="233.007512011528"><big>"The<span
class="highlight selected"> CKA_SIGN</span> attribute of the
signature key, whic h indicates whether the key supports
signatures with appendix, must be CK_TRUE."<br>
I cannot tell if this will be needed, just can make up an
attribute and allow it in an objectclass :-)<br>
<br>
But I think Jan's doc is a good start where he explains which
attributes will be used by specific modules eg for searches. <br>
</big></div>
<br>
<blockquote
cite="mid:1393344759.18299.45.camel@willson.li.ssimo.org"
type="cite">
<pre wrap="">
Thanks,
Simo.
</pre>
</blockquote>
<br>
</body>
</html>