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/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:
Any reason why we should follow in detail what softshm does ? > 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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel