subject:"Re\: \[Freeipa\-devel\] DNSSEC design page"


On 26.2.2014 16:00, Simo Sorce wrote:

need to be protected as carefully as the private key.

 
 This is something I meant to discuss too, how do we protect them ?
 Clearly we have ACIs but I am wondering if we want to encrypt them with
 keys not immediately or easily available via LDAP ?
 
 It's kind of catastrofic if they get inadvertently exposed like if
 someone does a ldapsearch as Directory Manager, which is one of the
 reasons why we encrypt kerberos key material before storing it into the
 db.


PKCS#8 allows encryption, I guess we can use that. There needs to be
some metadata on how to decrypt the blob though, so that the PKCS#11
module can actually decrypt it when necessary.

Yep, and we also need to decide what master key is used and where it is
placed, and who access it, and how:-)


Let's move the discussion forward, we need to implement the schema for 4.0.

Do I understand correctly that the whole purpose of
krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example
is just to encrypt keys with some other key which is located at some other 
place? I.e. the goal is to lower the probability that a random ldapsearch will 
return encrypted blob and master key at once, right?


What algorithm/method should we use for key wrapping? As far as I remember 
from my studies key wrapping is very sensitive thing and we definitely need to 
use some existing standardtool for doing it. Can we just call some NSS 
function with default/system-wide parameters and let it do it's job?


That would mean that, after all, we just need to provide some blob as key 
wrapping key :-) (Generated with care it deserves etc.)



We have had discussion with Honza and the first idea is to add attribute like 
'wrappingKeyId' to each encrypted blob and use it for locating appropriate key 
when necessary.
- During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) 
to find appropriate wrapping key.
- The harder part is how to pick a wrapping key for encryption. It can be 
tricky if the wrapped key is shared among more users (DNS servers) etc.
- It is possible to easily use multiple wrapping keys at once so key rollover 
is easy. You can re-encrypt keys one by one.



The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 
objects inside the same token will be encrypted with the same key.

- Decryption is easy - the same as in previous case.
- Encryption is basically the same as encryption.
- Key rollover is hard. You would have to re-encrypt all keys and change 
wrappingKeyId associated with given token at once - but it is impossible 
because we don't have LDAP transactions. As a result, clients will be confused 
during rollover. (Consider problems with syncrepl when clients can see changes 
immediately.)



The third approach is 'hybrid':
A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is 
used for encrypting new objects stored into PKCS#11 token. Each key stored in 
the token has own wrappingKeyId attribute and it is used for decryption.

- Decryption is easy - the same as in previous case.
- Encryption always use wrappingKeyId associated with given token.
- Key roll over can start from wrappingKeyId associated with the token and 
then re-encrypt keys in the token one by one. All keys can be decrypted in any 
step (assuming that changes in one LDAP object are atomic).



Where is a hole in this design? :-)

Where should we store wrapping keys for users/services and DNS servers? User 
object or cn=dns doesn't sound like a good idea because it would defeat the 
purpose.


--
Petr^2 Spacek

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

Re: [Freeipa-devel] DNSSEC design page: key wrapping

On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:
 On 26.2.2014 16:00, Simo Sorce wrote:
  need to be protected as carefully as the private key.
   
   This is something I meant to discuss too, how do we protect them ?
   Clearly we have ACIs but I am wondering if we want to encrypt them with
   keys not immediately or easily available via LDAP ?
   
   It's kind of catastrofic if they get inadvertently exposed like if
   someone does a ldapsearch as Directory Manager, which is one of the
   reasons why we encrypt kerberos key material before storing it into the
   db.
  
  PKCS#8 allows encryption, I guess we can use that. There needs to be
  some metadata on how to decrypt the blob though, so that the PKCS#11
  module can actually decrypt it when necessary.
  Yep, and we also need to decide what master key is used and where it is
  placed, and who access it, and how:-)
 
 Let's move the discussion forward, we need to implement the schema for 4.0.
 
 Do I understand correctly that the whole purpose of
 krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example
 is just to encrypt keys with some other key which is located at some other 
 place? I.e. the goal is to lower the probability that a random ldapsearch 
 will 
 return encrypted blob and master key at once, right?

Yes, it would also be nice if we could finally offload this key from
LDAP for added security, but we are not there yet.

 What algorithm/method should we use for key wrapping? As far as I remember 
 from my studies key wrapping is very sensitive thing and we definitely need 
 to 
 use some existing standardtool for doing it. Can we just call some NSS 
 function with default/system-wide parameters and let it do it's job?

I think that would be what we want to do in some form.

 That would mean that, after all, we just need to provide some blob as key 
 wrapping key :-) (Generated with care it deserves etc.)

The key must be self describing somehow (for algorithm agility).


 We have had discussion with Honza and the first idea is to add attribute like 
 'wrappingKeyId' to each encrypted blob and use it for locating appropriate 
 key 
 when necessary.
 - During decryption: Do a LDAP search with filter like 
 (keyId=wrappingKeyId) 
 to find appropriate wrapping key.
 - The harder part is how to pick a wrapping key for encryption. It can be 
 tricky if the wrapped key is shared among more users (DNS servers) etc.
 - It is possible to easily use multiple wrapping keys at once so key rollover 
 is easy. You can re-encrypt keys one by one.

This makes things complicated fast.
One thing I was thinking was to use a keytab and krb functions to do the
wrapping but that would be pretty IPA specific.

 The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 
 objects inside the same token will be encrypted with the same key.
 - Decryption is easy - the same as in previous case.
 - Encryption is basically the same as encryption.
 - Key rollover is hard. You would have to re-encrypt all keys and change 
 wrappingKeyId associated with given token at once - but it is impossible 
 because we don't have LDAP transactions. As a result, clients will be 
 confused 
 during rollover. (Consider problems with syncrepl when clients can see 
 changes 
 immediately.)

Yeah this is a problem we need to address.

 The third approach is 'hybrid':
 A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is 
 used for encrypting new objects stored into PKCS#11 token. Each key stored in 
 the token has own wrappingKeyId attribute and it is used for decryption.
 - Decryption is easy - the same as in previous case.
 - Encryption always use wrappingKeyId associated with given token.
 - Key roll over can start from wrappingKeyId associated with the token and 
 then re-encrypt keys in the token one by one. All keys can be decrypted in 
 any 
 step (assuming that changes in one LDAP object are atomic).
 
 
 Where is a hole in this design? :-)

I do not like the idea of having to add a wrappingKeyId everywhere.

My initial though was to have a central place where wrapping keys are
stored, and during a rollover period you try all the keys until one
works or decryption fails. At the end of rollover you delete the old key
so you avoid the additional load.

 Where should we store wrapping keys for users/services and DNS servers? User 
 object or cn=dns doesn't sound like a good idea because it would defeat the 
 purpose.

Indeed. And this is the biggest problem. It would be nice to have a
mechanism to securely transfer the key to the DNS servers w/o having to
store it permanently in LDAP. If we had this mechanism we'd be able to
apply it to the Kerberos master key too. But it can't be confined to
installation time only, which is easy, it needs to be possible to update
it at a later time, which is where we have issues, as our replication
mechanism is LDAP.

If we solve the DNA plugin issue with the ability to use groups for

Re: [Freeipa-devel] DNSSEC design page: key wrapping


On 03/04/2014 10:26 AM, Simo Sorce wrote:

On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:

On 26.2.2014 16:00, Simo Sorce wrote:

need to be protected as carefully as the private key.

This is something I meant to discuss too, how do we protect them ?
Clearly we have ACIs but I am wondering if we want to encrypt them with
keys not immediately or easily available via LDAP ?

It's kind of catastrofic if they get inadvertently exposed like if
someone does a ldapsearch as Directory Manager, which is one of the
reasons why we encrypt kerberos key material before storing it into the
db.

PKCS#8 allows encryption, I guess we can use that. There needs to be
some metadata on how to decrypt the blob though, so that the PKCS#11
module can actually decrypt it when necessary.

Yep, and we also need to decide what master key is used and where it is
placed, and who access it, and how:-)

Let's move the discussion forward, we need to implement the schema for 4.0.

Do I understand correctly that the whole purpose of
krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example
is just to encrypt keys with some other key which is located at some other
place? I.e. the goal is to lower the probability that a random ldapsearch will
return encrypted blob and master key at once, right?

Yes, it would also be nice if we could finally offload this key from
LDAP for added security, but we are not there yet.


What algorithm/method should we use for key wrapping? As far as I remember
from my studies key wrapping is very sensitive thing and we definitely need to
use some existing standardtool for doing it. Can we just call some NSS
function with default/system-wide parameters and let it do it's job?

I think that would be what we want to do in some form.


That would mean that, after all, we just need to provide some blob as key
wrapping key :-) (Generated with care it deserves etc.)

The key must be self describing somehow (for algorithm agility).



We have had discussion with Honza and the first idea is to add attribute like
'wrappingKeyId' to each encrypted blob and use it for locating appropriate key
when necessary.
- During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId)
to find appropriate wrapping key.
- The harder part is how to pick a wrapping key for encryption. It can be
tricky if the wrapped key is shared among more users (DNS servers) etc.
- It is possible to easily use multiple wrapping keys at once so key rollover
is easy. You can re-encrypt keys one by one.

This makes things complicated fast.
One thing I was thinking was to use a keytab and krb functions to do the
wrapping but that would be pretty IPA specific.


The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11
objects inside the same token will be encrypted with the same key.
- Decryption is easy - the same as in previous case.
- Encryption is basically the same as encryption.
- Key rollover is hard. You would have to re-encrypt all keys and change
wrappingKeyId associated with given token at once - but it is impossible
because we don't have LDAP transactions. As a result, clients will be confused
during rollover. (Consider problems with syncrepl when clients can see changes
immediately.)

Yeah this is a problem we need to address.


The third approach is 'hybrid':
A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is
used for encrypting new objects stored into PKCS#11 token. Each key stored in
the token has own wrappingKeyId attribute and it is used for decryption.
- Decryption is easy - the same as in previous case.
- Encryption always use wrappingKeyId associated with given token.
- Key roll over can start from wrappingKeyId associated with the token and
then re-encrypt keys in the token one by one. All keys can be decrypted in any
step (assuming that changes in one LDAP object are atomic).


Where is a hole in this design? :-)

I do not like the idea of having to add a wrappingKeyId everywhere.

My initial though was to have a central place where wrapping keys are
stored, and during a rollover period you try all the keys until one
works or decryption fails. At the end of rollover you delete the old key
so you avoid the additional load.


Where should we store wrapping keys for users/services and DNS servers? User
object or cn=dns doesn't sound like a good idea because it would defeat the
purpose.

Indeed. And this is the biggest problem. It would be nice to have a
mechanism to securely transfer the key to the DNS servers w/o having to
store it permanently in LDAP. If we had this mechanism we'd be able to
apply it to the Kerberos master key too. But it can't be confined to
installation time only, which is easy, it needs to be possible to update
it at a later time, which is where we have issues, as our replication
mechanism is LDAP.

If we solve the DNA plugin issue with the ability to use groups for
authentication I guess we could build a control/extend operation that

Re: [Freeipa-devel] DNSSEC design page: key wrapping


On 4.3.2014 17:00, Dmitri Pal wrote:

On 03/04/2014 10:26 AM, Simo Sorce wrote:

On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:

On 26.2.2014 16:00, Simo Sorce wrote:

need to be protected as carefully as the private key.

This is something I meant to discuss too, how do we protect them ?
Clearly we have ACIs but I am wondering if we want to encrypt them with
keys not immediately or easily available via LDAP ?

It's kind of catastrofic if they get inadvertently exposed like if
someone does a ldapsearch as Directory Manager, which is one of the
reasons why we encrypt kerberos key material before storing it into the
db.

PKCS#8 allows encryption, I guess we can use that. There needs to be
some metadata on how to decrypt the blob though, so that the PKCS#11
module can actually decrypt it when necessary.

Yep, and we also need to decide what master key is used and where it is
placed, and who access it, and how:-)

Let's move the discussion forward, we need to implement the schema for 4.0.

Do I understand correctly that the whole purpose of
krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example
is just to encrypt keys with some other key which is located at some other
place? I.e. the goal is to lower the probability that a random ldapsearch will
return encrypted blob and master key at once, right?

Yes, it would also be nice if we could finally offload this key from
LDAP for added security, but we are not there yet.


What algorithm/method should we use for key wrapping? As far as I remember
from my studies key wrapping is very sensitive thing and we definitely need to
use some existing standardtool for doing it. Can we just call some NSS
function with default/system-wide parameters and let it do it's job?

I think that would be what we want to do in some form.


That would mean that, after all, we just need to provide some blob as key
wrapping key :-) (Generated with care it deserves etc.)

The key must be self describing somehow (for algorithm agility).



We have had discussion with Honza and the first idea is to add attribute like
'wrappingKeyId' to each encrypted blob and use it for locating appropriate key
when necessary.
- During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId)
to find appropriate wrapping key.
- The harder part is how to pick a wrapping key for encryption. It can be
tricky if the wrapped key is shared among more users (DNS servers) etc.
- It is possible to easily use multiple wrapping keys at once so key rollover
is easy. You can re-encrypt keys one by one.

This makes things complicated fast.
One thing I was thinking was to use a keytab and krb functions to do the
wrapping but that would be pretty IPA specific.


The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11
objects inside the same token will be encrypted with the same key.
- Decryption is easy - the same as in previous case.
- Encryption is basically the same as encryption.
- Key rollover is hard. You would have to re-encrypt all keys and change
wrappingKeyId associated with given token at once - but it is impossible
because we don't have LDAP transactions. As a result, clients will be confused
during rollover. (Consider problems with syncrepl when clients can see changes
immediately.)

Yeah this is a problem we need to address.


The third approach is 'hybrid':
A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is
used for encrypting new objects stored into PKCS#11 token. Each key stored in
the token has own wrappingKeyId attribute and it is used for decryption.
- Decryption is easy - the same as in previous case.
- Encryption always use wrappingKeyId associated with given token.
- Key roll over can start from wrappingKeyId associated with the token and
then re-encrypt keys in the token one by one. All keys can be decrypted in any
step (assuming that changes in one LDAP object are atomic).


Where is a hole in this design? :-)

I do not like the idea of having to add a wrappingKeyId everywhere.

My initial though was to have a central place where wrapping keys are
stored, and during a rollover period you try all the keys until one
works or decryption fails. At the end of rollover you delete the old key
so you avoid the additional load.


Where should we store wrapping keys for users/services and DNS servers? User
object or cn=dns doesn't sound like a good idea because it would defeat the
purpose.

Indeed. And this is the biggest problem. It would be nice to have a
mechanism to securely transfer the key to the DNS servers w/o having to
store it permanently in LDAP. If we had this mechanism we'd be able to
apply it to the Kerberos master key too. But it can't be confined to
installation time only, which is easy, it needs to be possible to update
it at a later time, which is where we have issues, as our replication
mechanism is LDAP.

If we solve the DNA plugin issue with the ability to use groups for
authentication I guess we could

Re: [Freeipa-devel] DNSSEC design page: key wrapping


On 03/04/2014 11:25 AM, Petr Spacek wrote:

On 4.3.2014 17:00, Dmitri Pal wrote:

On 03/04/2014 10:26 AM, Simo Sorce wrote:

On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:

On 26.2.2014 16:00, Simo Sorce wrote:

need to be protected as carefully as the private key.
This is something I meant to discuss too, how do we protect 
them ?
Clearly we have ACIs but I am wondering if we want to encrypt 
them with

keys not immediately or easily available via LDAP ?

It's kind of catastrofic if they get inadvertently exposed 
like if
someone does a ldapsearch as Directory Manager, which is one 
of the
reasons why we encrypt kerberos key material before storing it 
into the

db.
PKCS#8 allows encryption, I guess we can use that. There needs 
to be
some metadata on how to decrypt the blob though, so that the 
PKCS#11

module can actually decrypt it when necessary.
Yep, and we also need to decide what master key is used and where 
it is

placed, and who access it, and how:-)
Let's move the discussion forward, we need to implement the schema 
for 4.0.


Do I understand correctly that the whole purpose of
krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example 

is just to encrypt keys with some other key which is located at 
some other
place? I.e. the goal is to lower the probability that a random 
ldapsearch will

return encrypted blob and master key at once, right?

Yes, it would also be nice if we could finally offload this key from
LDAP for added security, but we are not there yet.

What algorithm/method should we use for key wrapping? As far as I 
remember
from my studies key wrapping is very sensitive thing and we 
definitely need to
use some existing standardtool for doing it. Can we just call some 
NSS

function with default/system-wide parameters and let it do it's job?

I think that would be what we want to do in some form.

That would mean that, after all, we just need to provide some blob 
as key

wrapping key :-) (Generated with care it deserves etc.)

The key must be self describing somehow (for algorithm agility).


We have had discussion with Honza and the first idea is to add 
attribute like
'wrappingKeyId' to each encrypted blob and use it for locating 
appropriate key

when necessary.
- During decryption: Do a LDAP search with filter like 
(keyId=wrappingKeyId)

to find appropriate wrapping key.
- The harder part is how to pick a wrapping key for encryption. It 
can be
tricky if the wrapped key is shared among more users (DNS servers) 
etc.
- It is possible to easily use multiple wrapping keys at once so 
key rollover

is easy. You can re-encrypt keys one by one.

This makes things complicated fast.
One thing I was thinking was to use a keytab and krb functions to do 
the

wrapping but that would be pretty IPA specific.

The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all 
PKCS#11

objects inside the same token will be encrypted with the same key.
- Decryption is easy - the same as in previous case.
- Encryption is basically the same as encryption.
- Key rollover is hard. You would have to re-encrypt all keys and 
change
wrappingKeyId associated with given token at once - but it is 
impossible
because we don't have LDAP transactions. As a result, clients will 
be confused
during rollover. (Consider problems with syncrepl when clients can 
see changes

immediately.)

Yeah this is a problem we need to address.


The third approach is 'hybrid':
A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' 
and is
used for encrypting new objects stored into PKCS#11 token. Each key 
stored in
the token has own wrappingKeyId attribute and it is used for 
decryption.

- Decryption is easy - the same as in previous case.
- Encryption always use wrappingKeyId associated with given token.
- Key roll over can start from wrappingKeyId associated with the 
token and
then re-encrypt keys in the token one by one. All keys can be 
decrypted in any

step (assuming that changes in one LDAP object are atomic).


Where is a hole in this design? :-)

I do not like the idea of having to add a wrappingKeyId everywhere.

My initial though was to have a central place where wrapping keys are
stored, and during a rollover period you try all the keys until one
works or decryption fails. At the end of rollover you delete the old 
key

so you avoid the additional load.

Where should we store wrapping keys for users/services and DNS 
servers? User
object or cn=dns doesn't sound like a good idea because it would 
defeat the

purpose.

Indeed. And this is the biggest problem. It would be nice to have a
mechanism to securely transfer the key to the DNS servers w/o having to
store it permanently in LDAP. If we had this mechanism we'd be able to
apply it to the Kerberos master key too. But it can't be confined to
installation time only, which is easy, it needs to be possible to 
update

it at a later time, which is where we have issues, as our replication
mechanism is LDAP.

If we solve

Re: [Freeipa-devel] DNSSEC design page: key wrapping


On 4.3.2014 17:43, Dmitri Pal wrote:

On 03/04/2014 11:25 AM, Petr Spacek wrote:

On 4.3.2014 17:00, Dmitri Pal wrote:

On 03/04/2014 10:26 AM, Simo Sorce wrote:

On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:

On 26.2.2014 16:00, Simo Sorce wrote:

need to be protected as carefully as the private key.

This is something I meant to discuss too, how do we protect them ?
Clearly we have ACIs but I am wondering if we want to encrypt them with
keys not immediately or easily available via LDAP ?

It's kind of catastrofic if they get inadvertently exposed like if
someone does a ldapsearch as Directory Manager, which is one of the
reasons why we encrypt kerberos key material before storing it into the
db.

PKCS#8 allows encryption, I guess we can use that. There needs to be
some metadata on how to decrypt the blob though, so that the PKCS#11
module can actually decrypt it when necessary.

Yep, and we also need to decide what master key is used and where it is
placed, and who access it, and how:-)

Let's move the discussion forward, we need to implement the schema for 4.0.

Do I understand correctly that the whole purpose of
krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example

is just to encrypt keys with some other key which is located at some other
place? I.e. the goal is to lower the probability that a random ldapsearch
will
return encrypted blob and master key at once, right?

Yes, it would also be nice if we could finally offload this key from
LDAP for added security, but we are not there yet.


What algorithm/method should we use for key wrapping? As far as I remember
from my studies key wrapping is very sensitive thing and we definitely
need to
use some existing standardtool for doing it. Can we just call some NSS
function with default/system-wide parameters and let it do it's job?

I think that would be what we want to do in some form.


That would mean that, after all, we just need to provide some blob as key
wrapping key :-) (Generated with care it deserves etc.)

The key must be self describing somehow (for algorithm agility).



We have had discussion with Honza and the first idea is to add attribute
like
'wrappingKeyId' to each encrypted blob and use it for locating
appropriate key
when necessary.
- During decryption: Do a LDAP search with filter like
(keyId=wrappingKeyId)
to find appropriate wrapping key.
- The harder part is how to pick a wrapping key for encryption. It can be
tricky if the wrapped key is shared among more users (DNS servers) etc.
- It is possible to easily use multiple wrapping keys at once so key
rollover
is easy. You can re-encrypt keys one by one.

This makes things complicated fast.
One thing I was thinking was to use a keytab and krb functions to do the
wrapping but that would be pretty IPA specific.


The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11
objects inside the same token will be encrypted with the same key.
- Decryption is easy - the same as in previous case.
- Encryption is basically the same as encryption.
- Key rollover is hard. You would have to re-encrypt all keys and change
wrappingKeyId associated with given token at once - but it is impossible
because we don't have LDAP transactions. As a result, clients will be
confused
during rollover. (Consider problems with syncrepl when clients can see
changes
immediately.)

Yeah this is a problem we need to address.


The third approach is 'hybrid':
A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is
used for encrypting new objects stored into PKCS#11 token. Each key
stored in
the token has own wrappingKeyId attribute and it is used for decryption.
- Decryption is easy - the same as in previous case.
- Encryption always use wrappingKeyId associated with given token.
- Key roll over can start from wrappingKeyId associated with the token and
then re-encrypt keys in the token one by one. All keys can be decrypted
in any
step (assuming that changes in one LDAP object are atomic).


Where is a hole in this design? :-)

I do not like the idea of having to add a wrappingKeyId everywhere.

My initial though was to have a central place where wrapping keys are
stored, and during a rollover period you try all the keys until one
works or decryption fails. At the end of rollover you delete the old key
so you avoid the additional load.


Where should we store wrapping keys for users/services and DNS servers? User
object or cn=dns doesn't sound like a good idea because it would defeat the
purpose.

Indeed. And this is the biggest problem. It would be nice to have a
mechanism to securely transfer the key to the DNS servers w/o having to
store it permanently in LDAP. If we had this mechanism we'd be able to
apply it to the Kerberos master key too. But it can't be confined to
installation time only, which is easy, it needs to be possible to update
it at a later time, which is where we have issues, as our replication
mechanism is LDAP.

If we solve the DNA

Re: [Freeipa-devel] DNSSEC design page: key wrapping

On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote:
 On 4.3.2014 17:43, Dmitri Pal wrote:
  On 03/04/2014 11:25 AM, Petr Spacek wrote:
  On 4.3.2014 17:00, Dmitri Pal wrote:
  On 03/04/2014 10:26 AM, Simo Sorce wrote:
  On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:
  On 26.2.2014 16:00, Simo Sorce wrote:
  need to be protected as carefully as the private key.
  This is something I meant to discuss too, how do we protect them ?
  Clearly we have ACIs but I am wondering if we want to encrypt them 
  with
  keys not immediately or easily available via LDAP ?
 
  It's kind of catastrofic if they get inadvertently exposed like if
  someone does a ldapsearch as Directory Manager, which is one of 
  the
  reasons why we encrypt kerberos key material before storing it 
  into the
  db.
  PKCS#8 allows encryption, I guess we can use that. There needs to be
  some metadata on how to decrypt the blob though, so that the PKCS#11
  module can actually decrypt it when necessary.
  Yep, and we also need to decide what master key is used and where it is
  placed, and who access it, and how:-)
  Let's move the discussion forward, we need to implement the schema for 
  4.0.
 
  Do I understand correctly that the whole purpose of
  krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example
 
  is just to encrypt keys with some other key which is located at some 
  other
  place? I.e. the goal is to lower the probability that a random 
  ldapsearch
  will
  return encrypted blob and master key at once, right?
  Yes, it would also be nice if we could finally offload this key from
  LDAP for added security, but we are not there yet.
 
  What algorithm/method should we use for key wrapping? As far as I 
  remember
  from my studies key wrapping is very sensitive thing and we definitely
  need to
  use some existing standardtool for doing it. Can we just call some NSS
  function with default/system-wide parameters and let it do it's job?
  I think that would be what we want to do in some form.
 
  That would mean that, after all, we just need to provide some blob as 
  key
  wrapping key :-) (Generated with care it deserves etc.)
  The key must be self describing somehow (for algorithm agility).
 
 
  We have had discussion with Honza and the first idea is to add attribute
  like
  'wrappingKeyId' to each encrypted blob and use it for locating
  appropriate key
  when necessary.
  - During decryption: Do a LDAP search with filter like
  (keyId=wrappingKeyId)
  to find appropriate wrapping key.
  - The harder part is how to pick a wrapping key for encryption. It can 
  be
  tricky if the wrapped key is shared among more users (DNS servers) etc.
  - It is possible to easily use multiple wrapping keys at once so key
  rollover
  is easy. You can re-encrypt keys one by one.
  This makes things complicated fast.
  One thing I was thinking was to use a keytab and krb functions to do the
  wrapping but that would be pretty IPA specific.
 
  The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all 
  PKCS#11
  objects inside the same token will be encrypted with the same key.
  - Decryption is easy - the same as in previous case.
  - Encryption is basically the same as encryption.
  - Key rollover is hard. You would have to re-encrypt all keys and change
  wrappingKeyId associated with given token at once - but it is impossible
  because we don't have LDAP transactions. As a result, clients will be
  confused
  during rollover. (Consider problems with syncrepl when clients can see
  changes
  immediately.)
  Yeah this is a problem we need to address.
 
  The third approach is 'hybrid':
  A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and 
  is
  used for encrypting new objects stored into PKCS#11 token. Each key
  stored in
  the token has own wrappingKeyId attribute and it is used for decryption.
  - Decryption is easy - the same as in previous case.
  - Encryption always use wrappingKeyId associated with given token.
  - Key roll over can start from wrappingKeyId associated with the token 
  and
  then re-encrypt keys in the token one by one. All keys can be decrypted
  in any
  step (assuming that changes in one LDAP object are atomic).
 
 
  Where is a hole in this design? :-)
  I do not like the idea of having to add a wrappingKeyId everywhere.
 
  My initial though was to have a central place where wrapping keys are
  stored, and during a rollover period you try all the keys until one
  works or decryption fails. At the end of rollover you delete the old key
  so you avoid the additional load.
 
  Where should we store wrapping keys for users/services and DNS servers? 
  User
  object or cn=dns doesn't sound like a good idea because it would defeat 
  the
  purpose.
  Indeed. And this is the biggest problem. It would be nice to have a
  mechanism to securely transfer the key to the DNS servers w/o having to
  store it permanently in LDAP. If we had this mechanism we'd be

Re: [Freeipa-devel] DNSSEC design page: key wrapping

On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote:
 On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote:
  On 4.3.2014 17:43, Dmitri Pal wrote:
   On 03/04/2014 11:25 AM, Petr Spacek wrote:
   On 4.3.2014 17:00, Dmitri Pal wrote:
   On 03/04/2014 10:26 AM, Simo Sorce wrote:
   On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:
   On 26.2.2014 16:00, Simo Sorce wrote:
   need to be protected as carefully as the private key.
   This is something I meant to discuss too, how do we protect them 
   ?
   Clearly we have ACIs but I am wondering if we want to encrypt 
   them with
   keys not immediately or easily available via LDAP ?
  
   It's kind of catastrofic if they get inadvertently exposed like 
   if
   someone does a ldapsearch as Directory Manager, which is one 
   of the
   reasons why we encrypt kerberos key material before storing it 
   into the
   db.
   PKCS#8 allows encryption, I guess we can use that. There needs to 
   be
   some metadata on how to decrypt the blob though, so that the 
   PKCS#11
   module can actually decrypt it when necessary.
   Yep, and we also need to decide what master key is used and where it 
   is
   placed, and who access it, and how:-)
   Let's move the discussion forward, we need to implement the schema 
   for 4.0.
  
   Do I understand correctly that the whole purpose of
   krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example
  
   is just to encrypt keys with some other key which is located at some 
   other
   place? I.e. the goal is to lower the probability that a random 
   ldapsearch
   will
   return encrypted blob and master key at once, right?
   Yes, it would also be nice if we could finally offload this key from
   LDAP for added security, but we are not there yet.
  
   What algorithm/method should we use for key wrapping? As far as I 
   remember
   from my studies key wrapping is very sensitive thing and we definitely
   need to
   use some existing standardtool for doing it. Can we just call some 
   NSS
   function with default/system-wide parameters and let it do it's job?
   I think that would be what we want to do in some form.
  
   That would mean that, after all, we just need to provide some blob as 
   key
   wrapping key :-) (Generated with care it deserves etc.)
   The key must be self describing somehow (for algorithm agility).
  
  
   We have had discussion with Honza and the first idea is to add 
   attribute
   like
   'wrappingKeyId' to each encrypted blob and use it for locating
   appropriate key
   when necessary.
   - During decryption: Do a LDAP search with filter like
   (keyId=wrappingKeyId)
   to find appropriate wrapping key.
   - The harder part is how to pick a wrapping key for encryption. It 
   can be
   tricky if the wrapped key is shared among more users (DNS servers) 
   etc.
   - It is possible to easily use multiple wrapping keys at once so key
   rollover
   is easy. You can re-encrypt keys one by one.
   This makes things complicated fast.
   One thing I was thinking was to use a keytab and krb functions to do 
   the
   wrapping but that would be pretty IPA specific.
  
   The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all 
   PKCS#11
   objects inside the same token will be encrypted with the same key.
   - Decryption is easy - the same as in previous case.
   - Encryption is basically the same as encryption.
   - Key rollover is hard. You would have to re-encrypt all keys and 
   change
   wrappingKeyId associated with given token at once - but it is 
   impossible
   because we don't have LDAP transactions. As a result, clients will be
   confused
   during rollover. (Consider problems with syncrepl when clients can see
   changes
   immediately.)
   Yeah this is a problem we need to address.
  
   The third approach is 'hybrid':
   A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' 
   and is
   used for encrypting new objects stored into PKCS#11 token. Each key
   stored in
   the token has own wrappingKeyId attribute and it is used for 
   decryption.
   - Decryption is easy - the same as in previous case.
   - Encryption always use wrappingKeyId associated with given token.
   - Key roll over can start from wrappingKeyId associated with the 
   token and
   then re-encrypt keys in the token one by one. All keys can be 
   decrypted
   in any
   step (assuming that changes in one LDAP object are atomic).
  
  
   Where is a hole in this design? :-)
   I do not like the idea of having to add a wrappingKeyId everywhere.
  
   My initial though was to have a central place where wrapping keys are
   stored, and during a rollover period you try all the keys until one
   works or decryption fails. At the end of rollover you delete the old 
   key
   so you avoid the additional load.
  
   Where should we store wrapping keys for users/services and DNS 
   servers? User
   object or cn=dns doesn't sound like a good idea because it would 
   defeat the

Re: [Freeipa-devel] DNSSEC design page: key wrapping


On 4.3.2014 20:48, Simo Sorce wrote:

On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote:

On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote:

On 4.3.2014 17:43, Dmitri Pal wrote:

On 03/04/2014 11:25 AM, Petr Spacek wrote:

On 4.3.2014 17:00, Dmitri Pal wrote:

On 03/04/2014 10:26 AM, Simo Sorce wrote:

On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:

On 26.2.2014 16:00, Simo Sorce wrote:

need to be protected as carefully as the private key.

This is something I meant to discuss too, how do we protect them ?
Clearly we have ACIs but I am wondering if we want to encrypt them with
keys not immediately or easily available via LDAP ?

It's kind of catastrofic if they get inadvertently exposed like if
someone does a ldapsearch as Directory Manager, which is one of the
reasons why we encrypt kerberos key material before storing it into the
db.

PKCS#8 allows encryption, I guess we can use that. There needs to be
some metadata on how to decrypt the blob though, so that the PKCS#11
module can actually decrypt it when necessary.

Yep, and we also need to decide what master key is used and where it is
placed, and who access it, and how:-)

Let's move the discussion forward, we need to implement the schema for 4.0.

Do I understand correctly that the whole purpose of
krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example

is just to encrypt keys with some other key which is located at some other
place? I.e. the goal is to lower the probability that a random ldapsearch
will
return encrypted blob and master key at once, right?

Yes, it would also be nice if we could finally offload this key from
LDAP for added security, but we are not there yet.


What algorithm/method should we use for key wrapping? As far as I remember
from my studies key wrapping is very sensitive thing and we definitely
need to
use some existing standardtool for doing it. Can we just call some NSS
function with default/system-wide parameters and let it do it's job?

I think that would be what we want to do in some form.


That would mean that, after all, we just need to provide some blob as key
wrapping key :-) (Generated with care it deserves etc.)

The key must be self describing somehow (for algorithm agility).



We have had discussion with Honza and the first idea is to add attribute
like
'wrappingKeyId' to each encrypted blob and use it for locating
appropriate key
when necessary.
- During decryption: Do a LDAP search with filter like
(keyId=wrappingKeyId)
to find appropriate wrapping key.
- The harder part is how to pick a wrapping key for encryption. It can be
tricky if the wrapped key is shared among more users (DNS servers) etc.
- It is possible to easily use multiple wrapping keys at once so key
rollover
is easy. You can re-encrypt keys one by one.

This makes things complicated fast.
One thing I was thinking was to use a keytab and krb functions to do the
wrapping but that would be pretty IPA specific.


The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11
objects inside the same token will be encrypted with the same key.
- Decryption is easy - the same as in previous case.
- Encryption is basically the same as encryption.
- Key rollover is hard. You would have to re-encrypt all keys and change
wrappingKeyId associated with given token at once - but it is impossible
because we don't have LDAP transactions. As a result, clients will be
confused
during rollover. (Consider problems with syncrepl when clients can see
changes
immediately.)

Yeah this is a problem we need to address.


The third approach is 'hybrid':
A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is
used for encrypting new objects stored into PKCS#11 token. Each key
stored in
the token has own wrappingKeyId attribute and it is used for decryption.
- Decryption is easy - the same as in previous case.
- Encryption always use wrappingKeyId associated with given token.
- Key roll over can start from wrappingKeyId associated with the token and
then re-encrypt keys in the token one by one. All keys can be decrypted
in any
step (assuming that changes in one LDAP object are atomic).


Where is a hole in this design? :-)

I do not like the idea of having to add a wrappingKeyId everywhere.

My initial though was to have a central place where wrapping keys are
stored, and during a rollover period you try all the keys until one
works or decryption fails. At the end of rollover you delete the old key
so you avoid the additional load.


Where should we store wrapping keys for users/services and DNS servers? User
object or cn=dns doesn't sound like a good idea because it would defeat the
purpose.

Indeed. And this is the biggest problem. It would be nice to have a
mechanism to securely transfer the key to the DNS servers w/o having to
store it permanently in LDAP. If we had this mechanism we'd be able to
apply it to the Kerberos master key too. But it can't be confined to
installation time only, which is

Re: [Freeipa-devel] DNSSEC design page: key wrapping


On 4.3.2014 21:25, Petr Spacek wrote:

On 4.3.2014 20:48, Simo Sorce wrote:

On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote:

On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote:

On 4.3.2014 17:43, Dmitri Pal wrote:

On 03/04/2014 11:25 AM, Petr Spacek wrote:

On 4.3.2014 17:00, Dmitri Pal wrote:

On 03/04/2014 10:26 AM, Simo Sorce wrote:

On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:

On 26.2.2014 16:00, Simo Sorce wrote:

need to be protected as carefully as the private key.

This is something I meant to discuss too, how do we protect them ?
Clearly we have ACIs but I am wondering if we want to encrypt
them with
keys not immediately or easily available via LDAP ?

It's kind of catastrofic if they get inadvertently exposed like if
someone does a ldapsearch as Directory Manager, which is one
of the
reasons why we encrypt kerberos key material before storing it
into the
db.

PKCS#8 allows encryption, I guess we can use that. There needs to be
some metadata on how to decrypt the blob though, so that the PKCS#11
module can actually decrypt it when necessary.

Yep, and we also need to decide what master key is used and where it is
placed, and who access it, and how:-)

Let's move the discussion forward, we need to implement the schema
for 4.0.

Do I understand correctly that the whole purpose of
krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example


is just to encrypt keys with some other key which is located at some
other
place? I.e. the goal is to lower the probability that a random
ldapsearch
will
return encrypted blob and master key at once, right?

Yes, it would also be nice if we could finally offload this key from
LDAP for added security, but we are not there yet.


What algorithm/method should we use for key wrapping? As far as I
remember
from my studies key wrapping is very sensitive thing and we definitely
need to
use some existing standardtool for doing it. Can we just call some NSS
function with default/system-wide parameters and let it do it's job?

I think that would be what we want to do in some form.


That would mean that, after all, we just need to provide some blob as
key
wrapping key :-) (Generated with care it deserves etc.)

The key must be self describing somehow (for algorithm agility).



We have had discussion with Honza and the first idea is to add attribute
like
'wrappingKeyId' to each encrypted blob and use it for locating
appropriate key
when necessary.
- During decryption: Do a LDAP search with filter like
(keyId=wrappingKeyId)
to find appropriate wrapping key.
- The harder part is how to pick a wrapping key for encryption. It
can be
tricky if the wrapped key is shared among more users (DNS servers) etc.
- It is possible to easily use multiple wrapping keys at once so key
rollover
is easy. You can re-encrypt keys one by one.

This makes things complicated fast.
One thing I was thinking was to use a keytab and krb functions to do the
wrapping but that would be pretty IPA specific.


The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all
PKCS#11
objects inside the same token will be encrypted with the same key.
- Decryption is easy - the same as in previous case.
- Encryption is basically the same as encryption.
- Key rollover is hard. You would have to re-encrypt all keys and change
wrappingKeyId associated with given token at once - but it is impossible
because we don't have LDAP transactions. As a result, clients will be
confused
during rollover. (Consider problems with syncrepl when clients can see
changes
immediately.)

Yeah this is a problem we need to address.


The third approach is 'hybrid':
A 'wrappingKeyId' associated with PKCS#11 token is 'the active one'
and is
used for encrypting new objects stored into PKCS#11 token. Each key
stored in
the token has own wrappingKeyId attribute and it is used for decryption.
- Decryption is easy - the same as in previous case.
- Encryption always use wrappingKeyId associated with given token.
- Key roll over can start from wrappingKeyId associated with the
token and
then re-encrypt keys in the token one by one. All keys can be decrypted
in any
step (assuming that changes in one LDAP object are atomic).


Where is a hole in this design? :-)

I do not like the idea of having to add a wrappingKeyId everywhere.

My initial though was to have a central place where wrapping keys are
stored, and during a rollover period you try all the keys until one
works or decryption fails. At the end of rollover you delete the old key
so you avoid the additional load.


Where should we store wrapping keys for users/services and DNS
servers? User
object or cn=dns doesn't sound like a good idea because it would
defeat the
purpose.

Indeed. And this is the biggest problem. It would be nice to have a
mechanism to securely transfer the key to the DNS servers w/o having to
store it permanently in LDAP. If we had this mechanism we'd be able to
apply it to the Kerberos master key too. But it can't be confined

Re: [Freeipa-devel] DNSSEC design page: key wrapping

On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote:
 On 4.3.2014 20:48, Simo Sorce wrote:
  On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote:
  On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote:
  On 4.3.2014 17:43, Dmitri Pal wrote:
  On 03/04/2014 11:25 AM, Petr Spacek wrote:
  On 4.3.2014 17:00, Dmitri Pal wrote:
  On 03/04/2014 10:26 AM, Simo Sorce wrote:
  On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:
  On 26.2.2014 16:00, Simo Sorce wrote:
  need to be protected as carefully as the private key.
  This is something I meant to discuss too, how do we protect 
  them ?
  Clearly we have ACIs but I am wondering if we want to encrypt 
  them with
  keys not immediately or easily available via LDAP ?
 
  It's kind of catastrofic if they get inadvertently exposed like 
  if
  someone does a ldapsearch as Directory Manager, which is one 
  of the
  reasons why we encrypt kerberos key material before storing it 
  into the
  db.
  PKCS#8 allows encryption, I guess we can use that. There needs to 
  be
  some metadata on how to decrypt the blob though, so that the 
  PKCS#11
  module can actually decrypt it when necessary.
  Yep, and we also need to decide what master key is used and where 
  it is
  placed, and who access it, and how:-)
  Let's move the discussion forward, we need to implement the schema 
  for 4.0.
 
  Do I understand correctly that the whole purpose of
  krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example
 
  is just to encrypt keys with some other key which is located at some 
  other
  place? I.e. the goal is to lower the probability that a random 
  ldapsearch
  will
  return encrypted blob and master key at once, right?
  Yes, it would also be nice if we could finally offload this key from
  LDAP for added security, but we are not there yet.
 
  What algorithm/method should we use for key wrapping? As far as I 
  remember
  from my studies key wrapping is very sensitive thing and we 
  definitely
  need to
  use some existing standardtool for doing it. Can we just call some 
  NSS
  function with default/system-wide parameters and let it do it's job?
  I think that would be what we want to do in some form.
 
  That would mean that, after all, we just need to provide some blob 
  as key
  wrapping key :-) (Generated with care it deserves etc.)
  The key must be self describing somehow (for algorithm agility).
 
 
  We have had discussion with Honza and the first idea is to add 
  attribute
  like
  'wrappingKeyId' to each encrypted blob and use it for locating
  appropriate key
  when necessary.
  - During decryption: Do a LDAP search with filter like
  (keyId=wrappingKeyId)
  to find appropriate wrapping key.
  - The harder part is how to pick a wrapping key for encryption. It 
  can be
  tricky if the wrapped key is shared among more users (DNS servers) 
  etc.
  - It is possible to easily use multiple wrapping keys at once so key
  rollover
  is easy. You can re-encrypt keys one by one.
  This makes things complicated fast.
  One thing I was thinking was to use a keytab and krb functions to do 
  the
  wrapping but that would be pretty IPA specific.
 
  The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all 
  PKCS#11
  objects inside the same token will be encrypted with the same key.
  - Decryption is easy - the same as in previous case.
  - Encryption is basically the same as encryption.
  - Key rollover is hard. You would have to re-encrypt all keys and 
  change
  wrappingKeyId associated with given token at once - but it is 
  impossible
  because we don't have LDAP transactions. As a result, clients will be
  confused
  during rollover. (Consider problems with syncrepl when clients can 
  see
  changes
  immediately.)
  Yeah this is a problem we need to address.
 
  The third approach is 'hybrid':
  A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' 
  and is
  used for encrypting new objects stored into PKCS#11 token. Each key
  stored in
  the token has own wrappingKeyId attribute and it is used for 
  decryption.
  - Decryption is easy - the same as in previous case.
  - Encryption always use wrappingKeyId associated with given token.
  - Key roll over can start from wrappingKeyId associated with the 
  token and
  then re-encrypt keys in the token one by one. All keys can be 
  decrypted
  in any
  step (assuming that changes in one LDAP object are atomic).
 
 
  Where is a hole in this design? :-)
  I do not like the idea of having to add a wrappingKeyId everywhere.
 
  My initial though was to have a central place where wrapping keys are
  stored, and during a rollover period you try all the keys until one
  works or decryption fails. At the end of rollover you delete the old 
  key
  so you avoid the additional load.
 
  Where should we store wrapping keys for users/services and DNS 
  servers? User
  object or cn=dns doesn't sound like a good idea because it would 
  defeat the
  purpose.
  Indeed.

Re: [Freeipa-devel] DNSSEC design page: key wrapping


On 4.3.2014 22:15, Simo Sorce wrote:

On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote:

On 4.3.2014 20:48, Simo Sorce wrote:

On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote:

On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote:

On 4.3.2014 17:43, Dmitri Pal wrote:

On 03/04/2014 11:25 AM, Petr Spacek wrote:

On 4.3.2014 17:00, Dmitri Pal wrote:

On 03/04/2014 10:26 AM, Simo Sorce wrote:

On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:

On 26.2.2014 16:00, Simo Sorce wrote:

need to be protected as carefully as the private key.

This is something I meant to discuss too, how do we protect them ?
Clearly we have ACIs but I am wondering if we want to encrypt them with
keys not immediately or easily available via LDAP ?

It's kind of catastrofic if they get inadvertently exposed like if
someone does a ldapsearch as Directory Manager, which is one of the
reasons why we encrypt kerberos key material before storing it into the
db.

PKCS#8 allows encryption, I guess we can use that. There needs to be
some metadata on how to decrypt the blob though, so that the PKCS#11
module can actually decrypt it when necessary.

Yep, and we also need to decide what master key is used and where it is
placed, and who access it, and how:-)

Let's move the discussion forward, we need to implement the schema for 4.0.

Do I understand correctly that the whole purpose of
krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example

is just to encrypt keys with some other key which is located at some other
place? I.e. the goal is to lower the probability that a random ldapsearch
will
return encrypted blob and master key at once, right?

