[Freeipa-devel] LDAP schema for DNSSEC keys

[Petr Spacek]

On 1.8.2014 15:34, Simo Sorce wrote:
> On Fri, 2014-08-01 at 14:31 +0200, Jan Cholasta wrote:
>> >Dne 1.8.2014 v 13:54 Simo Sorce napsal(a):
>>> > >I have a questions about algorithms agility though, are we tied to use
>>> > >AES128 and RSA2048 ? Or do we have the means to specify and use
>>> > >alternative algorithms should it be necessary ?
>>> > >(Like EC instead of RSA ?)
>> >
>> >The schema allows different key types and wrapping algorithms to be used
>> >in the future.
To be more specific:

Keys are stored in LDAP in formats described on:
http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema#Encoded_key_data

I.e. algorithm OID, (optional) algorithm parameters and key data are stored as 
DER-encoded SubjectPublicKeyInfo / DER-encoded EncryptedPrivateKeyInfo / 
DER-encoded IPAEncryptedSecretKeyInfo blobs.

Our proprietary "IPAEncryptedSecretKeyInfo" structure is going to be the same 
thing as EncryptedPrivateKeyInfo, just the algorithm OID will specify some 
symmetric algorithm.

At the moment, there is no configuration in LDAP which says which algorithm 
and parameters to use for wrapping/creating blobs. We are going to hard code 
this for now into IPA daemons/tools. The implicit assumption here is that 
later versions of IPA will add configuration attributes as necessary.

The point is that decryption should 'just work' because all the metadata are 
in LDAP so even old replicas will know which algorithms and parameters to use 
for key unwrapping. (This assumes that new algorithms are supported by 
libraries etc.)

> Excellent
>
>>> > >
>>> > >Also would you know where I can find details on how
>>> > >CKM_AES_KEY_WRAP[_PAD] is actually implemented ?
>> >
>> >CKM_AES_KEY_WRAP uses the algorithm specified in RFC 3394,
>> >CKM_AES_KEY_WRAP_PAD uses the algorithm described in RFC 5649.

I have written RFC 5649 implementation for OpenSSL. You can see the code on
https://github.com/openssl/openssl/commit/d31fed73e25391cd71a0de488d88724db78f6f8a

More eyes on this code are more than welcome! :-)

>> >We don't
>> >use CKM_AES_KEY_WRAP ATM.

I have to say that pure RFC 3394 is unusable for us. It works only on inputs 
with (length % 8) == 0.

-- 
Petr^2 Spacek