[Freeipa-devel] DNSSEC design page

[Ludwig Krispenz]

On 02/25/2014 02:44 PM, Simo Sorce wrote:
> 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 ?
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,
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.
>