On 02/24/2014 08:20 PM, Simo Sorce wrote:
On Mon, 2014-02-24 at 13:11 +0100, Ludwig Krispenz wrote:
Hi,
here is a draft to start discussion. Lt me know if it is the right
direction and what you're missing.
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema
I think we need to think hard if you really can make all those
attributes a MUST for the private key, as not all the attributes
seem to
apply to all encryption algorithms. Would have to have to add bogus
attributes in some cases.
most of them are MAY, right now I have only" ipaPkcs11keyType
ipaPkcs11label
ipaPkcs11id" as MUST, but this can be argued. I looke what softhsm is
doing
when importing a keypair:
|softhsm --import key1.pem --slot 1 --label "My key" --id A1B2 --pin
123456
so I thought ID and LABEL woul be something provided from the
application and
should be there to describe the key. When storing the key (which is
in pkcs#8
format) softhsm breaks up the data from the file and creates two pkcs#11
attribute templates:
CK_ATTRIBUTE pubTemplate[] = {
{ CKA_CLASS, &pubClass, sizeof(pubClass) },
{ CKA_KEY_TYPE, &keyType, sizeof(keyType) },
{ CKA_LABEL, label, strlen(label) },
{ CKA_ID, objID, objIDLen },
{ CKA_TOKEN, &ckTrue, sizeof(ckTrue) },
{ CKA_VERIFY, &ckTrue, sizeof(ckTrue) },
{ CKA_ENCRYPT, &ckFalse, sizeof(ckFalse) },
{ CKA_WRAP, &ckFalse, sizeof(ckFalse) },
{ CKA_PUBLIC_EXPONENT, keyMat->bigE, keyMat->sizeE },
{ CKA_MODULUS, keyMat->bigN, keyMat->sizeN }
};
CK_ATTRIBUTE privTemplate[] = {
{ CKA_CLASS, &privClass, sizeof(privClass) },
{ CKA_KEY_TYPE, &keyType, sizeof(keyType) },
{ CKA_LABEL, label, strlen(label) },
{ CKA_ID, objID, objIDLen },
{ CKA_SIGN, &ckTrue, sizeof(ckTrue) },
{ CKA_DECRYPT, &ckFalse, sizeof(ckFalse) },
{ CKA_UNWRAP, &ckFalse, sizeof(ckFalse) },
{ CKA_SENSITIVE, &ckTrue, sizeof(ckTrue) },
{ CKA_TOKEN, &ckTrue, sizeof(ckTrue) },
{ CKA_PRIVATE, &ckTrue, sizeof(ckTrue) },
{ CKA_EXTRACTABLE, &ckFalse, sizeof(ckFalse) },
{ CKA_PUBLIC_EXPONENT, keyMat->bigE, keyMat->sizeE },
{ CKA_MODULUS, keyMat->bigN, keyMat->sizeN },
{ CKA_PRIVATE_EXPONENT, keyMat->bigD, keyMat->sizeD },
{ CKA_PRIME_1, keyMat->bigP, keyMat->sizeP },
{ CKA_PRIME_2, keyMat->bigQ, keyMat->sizeQ },
{ CKA_EXPONENT_1, keyMat->bigDMP1, keyMat->sizeDMP1 },
{ CKA_EXPONENT_2, keyMat->bigDMQ1, keyMat->sizeDMQ1 },
{ CKA_COEFFICIENT, keyMat->bigIQMP, keyMat->sizeIQMP }
};
I thought that CLASS would be translated to an LDAP objectclass, |
|CKA_KEY_TYPE,||CKA_LABEL and CKA_ID would be provided (or default to
rsa)|.
For the the private key itself it could be either stored completely as
ipaPkcs8privateKey or as individual key attributes:
ipaPkcs11publicExponent,
ipaPkcs11modulus, ipaPkcs11privateExponent, ipaPkcs11prim1,
ipaPkcs11prim2
I did ignore CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE as only
defaults
were used, but maybe this is my ignorance.
And|CKA_EXPONENT_1,||CKA_EXPONENT_2, CKA_COEFICIENT as they seemed
redundant
to me, calculated from other components.
If we need any of the attributes I omitted or if we need other
attributes for
other keytypes let me know.
|
ipaPkcs8privateKey
Also can you add some examples on how we would use these classes to
store DNS keys ?
in what format do you provide the dns key ? The public key could be
stored
using modulus and exponent, do we need the flags, protocol adn algorithm
attribute ? Does a schema for DNS records already exist ?
