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.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