Yes, it would also be nice if we could finally offload this key from
LDAP for added security, but we are not there yet.


What algorithm/method should we use for key wrapping? As far as I remember
from my studies key wrapping is very sensitive thing and we definitely
need to
use some existing standardtool for doing it. Can we just call some NSS
function with default/system-wide parameters and let it do it's job?

I think that would be what we want to do in some form.


That would mean that, after all, we just need to provide some blob as key
wrapping key :-) (Generated with care it deserves etc.)

The key must be self describing somehow (for algorithm agility).



We have had discussion with Honza and the first idea is to add attribute
like
'wrappingKeyId' to each encrypted blob and use it for locating
appropriate key
when necessary.
- During decryption: Do a LDAP search with filter like
(keyId=wrappingKeyId)
to find appropriate wrapping key.
- The harder part is how to pick a wrapping key for encryption. It can be
tricky if the wrapped key is shared among more users (DNS servers) etc.
- It is possible to easily use multiple wrapping keys at once so key
rollover
is easy. You can re-encrypt keys one by one.

This makes things complicated fast.
One thing I was thinking was to use a keytab and krb functions to do the
wrapping but that would be pretty IPA specific.


The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11
objects inside the same token will be encrypted with the same key.
- Decryption is easy - the same as in previous case.
- Encryption is basically the same as encryption.
- Key rollover is hard. You would have to re-encrypt all keys and change
wrappingKeyId associated with given token at once - but it is impossible
because we don't have LDAP transactions. As a result, clients will be
confused
during rollover. (Consider problems with syncrepl when clients can see
changes
immediately.)

Yeah this is a problem we need to address.


The third approach is 'hybrid':
A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is
used for encrypting new objects stored into PKCS#11 token. Each key
stored in
the token has own wrappingKeyId attribute and it is used for decryption.
- Decryption is easy - the same as in previous case.
- Encryption always use wrappingKeyId associated with given token.
- Key roll over can start from wrappingKeyId associated with the token and
then re-encrypt keys in the token one by one. All keys can be decrypted
in any
step (assuming that changes in one LDAP object are atomic).


Where is a hole in this design? :-)

I do not like the idea of having to add a wrappingKeyId everywhere.

My initial though was to have a central place where wrapping keys are
stored, and during a rollover period you try all the keys until one
works or decryption fails. At the end of rollover you delete the old key
so you avoid the additional load.


Where should we store wrapping keys for users/services and DNS servers? User
object or cn=dns doesn't sound like a good idea because it would defeat the
purpose.

Indeed. And this is the biggest problem. It would be nice to have a
mechanism to securely transfer the key to the DNS servers w/o having to
store it permanently in LDAP. If we had this mechanism we'd be able to
apply it to

Re: [Freeipa-devel] DNSSEC design page: key wrapping

On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote:
 On 4.3.2014 22:15, Simo Sorce wrote:
  On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote:
  On 4.3.2014 20:48, Simo Sorce wrote:
  On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote:
  On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote:
  On 4.3.2014 17:43, Dmitri Pal wrote:
  On 03/04/2014 11:25 AM, Petr Spacek wrote:
  On 4.3.2014 17:00, Dmitri Pal wrote:
  On 03/04/2014 10:26 AM, Simo Sorce wrote:
  On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:
  On 26.2.2014 16:00, Simo Sorce wrote:
  need to be protected as carefully as the private key.
  This is something I meant to discuss too, how do we protect 
  them ?
  Clearly we have ACIs but I am wondering if we want to encrypt 
  them with
  keys not immediately or easily available via LDAP ?
 
  It's kind of catastrofic if they get inadvertently exposed 
  like if
  someone does a ldapsearch as Directory Manager, which is 
  one of the
  reasons why we encrypt kerberos key material before storing 
  it into the
  db.
  PKCS#8 allows encryption, I guess we can use that. There needs 
  to be
  some metadata on how to decrypt the blob though, so that the 
  PKCS#11
  module can actually decrypt it when necessary.
  Yep, and we also need to decide what master key is used and where 
  it is
  placed, and who access it, and how:-)
  Let's move the discussion forward, we need to implement the schema 
  for 4.0.
 
  Do I understand correctly that the whole purpose of
  krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example
 
  is just to encrypt keys with some other key which is located at 
  some other
  place? I.e. the goal is to lower the probability that a random 
  ldapsearch
  will
  return encrypted blob and master key at once, right?
  Yes, it would also be nice if we could finally offload this key from
  LDAP for added security, but we are not there yet.
 
  What algorithm/method should we use for key wrapping? As far as I 
  remember
  from my studies key wrapping is very sensitive thing and we 
  definitely
  need to
  use some existing standardtool for doing it. Can we just call 
  some NSS
  function with default/system-wide parameters and let it do it's 
  job?
  I think that would be what we want to do in some form.
 
  That would mean that, after all, we just need to provide some blob 
  as key
  wrapping key :-) (Generated with care it deserves etc.)
  The key must be self describing somehow (for algorithm agility).
 
 
  We have had discussion with Honza and the first idea is to add 
  attribute
  like
  'wrappingKeyId' to each encrypted blob and use it for locating
  appropriate key
  when necessary.
  - During decryption: Do a LDAP search with filter like
  (keyId=wrappingKeyId)
  to find appropriate wrapping key.
  - The harder part is how to pick a wrapping key for encryption. It 
  can be
  tricky if the wrapped key is shared among more users (DNS servers) 
  etc.
  - It is possible to easily use multiple wrapping keys at once so 
  key
  rollover
  is easy. You can re-encrypt keys one by one.
  This makes things complicated fast.
  One thing I was thinking was to use a keytab and krb functions to 
  do the
  wrapping but that would be pretty IPA specific.
 
  The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all 
  PKCS#11
  objects inside the same token will be encrypted with the same key.
  - Decryption is easy - the same as in previous case.
  - Encryption is basically the same as encryption.
  - Key rollover is hard. You would have to re-encrypt all keys and 
  change
  wrappingKeyId associated with given token at once - but it is 
  impossible
  because we don't have LDAP transactions. As a result, clients will 
  be
  confused
  during rollover. (Consider problems with syncrepl when clients can 
  see
  changes
  immediately.)
  Yeah this is a problem we need to address.
 
  The third approach is 'hybrid':
  A 'wrappingKeyId' associated with PKCS#11 token is 'the active 
  one' and is
  used for encrypting new objects stored into PKCS#11 token. Each key
  stored in
  the token has own wrappingKeyId attribute and it is used for 
  decryption.
  - Decryption is easy - the same as in previous case.
  - Encryption always use wrappingKeyId associated with given token.
  - Key roll over can start from wrappingKeyId associated with the 
  token and
  then re-encrypt keys in the token one by one. All keys can be 
  decrypted
  in any
  step (assuming that changes in one LDAP object are atomic).
 
 
  Where is a hole in this design? :-)
  I do not like the idea of having to add a wrappingKeyId everywhere.
 
  My initial though was to have a central place where wrapping keys 
  are
  stored, and during a rollover period you try all the keys until one
  works or decryption fails. At the end of rollover you delete the 
  old key
  so you avoid the additional load.
 
  Where should we store wrapping keys for users/services and DNS 
  servers?

Re: [Freeipa-devel] DNSSEC design page: key wrapping


On 4.3.2014 22:53, Simo Sorce wrote:

On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote:

On 4.3.2014 22:15, Simo Sorce wrote:

On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote:

On 4.3.2014 20:48, Simo Sorce wrote:

On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote:

On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote:

On 4.3.2014 17:43, Dmitri Pal wrote:

On 03/04/2014 11:25 AM, Petr Spacek wrote:

On 4.3.2014 17:00, Dmitri Pal wrote:

On 03/04/2014 10:26 AM, Simo Sorce wrote:

On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:

Where should we store wrapping keys for users/services and DNS servers? User
object or cn=dns doesn't sound like a good idea because it would defeat the
purpose.

Indeed. And this is the biggest problem. It would be nice to have a
mechanism to securely transfer the key to the DNS servers w/o having to
store it permanently in LDAP. If we had this mechanism we'd be able to
apply it to the Kerberos master key too. But it can't be confined to
installation time only, which is easy, it needs to be possible to update
it at a later time, which is where we have issues, as our replication
mechanism is LDAP.

If we solve the DNA plugin issue with the ability to use groups for
authentication I guess we could build a control/extend operation that
would allow masters to transfer keys to each other w/o exposing them as
LDAP searches, do we want to try to go in that direction ?

Simo.


Should we consider vault as a storage for these keys too?
It already supports recovery of the symmetric and asymmetric keys so may be
these keys should be stored there?


Maybe. The question is if we want to support DNSSEC without Dogtag ...


Without Dogtag? Vault would be an independent component from CA I assume,
though CA might be needed anyways to issue transport keys for the internal
components.
But I think that even if we use Vault as an internal password and key storage
I do not see a reason why we can't require it for DNSSEC.
Why over-complicate things if we already have components that can be used? If
we see a requests to support DNSSEC without Vault component we will adjust but
I do not think we should limit ourselves in the first implementation.


I'm personally fine with that.

Are we going to re-prioritize Password Vault from Backlog to 4.0?
https://fedorahosted.org/freeipa/ticket/3872

We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo
that key wrapping is not necessary :-)


For 4.0 we could document that you have to copy the keys around
manually. And add Vault support in 4.1 ?

It could work ... Can we modify ipa-replica-prepare in 4.0 to add the wrapping
key to replica file to make it easier?

Can the vault approach work for Kerberos master key? If not, shouldn't we
design something universal instead of deferring it again and again?


We can use the same method for the M/K, now that the CA is installed
before the rest we do not have a chicken-egg issue anymore.


Another problem is that the PKCS#11 LDAP schema was designed as
application-independent but now we are adding very specific key-wrapping
mechanism (it is hard to believe that somebody else will implement it).


It could be optional.


Maybe we can add something like attribute 'pkcs11keyWrapMech':
- key is not wrapped if it is not present
- key is wrapped if it is present - value determines used mechanism (mandatory
mechanism to implement is only 'none')


What is 'none' ?

I mean 'attribute is not present'.


The only unknown here is who adds a new wrapper wen a new server is up
and it publishes the public key in LDAP. For existing servers they can
re-wrap themselves.

It's a few layers but should not be too hard.

I don't fully understand to your proposal but I'm afraid that it will not work
for ordinary IPA users. Don't forget that we want to have universal PKCS#11
storage usable even for private SSH keys and other stuff.


Well ... TBH I am not really that hot about storing private keys in IPA
like that, however for people that want to do it they can simply store
them not encrypted as you proposed above.


Please correct me if I'm wrong.


You are right, but I was caring for the DNS keys case, not the user's
ssh key case, which is hairy IMHO.

There is no difference between DNSSEC keys and any other keys except the fact
that we need shared wrapping key for DNSSEC. Nothing else. Note that SSH
private key is just an example. You can use PKCS#11 as storage for user
certificates used for authentication in Firefox etc.


I think the private ssh key case is a clear job for the Vault the fact
sssd might use a pkcs#11 interface to present it to ssh, or the user
simply pulls it to the local file system is, in my view, an
implementation detail.

I can see a huge difference. Properly implemented PKCS#11 provides you the
same separation as GSS-Proxy for keytabs. I.e. non-root process will not be
able to extract any private keys.

Also, PKCS#11 is a standard so any application can use it. I don't like

Re: [Freeipa-devel] DNSSEC design page: key wrapping


On 03/04/2014 04:53 PM, Simo Sorce wrote:

On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote:

On 4.3.2014 22:15, Simo Sorce wrote:

On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote:

On 4.3.2014 20:48, Simo Sorce wrote:

On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote:

On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote:

On 4.3.2014 17:43, Dmitri Pal wrote:

On 03/04/2014 11:25 AM, Petr Spacek wrote:

On 4.3.2014 17:00, Dmitri Pal wrote:

On 03/04/2014 10:26 AM, Simo Sorce wrote:

On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:

On 26.2.2014 16:00, Simo Sorce wrote:

need to be protected as carefully as the private key.

This is something I meant to discuss too, how do we protect them ?
Clearly we have ACIs but I am wondering if we want to encrypt them with
keys not immediately or easily available via LDAP ?

It's kind of catastrofic if they get inadvertently exposed like if
someone does a ldapsearch as Directory Manager, which is one of the
reasons why we encrypt kerberos key material before storing it into the
db.

PKCS#8 allows encryption, I guess we can use that. There needs to be
some metadata on how to decrypt the blob though, so that the PKCS#11
module can actually decrypt it when necessary.

Yep, and we also need to decide what master key is used and where it is
placed, and who access it, and how:-)

Let's move the discussion forward, we need to implement the schema for 4.0.

Do I understand correctly that the whole purpose of
krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example

is just to encrypt keys with some other key which is located at some other
place? I.e. the goal is to lower the probability that a random ldapsearch
will
return encrypted blob and master key at once, right?

Yes, it would also be nice if we could finally offload this key from
LDAP for added security, but we are not there yet.


What algorithm/method should we use for key wrapping? As far as I remember
from my studies key wrapping is very sensitive thing and we definitely
need to
use some existing standardtool for doing it. Can we just call some NSS
function with default/system-wide parameters and let it do it's job?

I think that would be what we want to do in some form.


That would mean that, after all, we just need to provide some blob as key
wrapping key :-) (Generated with care it deserves etc.)

The key must be self describing somehow (for algorithm agility).



We have had discussion with Honza and the first idea is to add attribute
like
'wrappingKeyId' to each encrypted blob and use it for locating
appropriate key
when necessary.
- During decryption: Do a LDAP search with filter like
(keyId=wrappingKeyId)
to find appropriate wrapping key.
- The harder part is how to pick a wrapping key for encryption. It can be
tricky if the wrapped key is shared among more users (DNS servers) etc.
- It is possible to easily use multiple wrapping keys at once so key
rollover
is easy. You can re-encrypt keys one by one.

This makes things complicated fast.
One thing I was thinking was to use a keytab and krb functions to do the
wrapping but that would be pretty IPA specific.


The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11
objects inside the same token will be encrypted with the same key.
- Decryption is easy - the same as in previous case.
- Encryption is basically the same as encryption.
- Key rollover is hard. You would have to re-encrypt all keys and change
wrappingKeyId associated with given token at once - but it is impossible
because we don't have LDAP transactions. As a result, clients will be
confused
during rollover. (Consider problems with syncrepl when clients can see
changes
immediately.)

Yeah this is a problem we need to address.


The third approach is 'hybrid':
A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is
used for encrypting new objects stored into PKCS#11 token. Each key
stored in
the token has own wrappingKeyId attribute and it is used for decryption.
- Decryption is easy - the same as in previous case.
- Encryption always use wrappingKeyId associated with given token.
- Key roll over can start from wrappingKeyId associated with the token and
then re-encrypt keys in the token one by one. All keys can be decrypted
in any
step (assuming that changes in one LDAP object are atomic).


Where is a hole in this design? :-)

I do not like the idea of having to add a wrappingKeyId everywhere.

My initial though was to have a central place where wrapping keys are
stored, and during a rollover period you try all the keys until one
works or decryption fails. At the end of rollover you delete the old key
so you avoid the additional load.


Where should we store wrapping keys for users/services and DNS servers? User
object or cn=dns doesn't sound like a good idea because it would defeat the
purpose.

Indeed. And this is the biggest problem. It would be nice to have a
mechanism to securely transfer the key to the DNS servers

Re: [Freeipa-devel] DNSSEC design page: key wrapping


On 03/04/2014 05:14 PM, Petr Spacek wrote:

On 4.3.2014 22:53, Simo Sorce wrote:

On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote:

On 4.3.2014 22:15, Simo Sorce wrote:

On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote:

On 4.3.2014 20:48, Simo Sorce wrote:

On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote:

On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote:

On 4.3.2014 17:43, Dmitri Pal wrote:

On 03/04/2014 11:25 AM, Petr Spacek wrote:

On 4.3.2014 17:00, Dmitri Pal wrote:

On 03/04/2014 10:26 AM, Simo Sorce wrote:

On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote:
Where should we store wrapping keys for users/services and 
DNS servers? User
object or cn=dns doesn't sound like a good idea because it 
would defeat the

purpose.
Indeed. And this is the biggest problem. It would be nice 
to have a
mechanism to securely transfer the key to the DNS servers 
w/o having to
store it permanently in LDAP. If we had this mechanism we'd 
be able to
apply it to the Kerberos master key too. But it can't be 
confined to
installation time only, which is easy, it needs to be 
possible to update
it at a later time, which is where we have issues, as our 
replication

mechanism is LDAP.

If we solve the DNA plugin issue with the ability to use 
groups for
authentication I guess we could build a control/extend 
operation that
would allow masters to transfer keys to each other w/o 
exposing them as

LDAP searches, do we want to try to go in that direction ?

Simo.


Should we consider vault as a storage for these keys too?
It already supports recovery of the symmetric and asymmetric 
keys so may be

these keys should be stored there?


Maybe. The question is if we want to support DNSSEC without 
Dogtag ...


Without Dogtag? Vault would be an independent component from 
CA I assume,
though CA might be needed anyways to issue transport keys for 
the internal

components.
But I think that even if we use Vault as an internal password 
and key storage

I do not see a reason why we can't require it for DNSSEC.
Why over-complicate things if we already have components that 
can be used? If
we see a requests to support DNSSEC without Vault component we 
will adjust but
I do not think we should limit ourselves in the first 
implementation.


I'm personally fine with that.

Are we going to re-prioritize Password Vault from Backlog to 4.0?
https://fedorahosted.org/freeipa/ticket/3872

We need that in 4.0 timeframe for DNSSEC otherwise you need to 
convince Simo

that key wrapping is not necessary :-)


For 4.0 we could document that you have to copy the keys around
manually. And add Vault support in 4.1 ?
It could work ... Can we modify ipa-replica-prepare in 4.0 to add 
the wrapping

key to replica file to make it easier?

Can the vault approach work for Kerberos master key? If not, 
shouldn't we

design something universal instead of deferring it again and again?


We can use the same method for the M/K, now that the CA is installed
before the rest we do not have a chicken-egg issue anymore.


Another problem is that the PKCS#11 LDAP schema was designed as
application-independent but now we are adding very specific 
key-wrapping
mechanism (it is hard to believe that somebody else will implement 
it).


It could be optional.


Maybe we can add something like attribute 'pkcs11keyWrapMech':
- key is not wrapped if it is not present
- key is wrapped if it is present - value determines used 
mechanism (mandatory

mechanism to implement is only 'none')


What is 'none' ?

I mean 'attribute is not present'.

The only unknown here is who adds a new wrapper wen a new server 
is up
and it publishes the public key in LDAP. For existing servers 
they can

re-wrap themselves.

It's a few layers but should not be too hard.
I don't fully understand to your proposal but I'm afraid that it 
will not work
for ordinary IPA users. Don't forget that we want to have 
universal PKCS#11

storage usable even for private SSH keys and other stuff.


Well ... TBH I am not really that hot about storing private keys in 
IPA

like that, however for people that want to do it they can simply store
them not encrypted as you proposed above.


Please correct me if I'm wrong.


You are right, but I was caring for the DNS keys case, not the user's
ssh key case, which is hairy IMHO.
There is no difference between DNSSEC keys and any other keys except 
the fact
that we need shared wrapping key for DNSSEC. Nothing else. Note that 
SSH

private key is just an example. You can use PKCS#11 as storage for user
certificates used for authentication in Firefox etc.


I think the private ssh key case is a clear job for the Vault the fact
sssd might use a pkcs#11 interface to present it to ssh, or the user
simply pulls it to the local file system is, in my view, an
implementation detail.
I can see a huge difference. Properly implemented PKCS#11 provides 
you the
same separation as GSS-Proxy for keytabs. I.e. non-root process will 
not be

able to extract any

Re: [Freeipa-devel] DNSSEC design page: key wrapping


On 4.3.2014 23:18, Dmitri Pal wrote:

We need PKCS#11 for CA certificates, BIND and OpenDNSSEC anyway so we need
to design schema for *public* data. All private data can be stored in Vault
if we agree on that.


Do we need it on the server and if so can it be exposed by the vault rather
than via LDAP?
We need standard PKCS#11 interface because applications like BIND and 
OpenDNSSEC do not care about IPA-specifics. However applications see only 
PKCS#11 interface and nothing else, there could be LDAP or some other protocol 
behind the API.


Honza's plan is to integrate PKCS#11 module to SSSD somehow so it will be 
available on all client machines, it will use caching facilities, fail-over etc.


Replying to the other thread to join both threads to one:

Also about PKCS#11 interface. I am all for PKCS#11 interface for client
exposed from SSSD that uses whatever means to fetch the central keys it being
SSH keys, gnome keyring keys or something else.

AFAIK that is exactly the plan.


I do not see a reason for IPA
to expose a remote PKCS#11 interface. If we need a remote PKCS#11 interface
(please insert why here) then it should be a part of the vault API rather than
anything else.

I'm not sure that I understand...

PKCS#11 is just a set of functions, for an application it is a library.

An application just calls the PKCS#11 API and knows nothing about 
implementation details so there is nothing like 'remote PKCS#11'. As I said 
above, SSSD will be behind scenes. Everything is local except the data storage 
in LDAP or vault, it doesn't matter.


Maybe I misunderstood you, sorry.

--
Petr^2 Spacek

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

Re: [Freeipa-devel] DNSSEC design page: key wrapping


  
  
On 03/04/2014 05:30 PM, Petr Spacek wrote:
On
  4.3.2014 23:18, Dmitri Pal wrote:
  
  
We need PKCS#11 for CA certificates,
  BIND and OpenDNSSEC anyway so we need
  
  to design schema for *public* data. All private data can be
  stored in Vault
  
  if we agree on that.
  


Do we need it on the server and if so can it be exposed by the
vault rather

than via LDAP?

  
  We need standard PKCS#11 interface because applications like BIND
  and OpenDNSSEC do not care about IPA-specifics. However
  applications see only PKCS#11 interface and nothing else, there
  could be LDAP or some other protocol behind the API.
  
  
  Honza's plan is to integrate PKCS#11 module to SSSD somehow so it
  will be available on all client machines, it will use caching
  facilities, fail-over etc.
  
  
  Replying to the other thread to join both threads to one:
  
  Also about PKCS#11 interface. I am all for
PKCS#11 interface for client

exposed from SSSD that uses whatever means to fetch the central
keys it being

SSH keys, gnome keyring keys or something else.

  
  AFAIK that is exactly the plan.
  
  
  I do not see a reason for IPA

to expose a remote PKCS#11 interface. If we need a remote
PKCS#11 interface

(please insert why here) then it should be a part of the vault
API rather than

anything else.

  
  I'm not sure that I understand...
  
  
  PKCS#11 is just a set of functions, for an application it is a
  library.
  
  
  An application just calls the PKCS#11 API and knows nothing about
  implementation details so there is nothing like 'remote PKCS#11'.
  As I said above, SSSD will be behind scenes. Everything is local
  except the data storage in LDAP or vault, it doesn't matter.
  
  
  Maybe I misunderstood you, sorry.
  
  

Remote means that there is a PKCS#11 library that can be loaded into
a process and would remotely connect to a central server via
LDAP/REST/whatever. My point is that library should be light weight
and always talk to a local service like SSSD rather than have a
remote interface. In this case SSSD on the server can talk to the
vault or IPA LDAP directly and all consumers would use PKCS#11
interface exposed by SSSD

Something like this...



-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



  

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

Re: [Freeipa-devel] DNSSEC design page: key wrapping

2014-03-04 Thread Jan Cholasta


On 5.3.2014 05:10, Simo Sorce wrote:

On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote:

Remote means that there is a PKCS#11 library that can be loaded into a
process and would remotely connect to a central server via
LDAP/REST/whatever. My point is that library should be light weight
and always talk to a local service like SSSD rather than have a remote
interface. In this case SSSD on the server can talk to the vault or
IPA LDAP directly and all consumers would use PKCS#11 interface
exposed by SSSD

Something like this...


Yes this is the setting we are discussing, the actual specific
discussion is how SSSD gets the information.

Honza proposed to use a PKCS#11-like schema to store data in LDAP given
DNS will need something similar, however the more we wandered into the
discussion the more I got convinced the Vault is probably a better place
to store this material than the LDAP tree itself at least for prvate
keys.


I only proposed something that would work for my needs (i.e. storing 
certificates and associated trust policy) and would be ready for 4.0. 
Can you say the same thing about the vault?




For public key material only though I am not sure a pkcs#11 schema will
necessarily be useful. It might, but we do not use it for public SSH
keys. And we also already have schema for public User or Servers X509
certs.


Support for SSH public keys was implemented like 2 years ago, way before 
any talk about the vault or PKCS#11 even started. As for certs, the 
proposed schema works on top of RFC 4523, which is the cert schema you 
mention.




We need to define something for DNS public keys, but they are already
published in DNS Records too if I am not wrong, would that be sufficient
as a storage for the public part ? I am assuming the private keys are
stored in the Vault and they can be files in the format used by bind ?


So the information would be scattered in different places, using 
different formats and accessed using different protocols? I'm fine with 
that, but it is way beyond my original idea, so please let whoever is in 
charge of the vault implement the PKCS#11 module themselves.




Simo.





--
Jan Cholasta

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

Re: [Freeipa-devel] DNSSEC design page


On 26.2.2014 17:37, Petr Spacek wrote:

On 26.2.2014 15:20, Ludwig Krispenz wrote:

I was talking about 'layer of indirection' previously. I'm digging into
details and it seems like a good idea to imitate what DNS registrars do
- use concept of key sets. It means that keys are not linked to a zone
one by one but rather a whole set of keys is linked to a zone.

It eases key rotation because you just need to drop a new key to a key
set and you don't have to add DNs of all zones to the new key (or the
other way around).

Another thing is that you could have different key rotation policies
for
different key sets... we need to think about it carefully.

For example (without policies for now):
- two DNS zones example.com and example.net contain a pointer to keyset
called 'setA'
- zone objects: idnsname=example.net,cn=dns and
idnsname=example.com,cn=dns

- key sets are stored under cn=keysets, cn=sec, cn=dns

- individual keys are stored under keyid=key1, keysetid=setA,
cn=keysets, cn=sec, cn=dns


How will the PKCS#11 module know into which keyset to store a key
generated
by OpenDNSSEC? Are you suggesting having a separate slot/token for each
keyset? I would like to keep the number of tokens low, because there are
applications which go slot by slot, token by token when searching for
objects (e.g. BIND and OpenSSH) and that might generate a lot of
unnecessary
traffic if the number of slots/tokens is high.

Okay, then we can store all DNSSEC keys in one slot and use key sets
only for administrative purposes (i.e. pairing zone = keys in BIND)
but it will be invisible for PKCS#11 interface.

Key set maintenance has to go over side channel for metadata and not
over PKCS#11.


Yep.




The pkcs11 data stored in ldap should represent pkcs11 objects. Other
entries
could reference these objects, eg a zone referencing a key. I don't
think we
should store references to other entries in an pkcs11 object. if you
want this
we probably need another auxiliary objectclass for these pkcs11 entries.

Regarding objectclasses for the pkcs11 objects, what should be the
structural
objectclass and what the naming attribute ?
So far I had defined the publicKey, privateKey, certificate
objectclass all as
auxiliary, maybe we should have one structural like pkcs11Object
containing
the required attrs like id, label, ...
and a naming attr if it is not one of them

This sounds like a good idea.



+1, although what we refer to as object is referred to as storage 
object in the PKCS#11 spec, so we might name the object class 
ipaPkcs11storageObject.


As for the naming attribute, the only PKCS#11 attribute that can't ever 
be empty is CKA_CLASS, so I guess we'll have to use ipaUniqueId.


--
Jan Cholasta

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

Re: [Freeipa-devel] DNSSEC design page



On 02/27/2014 10:17 AM, Jan Cholasta wrote:

On 26.2.2014 17:37, Petr Spacek wrote:

On 26.2.2014 15:20, Ludwig Krispenz wrote:
I was talking about 'layer of indirection' previously. I'm digging 
into
details and it seems like a good idea to imitate what DNS 
registrars do
- use concept of key sets. It means that keys are not linked to a 
zone

one by one but rather a whole set of keys is linked to a zone.

It eases key rotation because you just need to drop a new key to a 
key

set and you don't have to add DNs of all zones to the new key (or the
other way around).

Another thing is that you could have different key rotation policies
for
different key sets... we need to think about it carefully.

For example (without policies for now):
- two DNS zones example.com and example.net contain a pointer to 
keyset

called 'setA'
- zone objects: idnsname=example.net,cn=dns and
idnsname=example.com,cn=dns

- key sets are stored under cn=keysets, cn=sec, cn=dns

- individual keys are stored under keyid=key1, keysetid=setA,
cn=keysets, cn=sec, cn=dns


How will the PKCS#11 module know into which keyset to store a key
generated
by OpenDNSSEC? Are you suggesting having a separate slot/token for 
each
keyset? I would like to keep the number of tokens low, because 
there are

applications which go slot by slot, token by token when searching for
objects (e.g. BIND and OpenSSH) and that might generate a lot of
unnecessary
traffic if the number of slots/tokens is high.

Okay, then we can store all DNSSEC keys in one slot and use key sets
only for administrative purposes (i.e. pairing zone = keys in BIND)
but it will be invisible for PKCS#11 interface.

Key set maintenance has to go over side channel for metadata and not
over PKCS#11.


Yep.




The pkcs11 data stored in ldap should represent pkcs11 objects. Other
entries
could reference these objects, eg a zone referencing a key. I don't
think we
should store references to other entries in an pkcs11 object. if you
want this
we probably need another auxiliary objectclass for these pkcs11 
entries.


Regarding objectclasses for the pkcs11 objects, what should be the
structural
objectclass and what the naming attribute ?
So far I had defined the publicKey, privateKey, certificate
objectclass all as
auxiliary, maybe we should have one structural like pkcs11Object
containing
the required attrs like id, label, ...
and a naming attr if it is not one of them

This sounds like a good idea.



+1, although what we refer to as object is referred to as storage 
object in the PKCS#11 spec, so we might name the object class 
ipaPkcs11storageObject.


As for the naming attribute, the only PKCS#11 attribute that can't 
ever be empty is CKA_CLASS, so I guess we'll have to use ipaUniqueId.
do you mean to use this attributename or to use its values. I'd prefer 
to make the schema independent of other definitions if possible, so I 
thought of something like pkcs11objectId, which can have the same syntax 
as ipaUniqueid and use the same semantics.


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

Re: [Freeipa-devel] DNSSEC design page


On 27.2.2014 11:28, Ludwig Krispenz wrote:


On 02/27/2014 10:17 AM, Jan Cholasta wrote:

On 26.2.2014 17:37, Petr Spacek wrote:

On 26.2.2014 15:20, Ludwig Krispenz wrote:

I was talking about 'layer of indirection' previously. I'm digging
into
details and it seems like a good idea to imitate what DNS
registrars do
- use concept of key sets. It means that keys are not linked to a
zone
one by one but rather a whole set of keys is linked to a zone.

It eases key rotation because you just need to drop a new key to a
key
set and you don't have to add DNs of all zones to the new key (or the
other way around).

Another thing is that you could have different key rotation policies
for
different key sets... we need to think about it carefully.

For example (without policies for now):
- two DNS zones example.com and example.net contain a pointer to
keyset
called 'setA'
- zone objects: idnsname=example.net,cn=dns and
idnsname=example.com,cn=dns

- key sets are stored under cn=keysets, cn=sec, cn=dns

- individual keys are stored under keyid=key1, keysetid=setA,
cn=keysets, cn=sec, cn=dns


How will the PKCS#11 module know into which keyset to store a key
generated
by OpenDNSSEC? Are you suggesting having a separate slot/token for
each
keyset? I would like to keep the number of tokens low, because
there are
applications which go slot by slot, token by token when searching for
objects (e.g. BIND and OpenSSH) and that might generate a lot of
unnecessary
traffic if the number of slots/tokens is high.

Okay, then we can store all DNSSEC keys in one slot and use key sets
only for administrative purposes (i.e. pairing zone = keys in BIND)
but it will be invisible for PKCS#11 interface.

Key set maintenance has to go over side channel for metadata and not
over PKCS#11.


Yep.




The pkcs11 data stored in ldap should represent pkcs11 objects. Other
entries
could reference these objects, eg a zone referencing a key. I don't
think we
should store references to other entries in an pkcs11 object. if you
want this
we probably need another auxiliary objectclass for these pkcs11
entries.

Regarding objectclasses for the pkcs11 objects, what should be the
structural
objectclass and what the naming attribute ?
So far I had defined the publicKey, privateKey, certificate
objectclass all as
auxiliary, maybe we should have one structural like pkcs11Object
containing
the required attrs like id, label, ...
and a naming attr if it is not one of them

This sounds like a good idea.



+1, although what we refer to as object is referred to as storage
object in the PKCS#11 spec, so we might name the object class
ipaPkcs11storageObject.

As for the naming attribute, the only PKCS#11 attribute that can't
ever be empty is CKA_CLASS, so I guess we'll have to use ipaUniqueId.

do you mean to use this attributename or to use its values. I'd prefer
to make the schema independent of other definitions if possible, so I
thought of something like pkcs11objectId, which can have the same syntax
as ipaUniqueid and use the same semantics.



I meant ipaUniqueId the attribute, but I'm fine with anything else 
(pkcs11UniqueId perhaps? to avoid confusion with pkcs11Id)


--
Jan Cholasta

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

Re: [Freeipa-devel] DNSSEC design page


On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted. SoftHsm has
one component Softdatabase with an API, which more or less passes sets
of attributes (attributes defined by PKCS#11) and then stores it as
records in sql where each record has a keytype and opaque blob of
data.
If that is what is wanted the decision would be how fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we can
use
a single attribute containing PKCS#8 encoded private key rather than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, high-level
overview etc. There is still some confusion, probably from fact that we
want to use the same module for cert distribution and at the same time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway: 
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.


Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is 
CKA_CERTIFICATE_CATEGORY which can have values unspecified, token 
user, authority and other entity. We could map entries with object 
class pkiUser to certificate object with CKA_CERTIFICATE_CATEGORY token 
user and entries with object class pkiCA to certificate object with 
CKA_CERTIFICATE_CATEGORY authority. There are no object classes in RFC 
4523 for unspecified and other entity, but we will not be storing 
any certificates using PKCS#11 anyway, so I think it's OK.


Also the above got me thinking, is there any standard LDAP schema for 
private keys? If so, can we use it?


I'm going to store NSS trust objects along with CA certificates, so I'm 
going to need an object class for that. You can find the details on 
CKO_NSS_TRUST at 
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html.


If we store multiple related PKCS#11 objects in a single LDAP entry, 
there is going to be some redundancy. For example, public key value can 
be extracted from private key value, so we don't need to store both of 
the values. This can be bypassed by having separate object classes for 
data and for metadata. For a key pair entry, the object classes would be 
e.g. privateKey, pkcs11privateKey and pkcs11publicKey, where privateKey 
is an object class with private key data (without any PKCS#11 bits), 
pkcs11privateKey is an object class with PKCS#11 private key metadata 
and pkcs11publicKey is an object class with PKCS#11 public key metadata. 
In the PKCS#11 module, this entry would be visible as two separate 
objects (private key object and public key object).


Regarding PKCS#11 metadata attributes (i.e. excluding certificate, 
private key and public key value attributes), I think they all should be 
single-valued. Comments on specific attributes:


  * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, 
CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, 
CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS, CKA_VERIFY_RECOVER, 
CKA_SIGN_RECOVER, CKA_ALWAYS_SENSITIVE, CKA_NEVER_EXTRACTABLE, 
CKA_WRAP_WITH_TRUSTED, CKA_ALWAYS_AUTHENTICATE - there should be LDAP 
attributes for these, for the sake of completeness


  * CKA_TOKEN - this is CK_TRUE for persistent objects and objects in 
LDAP are always persistent, so there is no need for pkcs11token


  * CKA_CERTIFICATE_TYPE - this will always be CKC_X_509, no need for 
pkcs11certificateType


  * CKA_CERTIFICATE_CATEGORY - if this is mapped to RFC 4523 object 
classes (see above), we don't need an LDAP attribute for it


  * CKA_CHECK_VALUE, CKA_HASH_OF_SUBJECT_PUBLIC_KEY, 
CKA_HASH_OF_ISSUER_PUBLIC_KEY - can be generated on-the-fly from 
certificate value, no need for LDAP attributes


  * CKA_URL - do we want to support certificates with URL instead of value?

--
Jan Cholasta

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

Re: [Freeipa-devel] DNSSEC design page



On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted. 
SoftHsm has
one component Softdatabase with an API, which more or less 
passes sets
of attributes (attributes defined by PKCS#11) and then stores 
it as

records in sql where each record has a keytype and opaque blob of
data.
If that is what is wanted the decision would be how fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be 
the most

straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we 
can

use
a single attribute containing PKCS#8 encoded private key rather 
than

using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate 
objects.


So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, high-level
overview etc. There is still some confusion, probably from fact 
that we

want to use the same module for cert distribution and at the same time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway: 
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.


Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is 
CKA_CERTIFICATE_CATEGORY which can have values unspecified, token 
user, authority and other entity. We could map entries with 
object class pkiUser to certificate object with 
CKA_CERTIFICATE_CATEGORY token user and entries with object class 
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY authority. 
There are no object classes in RFC 4523 for unspecified and other 
entity, but we will not be storing any certificates using PKCS#11 
anyway, so I think it's OK.
not sure I understand what exactly you want here. If we don't store 
certificates using the pkcs#11 schema we don't need to define them, but 
on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY. 
Do you mean to have a pkcs11 cerificate object with 
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes 
userCertificate and cACertificate to store them ?


Also the above got me thinking, is there any standard LDAP schema 
for private keys? If so, can we use it?
I didn't find any, the only keys in ldap I found is a definition for 
sshPublicKey for openssh.


I'm going to store NSS trust objects along with CA certificates, so 
I'm going to need an object class for that. You can find the details 
on CKO_NSS_TRUST at 
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html.


If we store multiple related PKCS#11 objects in a single LDAP entry, 
there is going to be some redundancy. For example, public key value 
can be extracted from private key value, so we don't need to store 
both of the values. This can be bypassed by having separate object 
classes for data and for metadata. For a key pair entry, the object 
classes would be e.g. privateKey, pkcs11privateKey and 
pkcs11publicKey, where privateKey is an object class with private key 
data (without any PKCS#11 bits), pkcs11privateKey is an object class 
with PKCS#11 private key metadata and pkcs11publicKey is an object 
class with PKCS#11 public key metadata. In the PKCS#11 module, this 
entry would be visible as two separate objects (private key object and 
public key object).
I have not yet rewritten the objectcalss definition after the latest 
discussion, but I think if we have one structural objectclass 
pkcs11storageObject with only a uniqueid and auxiliary objectclasses for 
publickey,privatekey, certificate where the attributes (maybe 
withexception of label, id) are optional there will be no redundancy, 
store only what is needed.
you could use these aux objectclass also in other entries instead of 
using pkcs11storageObject.


Regarding PKCS#11 metadata attributes (i.e. excluding certificate, 
private key and public key value attributes), I think they all should 
be single-valued. Comments on specific attributes:


  * CKA_MODIFIABLE, CKA_SUBJECT, CKA_ISSUER, CKA_SERIAL_NUMBER, 
CKA_JAVA_MIDP_SECURITY_DOMAIN, CKA_DERIVE, CKA_LOCAL, 
CKA_KEY_GEN_MECHANISM, CKA_ALLOWED_MECHANISMS,

Re: [Freeipa-devel] DNSSEC design page


On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque blob of
data.
If that is what is wanted the decision would be how fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we
can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, high-level
overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the same time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values unspecified, token
user, authority and other entity. We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY token user and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY authority.
There are no object classes in RFC 4523 for unspecified and other
entity, but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them, but
on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY.
Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map 
PKCS#11 objects like this:


CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: id
userCertificate;binary: cert
other attrs

and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: id
caCertificate;binary: cert
other attrs

In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from 
objectClass, CKA_CERTIFICATE_CATEGORY: 1 = objectClass: pkiUser 
and CKA_CERTIFICATE_CATEGORY: 2 = objectClass: pkiCA.




Also the above got me thinking, is there any standard LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html.


If we store multiple related PKCS#11 objects in a single LDAP entry,
there is going to be some redundancy. For example, public key value
can be extracted from private key value, so we don't need to store
both of the values. This can be bypassed by having separate object
classes for data and for metadata. For a key pair entry, the object
classes would be e.g. privateKey, pkcs11privateKey and
pkcs11publicKey, where privateKey is an object class with private key
data (without any PKCS#11 bits), pkcs11privateKey is an object class
with

Re: [Freeipa-devel] DNSSEC design page



On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque 
blob of

data.
If that is what is wanted the decision would be how 
fingrained the

pkcs
objects/attribute types would have to be mapped to ldap: one 
ldap

attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we
can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible 
PKCS#11
attribute, ATM it would be sufficient to have just these 
attributes

necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, high-level
overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the same 
time

for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values unspecified, token
user, authority and other entity. We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY token user and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY authority.
There are no object classes in RFC 4523 for unspecified and other
entity, but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them, but
on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY.
Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map 
PKCS#11 objects like this:


CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: id
userCertificate;binary: cert
other attrs

and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: id
caCertificate;binary: cert
other attrs

In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from 
objectClass, CKA_CERTIFICATE_CATEGORY: 1 = objectClass: pkiUser 
and CKA_CERTIFICATE_CATEGORY: 2 = objectClass: pkiCA.

so you want to directly use the pkiUser|CA objectclass, that would be ok




Also the above got me thinking, is there any standard LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html. 

so this is a nss  extension to pkcs11, not in the standard ? If we add 
trust objects, should the naming reflect this like pkcs11nssattr or 
pkcs11extattr ?



If we store multiple related PKCS#11 objects in a single LDAP entry,
there is going to be some redundancy. For example, public key value
can be extracted from private key value, so we don't need to store
both of the values. This can be bypassed by

Re: [Freeipa-devel] DNSSEC design page

2014-02-27 Thread Petr Spacek


On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque blob of
data.
If that is what is wanted the decision would be how fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we
can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, high-level
overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the same time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values unspecified, token
user, authority and other entity. We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY token user and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY authority.
There are no object classes in RFC 4523 for unspecified and other
entity, but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them, but
on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY.
Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map
PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: id
userCertificate;binary: cert
other attrs

and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: id
caCertificate;binary: cert
other attrs

In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
objectClass, CKA_CERTIFICATE_CATEGORY: 1 = objectClass: pkiUser and
CKA_CERTIFICATE_CATEGORY: 2 = objectClass: pkiCA.

so you want to directly use the pkiUser|CA objectclass, that would be ok




Also the above got me thinking, is there any standard LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html.


so this is a nss  extension to pkcs11, not in the standard ? If we add trust
objects, should the naming reflect this like pkcs11nssattr or pkcs11extattr 
?



If we store multiple related PKCS#11 objects in a single LDAP entry,
there is going to be some redundancy. For example, public key value
can be extracted from private key value, so we don't need to store
both of the

Re: [Freeipa-devel] DNSSEC design page

2014-02-27 Thread Rich Megginson


On 02/27/2014 09:37 AM, Petr Spacek wrote:

On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in 
softhsm.

That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque 
blob of

data.
If that is what is wanted the decision would be how 
fingrained the

pkcs
objects/attribute types would have to be mapped to ldap: 
one ldap

attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said 
above, we

can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible 
PKCS#11
attribute, ATM it would be sufficient to have just these 
attributes

necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, 
high-level

overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the 
same time

for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values unspecified, token
user, authority and other entity. We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY token user and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY 
authority.

There are no object classes in RFC 4523 for unspecified and other
entity, but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them, 
but
on the other hand you talk about the usage of 
CKA_CERTIFICATE_CATEGORY.

Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map
PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: id
userCertificate;binary: cert
other attrs

and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: id
caCertificate;binary: cert
other attrs

In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
objectClass, CKA_CERTIFICATE_CATEGORY: 1 = objectClass: 
pkiUser and

CKA_CERTIFICATE_CATEGORY: 2 = objectClass: pkiCA.

so you want to directly use the pkiUser|CA objectclass, that would be ok




Also the above got me thinking, is there any standard LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html. 



so this is a nss  extension to pkcs11, not in the standard ? If we 
add trust
objects, should the naming reflect this like pkcs11nssattr or 
pkcs11extattr ?



If we store multiple related PKCS#11 objects in a single LDAP entry,
there is going to be some redundancy. For example, public key value
can be

Re: [Freeipa-devel] DNSSEC design page


On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque
blob of
data.
If that is what is wanted the decision would be how
fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one
ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we
can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible
PKCS#11
attribute, ATM it would be sufficient to have just these
attributes
necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, high-level
overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the same
time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values unspecified, token
user, authority and other entity. We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY token user and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY authority.
There are no object classes in RFC 4523 for unspecified and other
entity, but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them, but
on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY.
Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map
PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: id
userCertificate;binary: cert
other attrs

and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: id
caCertificate;binary: cert
other attrs

In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
objectClass, CKA_CERTIFICATE_CATEGORY: 1 = objectClass: pkiUser
and CKA_CERTIFICATE_CATEGORY: 2 = objectClass: pkiCA.

so you want to directly use the pkiUser|CA objectclass, that would be ok


I think it would make sense after all, if that's OK by the present LDAP 
gurus :-)






Also the above got me thinking, is there any standard LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html.


so this is a nss  extension to pkcs11, not in the standard ? If we add
trust objects, should the naming reflect this like pkcs11nssattr or
pkcs11extattr ?


Yes, it's a NSS vendor-specific extension. I like the prefix pkcs11nss.




If we store multiple related PKCS#11 objects in a single

Re: [Freeipa-devel] DNSSEC design page



On 02/27/2014 05:48 PM, Jan Cholasta wrote:

On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in 
softhsm.

That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque
blob of
data.
If that is what is wanted the decision would be how
fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one
ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said 
above, we

can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible
PKCS#11
attribute, ATM it would be sufficient to have just these
attributes
necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, 
high-level

overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the same
time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values unspecified, token
user, authority and other entity. We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY token user and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY 
authority.

There are no object classes in RFC 4523 for unspecified and other
entity, but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them, 
but
on the other hand you talk about the usage of 
CKA_CERTIFICATE_CATEGORY.

Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map
PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: id
userCertificate;binary: cert
other attrs

and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: id
caCertificate;binary: cert
other attrs

In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
objectClass, CKA_CERTIFICATE_CATEGORY: 1 = objectClass: pkiUser
and CKA_CERTIFICATE_CATEGORY: 2 = objectClass: pkiCA.

so you want to directly use the pkiUser|CA objectclass, that would be ok


I think it would make sense after all, if that's OK by the present 
LDAP gurus :-)






Also the above got me thinking, is there any standard LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html. 




so this is a nss  extension to pkcs11, not in the standard ? If we add
trust objects, should the naming reflect this like pkcs11nssattr or
pkcs11extattr ?


Yes, it's a NSS vendor-specific extension. I like the prefix pkcs11nss.

Re: [Freeipa-devel] DNSSEC design page


On 27.2.2014 17:49, Ludwig Krispenz wrote:


On 02/27/2014 05:48 PM, Jan Cholasta wrote:

On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in
softhsm.
That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque
blob of
data.
If that is what is wanted the decision would be how
fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one
ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said
above, we
can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible
PKCS#11
attribute, ATM it would be sufficient to have just these
attributes
necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement,
high-level
overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the same
time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values unspecified, token
user, authority and other entity. We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY token user and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY
authority.
There are no object classes in RFC 4523 for unspecified and other
entity, but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them,
but
on the other hand you talk about the usage of
CKA_CERTIFICATE_CATEGORY.
Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map
PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: id
userCertificate;binary: cert
other attrs

and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: id
caCertificate;binary: cert
other attrs

In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
objectClass, CKA_CERTIFICATE_CATEGORY: 1 = objectClass: pkiUser
and CKA_CERTIFICATE_CATEGORY: 2 = objectClass: pkiCA.

so you want to directly use the pkiUser|CA objectclass, that would be ok


I think it would make sense after all, if that's OK by the present
LDAP gurus :-)





Also the above got me thinking, is there any standard LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html.



so this is a nss  extension to pkcs11, not in the standard ? If we add
trust objects, should the naming reflect this like pkcs11nssattr or
pkcs11extattr ?


Yes, it's a NSS vendor-specific extension. I

Re: [Freeipa-devel] DNSSEC design page



On 02/27/2014 05:46 PM, Rich Megginson wrote:

On 02/27/2014 09:37 AM, Petr Spacek wrote:

On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in 
softhsm.

That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque 
blob of

data.
If that is what is wanted the decision would be how 
fingrained the

pkcs
objects/attribute types would have to be mapped to ldap: 
one ldap

attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said 
above, we

can
use
a single attribute containing PKCS#8 encoded private key 
rather

than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible 
PKCS#11
attribute, ATM it would be sufficient to have just these 
attributes

necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, 
high-level

overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the 
same time

for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values unspecified, token
user, authority and other entity. We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY token user and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY 
authority.

There are no object classes in RFC 4523 for unspecified and other
entity, but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define 
them, but
on the other hand you talk about the usage of 
CKA_CERTIFICATE_CATEGORY.

Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map
PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: id
userCertificate;binary: cert
other attrs

and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: id
caCertificate;binary: cert
other attrs

In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
objectClass, CKA_CERTIFICATE_CATEGORY: 1 = objectClass: 
pkiUser and

CKA_CERTIFICATE_CATEGORY: 2 = objectClass: pkiCA.
so you want to directly use the pkiUser|CA objectclass, that would 
be ok




Also the above got me thinking, is there any standard LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html. 



so this is a nss  extension to pkcs11, not in the standard ? If we 
add trust
objects, should the naming reflect this like pkcs11nssattr or 
pkcs11extattr ?



If we store multiple related PKCS#11 objects in a single LDAP entry,
there is going to be some

Re: [Freeipa-devel] DNSSEC design page

2014-02-27 Thread Petr Spacek


On 27.2.2014 17:55, Ludwig Krispenz wrote:


On 02/27/2014 05:46 PM, Rich Megginson wrote:

On 02/27/2014 09:37 AM, Petr Spacek wrote:

On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then stores
it as
records in sql where each record has a keytype and opaque blob of
data.
If that is what is wanted the decision would be how fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be
the most
straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we
can
use
a single attribute containing PKCS#8 encoded private key rather
than
using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate
objects.

So, I would say it should be something between high-level and
low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, high-level
overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the same time
for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values unspecified, token
user, authority and other entity. We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY token user and entries with object class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY authority.
There are no object classes in RFC 4523 for unspecified and other
entity, but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define them, but
on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY.
Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could map
PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: id
userCertificate;binary: cert
other attrs

and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: id
caCertificate;binary: cert
other attrs

In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
objectClass, CKA_CERTIFICATE_CATEGORY: 1 = objectClass: pkiUser and
CKA_CERTIFICATE_CATEGORY: 2 = objectClass: pkiCA.

so you want to directly use the pkiUser|CA objectclass, that would be ok




Also the above got me thinking, is there any standard LDAP schema
for private keys? If so, can we use it?

I didn't find any, the only keys in ldap I found is a definition for
sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA certificates, so
I'm going to need an object class for that. You can find the details
on CKO_NSS_TRUST at
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html.



so this is a nss  extension to pkcs11, not in the standard ? If we add trust
objects, should the naming reflect this like pkcs11nssattr or
pkcs11extattr ?



If we store multiple related PKCS#11 objects in a single LDAP entry,
there is going

Re: [Freeipa-devel] DNSSEC design page

2014-02-27 Thread Rich Megginson


On 02/27/2014 01:10 PM, Petr Spacek wrote:

On 27.2.2014 17:55, Ludwig Krispenz wrote:


On 02/27/2014 05:46 PM, Rich Megginson wrote:

On 02/27/2014 09:37 AM, Petr Spacek wrote:

On 27.2.2014 17:24, Ludwig Krispenz wrote:


On 02/27/2014 03:56 PM, Jan Cholasta wrote:

On 27.2.2014 15:23, Ludwig Krispenz wrote:


On 02/27/2014 02:14 PM, Jan Cholasta wrote:

On 18.2.2014 17:19, Martin Kosek wrote:

On 02/18/2014 04:38 PM, Jan Cholasta wrote:

On 18.2.2014 16:35, Petr Spacek wrote:

On 18.2.2014 16:31, Jan Cholasta wrote:


2] low level replacement for eg the sqlite3 database in 
softhsm.

That's what I sometimes get the impression what is wanted.
SoftHsm has
one component Softdatabase with an API, which more or less
passes sets
of attributes (attributes defined by PKCS#11) and then 
stores

it as
records in sql where each record has a keytype and 
opaque blob of

data.
If that is what is wanted the decision would be how 
fingrained the

pkcs
objects/attribute types would have to be mapped to ldap: 
one ldap

attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP 
would be

the most
straightforward way of doing this, but I think we can do 
some
optimization for our needs. For example, like you said 
above, we

can
use
a single attribute containing PKCS#8 encoded private key 
rather

than
using one attribute per private key component.

I don't think we need an LDAP attribute for every 
possible PKCS#11
attribute, ATM it would be sufficient to have just these 
attributes
necessary to represent private key, public key and 
certificate

objects.

So, I would say it should be something between high-level 
and

low-level.


There won't be a separate public key, it's represented by the
certificate.


I'm not sure if this is the case for DNSSEC.


Honzo,

we really need the design page with some goal statement, 
high-level

overview etc. There is still some confusion, probably from fact
that we
want to use the same module for cert distribution and at the 
same time

for DNSSEC key storage.



It's on my TODO list, I'll try to get it out ASAP.



+1, please do. We clearly need some design to start with.

Martin



I already posted the link in other thread, but here it is anyway:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.

Some more comments on the schema:

I think I may have been too quick to dismiss RFC 4523. There is
CKA_CERTIFICATE_CATEGORY which can have values unspecified, 
token

user, authority and other entity. We could map entries with
object class pkiUser to certificate object with
CKA_CERTIFICATE_CATEGORY token user and entries with object 
class
pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY 
authority.
There are no object classes in RFC 4523 for unspecified and 
other

entity, but we will not be storing any certificates using PKCS#11
anyway, so I think it's OK.

not sure I understand what exactly you want here. If we don't store
certificates using the pkcs#11 schema we don't need to define 
them, but
on the other hand you talk about the usage of 
CKA_CERTIFICATE_CATEGORY.

Do you mean to have a pkcs11 cerificate object with
CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
userCertificate and cACertificate to store them ?


Hopefully an example will better illustrate what I mean. We could 
map

PKCS#11 objects like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 1
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiUser
pkcs11uniqueId: id
userCertificate;binary: cert
other attrs

and PKCS#11 object like this:

CKA_CLASS: CKO_CERTIFICATE
CKA_CERTIFICATE_TYPE: CKC_X_509
CKA_CERTIFICATE_CATEGORY: 2
CKA_VALUE: cert
other attrs

to LDAP entries like this:

dn: pkcs11uniqueId=id,suffix
objectClass: pkcs11storageObject
objectClass: pkiCA
pkcs11uniqueId: id
caCertificate;binary: cert
other attrs

In other words, the value of CKA_CERTIFICATE_CATEGORY is implied 
from
objectClass, CKA_CERTIFICATE_CATEGORY: 1 = objectClass: 
pkiUser and

CKA_CERTIFICATE_CATEGORY: 2 = objectClass: pkiCA.
so you want to directly use the pkiUser|CA objectclass, that would 
be ok




Also the above got me thinking, is there any standard LDAP 
schema

for private keys? If so, can we use it?
I didn't find any, the only keys in ldap I found is a definition 
for

sshPublicKey for openssh.


And even this schema is for public keys only :-) OK, nevermind then.



I'm going to store NSS trust objects along with CA 
certificates, so
I'm going to need an object class for that. You can find the 
details

on CKO_NSS_TRUST at
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html. 




so this is a nss  extension to pkcs11, not in the standard ? If we 
add trust

objects, should the naming reflect this like pkcs11nssattr or

Re: [Freeipa-devel] DNSSEC design page

2014-02-27 Thread Martin Kosek

On 02/27/2014 05:46 PM, Rich Megginson wrote:
 On 02/27/2014 09:37 AM, Petr Spacek wrote:
 On 27.2.2014 17:24, Ludwig Krispenz wrote:

 On 02/27/2014 03:56 PM, Jan Cholasta wrote:
 On 27.2.2014 15:23, Ludwig Krispenz wrote:

 On 02/27/2014 02:14 PM, Jan Cholasta wrote:
 On 18.2.2014 17:19, Martin Kosek wrote:
 On 02/18/2014 04:38 PM, Jan Cholasta wrote:
 On 18.2.2014 16:35, Petr Spacek wrote:
 On 18.2.2014 16:31, Jan Cholasta wrote:

 2] low level replacement for eg the sqlite3 database in softhsm.
 That's what I sometimes get the impression what is wanted.
 SoftHsm has
 one component Softdatabase with an API, which more or less
 passes sets
 of attributes (attributes defined by PKCS#11) and then stores
 it as
 records in sql where each record has a keytype and opaque blob of
 data.
 If that is what is wanted the decision would be how fingrained the
 pkcs
 objects/attribute types would have to be mapped to ldap: one ldap
 attribute for each possible attribute type ?

 One-to-one mapping of attributes from PKCS#11 to LDAP would be
 the most
 straightforward way of doing this, but I think we can do some
 optimization for our needs. For example, like you said above, we
 can
 use
 a single attribute containing PKCS#8 encoded private key rather
 than
 using one attribute per private key component.

 I don't think we need an LDAP attribute for every possible PKCS#11
 attribute, ATM it would be sufficient to have just these attributes
 necessary to represent private key, public key and certificate
 objects.

 So, I would say it should be something between high-level and
 low-level.

 There won't be a separate public key, it's represented by the
 certificate.

 I'm not sure if this is the case for DNSSEC.

 Honzo,

 we really need the design page with some goal statement, high-level
 overview etc. There is still some confusion, probably from fact
 that we
 want to use the same module for cert distribution and at the same time
 for DNSSEC key storage.


 It's on my TODO list, I'll try to get it out ASAP.


 +1, please do. We clearly need some design to start with.

 Martin


 I already posted the link in other thread, but here it is anyway:
 http://www.freeipa.org/page/V3/PKCS11_in_LDAP.

 Some more comments on the schema:

 I think I may have been too quick to dismiss RFC 4523. There is
 CKA_CERTIFICATE_CATEGORY which can have values unspecified, token
 user, authority and other entity. We could map entries with
 object class pkiUser to certificate object with
 CKA_CERTIFICATE_CATEGORY token user and entries with object class
 pkiCA to certificate object with CKA_CERTIFICATE_CATEGORY authority.
 There are no object classes in RFC 4523 for unspecified and other
 entity, but we will not be storing any certificates using PKCS#11
 anyway, so I think it's OK.
 not sure I understand what exactly you want here. If we don't store
 certificates using the pkcs#11 schema we don't need to define them, but
 on the other hand you talk about the usage of CKA_CERTIFICATE_CATEGORY.
 Do you mean to have a pkcs11 cerificate object with
 CKA_CERTIFICATE_CATEGORY and allow the the rfc4523 attributes
 userCertificate and cACertificate to store them ?

 Hopefully an example will better illustrate what I mean. We could map
 PKCS#11 objects like this:

 CKA_CLASS: CKO_CERTIFICATE
 CKA_CERTIFICATE_TYPE: CKC_X_509
 CKA_CERTIFICATE_CATEGORY: 1
 CKA_VALUE: cert
 other attrs

 to LDAP entries like this:

 dn: pkcs11uniqueId=id,suffix
 objectClass: pkcs11storageObject
 objectClass: pkiUser
 pkcs11uniqueId: id
 userCertificate;binary: cert
 other attrs

 and PKCS#11 object like this:

 CKA_CLASS: CKO_CERTIFICATE
 CKA_CERTIFICATE_TYPE: CKC_X_509
 CKA_CERTIFICATE_CATEGORY: 2
 CKA_VALUE: cert
 other attrs

 to LDAP entries like this:

 dn: pkcs11uniqueId=id,suffix
 objectClass: pkcs11storageObject
 objectClass: pkiCA
 pkcs11uniqueId: id
 caCertificate;binary: cert
 other attrs

 In other words, the value of CKA_CERTIFICATE_CATEGORY is implied from
 objectClass, CKA_CERTIFICATE_CATEGORY: 1 = objectClass: pkiUser and
 CKA_CERTIFICATE_CATEGORY: 2 = objectClass: pkiCA.
 so you want to directly use the pkiUser|CA objectclass, that would be ok


 Also the above got me thinking, is there any standard LDAP schema
 for private keys? If so, can we use it?
 I didn't find any, the only keys in ldap I found is a definition for
 sshPublicKey for openssh.

 And even this schema is for public keys only :-) OK, nevermind then.


 I'm going to store NSS trust objects along with CA certificates, so
 I'm going to need an object class for that. You can find the details
 on CKO_NSS_TRUST at
 http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html.


 so this is a nss  extension to pkcs11, not in the standard ? If we add trust
 objects, should the naming reflect this like pkcs11nssattr or
 pkcs11extattr ?


 If we store multiple related PKCS#11 objects in

Re: [Freeipa-devel] DNSSEC design page

2014-02-26 Thread Jan Cholasta


On 25.2.2014 20:26, Petr Spacek wrote:

On 25.2.2014 19:13, Dmitri Pal wrote:

On 02/25/2014 08:46 AM, Simo Sorce wrote:

On Tue, 2014-02-25 at 11:08 +0100, Petr Spacek wrote:

On 24.2.2014 20:20, Simo Sorce wrote:

Also can you add some examples on how we would use these classes to
store DNS keys ?

We need to think about it a bit more. We plan to use PKCS#11 for key
manipulation and data signing so the key itself will be unaware of any
DNSSEC-specific attributes. DNSSEC-specifics could be in an auxiliary
objectClass.

I'm discussing this with CZ.NIC guys and they propose to add a
'layer of
indirection' between DNS zones and keys so one key set can be used
by more DNS
zones. They claim that it is relatively common practice and I trust
them.

Note that I'm not saying that IPA should use one key for multiple
DNS zones by
default, but the schema should be future-proof and allow that if
necessary.

Makes sense.


Let's start with this proposal:
DNS zone: idnsname=dnssec.test, cn=dns, dc=example
There will be multi-valued attribute idnsseckey pointing to DNs of
keys stored
somewhere else.

Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns
and store
keys there.

Ok, do we really want to have zones pointing at keys ?
Or do we want keys have a list of zones they are supposed to apply to ?



If we plan to store DNS keys in one place and other keys in other
places in
the tree (no common key store) then it really does not matter much.
It should be derived from the LDAP searches that would need to be
conducted by
the software.

We need keys for signing, right?
Any other use case?

In DNSSEC-context no, but the same principle will be re-used for CA
certificates and possibly user-keys (in future, like SSH private keys or
certificated used from Firefox).


If for signing we will start with a zone and would need to find keys
that are
relevant to this zone.
It seems that having a generic key class + auxiliary class that would
keep
metadata about the key, its expiration and DN it applies to would be a
way to go.

Yes, this is the plan.


So it seems that I agree with Simo that it would make sense to have
the zone
the key applies to specified in the key entry rather than in the zone
entry.

Practically it doesn't matter. You have to do either search to find
zones associated with given key or another search to find keys
associated with given zone.

Maybe the version with list of zones stored in key is better from ACI's
point of view. Access to list of zones will be controlled with ACI
attached to the key object.

... Would it be a problem to have bi-directional link between key and
zone (member-memberOf style)? It would ease processing on the client
side and I think that the price is not that high. We can use existing
member and memberOf attributes if we decide to do that.


I expect that PKCS#11 module will handle keys scattered over the
LDAP tree
somehow.

Sure as long as it can understand what the keys are for.


Ideally the example would show the LDAP tree and some example data in
detail, and also what operation we think would be common.


I was talking about 'layer of indirection' previously. I'm digging into
details and it seems like a good idea to imitate what DNS registrars do
- use concept of key sets. It means that keys are not linked to a zone
one by one but rather a whole set of keys is linked to a zone.

It eases key rotation because you just need to drop a new key to a key
set and you don't have to add DNs of all zones to the new key (or the
other way around).

Another thing is that you could have different key rotation policies for
different key sets... we need to think about it carefully.

For example (without policies for now):
- two DNS zones example.com and example.net contain a pointer to keyset
called 'setA'
- zone objects: idnsname=example.net,cn=dns and idnsname=example.com,cn=dns

- key sets are stored under cn=keysets, cn=sec, cn=dns

- individual keys are stored under keyid=key1, keysetid=setA,
cn=keysets, cn=sec, cn=dns


How will the PKCS#11 module know into which keyset to store a key 
generated by OpenDNSSEC? Are you suggesting having a separate slot/token 
for each keyset? I would like to keep the number of tokens low, because 
there are applications which go slot by slot, token by token when 
searching for objects (e.g. BIND and OpenSSH) and that might generate a 
lot of unnecessary traffic if the number of slots/tokens is high.




See the attached picture.

Are you okay with that? If so, we need to somehow add key rotation
policy to this mix :-)

This machinery has to allow algorithm-rollover, keysize-rollover etc.
We can get some inspiration from
https://wiki.opendnssec.org/display/DOCS/kasp.xml . Note that OpenDNSSEC
1.x can't do algorithm-rollover so we need to be creative with the design.


--
Jan Cholasta

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

Re: [Freeipa-devel] DNSSEC design page

2014-02-26 Thread Jan Cholasta


On 25.2.2014 20:22, Simo Sorce wrote:

On Tue, 2014-02-25 at 13:22 -0500, Rob Crittenden wrote:

Jan Cholasta wrote:

On 25.2.2014 17:36, Ludwig Krispenz wrote:


On 02/25/2014 05:12 PM, Simo Sorce wrote:

On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote:

On 25.2.2014 16:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:

On 25.2.2014 15:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:

Any reason why we should follow in detail what softshm does ?

because I did't know what is really needed. If you want to have a
pkcs11
module, which stores data in ldap, I though it should have all the
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
CKA_EXTRACTABLE,
so there is at least one requirement for fine grained attributes.

Does OpenDNSSEC store them as separate entities and need access
to them
independently ?

AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP
schema
doesn't matter as long as our PKCS#11 module can derive all values
defined by
standard.

Honza, you did investigate OpenDNSSEC integration, please add some
details if
you can.


Or is this internal use that can be satisfied by unpacking a blob in
OpenDNSSEC ?

What does bind9 uses ? Petr, can you provide example key files ?

Private+public keys stored in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html


Private keys stored in HSM and public keys in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html

(I.e. some values in .private file are replaced by PKCS#11 label.)

Ok it seem clear to me we do not need to spell out a lot of values
when
using pkcs#11 as bind doesn't need them in the key files. So I
assume it
can query the pkcs#11 module to find what it needs.

I would use these key files as a sort of guide to understand what we
need in LDAP. I would try to put in a single blob as much as we can
that
we do not explicitly need by a client querying LDAP directly.

I think in order to nail down exactly what we need, at this point, we
require some example use cases and queries the various clients would
perform with spelled out what they are looking for to identify or
manipulate keys.

Simo.


See How applications interact with PKCS#11 at
http://www.freeipa.org/page/V3/PKCS11_in_LDAP. Tl;dr: applications
don't search for keys by key data, but by metadata, so like I said in
the other thread, key data can be in a single blob, but metadata should
be in separate attributes.

Ah sorry, I hadn't looked at that one yet.
It helps quite a bit.

So are the class, key_type, id, label, token, 'sign' the only values we
should really care to split off ?


They are all metadata related to PKCS#11 operation. I don't think you
can easily encode them in PKCS#8 or certificate blob, so they actually
need to be split off. You can find the full list of them in the PKCS#11
spec (link below).



Can you describe what are these values ?
What is class ? Why is it important, and how does it differ from
key_type ?
What is the token ? What is 'sign' ?

Feel free to give references to specific documents to read up about
these attributes.

I'm a newcomer to this area and am orienting myself at this doc:
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf
and looking into opendnssec andsofthsm code.


I use mainly
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf, as
2.30 is a draft ATM.



It explains CKA_SIGN as:
TheCKA_SIGN attribute of the signature key, whic h indicates whether
the key supports signatures with appendix, must be CK_TRUE.
I cannot tell if this will be needed, just can make up an attribute and
allow it in an objectclass :-)


