[Freeipa-devel] DNSSEC design page

[Simo Sorce]

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