<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 02/27/2014 03:56 PM, Jan Cholasta
wrote:<br>
</div>
<blockquote cite="mid:530F5201.10303@redhat.com" type="cite">On
27.2.2014 15:23, Ludwig Krispenz wrote:
<br>
<blockquote type="cite">
<br>
On 02/27/2014 02:14 PM, Jan Cholasta wrote:
<br>
<blockquote type="cite">On 18.2.2014 17:19, Martin Kosek wrote:
<br>
<blockquote type="cite">On 02/18/2014 04:38 PM, Jan Cholasta
wrote:
<br>
<blockquote type="cite">On 18.2.2014 16:35, Petr Spacek
wrote:
<br>
<blockquote type="cite">On 18.2.2014 16:31, Jan Cholasta
wrote:
<br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<br>
2] low level replacement for eg the sqlite3
database in softhsm.
<br>
That's what I sometimes get the impression what
is wanted.
<br>
SoftHsm has
<br>
one component Softdatabase with an API, which
more or less
<br>
passes sets
<br>
of attributes (attributes defined by PKCS#11)
and then stores
<br>
it as
<br>
records in sql where each record has a keytype
and opaque blob of
<br>
data.
<br>
If that is what is wanted the decision would be
how fingrained the
<br>
pkcs
<br>
objects/attribute types would have to be mapped
to ldap: one ldap
<br>
attribute for each possible attribute type ?
<br>
</blockquote>
<br>
One-to-one mapping of attributes from PKCS#11 to
LDAP would be
<br>
the most
<br>
straightforward way of doing this, but I think we
can do some
<br>
optimization for our needs. For example, like you
said above, we
<br>
can
<br>
use
<br>
a single attribute containing PKCS#8 encoded
private key rather
<br>
than
<br>
using one attribute per private key component.
<br>
<br>
I don't think we need an LDAP attribute for every
possible PKCS#11
<br>
attribute, ATM it would be sufficient to have just
these attributes
<br>
necessary to represent private key, public key and
certificate
<br>
objects.
<br>
<br>
So, I would say it should be something between
high-level and
<br>
low-level.
<br>
</blockquote>
<br>
There won't be a separate public key, it's
represented by the
<br>
certificate.
<br>
</blockquote>
<br>
I'm not sure if this is the case for DNSSEC.
<br>
</blockquote>
<br>
Honzo,
<br>
<br>
we really need the design page with some goal statement,
high-level
<br>
overview etc. There is still some confusion, probably
from fact
<br>
that we
<br>
want to use the same module for cert distribution and at
the same time
<br>
for DNSSEC key storage.
<br>
<br>
</blockquote>
<br>
It's on my TODO list, I'll try to get it out ASAP.
<br>
<br>
</blockquote>
<br>
+1, please do. We clearly need some design to start with.
<br>
<br>
Martin
<br>
<br>
</blockquote>
<br>
I already posted the link in other thread, but here it is
anyway:
<br>
<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>.
<br>
<br>
Some more comments on the schema:
<br>
<br>
I think I may have been too quick to dismiss RFC 4523. There
is
<br>
CKA_CERTIFICATE_CATEGORY which can have values "unspecified",
"token
<br>
user", "authority" and "other entity". We could map entries
with
<br>
object class pkiUser to certificate object with
<br>
CKA_CERTIFICATE_CATEGORY "token user" and entries with object
class
<br>
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY
"authority".
<br>
There are no object classes in RFC 4523 for "unspecified" and
"other
<br>
entity", but we will not be storing any certificates using
PKCS#11
<br>
anyway, so I think it's OK.
<br>
</blockquote>
not sure I understand what exactly you want here. If we don't
store
<br>
certificates using the pkcs#11 schema we don't need to define
them, but
<br>
on the other hand you talk about the usage of
CKA_CERTIFICATE_CATEGORY.
<br>
Do you mean to have a pkcs11 cerificate object with
<br>
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
<br>
userCertificate and cACertificate to store them ?
<br>
</blockquote>
<br>
Hopefully an example will better illustrate what I mean. We could
map PKCS#11 objects like this:
<br>
<br>
CKA_CLASS: CKO_CERTIFICATE
<br>
CKA_CERTIFICATE_TYPE: CKC_X_509
<br>
CKA_CERTIFICATE_CATEGORY: 1
<br>
CKA_VALUE: <cert>
<br>
<other attrs>
<br>
<br>
to LDAP entries like this:
<br>
<br>
dn: pkcs11uniqueId=<id>,<suffix>
<br>
objectClass: pkcs11storageObject
<br>
objectClass: pkiUser
<br>
pkcs11uniqueId: <id>
<br>
userCertificate;binary: <cert>
<br>
<other attrs>
<br>
<br>
and PKCS#11 object like this:
<br>
<br>
CKA_CLASS: CKO_CERTIFICATE
<br>
CKA_CERTIFICATE_TYPE: CKC_X_509
<br>
CKA_CERTIFICATE_CATEGORY: 2
<br>
CKA_VALUE: <cert>
<br>
<other attrs>
<br>
<br>
to LDAP entries like this:
<br>
<br>
dn: pkcs11uniqueId=<id>,<suffix>
<br>
objectClass: pkcs11storageObject
<br>
objectClass: pkiCA
<br>
pkcs11uniqueId: <id>
<br>
caCertificate;binary: <cert>
<br>
<other attrs>
<br>
<br>
In other words, the value of CKA_CERTIFICATE_CATEGORY is implied
from objectClass, "CKA_CERTIFICATE_CATEGORY: 1" <=>
"objectClass: pkiUser" and "CKA_CERTIFICATE_CATEGORY: 2" <=>
"objectClass: pkiCA".
<br>
</blockquote>
so you want to directly use the pkiUser|CA objectclass, that would
be ok<br>
<blockquote cite="mid:530F5201.10303@redhat.com" type="cite">
<br>
<blockquote type="cite">
<blockquote type="cite">
<br>
Also the above got me thinking, is there any "standard" LDAP
schema
<br>
for private keys? If so, can we use it?
<br>
</blockquote>
I didn't find any, the only keys in ldap I found is a definition
for
<br>
sshPublicKey for openssh.
<br>
</blockquote>
<br>
And even this schema is for public keys only :-) OK, nevermind
then.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">
<br>
I'm going to store NSS trust objects along with CA
certificates, so
<br>
I'm going to need an object class for that. You can find the
details
<br>
on CKO_NSS_TRUST at
<br>
<a class="moz-txt-link-rfc2396E" href="http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html"><http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html></a>.
<br>
</blockquote>
</blockquote>
</blockquote>
so this is a nss extension to pkcs11, not in the standard ? If we
add trust objects, should the naming reflect this like
pkcs11nss<attr> or pkcs11ext<attr> ?<br>
<blockquote cite="mid:530F5201.10303@redhat.com" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<br>
<br>
If we store multiple related PKCS#11 objects in a single LDAP
entry,
<br>
there is going to be some redundancy. For example, public key
value
<br>
can be extracted from private key value, so we don't need to
store
<br>
both of the values. This can be bypassed by having separate
object
<br>
classes for data and for metadata. For a key pair entry, the
object
<br>
classes would be e.g. privateKey, pkcs11privateKey and
<br>
pkcs11publicKey, where privateKey is an object class with
private key
<br>
data (without any PKCS#11 bits), pkcs11privateKey is an object
class
<br>
with PKCS#11 private key metadata and pkcs11publicKey is an
object
<br>
class with PKCS#11 public key metadata. In the PKCS#11 module,
this
<br>
entry would be visible as two separate objects (private key
object and
<br>
public key object).
<br>
</blockquote>
I have not yet rewritten the objectcalss definition after the
latest
<br>
discussion, but I think if we have one structural objectclass
<br>
pkcs11storageObject with only a uniqueid and auxiliary
objectclasses for
<br>
publickey,privatekey, certificate where the attributes (maybe
<br>
withexception of label, id) are optional there will be no
redundancy,
<br>
store only what is needed.
<br>
you could use these aux objectclass also in other entries
instead of
<br>
using pkcs11storageObject.
<br>
</blockquote>
<br>
OK, great. BTW, CKA_LABEL and CKA_ID are both optional in PKCS#11,
so I think they should be optional in LDAP as well.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">
<br>
Regarding PKCS#11 metadata attributes (i.e. excluding
certificate,
<br>
private key and public key value attributes), I think they all
should
<br>
be single-valued. Comments on specific attributes:
<br>
<br>
* CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER,
CKA_SERIAL_NUMBER,
<br>
CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL,
<br>
CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS,
CKA_VERIFY_RECOVER,
<br>
CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE,
<br>
CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should
be LDAP
<br>
attributes for these, for the sake of completeness
<br>
</blockquote>
in progress
<br>
<blockquote type="cite">
<br>
* CKA_TOKEN - this is CK_TRUE for persistent objects and
objects in
<br>
LDAP are always persistent, so there is no need for
pkcs11token
<br>
</blockquote>
ok
<br>
<blockquote type="cite">
<br>
* CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no
need for
<br>
pkcs11certificateType
<br>
</blockquote>
ok
<br>
<blockquote type="cite">
<br>
* CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523
object
<br>
classes (see above), we don't need an LDAP attribute for it
<br>
</blockquote>
see above, where do you want to define the mapping. Do we then
need
<br>
cert attrs at all ?
<br>
</blockquote>
<br>
If we use userCertificate and cACertificate, we don't need
pkcs11certificateValue, if that's what you are asking.
<br>
</blockquote>
I was asking if we need the pkcs11certificate objectclass and the
certificate metadata since you were using the pkiUser and pkiCA
objectclasses to store the cert, but you probably want the
startdate, enddate and other attrs at least available<br>
<blockquote cite="mid:530F5201.10303@redhat.com" type="cite">
<br>
<blockquote type="cite">
<blockquote type="cite">
<br>
* CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY,
<br>
CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly
from
<br>
certificate value, no need for LDAP attributes
<br>
</blockquote>
ok
<br>
<blockquote type="cite">
<br>
* CKA_URL - do we want to support certificates with URL
instead of
<br>
value?
<br>
</blockquote>
don't know, there are just some other attrs required when a URL
is used
<br>
</blockquote>
<br>
If you mean CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY, they are not
required AFAIK, it's just that URL-only certificates do not make
much sense without them.
<br>
<br>
</blockquote>
yes, It says:CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY Can only be
empty if <a class="el"
href="http://www.cryptsoft.com/pkcs11doc/v220/pkcs11__all_8h.html#aCKA_URL">CKA_URL</a>
is empty.<br>
<br>
</body>
</html>