On 02/27/2014 01:10 PM, Petr Spacek wrote:
On 27.2.2014 17:55, Ludwig Krispenz wrote:
On 02/27/2014 05:46 PM, Rich Megginson wrote:
On 02/27/2014 09:37 AM, Petr Spacek wrote:
On 27.2.2014 17:24, Ludwig Krispenz wrote:
On 02/27/2014 03:56 PM, Jan Cholasta wrote:
On 27.2.2014 15:23, Ludwig Krispenz wrote:
On 02/27/2014 02:14 PM, Jan Cholasta wrote:
On 18.2.2014 17:19, Martin Kosek wrote:
On 02/18/2014 04:38 PM, Jan Cholasta wrote:
On 18.2.2014 16:35, Petr Spacek wrote:
On 18.2.2014 16:31, Jan Cholasta wrote:
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.
There won't be a separate public key, it's represented by the
certificate.
I'm not sure if this is the case for DNSSEC.
Honzo,
we really need the design page with some goal statement,
high-level
overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the
same time
for DNSSEC key storage.
It's on my TODO list, I'll try to get it out ASAP.
+1, please do. We clearly need some design to start with.
Martin
I already posted the link in other thread, but here it is anyway:
<http://www.freeipa.org/page/V3/PKCS11_in_LDAP>.
Some more comments on the schema:
I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values "unspecified",
"token
user", "authority" and "other entity". We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY "token user" and entries with object
class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY
"authority".
There are no object classes in RFC 4523 for "unspecified" and
"other
entity", but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.
not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define
them, but
on the other hand you talk about the usage of
CKA_CERTIFICATE_CATEGORY.
Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?
Hopefully an example will better illustrate what I mean. We could
map
PKCS#11 objects like this:
CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: <cert>
<other attrs>
to LDAP entries like this:
dn: pkcs11uniqueId=<id>,<suffix>
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: <id>
userCertificate;binary: <cert>
<other attrs>
and PKCS#11 object like this:
CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: <cert>
<other attrs>
to LDAP entries like this:
dn: pkcs11uniqueId=<id>,<suffix>
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: <id>
caCertificate;binary: <cert>
<other attrs>
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".
so you want to directly use the pkiUser|CA objectclass, that would
be ok
Also the above got me thinking, is there any "standard" LDAP
schema
for private keys? If so, can we use it?
I didn't find any, the only keys in ldap I found is a definition
for
sshPublicKey for openssh.
And even this schema is for public keys only :-) OK, nevermind then.
I'm going to store NSS trust objects along with CA
certificates, so
I'm going to need an object class for that. You can find the
details
on CKO_NSS_TRUST at
<http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html>.
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> ?
If we store multiple related PKCS#11 objects in a single LDAP
entry,
there is going to be some redundancy. For example, public key
value
can be extracted from private key value, so we don't need to store
both of the values. This can be bypassed by having separate object
classes for data and for metadata. For a key pair entry, the
object
classes would be e.g. privateKey, pkcs11privateKey and
pkcs11publicKey, where privateKey is an object class with
private key
data (without any PKCS#11 bits), pkcs11privateKey is an object
class
with PKCS#11 private key metadata and pkcs11publicKey is an object
class with PKCS#11 public key metadata. In the PKCS#11 module,
this
entry would be visible as two separate objects (private key
object and
public key object).
I have not yet rewritten the objectcalss definition after the
latest
discussion, but I think if we have one structural objectclass
pkcs11storageObject with only a uniqueid and auxiliary
objectclasses for
publickey,privatekey, certificate where the attributes (maybe
withexception of label, id) are optional there will be no
redundancy,
store only what is needed.
you could use these aux objectclass also in other entries
instead of
using pkcs11storageObject.
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.
Regarding PKCS#11 metadata attributes (i.e. excluding certificate,
private key and public key value attributes), I think they all
should
be single-valued. Comments on specific attributes:
* CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER,
CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL,
CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER,
CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE,
CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should
be LDAP
attributes for these, for the sake of completeness
in progress
* CKA_TOKEN - this is CK_TRUE for persistent objects and
objects in
LDAP are always persistent, so there is no need for pkcs11token
ok
* CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no
need for
pkcs11certificateType
ok
* CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523
object
classes (see above), we don't need an LDAP attribute for it
see above, where do you want to define the mapping. Do we then need
cert attrs at all ?
If we use userCertificate and cACertificate, we don't need
pkcs11certificateValue, if that's what you are asking.
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
* CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY,
CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from
certificate value, no need for LDAP attributes
ok
* CKA_URL - do we want to support certificates with URL
instead of
value?
don't know, there are just some other attrs required when a URL
is used
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.
yes, It says:CKA_HASH_OF_{SUBJECT,ISSUER}_PUBLIC_KEY Can only be
empty if
CKA_URL
<http://www.cryptsoft.com/pkcs11doc/v220/pkcs11__all_8h.html#aCKA_URL>
is empty.
I have a note about naming attribute:
- I don't like nsUniqId here because you can't read it in LDAP
browser by
naked eye
- I propose to use
-- dn: CKA_CLASS=...+CKA_LABEL=...
-- dn: CKA_CLASS=...+CKA_ID=...
One of them should be present almost always and the writing 'entity'
(effectively PKCS#11 module generating a new key or storing a new
certificate) can fall back to uniqueId if there is neither LABEL
nor ID.
Honza told me that PKCS#11 module/user have to always do a LDAP
search so
this change should be 'cosmetic'.
We are not LDAP experts. Ludwig, what do you think about compound
names?
Are they okay for general use?
They are problematic. I would prefer to avoid having
multi-component RDNs.
agreed, they are not very common. You can make any allowed attribute the
naming attribute, so you have the choice eg "dn: pkcs11label=.....,
". It
should be some attr available in all the objects. You can also use the
suggested attribute pkcs11uniqueid and do not use the ipaUniqueid
strings, but
soemthing readable.
We can als define an other attr which does not sound like uniqueid eg
pkcs11object[id|name|..]
Okay. I have talked again with Honza about that and the current schema
proposal combines public and private keys to one object so collision
on LABEL or ID-level should not happen.
Is it okay to mix objects with DNs like:
pkcs11label=...
pkcs11id=...
pkcs11uniqid=...
in one sub-tree? (Assuming that our client can handle that.)
That's fine.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel