On 02/25/2014 02:44 PM, Simo Sorce wrote:
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,On Tue, 2014-02-25 at 11:28 +0100, Ludwig Krispenz wrote: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/pkcs11SchemaI 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:Any reason why we should follow in detail what softshm does ?
so there is at least one requirement for fine grained attributes.
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. |I am unsure that splitting keys this way really is useful to us, in what case an LDAP client will ever need such details ? Wouldn't it make sense to keep a pkcs11 blob and only split out attributes we need to identify the key for our needs ?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 ?Well for example we store SSH keys in DNS, the whole key in one single attribute. I am not sure what is the point for us to split keys in parts, the only thing I see is a risk of messing up keys by inadvertently changing one of the attributes only and a burden to recompose keys every time they are queried.Ideally the example would show the LDAP tree and some example data in detail, and also what operation we think would be common. Simo.Simo.
_______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
