[Freeipa-devel] DNSSEC design page

Tue Feb 25 12:49:58 UTC 2014

On 02/25/2014 01:30 PM, Petr Spacek wrote:
> On 25.2.2014 11:28, 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:
>>
>>
>>   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 ?
>
> I would store DNSSEC-specific attributes in separate objectClass not 
> to pollute pure PKCS#11 object classes.
>
> We have to be able to reproduce BIND key-files in the first 
> implementation phase. I'm attaching public-private key pairs with 
> different algorithms and flags to this e-mail.
>
> .key files contain DNSKEY record. It is basically public key, 
> algorithm and flags as used by DNS clients. This is just one long 
> string stored in normal idnsZone object.
>
> DNSKEY format is described on 
> http://tools.ietf.org/html/rfc4034#section-2.3
but you already have a KeyRecord defined in ".../schema/60ipadns.ldif" 
which refers to RFC2535, which is obsoleted by 4034, the one you 
reference. Do you wan to split this up into several attributes in a new 
objectclass (why)?

I will look at the examples, thanks.
>
>
>
> .private files contain private keys and metadata for BIND, stored as 
> key-value pairs.
>
> Some values can be derived from standard PKCS#11 attributes, some 
> other have to be stored explicitly.
>
> For example (file Kdsa-ksk.+006+51642.private):
> > Private-key-format: v1.3
> > Algorithm: 6 (NSEC3DSA)
> - We need to check if this can be derived from PKCS#11 type or not. 
> (It could contain some DNSSEC-specific values.)
> - See 
> http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1
>
> > Prime(p): 
> 6h4K2APYLBWTOFgoo9b2aMpCNz9QfhYMh1fUnipZFdCt3TsBy2mYueC8iVrqC35EUCCU/SbKkZv2SfVjpwJRc37bmSNhsGt6tFCqHAvuMO/KD43erLebvTuQc58zmkswLqDM1+Rx6sCtk1Dse6xdRrWAi1CXhpQfyHD
> > Subprime(q): tzQKBcEOLQT5/R7WzaMij86hwEM=
> > Base(g): 
> uHVjFBrRFijLHFUWP+1aWZA1kiq85Wrn+npPu39F4P9VOIyasJaxSEncw7F0T1b2h+ADZ3/Ny1aQPBeJJ4o5NuTNUb92tifjr6peP8UZWG3NHoyU+RZJkoHIjaMiTHaPwBJItRQdEg+3nSCjmCEDNaFhUwwfG+yJ1FZJ
> > Private_value(x): avcS6O/s60qa4TZ8m5dlHvyiSQI=
> > Public_value(y): 
> 5cb5cH2hLkIrLGO9xCv4fgWYOTN+txiVD4hRILTJHG8GXhadIPuKmvuvyc6ynnPIn8XgZnrpVqCJXteMoPk0ERQh1wmSoxPqks9pyKJlnIGADW8zH5uEueBT53lx6I2WkNXU+BK0/A7psVPpqo51iX1s0h5f
> - All this is algorithm-specific but we need to be able to extract 
> each field separately for BIND-keyfile generation
>
> There is also a bunch of DNSSEC-specific timestamps:
> > Created: 20140225113328
> > Publish: 20140327113328
> - When the key will be made visible for the first time.
> > Activate: 20140327113328
> - When the key will be used for signing the first time.
> - Probably can be mapped to PKCS#11 ??
> > Inactive: 20140426113328
> - From when the key will not be used for signing anymore.
> - Probably can be mapped to PKCS#11 ??
> > Revoke: 20140526113328
> > Delete: 20140625113328
>
> There is also some information coded in file name:
> - name of the DNS zone
> - key_id - some value computed from the DNSKEY record
> - key_alg - the same value as in .key and .private files
>
> I hope this clarifies requirements from DNSSEC-point of view.
>
> We need to find what is possible to derive from PKCS#11 attributes and 
> create auxiliary object class for remaining values.
>
> Petr^2 Spacek
>
>>> Ideally the example would show the LDAP tree and some example data in
>>> detail, and also what operation we think would be common.
>>>
>>> Simo.
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

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