On 17.7.2014 10:30, Jan Cholasta wrote:
On 16.7.2014 17:13, Petr Spacek wrote:
On 24.6.2014 08:43, Jan Cholasta wrote:
On 20.6.2014 20:23, Simo Sorce wrote:
On Fri, 2014-06-20 at 20:04 +0200, Petr Spacek wrote:
ipk11Private;privatekey: TRUE
ipk11Private;publickey: FALSE

can these two ever hold a different value ?
ie a privatekey be FALSE and a publickey be TRUE ?

If not I suggest you do not add this attribute at all and assume their
value ?

+1, we can use default values for most, if not all of the boolean flag
attributes. Personally, I would try to avoid using ipk11 attributes
until the
PKCS#11 module is designed/implemented.

I hope that this will not create headache in future...

Anyway, I have taken default values used by OpenDNSSEC v1 and modified
them a little bit to accommodate our requirements.

I'm using [1] as reference.

Public keys
===========
CKA_CLASS    CKO_PUBLIC_KEY
CKA_COPYABLE    TRUE
CKA_DERIVE    FALSE
CKA_ENCRYPT    FALSE
CKA_LOCAL    TRUE
CKA_MODIFIABLE    TRUE
CKA_PRIVATE    TRUE
CKA_TRUSTED    FALSE
CKA_VERIFY    TRUE
CKA_VERIFY_RECOVER    TRUE
CKA_WRAP    FALSE


Private keys
============
CKA_CLASS    CKO_PRIVATE_KEY
CKA_ALWAYS_AUTHENTICATE    FALSE
CKA_ALWAYS_SENSITIVE    TRUE
CKA_COPYABLE    TRUE
CKA_DECRYPT    FALSE
CKA_DERIVE    FALSE
CKA_EXTRACTABLE    TRUE # changed by pspacek
CKA_LOCAL    TRUE
CKA_MODIFIABLE    TRUE
CKA_NEVER_EXTRACTABLE    TRUE
CKA_PRIVATE    TRUE
CKA_SENSITIVE    TRUE
CKA_SIGN    TRUE
CKA_SIGN_RECOVER    TRUE
CKA_UNWRAP    FALSE
CKA_WRAP_WITH_TRUSTED    FALSE

If you want the keys to be extractable, you also need to set CKA_SENSITIVE
(and CKA_ALWAYS_SENSITIVE) to CK_FALSE.


We can use this set for all DNSSEC key pair objects. Replica keys will
require small change, i.e. to change SIGN/VERIFY attributes to FALSE and
WRAP/UNWRAP attributes to TRUE.

Replica private keys should not be extractable, i.e. should have
CKA_EXTRACTABLE = CK_FALSE and CKA_SENSITIVE = CK_TRUE.


OpenDNSSEC itself doesn't create any secret keys so we have to invent
own defaults. I propose to use following values:

Secret keys
===========
CKA_CLASS    CKO_SECRET_KEY
CKA_COPYABLE    TRUE
CKA_DECRYPT    FALSE
CKA_DERIVE    FALSE
CKA_ENCRYPT    FALSE
CKA_EXTRACTABLE    TRUE
CKA_MODIFIABLE    TRUE
CKA_PRIVATE    TRUE
CKA_SENSITIVE    FALSE
CKA_SIGN    FALSE
CKA_UNWRAP    TRUE
CKA_VERIFY    FALSE
CKA_WRAP    TRUE
CKA_WRAP_WITH_TRUSTED    FALSE

When master key is rotated, CKA_WRAP on the old key should be set to CK_FALSE,
so that new DNSSEC keys can't be wrapped with it.



(btw I forgot what's the point of that attribute)

When it is true, a user may not access the object until the user has been
authenticated to the token (what PKCS#11 spec says).

In practice it means that SoftHSM encrypts values of "PRIVATE" objects
before storing them to file system.

[1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf


BTW I have noticed at
<https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm>
that public key of each replica is stored in a ipk11 entry under cn=DNS. IMO
it should be enough to store just the public key blob in ipaPublicKey
attribute in cn=DNS itself.

I have updated design page and diagrams:
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm#LDAPschema

--
Petr^2 Spacek

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to