[Freeipa-devel] DNSSEC design page

[Ludwig Krispenz]

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 ?
>
> Ideally the example would show the LDAP tree and some example data in
> detail, and also what operation we think would be common.
>
> Simo.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140225/2fcfd091/attachment.htm>