OpenDNSSEC puts it in public key objects it generates, so it's needed at
least for the sake of it.

Actually, I think we should support all of the metadata attributes, so
that our PKCS#11 module is reasonably generic and not tailored to needs
of a specific consumer.


We could hardcode some of these values but it will very likely cause
problems later. It seems simple enough to just define schema for all of
them and store them, except perhaps in the cases where they are easily
derived. If we, for example, store the prime numbers and exponents, they
need to be protected as carefully as the private key.


This is something I meant to discuss too, how do we protect them ?
Clearly we have ACIs but I am wondering if we want to encrypt them with
keys not immediately or easily available via LDAP ?

It's kind of catastrofic if they get inadvertently exposed like if
someone does a ldapsearch as Directory Manager, which is one of the
reasons why we encrypt kerberos key material before storing it into the
db.


PKCS#8 allows encryption, I guess we can use that. There needs to be 
some metadata on how to decrypt the blob though, so that the PKCS#11 
module can actually decrypt

Re: [Freeipa-devel] DNSSEC design page

2014-02-26 Thread Ludwig Krispenz




I was talking about 'layer of indirection' previously. I'm digging into
details and it seems like a good idea to imitate what DNS registrars do
- use concept of key sets. It means that keys are not linked to a zone
one by one but rather a whole set of keys is linked to a zone.

It eases key rotation because you just need to drop a new key to a key
set and you don't have to add DNs of all zones to the new key (or the
other way around).

Another thing is that you could have different key rotation policies for
different key sets... we need to think about it carefully.

For example (without policies for now):
- two DNS zones example.com and example.net contain a pointer to keyset
called 'setA'
- zone objects: idnsname=example.net,cn=dns and 
idnsname=example.com,cn=dns


- key sets are stored under cn=keysets, cn=sec, cn=dns

- individual keys are stored under keyid=key1, keysetid=setA,
cn=keysets, cn=sec, cn=dns


How will the PKCS#11 module know into which keyset to store a key 
generated by OpenDNSSEC? Are you suggesting having a separate 
slot/token for each keyset? I would like to keep the number of tokens 
low, because there are applications which go slot by slot, token by 
token when searching for objects (e.g. BIND and OpenSSH) and that 
might generate a lot of unnecessary traffic if the number of 
slots/tokens is high.
The pkcs11 data stored in ldap should represent pkcs11 objects. Other 
entries could reference these objects, eg a zone referencing a key. I 
don't think we should store references to other entries in an pkcs11 
object. if you want this we probably need another auxiliary objectclass 
for these pkcs11 entries.


Regarding objectclasses for the pkcs11 objects, what should be the 
structural objectclass and what the naming attribute ?
So far I had defined the publicKey, privateKey, certificate objectclass 
all as auxiliary, maybe we should have one structural like pkcs11Object 
containing the required attrs like id, label, ...

and a naming attr if it is not one of them

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

Re: [Freeipa-devel] DNSSEC design page

2014-02-26 Thread Rob Crittenden


Jan Cholasta wrote:

On 25.2.2014 20:22, Simo Sorce wrote:

On Tue, 2014-02-25 at 13:22 -0500, Rob Crittenden wrote:

Jan Cholasta wrote:

On 25.2.2014 17:36, Ludwig Krispenz wrote:


On 02/25/2014 05:12 PM, Simo Sorce wrote:

On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote:

On 25.2.2014 16:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:

On 25.2.2014 15:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:

Any reason why we should follow in detail what softshm does ?

because I did't know what is really needed. If you want to
have a
pkcs11
module, which stores data in ldap, I though it should have
all the
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
CKA_EXTRACTABLE,
so there is at least one requirement for fine grained
attributes.

Does OpenDNSSEC store them as separate entities and need access
to them
independently ?

AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP
schema
doesn't matter as long as our PKCS#11 module can derive all values
defined by
standard.

Honza, you did investigate OpenDNSSEC integration, please add some
details if
you can.


Or is this internal use that can be satisfied by unpacking a
blob in
OpenDNSSEC ?

What does bind9 uses ? Petr, can you provide example key files ?

Private+public keys stored in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html



Private keys stored in HSM and public keys in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html


(I.e. some values in .private file are replaced by PKCS#11 label.)

Ok it seem clear to me we do not need to spell out a lot of values
when
using pkcs#11 as bind doesn't need them in the key files. So I
assume it
can query the pkcs#11 module to find what it needs.

I would use these key files as a sort of guide to understand
what we
need in LDAP. I would try to put in a single blob as much as we can
that
we do not explicitly need by a client querying LDAP directly.

I think in order to nail down exactly what we need, at this
point, we
require some example use cases and queries the various clients
would
perform with spelled out what they are looking for to identify or
manipulate keys.

Simo.


See How applications interact with PKCS#11 at
http://www.freeipa.org/page/V3/PKCS11_in_LDAP. Tl;dr: applications
don't search for keys by key data, but by metadata, so like I
said in
the other thread, key data can be in a single blob, but metadata
should
be in separate attributes.

Ah sorry, I hadn't looked at that one yet.
It helps quite a bit.

So are the class, key_type, id, label, token, 'sign' the only
values we
should really care to split off ?


They are all metadata related to PKCS#11 operation. I don't think you
can easily encode them in PKCS#8 or certificate blob, so they actually
need to be split off. You can find the full list of them in the PKCS#11
spec (link below).



Can you describe what are these values ?
What is class ? Why is it important, and how does it differ from
key_type ?
What is the token ? What is 'sign' ?

Feel free to give references to specific documents to read up about
these attributes.

I'm a newcomer to this area and am orienting myself at this doc:
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf
and looking into opendnssec andsofthsm code.


I use mainly
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf, as
2.30 is a draft ATM.



It explains CKA_SIGN as:
TheCKA_SIGN attribute of the signature key, whic h indicates whether
the key supports signatures with appendix, must be CK_TRUE.
I cannot tell if this will be needed, just can make up an attribute
and
allow it in an objectclass :-)


OpenDNSSEC puts it in public key objects it generates, so it's
needed at
least for the sake of it.

Actually, I think we should support all of the metadata attributes, so
that our PKCS#11 module is reasonably generic and not tailored to needs
of a specific consumer.


We could hardcode some of these values but it will very likely cause
problems later. It seems simple enough to just define schema for all of
them and store them, except perhaps in the cases where they are easily
derived. If we, for example, store the prime numbers and exponents, they
need to be protected as carefully as the private key.


This is something I meant to discuss too, how do we protect them ?
Clearly we have ACIs but I am wondering if we want to encrypt them with
keys not immediately or easily available via LDAP ?

It's kind of catastrofic if they get inadvertently exposed like if
someone does a ldapsearch as Directory Manager, which is one of the
reasons why we encrypt kerberos key material before storing it into the
db.


PKCS#8 allows encryption, I guess we can use that. There needs to be
some metadata on how to decrypt the blob though, so that the PKCS#11
module

Re: [Freeipa-devel] DNSSEC design page

2014-02-26 Thread Simo Sorce

On Wed, 2014-02-26 at 15:04 +0100, Jan Cholasta wrote:
 On 25.2.2014 20:22, Simo Sorce wrote:
  On Tue, 2014-02-25 at 13:22 -0500, Rob Crittenden wrote:
  Jan Cholasta wrote:
  On 25.2.2014 17:36, Ludwig Krispenz wrote:
 
  On 02/25/2014 05:12 PM, Simo Sorce wrote:
  On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote:
  On 25.2.2014 16:11, Simo Sorce wrote:
  On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:
  On 25.2.2014 15:11, Simo Sorce wrote:
  On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:
  Any reason why we should follow in detail what softshm does ?
  because I did't know what is really needed. If you want to have a
  pkcs11
  module, which stores data in ldap, I though it should have all the
  attributes potentially needed.
  Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
  CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
  CKA_EXTRACTABLE,
  so there is at least one requirement for fine grained attributes.
  Does OpenDNSSEC store them as separate entities and need access
  to them
  independently ?
  AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP
  schema
  doesn't matter as long as our PKCS#11 module can derive all values
  defined by
  standard.
 
  Honza, you did investigate OpenDNSSEC integration, please add some
  details if
  you can.
 
  Or is this internal use that can be satisfied by unpacking a blob in
  OpenDNSSEC ?
 
  What does bind9 uses ? Petr, can you provide example key files ?
  Private+public keys stored in files:
  https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html
 
 
  Private keys stored in HSM and public keys in files:
  https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html
 
  (I.e. some values in .private file are replaced by PKCS#11 label.)
  Ok it seem clear to me we do not need to spell out a lot of values
  when
  using pkcs#11 as bind doesn't need them in the key files. So I
  assume it
  can query the pkcs#11 module to find what it needs.
 
  I would use these key files as a sort of guide to understand what we
  need in LDAP. I would try to put in a single blob as much as we can
  that
  we do not explicitly need by a client querying LDAP directly.
 
  I think in order to nail down exactly what we need, at this point, we
  require some example use cases and queries the various clients would
  perform with spelled out what they are looking for to identify or
  manipulate keys.
 
  Simo.
 
  See How applications interact with PKCS#11 at
  http://www.freeipa.org/page/V3/PKCS11_in_LDAP. Tl;dr: applications
  don't search for keys by key data, but by metadata, so like I said in
  the other thread, key data can be in a single blob, but metadata should
  be in separate attributes.
  Ah sorry, I hadn't looked at that one yet.
  It helps quite a bit.
 
  So are the class, key_type, id, label, token, 'sign' the only values we
  should really care to split off ?
 
  They are all metadata related to PKCS#11 operation. I don't think you
  can easily encode them in PKCS#8 or certificate blob, so they actually
  need to be split off. You can find the full list of them in the PKCS#11
  spec (link below).
 
 
  Can you describe what are these values ?
  What is class ? Why is it important, and how does it differ from
  key_type ?
  What is the token ? What is 'sign' ?
 
  Feel free to give references to specific documents to read up about
  these attributes.
  I'm a newcomer to this area and am orienting myself at this doc:
  ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf
  and looking into opendnssec andsofthsm code.
 
  I use mainly
  ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf, as
  2.30 is a draft ATM.
 
 
  It explains CKA_SIGN as:
  TheCKA_SIGN attribute of the signature key, whic h indicates whether
  the key supports signatures with appendix, must be CK_TRUE.
  I cannot tell if this will be needed, just can make up an attribute and
  allow it in an objectclass :-)
 
  OpenDNSSEC puts it in public key objects it generates, so it's needed at
  least for the sake of it.
 
  Actually, I think we should support all of the metadata attributes, so
  that our PKCS#11 module is reasonably generic and not tailored to needs
  of a specific consumer.
 
  We could hardcode some of these values but it will very likely cause
  problems later. It seems simple enough to just define schema for all of
  them and store them, except perhaps in the cases where they are easily
  derived. If we, for example, store the prime numbers and exponents, they
  need to be protected as carefully as the private key.
 
  This is something I meant to discuss too, how do we protect them ?
  Clearly we have ACIs but I am wondering if we want to encrypt them with
  keys not immediately or easily available via LDAP ?
 
  It's kind of catastrofic if they get inadvertently exposed like if
  someone does a ldapsearch as Directory Manager, which is one of the

Re: [Freeipa-devel] DNSSEC design page

2014-02-26 Thread Petr Spacek


On 26.2.2014 15:20, Ludwig Krispenz wrote:

I was talking about 'layer of indirection' previously. I'm digging into
details and it seems like a good idea to imitate what DNS registrars do
- use concept of key sets. It means that keys are not linked to a zone
one by one but rather a whole set of keys is linked to a zone.

It eases key rotation because you just need to drop a new key to a key
set and you don't have to add DNs of all zones to the new key (or the
other way around).

Another thing is that you could have different key rotation policies for
different key sets... we need to think about it carefully.

For example (without policies for now):
- two DNS zones example.com and example.net contain a pointer to keyset
called 'setA'
- zone objects: idnsname=example.net,cn=dns and idnsname=example.com,cn=dns

- key sets are stored under cn=keysets, cn=sec, cn=dns

- individual keys are stored under keyid=key1, keysetid=setA,
cn=keysets, cn=sec, cn=dns


How will the PKCS#11 module know into which keyset to store a key generated
by OpenDNSSEC? Are you suggesting having a separate slot/token for each
keyset? I would like to keep the number of tokens low, because there are
applications which go slot by slot, token by token when searching for
objects (e.g. BIND and OpenSSH) and that might generate a lot of unnecessary
traffic if the number of slots/tokens is high.
Okay, then we can store all DNSSEC keys in one slot and use key sets only 
for administrative purposes (i.e. pairing zone = keys in BIND) but it will 
be invisible for PKCS#11 interface.


Key set maintenance has to go over side channel for metadata and not over 
PKCS#11.


The pkcs11 data stored in ldap should represent pkcs11 objects. Other entries
could reference these objects, eg a zone referencing a key. I don't think we
should store references to other entries in an pkcs11 object. if you want this
we probably need another auxiliary objectclass for these pkcs11 entries.

Regarding objectclasses for the pkcs11 objects, what should be the structural
objectclass and what the naming attribute ?
So far I had defined the publicKey, privateKey, certificate objectclass all as
auxiliary, maybe we should have one structural like pkcs11Object containing
the required attrs like id, label, ...
and a naming attr if it is not one of them

This sounds like a good idea.

--
Petr^2 Spacek

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

Re: [Freeipa-devel] DNSSEC design page


On 24.2.2014 20:20, 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.

Also can you add some examples on how we would use these classes to
store DNS keys ?


We need to think about it a bit more. We plan to use PKCS#11 for key 
manipulation and data signing so the key itself will be unaware of any 
DNSSEC-specific attributes. DNSSEC-specifics could be in an auxiliary objectClass.


I'm discussing this with CZ.NIC guys and they propose to add a 'layer of 
indirection' between DNS zones and keys so one key set can be used by more DNS 
zones. They claim that it is relatively common practice and I trust them.


Note that I'm not saying that IPA should use one key for multiple DNS zones by 
default, but the schema should be future-proof and allow that if necessary.


Let's start with this proposal:
DNS zone: idnsname=dnssec.test, cn=dns, dc=example
There will be multi-valued attribute idnsseckey pointing to DNs of keys stored 
somewhere else.


Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns and store 
keys there.


I expect that PKCS#11 module will handle keys scattered over the LDAP tree 
somehow.



Ideally the example would show the LDAP tree and some example data in
detail, and also what operation we think would be common.


--
Petr^2 Spacek

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

Re: [Freeipa-devel] DNSSEC design page



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 ?


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@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DNSSEC design page


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



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

Re: [Freeipa-devel] DNSSEC design page


Hi,

here is a draft of the PKCS#11 design: 
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.


On 24.2.2014 13:11, 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


IMO we don't need attribute types for key components 
(ipaPkcs11publicExponent, ipaPkcs11modulus, ipaPkcs11privateExponent, 
ipaPkcs11prime1, ipaPkcs11prime2) at all. As I said before, I don't 
think we need such granularity in LDAP and it would limit us to RSA only 
(unless we add attribute types for every other key type). We can store 
both private keys and public keys in single attribute as a DER blob (I 
would name the attributes ipaPkcs11privateKeyValue instead of 
ipaPkcs8privateKey for private keys, ipaPkcs11publicKeyValue for public 
keys, there already is ipaPkcs11certificateValue for certificates).


OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, 
CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE 
when generating new key pairs, and the PKCS#11 spec says that keys 
generated on a token should have CKA_LOCAL and CKA_KEY_GEN_MECHANISM 
set, so I think we should have attribute types for all of them.




Ludwig

On 02/18/2014 03:17 PM, Jan Cholasta wrote:

Hi,

On 18.2.2014 14:02, Ludwig Krispenz wrote:

Hi,

yesterday jan asked me about the status of the schema and if it would be
ready for certificate storage an dthat puzzled me a bit and showed that
I still do not really understand what you want to store in LDAP.
Two me there are two very different approaches.

1] LDAP as store for high level objects like certs and keys
For certs and related stuff there is rfc4523 and the schema for ldif
exists. For keys we would decide if the key is stored in PKCS#8 format
or as bind keypairs and define a key attribute and that's it. we could
export keys with softhsm, (eventually convert them) and add to ldap, in
the long term solution the PKCS#11 replacemnt would need to manage these
high level objects


I think RFC 4523 is not the right schema in this case, as it is suited
for PKIs rather than generic cryptographic data storage. For example,
RFC 4523 distinguishes between CA and end entity certificates, but in
PKCS#11 there are just certificates without any semantics attached to
them.



2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted. SoftHsm has
one component Softdatabase with an API, which more or less passes sets
of attributes (attributes defined by PKCS#11) and then stores it as
records in sql where each record has a keytype and opaque blob of data.
If that is what is wanted the decision would be how fingrained the pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be the
most straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we can
use a single attribute containing PKCS#8 encoded private key rather
than using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate objects.

So, I would say it should be something between high-level and low-level.

Honza






--
Jan Cholasta

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

Re: [Freeipa-devel] DNSSEC design page



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

Re: [Freeipa-devel] DNSSEC design page



On 02/25/2014 01:47 PM, Jan Cholasta wrote:

Hi,

here is a draft of the PKCS#11 design: 
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.


On 24.2.2014 13:11, 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


IMO we don't need attribute types for key components 
(ipaPkcs11publicExponent, ipaPkcs11modulus, ipaPkcs11privateExponent, 
ipaPkcs11prime1, ipaPkcs11prime2) at all. As I said before, I don't 
think we need such granularity in LDAP and it would limit us to RSA 
only (unless we add attribute types for every other key type). We can 
store both private keys and public keys in single attribute as a DER 
blob (I would name the attributes ipaPkcs11privateKeyValue instead of 
ipaPkcs8privateKey for private keys, ipaPkcs11publicKeyValue for 
public keys, there already is ipaPkcs11certificateValue for 
certificates).


OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, 
CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE 
when generating new key pairs, and the PKCS#11 spec says that keys 
generated on a token should have CKA_LOCAL and CKA_KEY_GEN_MECHANISM 
set, so I think we should have attribute types for all of them.

ok.




Ludwig

On 02/18/2014 03:17 PM, Jan Cholasta wrote:

Hi,

On 18.2.2014 14:02, Ludwig Krispenz wrote:

Hi,

yesterday jan asked me about the status of the schema and if it 
would be
ready for certificate storage an dthat puzzled me a bit and showed 
that

I still do not really understand what you want to store in LDAP.
Two me there are two very different approaches.

1] LDAP as store for high level objects like certs and keys
For certs and related stuff there is rfc4523 and the schema for ldif
exists. For keys we would decide if the key is stored in PKCS#8 format
or as bind keypairs and define a key attribute and that's it. we could
export keys with softhsm, (eventually convert them) and add to 
ldap, in
the long term solution the PKCS#11 replacemnt would need to manage 
these

high level objects


I think RFC 4523 is not the right schema in this case, as it is suited
for PKIs rather than generic cryptographic data storage. For example,
RFC 4523 distinguishes between CA and end entity certificates, but in
PKCS#11 there are just certificates without any semantics attached to
them.



2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted. SoftHsm has
one component Softdatabase with an API, which more or less passes sets
of attributes (attributes defined by PKCS#11) and then stores it as
records in sql where each record has a keytype and opaque blob of 
data.
If that is what is wanted the decision would be how fingrained the 
pkcs

objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be the
most straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we can
use a single attribute containing PKCS#8 encoded private key rather
than using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate objects.

So, I would say it should be something between high-level and 
low-level.


Honza








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

Re: [Freeipa-devel] DNSSEC design page



On 02/25/2014 01:47 PM, Jan Cholasta wrote:

Hi,

here is a draft of the PKCS#11 design: 
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.


On 24.2.2014 13:11, 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


IMO we don't need attribute types for key components 
(ipaPkcs11publicExponent, ipaPkcs11modulus, ipaPkcs11privateExponent, 
ipaPkcs11prime1, ipaPkcs11prime2) at all. As I said before, I don't 
think we need such granularity in LDAP and it would limit us to RSA 
only (unless we add attribute types for every other key type). We can 
store both private keys and public keys in single attribute as a DER 
blob (I would name the attributes ipaPkcs11privateKeyValue instead of 
ipaPkcs8privateKey for private keys, ipaPkcs11publicKeyValue for 
public keys, there already is ipaPkcs11certificateValue for 
certificates).

ok for me, if everybody agrees.


OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, 
CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE 
when generating new key pairs, and the PKCS#11 spec says that keys 
generated on a token should have CKA_LOCAL and CKA_KEY_GEN_MECHANISM 
set, so I think we should have attribute types for all of them.

ok.




Ludwig

On 02/18/2014 03:17 PM, Jan Cholasta wrote:

Hi,

On 18.2.2014 14:02, Ludwig Krispenz wrote:

Hi,

yesterday jan asked me about the status of the schema and if it 
would be
ready for certificate storage an dthat puzzled me a bit and showed 
that

I still do not really understand what you want to store in LDAP.
Two me there are two very different approaches.

1] LDAP as store for high level objects like certs and keys
For certs and related stuff there is rfc4523 and the schema for ldif
exists. For keys we would decide if the key is stored in PKCS#8 format
or as bind keypairs and define a key attribute and that's it. we could
export keys with softhsm, (eventually convert them) and add to 
ldap, in
the long term solution the PKCS#11 replacemnt would need to manage 
these

high level objects


I think RFC 4523 is not the right schema in this case, as it is suited
for PKIs rather than generic cryptographic data storage. For example,
RFC 4523 distinguishes between CA and end entity certificates, but in
PKCS#11 there are just certificates without any semantics attached to
them.



2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted. SoftHsm has
one component Softdatabase with an API, which more or less passes sets
of attributes (attributes defined by PKCS#11) and then stores it as
records in sql where each record has a keytype and opaque blob of 
data.
If that is what is wanted the decision would be how fingrained the 
pkcs

objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be the
most straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we can
use a single attribute containing PKCS#8 encoded private key rather
than using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate objects.

So, I would say it should be something between high-level and 
low-level.


Honza








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

Re: [Freeipa-devel] DNSSEC design page



On 02/25/2014 01:47 PM, Jan Cholasta wrote:

Hi,

here is a draft of the PKCS#11 design: 
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.


On 24.2.2014 13:11, 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


IMO we don't need attribute types for key components 
(ipaPkcs11publicExponent, ipaPkcs11modulus, ipaPkcs11privateExponent, 
ipaPkcs11prime1, ipaPkcs11prime2) at all. As I said before, I don't 
think we need such granularity in LDAP and it would limit us to RSA 
only (unless we add attribute types for every other key type). We can 
store both private keys and public keys in single attribute as a DER 
blob (I would name the attributes ipaPkcs11privateKeyValue instead of 
ipaPkcs8privateKey for private keys, ipaPkcs11publicKeyValue for 
public keys, there already is ipaPkcs11certificateValue for 
certificates).

ok for me, if anybody agrees.


OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, 
CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE 
when generating new key pairs, and the PKCS#11 spec says that keys 
generated on a token should have CKA_LOCAL and CKA_KEY_GEN_MECHANISM 
set, so I think we should have attribute types for all of them.

ok.




Ludwig

On 02/18/2014 03:17 PM, Jan Cholasta wrote:

Hi,

On 18.2.2014 14:02, Ludwig Krispenz wrote:

Hi,

yesterday jan asked me about the status of the schema and if it 
would be
ready for certificate storage an dthat puzzled me a bit and showed 
that

I still do not really understand what you want to store in LDAP.
Two me there are two very different approaches.

1] LDAP as store for high level objects like certs and keys
For certs and related stuff there is rfc4523 and the schema for ldif
exists. For keys we would decide if the key is stored in PKCS#8 format
or as bind keypairs and define a key attribute and that's it. we could
export keys with softhsm, (eventually convert them) and add to 
ldap, in
the long term solution the PKCS#11 replacemnt would need to manage 
these

