[Freeipa-devel] DNSSEC design page

Tue Feb 25 12:58:08 UTC 2014

On 25.2.2014 13:49, Ludwig Krispenz wrote:
>
> 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'm sorry for not being clear. I don't insist on splitting it to multiple 
attributes as long as we are able to reconstruct BIND key files.

"This is just one long string stored in normal idnsZone object." was meant as 
"we can re-use DNSKEY records as currently defined".

Petr^2 Spacek

> 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.