high level objects


I think RFC 4523 is not the right schema in this case, as it is suited
for PKIs rather than generic cryptographic data storage. For example,
RFC 4523 distinguishes between CA and end entity certificates, but in
PKCS#11 there are just certificates without any semantics attached to
them.



2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted. SoftHsm has
one component Softdatabase with an API, which more or less passes sets
of attributes (attributes defined by PKCS#11) and then stores it as
records in sql where each record has a keytype and opaque blob of 
data.
If that is what is wanted the decision would be how fingrained the 
pkcs

objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be the
most straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we can
use a single attribute containing PKCS#8 encoded private key rather
than using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate objects.

So, I would say it should be something between high-level and 
low-level.


Honza








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

Re: [Freeipa-devel] DNSSEC design page


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

Re: [Freeipa-devel] DNSSEC design page

On Tue, 2014-02-25 at 11:08 +0100, Petr Spacek wrote:
 On 24.2.2014 20:20, Simo Sorce wrote:

  Also can you add some examples on how we would use these classes to
  store DNS keys ?
 
 We need to think about it a bit more. We plan to use PKCS#11 for key 
 manipulation and data signing so the key itself will be unaware of any 
 DNSSEC-specific attributes. DNSSEC-specifics could be in an auxiliary 
 objectClass.
 
 I'm discussing this with CZ.NIC guys and they propose to add a 'layer of 
 indirection' between DNS zones and keys so one key set can be used by more 
 DNS 
 zones. They claim that it is relatively common practice and I trust them.
 
 Note that I'm not saying that IPA should use one key for multiple DNS zones 
 by 
 default, but the schema should be future-proof and allow that if necessary.

Makes sense.

 Let's start with this proposal:
 DNS zone: idnsname=dnssec.test, cn=dns, dc=example
 There will be multi-valued attribute idnsseckey pointing to DNs of keys 
 stored 
 somewhere else.
 
 Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns and 
 store 
 keys there.

Ok, do we really want to have zones pointing at keys ?
Or do we want keys have a list of zones they are supposed to apply to ?

 I expect that PKCS#11 module will handle keys scattered over the LDAP tree 
 somehow.

Sure as long as it can understand what the keys are for.

  Ideally the example would show the LDAP tree and some example data in
  detail, and also what operation we think would be common.
 


-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: [Freeipa-devel] DNSSEC design page

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

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

Re: [Freeipa-devel] DNSSEC design page


On 25.2.2014 13:47, Jan Cholasta wrote:

here is a draft of the PKCS#11 design:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.


I don't understand the purpose of cn=crypto suffix. I thought that PKCS#11 
module will have to search for token with given TOKEN_ID or LABEL anyway, 
right? Do I miss something?


Where the token will be placed if someobody generates new key via PKCS#11? How 
it will determine the right sub-tree?


I would rather see keys stored under user account:
uid=admin,cn=users,cn=accounts,dc=ipa,dc=example

I like this approach because it allows you to manipulate with the user account 
easily without paying special attention to dangling references etc.


Key storage under service account like:
krbprincipalname=DNS/vm.example.com@IPA.EXAMPLE,cn=services,cn=accounts,dc=ipa,dc=example
doesn't solve problem with shared keys in DNS tree... I can imagine that 
objects in LDAP have TOKEN_ID and LABEL attributes indexed and the PKCS#11 
module will do full sub-tree search for particular ID or LABEL value, so the 
key can be always found.


On the other side, it would require special handling for replica deletion etc.

Petr^2 Spacek


On 24.2.2014 13:11, 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


IMO we don't need attribute types for key components (ipaPkcs11publicExponent,
ipaPkcs11modulus, ipaPkcs11privateExponent, ipaPkcs11prime1, ipaPkcs11prime2)
at all. As I said before, I don't think we need such granularity in LDAP and
it would limit us to RSA only (unless we add attribute types for every other
key type). We can store both private keys and public keys in single attribute
as a DER blob (I would name the attributes ipaPkcs11privateKeyValue instead of
ipaPkcs8privateKey for private keys, ipaPkcs11publicKeyValue for public keys,
there already is ipaPkcs11certificateValue for certificates).

OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, CKA_DECRYPT,
CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE when generating new
key pairs, and the PKCS#11 spec says that keys generated on a token should
have CKA_LOCAL and CKA_KEY_GEN_MECHANISM set, so I think we should have
attribute types for all of them.



Ludwig

On 02/18/2014 03:17 PM, Jan Cholasta wrote:

Hi,

On 18.2.2014 14:02, Ludwig Krispenz wrote:

Hi,

yesterday jan asked me about the status of the schema and if it would be
ready for certificate storage an dthat puzzled me a bit and showed that
I still do not really understand what you want to store in LDAP.
Two me there are two very different approaches.

1] LDAP as store for high level objects like certs and keys
For certs and related stuff there is rfc4523 and the schema for ldif
exists. For keys we would decide if the key is stored in PKCS#8 format
or as bind keypairs and define a key attribute and that's it. we could
export keys with softhsm, (eventually convert them) and add to ldap, in
the long term solution the PKCS#11 replacemnt would need to manage these
high level objects


I think RFC 4523 is not the right schema in this case, as it is suited
for PKIs rather than generic cryptographic data storage. For example,
RFC 4523 distinguishes between CA and end entity certificates, but in
PKCS#11 there are just certificates without any semantics attached to
them.



2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted. SoftHsm has
one component Softdatabase with an API, which more or less passes sets
of attributes (attributes defined by PKCS#11) and then stores it as
records in sql where each record has a keytype and opaque blob of data.
If that is what is wanted the decision would be how fingrained the pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be the
most straightforward way of doing this, but I think we can do some
optimization for our needs. For example, like you said above, we can
use a single attribute containing PKCS#8 encoded private key rather
than using one attribute per private key component.

I don't think we need an LDAP attribute for every possible PKCS#11
attribute, ATM it would be sufficient to have just these attributes
necessary to represent private key, public key and certificate objects.

So, I would say it should be something between high-level and low-level.

Honza


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

Re: [Freeipa-devel] DNSSEC design page



On 02/25/2014 02:44 PM, Simo Sorce wrote:

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 ?
because I did't know what is really needed. If you want to have a pkcs11 
module, which stores data in ldap, I though it should have all the 
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, 
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, 
CKA_EXTRACTABLE,

so there is at least one requirement for fine grained attributes.



   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

Re: [Freeipa-devel] DNSSEC design page


On 25.2.2014 14:52, Petr Spacek wrote:

On 25.2.2014 13:47, Jan Cholasta wrote:

here is a draft of the PKCS#11 design:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.


I don't understand the purpose of cn=crypto suffix. I thought that
PKCS#11 module will have to search for token with given TOKEN_ID or
LABEL anyway, right? Do I miss something?


That's just a base DN for LDAP searches I came up with, it has no 
particular meaning.




Where the token will be placed if someobody generates new key via
PKCS#11? How it will determine the right sub-tree?


In order to generate a key, you must have an open session (see 
C_GenerateKeyPair). When you open a session, you must specify slot ID 
(see C_OpenSession). This is where the association takes place.




I would rather see keys stored under user account:
uid=admin,cn=users,cn=accounts,dc=ipa,dc=example


Do you mean storing private keys in a single attribute in user's entry? 
We wouldn't be able to store per-key metadata that way.


If you mean storing private keys in entries under user's entry, there is 
nothing similar in our current schema, so I thought we just don't do 
that (there probably is a reason for that).


(Anyway, we don't need to solve this right away, DNSSEC and CA 
certificates are what matters now.)




I like this approach because it allows you to manipulate with the user
account easily without paying special attention to dangling references etc.


References are managed automatically by the referint plugin.



Key storage under service account like:
krbprincipalname=DNS/vm.example.com@IPA.EXAMPLE,cn=services,cn=accounts,dc=ipa,dc=example

doesn't solve problem with shared keys in DNS tree... I can imagine that
objects in LDAP have TOKEN_ID and LABEL attributes indexed and the
PKCS#11 module will do full sub-tree search for particular ID or LABEL
value, so the key can be always found.


The objects need to be associated with a particular token somehow. 
Having them in a token-specific sub-tree seems like the easiest way to 
do it to me.




On the other side, it would require special handling for replica
deletion etc.

Petr^2 Spacek


On 24.2.2014 13:11, 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


IMO we don't need attribute types for key components
(ipaPkcs11publicExponent,
ipaPkcs11modulus, ipaPkcs11privateExponent, ipaPkcs11prime1,
ipaPkcs11prime2)
at all. As I said before, I don't think we need such granularity in
LDAP and
it would limit us to RSA only (unless we add attribute types for every
other
key type). We can store both private keys and public keys in single
attribute
as a DER blob (I would name the attributes ipaPkcs11privateKeyValue
instead of
ipaPkcs8privateKey for private keys, ipaPkcs11publicKeyValue for
public keys,
there already is ipaPkcs11certificateValue for certificates).

OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP, CKA_SIGN, CKA_DECRYPT,
CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE, CKA_EXTRACTABLE when
generating new
key pairs, and the PKCS#11 spec says that keys generated on a token
should
have CKA_LOCAL and CKA_KEY_GEN_MECHANISM set, so I think we should have
attribute types for all of them.



Ludwig

On 02/18/2014 03:17 PM, Jan Cholasta wrote:

Hi,

On 18.2.2014 14:02, Ludwig Krispenz wrote:

Hi,

yesterday jan asked me about the status of the schema and if it
would be
ready for certificate storage an dthat puzzled me a bit and showed
that
I still do not really understand what you want to store in LDAP.
Two me there are two very different approaches.

1] LDAP as store for high level objects like certs and keys
For certs and related stuff there is rfc4523 and the schema for ldif
exists. For keys we would decide if the key is stored in PKCS#8 format
or as bind keypairs and define a key attribute and that's it. we could
export keys with softhsm, (eventually convert them) and add to
ldap, in
the long term solution the PKCS#11 replacemnt would need to manage
these
high level objects


I think RFC 4523 is not the right schema in this case, as it is suited
for PKIs rather than generic cryptographic data storage. For example,
RFC 4523 distinguishes between CA and end entity certificates, but in
PKCS#11 there are just certificates without any semantics attached to
them.



2] low level replacement for eg the sqlite3 database in softhsm.
That's what I sometimes get the impression what is wanted. SoftHsm has
one component Softdatabase with an API, which more or less passes sets
of attributes (attributes defined by PKCS#11) and then stores it as
records in sql where each record has a keytype and opaque blob of
data.
If that is what is wanted the decision would be how fingrained the
pkcs
objects/attribute types would have to be mapped to ldap: one ldap
attribute for each possible attribute type ?


One-to-one mapping of attributes from PKCS#11 to LDAP would be the

Re: [Freeipa-devel] DNSSEC design page

On Tue, 2014-02-25 at 13:58 +0100, Petr Spacek wrote:
 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.
 
I personally favor using the defined DNSKEY records, as this is future
proof. If the spec changes in future it will have to be backwards
compatible, meaning we will be able to also follow the DNSSEC spec w/o
major changes to our data.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: [Freeipa-devel] DNSSEC design page

On Tue, 2014-02-25 at 14:52 +0100, Petr Spacek wrote:
On 25.2.2014 13:47, Jan Cholasta wrote:
here is a draft of the PKCS#11 design:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.

I don't understand the purpose of cn=crypto suffix. I thought that PKCS#11
module will have to search for token with given TOKEN_ID or LABEL anyway,
right? Do I miss something?

Where the token will be placed if someobody generates new key via PKCS#11?
How
it will determine the right sub-tree?

I would rather see keys stored under user account:
uid=admin,cn=users,cn=accounts,dc=ipa,dc=example

User objects should stay as leaves imo.
We can use the managed-by attribute to easily allow control by a user.

I like this approach because it allows you to manipulate with the user
account
easily without paying special attention to dangling references etc.

the referential integrity plugin can handle references, usually.

Key storage under service account like:
krbprincipalname=DNS/vm.example.com@IPA.EXAMPLE,cn=services,cn=accounts,dc=ipa,dc=example
doesn't solve problem with shared keys in DNS tree... I can imagine that
objects in LDAP have TOKEN_ID and LABEL attributes indexed and the PKCS#11
module will do full sub-tree search for particular ID or LABEL value, so the
key can be always found.

DNS Keys should stay in the DNS tree IMHO.

On the other side, it would require special handling for replica deletion etc.

Right.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

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

Re: [Freeipa-devel] DNSSEC design page


On 25.2.2014 15:32, Simo Sorce wrote:

On Tue, 2014-02-25 at 14:52 +0100, Petr Spacek wrote:

On 25.2.2014 13:47, Jan Cholasta wrote:

here is a draft of the PKCS#11 design:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.


I don't understand the purpose of cn=crypto suffix. I thought that PKCS#11
module will have to search for token with given TOKEN_ID or LABEL anyway,
right? Do I miss something?

Where the token will be placed if someobody generates new key via PKCS#11? How
it will determine the right sub-tree?

I would rather see keys stored under user account:
uid=admin,cn=users,cn=accounts,dc=ipa,dc=example


User objects should stay as leaves imo.
We can use the managed-by attribute to easily allow control by a user.


I have never understood to this design. Could you elaborate on that, please? 
I'm curious why it is designed in this way because from my point of view it 
adds complexity (managed by etc.) and I don't see the benefit.



I like this approach because it allows you to manipulate with the user account
easily without paying special attention to dangling references etc.


the referential integrity plugin can handle references, usually.


... but the plugin can only delete references and nothing else, right? It 
works perfectly for user-group membership but it is not that great for keys. 
If you delete a user account then all associated keys will be there until 
somebody deletes them manually.


That is the reason why I don't like this design.


Key storage under service account like:
krbprincipalname=DNS/vm.example.com@IPA.EXAMPLE,cn=services,cn=accounts,dc=ipa,dc=example
doesn't solve problem with shared keys in DNS tree... I can imagine that
objects in LDAP have TOKEN_ID and LABEL attributes indexed and the PKCS#11
module will do full sub-tree search for particular ID or LABEL value, so the
key can be always found.


DNS Keys should stay in the DNS tree IMHO.


That seems like an optimal solution, sure. I didn't realize that PKCS#11 
slot_id can be used to determine the right container for new keys.



On the other side, it would require special handling for replica deletion etc.


Right.

Simo.


--
Petr^2 Spacek

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

Re: [Freeipa-devel] DNSSEC design page



On 02/25/2014 03:11 PM, Simo Sorce wrote:

On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:

Any reason why we should follow in detail what softshm does ?

because I did't know what is really needed. If you want to have a
pkcs11
module, which stores data in ldap, I though it should have all the
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
CKA_EXTRACTABLE,
so there is at least one requirement for fine grained attributes.

Does OpenDNSSEC store them as separate entities and need access to them
independently ?
It's all individual records in the attribute table in teh sql database, 
dont know what the access pattern is.

Or is this internal use that can be satisfied by unpacking a blob in
OpenDNSSEC ?

What does bind9 uses ? Petr, can you provide example key files ?

Simo.



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

Re: [Freeipa-devel] DNSSEC design page


On 25.2.2014 15:48, Ludwig Krispenz wrote:


On 02/25/2014 03:11 PM, Simo Sorce wrote:

On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:

Any reason why we should follow in detail what softshm does ?

because I did't know what is really needed. If you want to have a
pkcs11
module, which stores data in ldap, I though it should have all the
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
CKA_EXTRACTABLE,
so there is at least one requirement for fine grained attributes.

Does OpenDNSSEC store them as separate entities and need access to them
independently ?

It's all individual records in the attribute table in teh sql database,
dont know what the access pattern is.

Or is this internal use that can be satisfied by unpacking a blob in
OpenDNSSEC ?

What does bind9 uses ? Petr, can you provide example key files ?

Simo.





Both OpenDNSSEC and BIND use PKCS#11 directly, so no blob unpacking.

IMO key material (modulus, exponents, etc.) should be stored in a blob, 
but metadata (such as the CKAs above) should be in separate attributes 
(for starters, I don't think there is a way to encode them in PKCS#8, so 
we would have to invent our own blob type for private keys).


--
Jan Cholasta

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

Re: [Freeipa-devel] DNSSEC design page


On 25.2.2014 15:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:

Any reason why we should follow in detail what softshm does ?

because I did't know what is really needed. If you want to have a
pkcs11
module, which stores data in ldap, I though it should have all the
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
CKA_EXTRACTABLE,
so there is at least one requirement for fine grained attributes.


Does OpenDNSSEC store them as separate entities and need access to them
independently ?
AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema 
doesn't matter as long as our PKCS#11 module can derive all values defined by 
standard.


Honza, you did investigate OpenDNSSEC integration, please add some details if 
you can.



Or is this internal use that can be satisfied by unpacking a blob in
OpenDNSSEC ?

What does bind9 uses ? Petr, can you provide example key files ?


Private+public keys stored in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html

Private keys stored in HSM and public keys in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html
(I.e. some values in .private file are replaced by PKCS#11 label.)

--
Petr^2 Spacek

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

Re: [Freeipa-devel] DNSSEC design page

On Tue, 2014-02-25 at 15:43 +0100, Petr Spacek wrote:
On 25.2.2014 15:32, Simo Sorce wrote:
On Tue, 2014-02-25 at 14:52 +0100, Petr Spacek wrote:
On 25.2.2014 13:47, Jan Cholasta wrote:
here is a draft of the PKCS#11 design:
http://www.freeipa.org/page/V3/PKCS11_in_LDAP.

I don't understand the purpose of cn=crypto suffix. I thought that PKCS#11
module will have to search for token with given TOKEN_ID or LABEL anyway,
right? Do I miss something?

Where the token will be placed if someobody generates new key via PKCS#11?
How
it will determine the right sub-tree?

I would rather see keys stored under user account:
uid=admin,cn=users,cn=accounts,dc=ipa,dc=example

User objects should stay as leaves imo.
We can use the managed-by attribute to easily allow control by a user.

I have never understood to this design. Could you elaborate on that, please?
I'm curious why it is designed in this way because from my point of view it
adds complexity (managed by etc.) and I don't see the benefit.

One of the reasons is that normally you delete leaves with an ldap
delete operation, bit that will fail if the object is a node in a
subtree instead of a leaf.

You can delete entire subtrees but you need to explicitly make a
recursive delete and a lot of tools probably don't.

Adding leaves therefore has consequences that should not be
underestimated.

I like this approach because it allows you to manipulate with the user
account
easily without paying special attention to dangling references etc.

the referential integrity plugin can handle references, usually.

... but the plugin can only delete references and nothing else, right? It
works perfectly for user-group membership but it is not that great for keys.
If you delete a user account then all associated keys will be there until
somebody deletes them manually.

That is the reason why I don't like this design.

We can solve this through the use of the managed entries plugin too I
think. We have ways to cope with this, I do not think we should waste
too much time on it though, for now.

DNS Keys should stay in the DNS tree IMHO.

That seems like an optimal solution, sure. I didn't realize that PKCS#11
slot_id can be used to determine the right container for new keys.

Ok.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

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

Re: [Freeipa-devel] DNSSEC design page


On 25.2.2014 16:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:

On 25.2.2014 15:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:

Any reason why we should follow in detail what softshm does ?

because I did't know what is really needed. If you want to have a
pkcs11
module, which stores data in ldap, I though it should have all the
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
CKA_EXTRACTABLE,
so there is at least one requirement for fine grained attributes.


Does OpenDNSSEC store them as separate entities and need access to them
independently ?

AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema
doesn't matter as long as our PKCS#11 module can derive all values defined by
standard.

Honza, you did investigate OpenDNSSEC integration, please add some details if
you can.


Or is this internal use that can be satisfied by unpacking a blob in
OpenDNSSEC ?

What does bind9 uses ? Petr, can you provide example key files ?


Private+public keys stored in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html

Private keys stored in HSM and public keys in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html
(I.e. some values in .private file are replaced by PKCS#11 label.)


Ok it seem clear to me we do not need to spell out a lot of values when
using pkcs#11 as bind doesn't need them in the key files. So I assume it
can query the pkcs#11 module to find what it needs.

I would use these key files as a sort of guide to understand what we
need in LDAP. I would try to put in a single blob as much as we can that
we do not explicitly need by a client querying LDAP directly.

I think in order to nail down exactly what we need, at this point, we
require some example use cases and queries the various clients would
perform with spelled out what they are looking for to identify or
manipulate keys.

Simo.



See How applications interact with PKCS#11 at 
http://www.freeipa.org/page/V3/PKCS11_in_LDAP. Tl;dr: applications 
don't search for keys by key data, but by metadata, so like I said in 
the other thread, key data can be in a single blob, but metadata should 
be in separate attributes.


--
Jan Cholasta

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

Re: [Freeipa-devel] DNSSEC design page

On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:
 On 25.2.2014 15:11, Simo Sorce wrote:
  On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:
  Any reason why we should follow in detail what softshm does ?
  because I did't know what is really needed. If you want to have a
  pkcs11
  module, which stores data in ldap, I though it should have all the
  attributes potentially needed.
  Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
  CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
  CKA_EXTRACTABLE,
  so there is at least one requirement for fine grained attributes.
 
  Does OpenDNSSEC store them as separate entities and need access to them
  independently ?
 AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema 
 doesn't matter as long as our PKCS#11 module can derive all values defined by 
 standard.
 
 Honza, you did investigate OpenDNSSEC integration, please add some details if 
 you can.
 
  Or is this internal use that can be satisfied by unpacking a blob in
  OpenDNSSEC ?
 
  What does bind9 uses ? Petr, can you provide example key files ?
 
 Private+public keys stored in files:
 https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html
 
 Private keys stored in HSM and public keys in files:
 https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html
 (I.e. some values in .private file are replaced by PKCS#11 label.)

Ok it seem clear to me we do not need to spell out a lot of values when
using pkcs#11 as bind doesn't need them in the key files. So I assume it
can query the pkcs#11 module to find what it needs.

I would use these key files as a sort of guide to understand what we
need in LDAP. I would try to put in a single blob as much as we can that
we do not explicitly need by a client querying LDAP directly.

I think in order to nail down exactly what we need, at this point, we
require some example use cases and queries the various clients would
perform with spelled out what they are looking for to identify or
manipulate keys.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: [Freeipa-devel] DNSSEC design page

2014-02-25 Thread Rob Crittenden


Jan Cholasta wrote:

On 25.2.2014 16:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:

On 25.2.2014 15:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:

Any reason why we should follow in detail what softshm does ?

because I did't know what is really needed. If you want to have a
pkcs11
module, which stores data in ldap, I though it should have all the
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
CKA_EXTRACTABLE,
so there is at least one requirement for fine grained attributes.


Does OpenDNSSEC store them as separate entities and need access to them
independently ?

AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema
doesn't matter as long as our PKCS#11 module can derive all values
defined by
standard.

Honza, you did investigate OpenDNSSEC integration, please add some
details if
you can.


Or is this internal use that can be satisfied by unpacking a blob in
OpenDNSSEC ?

What does bind9 uses ? Petr, can you provide example key files ?


Private+public keys stored in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html


Private keys stored in HSM and public keys in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html

(I.e. some values in .private file are replaced by PKCS#11 label.)


Ok it seem clear to me we do not need to spell out a lot of values when
using pkcs#11 as bind doesn't need them in the key files. So I assume it
can query the pkcs#11 module to find what it needs.

I would use these key files as a sort of guide to understand what we
need in LDAP. I would try to put in a single blob as much as we can that
we do not explicitly need by a client querying LDAP directly.

I think in order to nail down exactly what we need, at this point, we
require some example use cases and queries the various clients would
perform with spelled out what they are looking for to identify or
manipulate keys.

Simo.



See How applications interact with PKCS#11 at
http://www.freeipa.org/page/V3/PKCS11_in_LDAP. Tl;dr: applications
don't search for keys by key data, but by metadata, so like I said in
the other thread, key data can be in a single blob, but metadata should
be in separate attributes.



Splitting hairs, I think that one can search based on the cert DER which 
I guess represents the public key. You mean search by private key?


How do you plan to generate the CKA_ID? IIRC it needs to be unique per 
token and since this will be rather dynamically available. I think it's 
just a set of bytes so maybe a UUID is adequate.


I think you're on the right path defining these as discrete attributes. 
IMHO it will be worth submitting this as an RFC once the schema design 
is complete. So I wonder if the 'ipa' string should be dropped from the 
proposed schema. I guess that would also require specifying the other 
CKA values for other key types (e.g. DSA and DH).


In the schema ipaPkcs11prim1 is missing an 'e' I think and the comment 
should be CKA_PRIME_1.


rob

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

Re: [Freeipa-devel] DNSSEC design page


On 25.2.2014 16:42, Rob Crittenden wrote:

Jan Cholasta wrote:

On 25.2.2014 16:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:

On 25.2.2014 15:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:

Any reason why we should follow in detail what softshm does ?

because I did't know what is really needed. If you want to have a
pkcs11
module, which stores data in ldap, I though it should have all the
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
CKA_EXTRACTABLE,
so there is at least one requirement for fine grained attributes.


Does OpenDNSSEC store them as separate entities and need access to
them
independently ?

AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP
schema
doesn't matter as long as our PKCS#11 module can derive all values
defined by
standard.

Honza, you did investigate OpenDNSSEC integration, please add some
details if
you can.


Or is this internal use that can be satisfied by unpacking a blob in
OpenDNSSEC ?

What does bind9 uses ? Petr, can you provide example key files ?


Private+public keys stored in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html



Private keys stored in HSM and public keys in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html


(I.e. some values in .private file are replaced by PKCS#11 label.)


Ok it seem clear to me we do not need to spell out a lot of values when
using pkcs#11 as bind doesn't need them in the key files. So I assume it
can query the pkcs#11 module to find what it needs.

I would use these key files as a sort of guide to understand what we
need in LDAP. I would try to put in a single blob as much as we can that
we do not explicitly need by a client querying LDAP directly.

I think in order to nail down exactly what we need, at this point, we
require some example use cases and queries the various clients would
perform with spelled out what they are looking for to identify or
manipulate keys.

Simo.



See How applications interact with PKCS#11 at
http://www.freeipa.org/page/V3/PKCS11_in_LDAP. Tl;dr: applications
don't search for keys by key data, but by metadata, so like I said in
the other thread, key data can be in a single blob, but metadata should
be in separate attributes.



Splitting hairs, I think that one can search based on the cert DER which
I guess represents the public key. You mean search by private key?


Public keys in PKCS#11 are represented by a set of attributes (e.g. 
CKA_MODULUS, CKA_MODULUS_BITS and CKA_PUBLIC_EXPONENT for RSA public 
keys), I meant search by values of some of them.




How do you plan to generate the CKA_ID? IIRC it needs to be unique per
token and since this will be rather dynamically available. I think it's
just a set of bytes so maybe a UUID is adequate.


That's a possibility. OpenDNSSEC puts 16 random bytes in CKA_ID.



I think you're on the right path defining these as discrete attributes.
IMHO it will be worth submitting this as an RFC once the schema design
is complete. So I wonder if the 'ipa' string should be dropped from the
proposed schema. I guess that would also require specifying the other
CKA values for other key types (e.g. DSA and DH).

In the schema ipaPkcs11prim1 is missing an 'e' I think and the comment
should be CKA_PRIME_1.

rob



--
Jan Cholasta

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

Re: [Freeipa-devel] DNSSEC design page

On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote:
 On 25.2.2014 16:11, Simo Sorce wrote:
  On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:
  On 25.2.2014 15:11, Simo Sorce wrote:
  On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:
  Any reason why we should follow in detail what softshm does ?
  because I did't know what is really needed. If you want to have a
  pkcs11
  module, which stores data in ldap, I though it should have all the
  attributes potentially needed.
  Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
  CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
  CKA_EXTRACTABLE,
  so there is at least one requirement for fine grained attributes.
 
  Does OpenDNSSEC store them as separate entities and need access to them
  independently ?
  AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema
  doesn't matter as long as our PKCS#11 module can derive all values defined 
  by
  standard.
 
  Honza, you did investigate OpenDNSSEC integration, please add some details 
  if
  you can.
 
  Or is this internal use that can be satisfied by unpacking a blob in
  OpenDNSSEC ?
 
  What does bind9 uses ? Petr, can you provide example key files ?
 
  Private+public keys stored in files:
  https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html
 
  Private keys stored in HSM and public keys in files:
  https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html
  (I.e. some values in .private file are replaced by PKCS#11 label.)
 
  Ok it seem clear to me we do not need to spell out a lot of values when
  using pkcs#11 as bind doesn't need them in the key files. So I assume it
  can query the pkcs#11 module to find what it needs.
 
  I would use these key files as a sort of guide to understand what we
  need in LDAP. I would try to put in a single blob as much as we can that
  we do not explicitly need by a client querying LDAP directly.
 
  I think in order to nail down exactly what we need, at this point, we
  require some example use cases and queries the various clients would
  perform with spelled out what they are looking for to identify or
  manipulate keys.
 
  Simo.
 
 
 See How applications interact with PKCS#11 at 
 http://www.freeipa.org/page/V3/PKCS11_in_LDAP. Tl;dr: applications 
 don't search for keys by key data, but by metadata, so like I said in 
 the other thread, key data can be in a single blob, but metadata should 
 be in separate attributes.

Ah sorry, I hadn't looked at that one yet.
It helps quite a bit.

So are the class, key_type, id, label, token, 'sign' the only values we
should really care to split off ?

Can you describe what are these values ?
What is class ? Why is it important, and how does it differ from
key_type ?
What is the token ? What is 'sign' ?

Feel free to give references to specific documents to read up about
these attributes.

Thanks,
Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: [Freeipa-devel] DNSSEC design page



On 02/25/2014 05:12 PM, Simo Sorce wrote:

On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote:

On 25.2.2014 16:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:

On 25.2.2014 15:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:

Any reason why we should follow in detail what softshm does ?

because I did't know what is really needed. If you want to have a
pkcs11
module, which stores data in ldap, I though it should have all the
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
CKA_EXTRACTABLE,
so there is at least one requirement for fine grained attributes.

Does OpenDNSSEC store them as separate entities and need access to them
independently ?

AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema
doesn't matter as long as our PKCS#11 module can derive all values defined by
standard.

Honza, you did investigate OpenDNSSEC integration, please add some details if
you can.


Or is this internal use that can be satisfied by unpacking a blob in
OpenDNSSEC ?

What does bind9 uses ? Petr, can you provide example key files ?

Private+public keys stored in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html

Private keys stored in HSM and public keys in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html
(I.e. some values in .private file are replaced by PKCS#11 label.)

Ok it seem clear to me we do not need to spell out a lot of values when
using pkcs#11 as bind doesn't need them in the key files. So I assume it
can query the pkcs#11 module to find what it needs.

I would use these key files as a sort of guide to understand what we
need in LDAP. I would try to put in a single blob as much as we can that
we do not explicitly need by a client querying LDAP directly.

I think in order to nail down exactly what we need, at this point, we
require some example use cases and queries the various clients would
perform with spelled out what they are looking for to identify or
manipulate keys.

Simo.


See How applications interact with PKCS#11 at
http://www.freeipa.org/page/V3/PKCS11_in_LDAP. Tl;dr: applications
don't search for keys by key data, but by metadata, so like I said in
the other thread, key data can be in a single blob, but metadata should
be in separate attributes.

Ah sorry, I hadn't looked at that one yet.
It helps quite a bit.

So are the class, key_type, id, label, token, 'sign' the only values we
should really care to split off ?

Can you describe what are these values ?
What is class ? Why is it important, and how does it differ from
key_type ?
What is the token ? What is 'sign' ?

Feel free to give references to specific documents to read up about
these attributes.
I'm a newcomer to this area and am orienting myself at this doc: 
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf

and looking into opendnssec andsofthsm code.

It explains CKA_SIGN as:
TheCKA_SIGN attribute of the signature key, whic h indicates whether 
the key supports signatures with appendix, must be CK_TRUE.
I cannot tell if this will be needed, just can make up an attribute and 
allow it in an objectclass :-)


But I think Jan's doc is a good start where he explains which attributes 
will be used by specific modules eg for searches.




Thanks,
Simo.



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

Re: [Freeipa-devel] DNSSEC design page


On 25.2.2014 17:36, Ludwig Krispenz wrote:


On 02/25/2014 05:12 PM, Simo Sorce wrote:

On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote:

On 25.2.2014 16:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:

On 25.2.2014 15:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:

Any reason why we should follow in detail what softshm does ?

because I did't know what is really needed. If you want to have a
pkcs11
module, which stores data in ldap, I though it should have all the
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
CKA_EXTRACTABLE,
so there is at least one requirement for fine grained attributes.

Does OpenDNSSEC store them as separate entities and need access to them
independently ?

AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema
doesn't matter as long as our PKCS#11 module can derive all values defined by
standard.

Honza, you did investigate OpenDNSSEC integration, please add some details if
you can.


Or is this internal use that can be satisfied by unpacking a blob in
OpenDNSSEC ?

What does bind9 uses ? Petr, can you provide example key files ?

Private+public keys stored in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html

Private keys stored in HSM and public keys in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html
(I.e. some values in .private file are replaced by PKCS#11 label.)

Ok it seem clear to me we do not need to spell out a lot of values when
using pkcs#11 as bind doesn't need them in the key files. So I assume it
can query the pkcs#11 module to find what it needs.

I would use these key files as a sort of guide to understand what we
need in LDAP. I would try to put in a single blob as much as we can that
we do not explicitly need by a client querying LDAP directly.

I think in order to nail down exactly what we need, at this point, we
require some example use cases and queries the various clients would
perform with spelled out what they are looking for to identify or
manipulate keys.

Simo.


See How applications interact with PKCS#11 at
http://www.freeipa.org/page/V3/PKCS11_in_LDAP. Tl;dr: applications
don't search for keys by key data, but by metadata, so like I said in
the other thread, key data can be in a single blob, but metadata should
be in separate attributes.

Ah sorry, I hadn't looked at that one yet.
It helps quite a bit.

So are the class, key_type, id, label, token, 'sign' the only values we
should really care to split off ?


They are all metadata related to PKCS#11 operation. I don't think you 
can easily encode them in PKCS#8 or certificate blob, so they actually 
need to be split off. You can find the full list of them in the PKCS#11 
spec (link below).




Can you describe what are these values ?
What is class ? Why is it important, and how does it differ from
key_type ?
What is the token ? What is 'sign' ?

Feel free to give references to specific documents to read up about
these attributes.

I'm a newcomer to this area and am orienting myself at this doc:
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf
and looking into opendnssec andsofthsm code.


I use mainly 
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf, as 
2.30 is a draft ATM.




It explains CKA_SIGN as:
TheCKA_SIGN attribute of the signature key, whic h indicates whether
the key supports signatures with appendix, must be CK_TRUE.
I cannot tell if this will be needed, just can make up an attribute and
allow it in an objectclass :-)


OpenDNSSEC puts it in public key objects it generates, so it's needed at 
least for the sake of it.


Actually, I think we should support all of the metadata attributes, so 
that our PKCS#11 module is reasonably generic and not tailored to needs 
of a specific consumer.




But I think Jan's doc is a good start where he explains which attributes
will be used by specific modules eg for searches.



Thanks,
Simo.






--
Jan Cholasta

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

Re: [Freeipa-devel] DNSSEC design page

2014-02-25 Thread Dmitri Pal


On 02/25/2014 08:46 AM, Simo Sorce wrote:

On Tue, 2014-02-25 at 11:08 +0100, Petr Spacek wrote:

On 24.2.2014 20:20, Simo Sorce wrote:

Also can you add some examples on how we would use these classes to
store DNS keys ?

We need to think about it a bit more. We plan to use PKCS#11 for key
manipulation and data signing so the key itself will be unaware of any
DNSSEC-specific attributes. DNSSEC-specifics could be in an auxiliary 
objectClass.

I'm discussing this with CZ.NIC guys and they propose to add a 'layer of
indirection' between DNS zones and keys so one key set can be used by more DNS
zones. They claim that it is relatively common practice and I trust them.

Note that I'm not saying that IPA should use one key for multiple DNS zones by
default, but the schema should be future-proof and allow that if necessary.

Makes sense.


Let's start with this proposal:
DNS zone: idnsname=dnssec.test, cn=dns, dc=example
There will be multi-valued attribute idnsseckey pointing to DNs of keys stored
somewhere else.

Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns and store
keys there.

Ok, do we really want to have zones pointing at keys ?
Or do we want keys have a list of zones they are supposed to apply to ?



If we plan to store DNS keys in one place and other keys in other places 
in the tree (no common key store) then it really does not matter much.
It should be derived from the LDAP searches that would need to be 
conducted by the software.


We need keys for signing, right?
Any other use case?

If for signing we will start with a zone and would need to find keys 
that are relevant to this zone.
It seems that having a generic key class + auxiliary class that would 
keep metadata about the key, its expiration and DN it applies to would 
be a way to go.


So it seems that I agree with Simo that it would make sense to have the 
zone the key applies to specified in the key entry rather than in the 
zone entry.



I expect that PKCS#11 module will handle keys scattered over the LDAP tree
somehow.

Sure as long as it can understand what the keys are for.


Ideally the example would show the LDAP tree and some example data in
detail, and also what operation we think would be common.





--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-devel] DNSSEC design page

2014-02-25 Thread Rob Crittenden


Jan Cholasta wrote:

On 25.2.2014 17:36, Ludwig Krispenz wrote:


On 02/25/2014 05:12 PM, Simo Sorce wrote:

On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote:

On 25.2.2014 16:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:

On 25.2.2014 15:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:

Any reason why we should follow in detail what softshm does ?

because I did't know what is really needed. If you want to have a
pkcs11
module, which stores data in ldap, I though it should have all the
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
CKA_EXTRACTABLE,
so there is at least one requirement for fine grained attributes.

Does OpenDNSSEC store them as separate entities and need access
to them
independently ?

AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP
schema
doesn't matter as long as our PKCS#11 module can derive all values
defined by
standard.

Honza, you did investigate OpenDNSSEC integration, please add some
details if
you can.


Or is this internal use that can be satisfied by unpacking a blob in
OpenDNSSEC ?

What does bind9 uses ? Petr, can you provide example key files ?

Private+public keys stored in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html


Private keys stored in HSM and public keys in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html

(I.e. some values in .private file are replaced by PKCS#11 label.)

Ok it seem clear to me we do not need to spell out a lot of values
when
using pkcs#11 as bind doesn't need them in the key files. So I
assume it
can query the pkcs#11 module to find what it needs.

I would use these key files as a sort of guide to understand what we
need in LDAP. I would try to put in a single blob as much as we can
that
we do not explicitly need by a client querying LDAP directly.

I think in order to nail down exactly what we need, at this point, we
require some example use cases and queries the various clients would
perform with spelled out what they are looking for to identify or
manipulate keys.

Simo.


See How applications interact with PKCS#11 at
http://www.freeipa.org/page/V3/PKCS11_in_LDAP. Tl;dr: applications
don't search for keys by key data, but by metadata, so like I said in
the other thread, key data can be in a single blob, but metadata should
be in separate attributes.

Ah sorry, I hadn't looked at that one yet.
It helps quite a bit.

So are the class, key_type, id, label, token, 'sign' the only values we
should really care to split off ?


They are all metadata related to PKCS#11 operation. I don't think you
can easily encode them in PKCS#8 or certificate blob, so they actually
need to be split off. You can find the full list of them in the PKCS#11
spec (link below).



Can you describe what are these values ?
What is class ? Why is it important, and how does it differ from
key_type ?
What is the token ? What is 'sign' ?

Feel free to give references to specific documents to read up about
these attributes.

I'm a newcomer to this area and am orienting myself at this doc:
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf
and looking into opendnssec andsofthsm code.


I use mainly
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf, as
2.30 is a draft ATM.



It explains CKA_SIGN as:
TheCKA_SIGN attribute of the signature key, whic h indicates whether
the key supports signatures with appendix, must be CK_TRUE.
I cannot tell if this will be needed, just can make up an attribute and
allow it in an objectclass :-)


OpenDNSSEC puts it in public key objects it generates, so it's needed at
least for the sake of it.

Actually, I think we should support all of the metadata attributes, so
that our PKCS#11 module is reasonably generic and not tailored to needs
of a specific consumer.


We could hardcode some of these values but it will very likely cause 
problems later. It seems simple enough to just define schema for all of 
them and store them, except perhaps in the cases where they are easily 
derived. If we, for example, store the prime numbers and exponents, they 
need to be protected as carefully as the private key.


rob

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

Re: [Freeipa-devel] DNSSEC design page

On Tue, 2014-02-25 at 13:22 -0500, Rob Crittenden wrote:
 Jan Cholasta wrote:
  On 25.2.2014 17:36, Ludwig Krispenz wrote:
 
  On 02/25/2014 05:12 PM, Simo Sorce wrote:
  On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote:
  On 25.2.2014 16:11, Simo Sorce wrote:
  On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:
  On 25.2.2014 15:11, Simo Sorce wrote:
  On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:
  Any reason why we should follow in detail what softshm does ?
  because I did't know what is really needed. If you want to have a
  pkcs11
  module, which stores data in ldap, I though it should have all the
  attributes potentially needed.
  Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
  CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
  CKA_EXTRACTABLE,
  so there is at least one requirement for fine grained attributes.
  Does OpenDNSSEC store them as separate entities and need access
  to them
  independently ?
  AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP
  schema
  doesn't matter as long as our PKCS#11 module can derive all values
  defined by
  standard.
 
  Honza, you did investigate OpenDNSSEC integration, please add some
  details if
  you can.
 
  Or is this internal use that can be satisfied by unpacking a blob in
  OpenDNSSEC ?
 
  What does bind9 uses ? Petr, can you provide example key files ?
  Private+public keys stored in files:
  https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html
 
 
  Private keys stored in HSM and public keys in files:
  https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html
 
  (I.e. some values in .private file are replaced by PKCS#11 label.)
  Ok it seem clear to me we do not need to spell out a lot of values
  when
  using pkcs#11 as bind doesn't need them in the key files. So I
  assume it
  can query the pkcs#11 module to find what it needs.
 
  I would use these key files as a sort of guide to understand what we
  need in LDAP. I would try to put in a single blob as much as we can
  that
  we do not explicitly need by a client querying LDAP directly.
 
  I think in order to nail down exactly what we need, at this point, we
  require some example use cases and queries the various clients would
  perform with spelled out what they are looking for to identify or
  manipulate keys.
 
  Simo.
 
  See How applications interact with PKCS#11 at
  http://www.freeipa.org/page/V3/PKCS11_in_LDAP. Tl;dr: applications
  don't search for keys by key data, but by metadata, so like I said in
  the other thread, key data can be in a single blob, but metadata should
  be in separate attributes.
  Ah sorry, I hadn't looked at that one yet.
  It helps quite a bit.
 
  So are the class, key_type, id, label, token, 'sign' the only values we
  should really care to split off ?
 
  They are all metadata related to PKCS#11 operation. I don't think you
  can easily encode them in PKCS#8 or certificate blob, so they actually
  need to be split off. You can find the full list of them in the PKCS#11
  spec (link below).
 
 
  Can you describe what are these values ?
  What is class ? Why is it important, and how does it differ from
  key_type ?
  What is the token ? What is 'sign' ?
 
  Feel free to give references to specific documents to read up about
  these attributes.
  I'm a newcomer to this area and am orienting myself at this doc:
  ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf
  and looking into opendnssec andsofthsm code.
 
  I use mainly
  ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf, as
  2.30 is a draft ATM.
 
 
  It explains CKA_SIGN as:
  TheCKA_SIGN attribute of the signature key, whic h indicates whether
  the key supports signatures with appendix, must be CK_TRUE.
  I cannot tell if this will be needed, just can make up an attribute and
  allow it in an objectclass :-)
 
  OpenDNSSEC puts it in public key objects it generates, so it's needed at
  least for the sake of it.
 
  Actually, I think we should support all of the metadata attributes, so
  that our PKCS#11 module is reasonably generic and not tailored to needs
  of a specific consumer.
 
 We could hardcode some of these values but it will very likely cause 
 problems later. It seems simple enough to just define schema for all of 
 them and store them, except perhaps in the cases where they are easily 
 derived. If we, for example, store the prime numbers and exponents, they 
 need to be protected as carefully as the private key.

This is something I meant to discuss too, how do we protect them ?
Clearly we have ACIs but I am wondering if we want to encrypt them with
keys not immediately or easily available via LDAP ?

It's kind of catastrofic if they get inadvertently exposed like if
someone does a ldapsearch as Directory Manager, which is one of the
reasons why we encrypt kerberos key material before storing it into the
db.

Simo.

-- 
Simo Sorce * Red Hat,

Re: [Freeipa-devel] DNSSEC design page: PKCS#11 references