Re: [Freeipa-devel] [PATCH 0228] Drop unnecessary #define _BSD_SOURCE
On 24.2.2014 18:56, Lukas Slebodnik wrote: On (24/02/14 16:48), Petr Spacek wrote: Hello, Drop unnecessary #define _BSD_SOURCE. -- Petr^2 Spacek From 1b5105e3ab92f2a898313da5f7e20e6f3e9d1d2a Mon Sep 17 00:00:00 2001 From: Petr Spacek pspa...@redhat.com Date: Mon, 24 Feb 2014 16:48:09 +0100 Subject: [PATCH] Drop unnecessary #define _BSD_SOURCE. Signed-off-by: Petr Spacek pspa...@redhat.com --- src/krb5_helper.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/krb5_helper.c b/src/krb5_helper.c index d1787209483f2ae49b480492290ff5d4bafc677c..71f4fff9fec551abbd81e25c59de80d2ded0dfc6 100644 --- a/src/krb5_helper.c +++ b/src/krb5_helper.c @@ -15,8 +15,6 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#define _BSD_SOURCE - #include isc/util.h #include string.h #include stdlib.h -- 1.8.5.3 Simo is an author (according to git blame) He defined this macro due to function setenv from man setenv: NAME setenv - change or add an environment variable SYNOPSIS #include stdlib.h int setenv(const char *name, const char *value, int overwrite); int unsetenv(const char *name); Feature Test Macro Requirements for glibc (see feature_test_macros(7)): setenv(), unsetenv(): _BSD_SOURCE || _POSIX_C_SOURCE = 200112L || _XOPEN_SOURCE = 600 Macros _BSD_SOURCE _POSIX_C_SOURCE were defined when I included header file stdlib.h. I tested only on fedora 20. It can be used on the other distributions. I would rather let this macro as is. Wow, I didn't expect that somebody will spend time on this :-) See build logs from Fedora 21 http://koji.fedoraproject.org/koji/getfile?taskID=6565007name=build.log and https://bugzilla.redhat.com/show_bug.cgi?id=1067110 Patches with 'the right' solution are welcome. I'm not going to spend more time on this. If you really want to remove unused macro, you should look to the another file :-) ldap_helper.c:3829:0: warning: macro LDAP_ENTRYCHANGE_ALL is not used [-Wunused-macros] #define LDAP_ENTRYCHANGE_ALL (LDAP_SYNC_CAPI_ADD | LDAP_SYNC_CAPI_DELETE | LDAP_SYNC_CAPI_MODIFY) Have a nice day! -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0153] ipatests: Fix incorrect order of operations when restoring
On 02/25/2014 08:56 AM, Tomas Babej wrote: Given the fact that the patch has been ACKed, can we push the current iteration? On 02/20/2014 01:07 PM, Petr Viktorin wrote: On 02/20/2014 12:58 PM, Jan Pazdziora wrote: On Thu, Feb 20, 2014 at 12:20:12PM +0100, Petr Viktorin wrote: On 02/19/2014 04:54 PM, Jan Pazdziora wrote: However: since this is about restoring a backup, can't the backup contain the extended attributes, so that the SELinux context gets restored to the original state (which could be different from what the restorecon will give you)? Well, I guess you're the Beaker authority here. Is that necessary This is not about Beaker, is it? It is; all other use cases I know of use disposable or at least single-purpose VMs. But since you mention it, beakerlib does cp -a upon backup and restore https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n484 https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n593 for files to preserve the SELinux context, plus chcon --reference upon backup for directories: https://git.fedorahosted.org/cgit/beakerlib.git/tree/src/infrastructure.sh#n495 when restoring? The tests expect a sane state, and they return to that; using a somehow customized machine to test on is a bad idea anyway. You might specifically want to run your test on non-sane state because you want to test that the non-sane state will for example produce correct error, SELinux-related or other. In that case you're on your own, you should wrap the test in custom setup teardown code. There's no way we can perfectly restore a system after IPA has been installed on it, much less if it was an unstable/testing version of IPA, so returning to a sane state seems good for me. Pushed to: master: bc0872cc0b33379a2a4109c9b353ac81d10cec83 ipa-3-3: edba30d2c6c9b01cf023abb6c5bcc378a3d56272 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] FreeIPA documentation: getting started devel docs (FOSDEM takeaways - Software Archaeology for Beginners)
Hello list, I have seen talk Software Archaeology for Beginners from FOSDEM 2014 [1] and I have couple notes: 1) User docs: Make sure that project's documentation tells its own story: Documentation is not so useful if it is a bunch of unrelated documents. Make sure that there is 'introduction' document starting with project description. The 'story' should continue to installation and very basic configuration and use cases. There should not be a 'gap' between steps like missing steps between installation and client configuration etc. We have something like that in RHEL IdM guide. Should we add Getting Started link to the very beginning of http://www.freeipa.org/page/Documentation#User_Documentation ? Maybe the RHEL guide is too huge and scary for 'getting started' so we would need to write something/compile it from existing blogs posts etc. 2) Pictures with a story are nice: Diagrams with system components are more useful when they *visualize some basic workflows step by step*. Imagine one SSSD client and one IPA server and describe what happens if the user enters his username and password to login prompt. - Arrow #0 from NSS db /passwd/ to SSSD component /s1/ with description /d/ - Arrow #1 from SSSD component /s1/ to IPA component /i1/ with description /d/ - Arrow #2 from NSS db /shadow/ to SSSD component /s2/ with description /d/ - Arrow #3 from SSSD component /s2/ to IPA component /i2/ with description /d/ etc. Such diagram not only helps to new developers but also gives tremendous help to people debugging the whole solution. (We have to admit that debugging is always PITA.) As usual, this sounds like a good task for newcomers (sorry Adam! :-). [1] http://video.fosdem.org/2014/Janson/Saturday/Software_Archaeology_for_Beginners.webm -- 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] [PATCH 0137] ipalib: Add DateTime parameter
On 01/14/2014 10:19 AM, Petr Viktorin wrote:
On 01/14/2014 09:27 AM, Jan Cholasta wrote:
On 13.1.2014 14:57, Petr Vobornik wrote:
On 13.1.2014 13:41, Jan Cholasta wrote:
Hi,
On 10.1.2014 21:21, Nathaniel McCallum wrote:
On Thu, 2014-01-09 at 16:30 +0100, Tomas Babej wrote:
Hi,
Adds a parameter that represents a DateTime format using
datetime.datetime
object from python's native datetime library.
In the CLI, accepts one of the following formats:
Accepts subset of values defined by ISO 8601:
%Y-%m-%dT%H:%M:%S
%Y-%m-%dT%H:%M
'%Y%m%dT%H:%M:%S'
'%Y%m%dT%H:%M'
Also accepts LDAP Generalized time in the following format:
'%Y%m%d%H%M%SZ'
As a simplification, it does not deal with timezone info and ISO
8601
values with timezone info (+-hhmm) are rejected. Values are expected
to be in the UTC timezone.
Values are saved to LDAP as LDAP Generalized time values in the
format
'%Y%m%d%H%SZ' (no time fractions and UTC timezone is assumed). To
avoid
confusion, in addition to subset of ISO 8601 values, the LDAP
generalized
time in the format '%Y%m%d%H%M%SZ' is also accepted as an input (as
this
is the
format user will see on the output).
Part of: https://fedorahosted.org/freeipa/ticket/3306
The date/time syntax formats are not compliant with ISO 8601. You
stated
they are expected to be in UTC timezone, but no 'Z' is expected in
most
of them. This is not only non-standard, but would prevent you from
every
supporting local time in the future.
+1, please require the trailing Z.
I think generalized time format should be the preferred one, as it is
stored in LDAP and thus returned by commands. Also, do we really need
all of these other formats?
+1 That API should accept and always return generalized time.
But UIs(CLI, Web) should display something more human readable. Like:
%Y-%m-%dT%H:%M:%SZ or IMHO better (but not ISO 8601): %Y-%m-%d
%H:%M:%SZ
ie. 2014-03-08 14:16:55Z compared to 2014-03-08T14:16:55Z or
20140308141655Z
Both should accept input value in the same format. Usage of different
output and input formats is confusing. Thus I agree with supporting
more
input formats. Decision whether it should be done on API level or
client
level is another matter.
If you want human readable output, you have to do the conversion from
generalized time on clients. If you want to support local time and
timezones, you have to do some processing on the client as well. I would
be perfectly happy if we supported only generalized time over the wire
and did conversion from/to human readable on clients.
I has been implementing the Web UI part and I think we should also
support a formats without time component. My initial impl. supports
combinations of:
var dates = [
['-MM-DD', /^(\d{4})-(\d{2})-(\d{2})$/],
['MMDD',/^(\d{4})(\d{2})(\d{2})$/]
];
var times = [
['HH:mm:ss', /^(\d\d):(\d\d):(\d\d)Z$/],
['HH:mm', /^(\d\d):(\d\d)Z$/],
['HH', /^(\d\d)Z$/]
];
+ generalized time
['MMDDHHmmssZ',/^(\d{4})(\d{2})(\d{2})(\d{2})(\d{2})(\d{2})Z$/]
with /( |T)/ as divider and time optional.
Both UIs should also tell the user what is the expected format (at
least
one of them). Getting incorrect format error without knowing it is
annoying.
The current code raises a ValidationError including the list of formats.
On yesterday's meeting, Simo said that on the wire and for CLI output,
we should use generalized time.
I disagree with using it for CLI ouptut, as I find generalized time
unreadable, but for the API it's the obvious choice.
I believe we should require the Z postfix in all formats, so that 1)
users are forced to be aware that it's UTC, and 2) we can
theoretically support local time in the future.
I think the supported input formats should be:
%Y%m%d%H%M%SZ (generalized time)
%Y-%m-%dT%H:%M:%SZ (ISO 8601, with seconds)
%Y-%m-%dT%H:%MZ(ISO 8601, without seconds)
%Y-%m-%dZ (ISO 8601, date only)
I also think we should accept a space instead of the T, as Petr²
said above.
Thanks for review, everybody.
* All accepted formats now require explicit Z
* Accept values with ' ' instead of T
* LDAP generalized time used on the wire with JSON
* Minor implementation fixes
Updated patch should address all the issues.
--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From 4153e0010e5cf9eb5565e9bb2e29ec0e21c43e5d Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Thu, 9 Jan 2014 11:14:56 +0100
Subject: [PATCH] ipalib: Add DateTime parameter
Adds a parameter that represents a DateTime format using datetime.datetime
object from python's native datetime library.
In the CLI, accepts one of the following formats:
Accepts LDAP Generalized time without in the following format:
'%Y%m%d%H%M%SZ'
Accepts subset of values defined by ISO 8601:
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
[Freeipa-devel] [PATCH 0155] ipatests: Kill winbindd process after uninstall
Hi,
As a part of a better cleanup procedure in the integration tests,
make sure that winbindd is not running after uninstalling the IPA
server.
--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From ae2c3a7d3c559c53d7c4b61b80599145e8956db5 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Tue, 25 Feb 2014 12:53:44 +0100
Subject: [PATCH] ipatests: Kill winbindd process after uninstall
As a part of a better cleanup procedure in the integration tests,
make sure that winbindd is not running after uninstalling the IPA
server.
---
ipatests/test_integration/tasks.py | 9 +
1 file changed, 9 insertions(+)
diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py
index 9a6ea3fa548a53d6e5ab6d19783227c2d956a001..c180b0af0ba41b05f3e95ada63aa3aa68d6fc31c 100644
--- a/ipatests/test_integration/tasks.py
+++ b/ipatests/test_integration/tasks.py
@@ -444,6 +444,15 @@ def uninstall_master(host):
host.run_command(['ipa-server-install', '--uninstall', '-U'],
raiseonerr=False)
+
+# Processes that should not be left running after uninstall
+# So far we encountered stray processes of winbind only,
+# add more if required
+
+processes_to_kill = ('winbindd', )
+for process in processes_to_kill:
+host.run_command(['killall', '-9', process], raiseonerr=False)
+
unapply_fixes(host)
--
1.8.5.3
___
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] [PATCH 0155] ipatests: Kill winbindd process after uninstall
On Tue, 25 Feb 2014, Tomas Babej wrote:
Hi,
As a part of a better cleanup procedure in the integration tests,
make sure that winbindd is not running after uninstalling the IPA
server.
--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From ae2c3a7d3c559c53d7c4b61b80599145e8956db5 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Tue, 25 Feb 2014 12:53:44 +0100
Subject: [PATCH] ipatests: Kill winbindd process after uninstall
As a part of a better cleanup procedure in the integration tests,
make sure that winbindd is not running after uninstalling the IPA
server.
---
ipatests/test_integration/tasks.py | 9 +
1 file changed, 9 insertions(+)
diff --git a/ipatests/test_integration/tasks.py
b/ipatests/test_integration/tasks.py
index
9a6ea3fa548a53d6e5ab6d19783227c2d956a001..c180b0af0ba41b05f3e95ada63aa3aa68d6fc31c
100644
--- a/ipatests/test_integration/tasks.py
+++ b/ipatests/test_integration/tasks.py
@@ -444,6 +444,15 @@ def uninstall_master(host):
host.run_command(['ipa-server-install', '--uninstall', '-U'],
raiseonerr=False)
+
+# Processes that should not be left running after uninstall
+# So far we encountered stray processes of winbind only,
+# add more if required
+
+processes_to_kill = ('winbindd', )
+for process in processes_to_kill:
+host.run_command(['killall', '-9', process], raiseonerr=False)
+
unapply_fixes(host)
ACK.
--
/ Alexander Bokovoy
___
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
[Freeipa-devel] [PATCH] 544 webui: Focus expand/collapse link in batch_error dialog
Dialog loses focus when the links are clicked making the dialog
uncontrollable by keyboard. This patch focuses the link again after
expanding/collapsing the error list. Thus keeping the focus in a dialog
https://fedorahosted.org/freeipa/ticket/4097
--
Petr Vobornik
From 54c117596a19ed512c29d5bbeea42d58f31ebbce Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 14 Jan 2014 13:52:44 +0100
Subject: [PATCH] webui: Focus expand/collapse link in batch_error dialog
Dialog loses focus when the links are clicked making the dialog uncontrollable by keyboard. This patch focuses the link again after expanding/collapsing the error list. Thus keeping the focus in a dialog
https://fedorahosted.org/freeipa/ticket/4097
---
install/ui/src/freeipa/ipa.js | 2 ++
1 file changed, 2 insertions(+)
diff --git a/install/ui/src/freeipa/ipa.js b/install/ui/src/freeipa/ipa.js
index 54cd90cb659bbe64395061a5a7acfd4b8af0b249..e6f10d8a2e873a5953212b4249fab68599831f21 100644
--- a/install/ui/src/freeipa/ipa.js
+++ b/install/ui/src/freeipa/ipa.js
@@ -1730,6 +1730,7 @@ IPA.error_dialog = function(spec) {
errors_container.show();
show_details.hide();
hide_details.show();
+hide_details.focus();
return false;
});
@@ -1737,6 +1738,7 @@ IPA.error_dialog = function(spec) {
errors_container.hide();
hide_details.hide();
show_details.show();
+show_details.focus();
return false;
});
}
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 545 webui: Don't act on keyboard events which originated in, different dialog
Fixes issue when:
1. 2 dialogs are opened
2. top dialog's close button is focused
3. user presses enter to execute 'close' action
4. dialog is immediately closed (enter key is still pressed)
5. second dialog automatically receives focus (it's top dialog now)
6. user releases the key
7. second dialog reacts to keyup event - which is by default
confirmation mixin's confirm event
8. UNDESIRED behavior occurs
Now confirmation mixin remembers which keys were pressed and released
and reacts only to those which originated there.
https://fedorahosted.org/freeipa/ticket/4098
--
Petr Vobornik
From 38b586a287dba18abab885072db067a0411820e5 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Tue, 14 Jan 2014 17:29:47 +0100
Subject: [PATCH] webui: Don't act on keyboard events which originated in
different dialog
Fixes issue when:
1. 2 dialogs are opened
2. top dialog's close button is focused
3. user presses enter to execute 'close' action
4. dialog is immediately closed (enter key is still pressed)
5. second dialog automatically receives focus (it's top dialog now)
6. user releases the key
7. second dialog reacts to keyup event - which is by default confirmation mixin's confirm event
8. UNDESIRED behavior occurs
Now confirmation mixin remembers which keys were pressed and released and reacts only to those which originated there.
https://fedorahosted.org/freeipa/ticket/4098
---
install/ui/src/freeipa/dialog.js | 35 +--
1 file changed, 33 insertions(+), 2 deletions(-)
diff --git a/install/ui/src/freeipa/dialog.js b/install/ui/src/freeipa/dialog.js
index cf9c7c304b8033552a84215fbb1966d664fdf222..941ff8a292e0263217c3fae900d3afc9e6380a76 100644
--- a/install/ui/src/freeipa/dialog.js
+++ b/install/ui/src/freeipa/dialog.js
@@ -1249,7 +1249,16 @@ IPA.confirm_mixin = function() {
},
/**
+ * Map of keys which are down
+ * @property {Object}
+ */
+keysdown: {},
+
+/**
* Test if event is confirmation event
+ *
+ * Clears event's keyCode in `keysdown` map
+ *
* @param {Event} event
* @return {boolean}
*/
@@ -1257,9 +1266,11 @@ IPA.confirm_mixin = function() {
var ir = this.ignore_enter_rules,
t = event.target,
-
+key = event.keyCode,
ignore = ir.src_elements.indexOf(t.tagName.toLowerCase()) -1 ||
- ir.src_types.indexOf(t.type) -1;
+ ir.src_types.indexOf(t.type) -1 ||
+ !this.keysdown[key];
+delete this.keysdown[key];
return ignore;
},
@@ -1270,8 +1281,10 @@ IPA.confirm_mixin = function() {
register_listeners: function() {
var self = this;
this._on_key_up_listener = function(e) { self.on_key_up(e); };
+this._on_key_down_listener = function(e) { self._on_key_down(e); };
var dialog_container = this.dom_node;
dialog_container.bind('keyup', this._on_key_up_listener);
+dialog_container.bind('keydown', this._on_key_down_listener);
},
/**
@@ -1280,6 +1293,7 @@ IPA.confirm_mixin = function() {
remove_listeners: function() {
var dialog_container = this.dom_node;
dialog_container.unbind('keyup', this._on_key_up_listener);
+dialog_container.unbind('keydown', this._on_key_down_listener);
},
/**
@@ -1298,6 +1312,23 @@ IPA.confirm_mixin = function() {
event.preventDefault();
this.on_cancel();
}
+delete this.keysdown[event.keyCode];
+},
+
+/**
+ * Internal listener for saving which keys were pressed to
+ * prevent reaction to event which originated in completely different
+ * control.
+ *
+ * Example: first dialog is closed by keydown event, second is
+ * therefore focused and consumes keyup event which can lead to undesired
+ * behavior.
+ *
+ * @private
+ * @param {Event} event
+ */
+_on_key_down: function(event) {
+this.keysdown[event.keyCode] = true;
}
},
--
1.8.5.3
___
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: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] [PATCH 0228] Drop unnecessary #define _BSD_SOURCE
On (25/02/14 09:54), Petr Spacek wrote: On 24.2.2014 18:56, Lukas Slebodnik wrote: On (24/02/14 16:48), Petr Spacek wrote: Hello, Drop unnecessary #define _BSD_SOURCE. -- Petr^2 Spacek From 1b5105e3ab92f2a898313da5f7e20e6f3e9d1d2a Mon Sep 17 00:00:00 2001 From: Petr Spacek pspa...@redhat.com Date: Mon, 24 Feb 2014 16:48:09 +0100 Subject: [PATCH] Drop unnecessary #define _BSD_SOURCE. Signed-off-by: Petr Spacek pspa...@redhat.com --- src/krb5_helper.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/krb5_helper.c b/src/krb5_helper.c index d1787209483f2ae49b480492290ff5d4bafc677c..71f4fff9fec551abbd81e25c59de80d2ded0dfc6 100644 --- a/src/krb5_helper.c +++ b/src/krb5_helper.c @@ -15,8 +15,6 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -#define _BSD_SOURCE - #include isc/util.h #include string.h #include stdlib.h -- 1.8.5.3 Simo is an author (according to git blame) He defined this macro due to function setenv from man setenv: NAME setenv - change or add an environment variable SYNOPSIS #include stdlib.h int setenv(const char *name, const char *value, int overwrite); int unsetenv(const char *name); Feature Test Macro Requirements for glibc (see feature_test_macros(7)): setenv(), unsetenv(): _BSD_SOURCE || _POSIX_C_SOURCE = 200112L || _XOPEN_SOURCE = 600 Macros _BSD_SOURCE _POSIX_C_SOURCE were defined when I included header file stdlib.h. I tested only on fedora 20. It can be used on the other distributions. I would rather let this macro as is. Wow, I didn't expect that somebody will spend time on this :-) See build logs from Fedora 21 http://koji.fedoraproject.org/koji/getfile?taskID=6565007name=build.log You should have noticed this in the 1st mail. Because it is difference between removing unnecessary macro and depprecated usage of macro. /usr/include/features.h:145:3: error: #warning _BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE [-Werror=cpp] # warning _BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE Patches with 'the right' solution are welcome. I'm not going to spend more time on this. ACK LS ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0043] Remove NULLS from constants.py
On Fri, Feb 21, 2014 at 11:42:45AM -0500, Nathaniel McCallum wrote: In the parameters system, we have been checking for a positive list of values which get converted to None. The problem is that this method can in some cases throw warnings when type coercion doesn't work (particularly, string to unicode). Instead, any values that evaluate to False that are neither numeric nor boolean should be converted to None. From 98911a96a9b023081458e0f3674bf8096f8f5c43 Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum npmccal...@redhat.com Date: Fri, 21 Feb 2014 11:38:32 -0500 Subject: [PATCH] Remove NULLS from constants.py In the parameters system, we have been checking for a positive list of values which get converted to None. The problem is that this method can in some cases throw warnings when type coercion doesn't work (particularly, string to unicode). Instead, any values that evaluate to False that are neither numeric nor boolean should be converted to None. [...] Ack, all original values pass the _is_null() test. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ 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 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] [PATCH] Certificate search max_serial_number problem fixed
On 02/25/2014 02:47 PM, Jan Cholasta wrote: On 21.2.2014 12:11, Adam Misnyovszki wrote: - Original Message - From: Jan Cholasta jchol...@redhat.com To: Adam Misnyovszki amisn...@redhat.com, freeipa-devel@redhat.com Sent: Friday, February 21, 2014 11:05:12 AM Subject: Re: [Freeipa-devel] [PATCH] Certificate search max_serial_number problem fixed Hi, On 20.2.2014 18:15, Adam Misnyovszki wrote: Hi, this patch fixes ticket https://fedorahosted.org/freeipa/ticket/4163 maximum serial number field now accepts only positive numbers Thanks Adam I think you should also add maxvalue to min_serial_number, so that they are consistent. Honza -- Jan Cholasta Makes sense, new patch added. Adam Thanks, ACK. Pushed to master: be7b1b94e300b137c34bab80df3dc91195259c89 -- Petr³ ___ 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. 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. 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
[Freeipa-devel] 389-DS ACI improvement to control MODDN
Hello, Ticket https://fedorahosted.org/389/ticket/47553, is a 389-ds enhancement to allow a finer access control during a MODDN (new superior) operation. The use case being to allow/deny a bound user to move an entry from one specified part of the DIT to an other part. This without the need to grant the ADD permission. I started a design of it http://port389.org/wiki/Access_control_on_trees_specified_in_MODDN_operation. Comments are welcomed. regards thierry ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0043] Remove NULLS from constants.py
On 02/25/2014 03:07 PM, Jan Pazdziora wrote: On Fri, Feb 21, 2014 at 11:42:45AM -0500, Nathaniel McCallum wrote: In the parameters system, we have been checking for a positive list of values which get converted to None. The problem is that this method can in some cases throw warnings when type coercion doesn't work (particularly, string to unicode). Instead, any values that evaluate to False that are neither numeric nor boolean should be converted to None. From 98911a96a9b023081458e0f3674bf8096f8f5c43 Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum npmccal...@redhat.com Date: Fri, 21 Feb 2014 11:38:32 -0500 Subject: [PATCH] Remove NULLS from constants.py In the parameters system, we have been checking for a positive list of values which get converted to None. The problem is that this method can in some cases throw warnings when type coercion doesn't work (particularly, string to unicode). Instead, any values that evaluate to False that are neither numeric nor boolean should be converted to None. [...] Ack, all original values pass the _is_null() test. Pushed to master: 4499b25be90227e54fc4a9f54598cadc8d2f6394 -- Petr³ ___ 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] [PATCH] Certificate search max_serial_number problem fixed
On 02/25/2014 04:01 PM, Petr Viktorin wrote:
On 02/25/2014 02:47 PM, Jan Cholasta wrote:
On 21.2.2014 12:11, Adam Misnyovszki wrote:
- Original Message -
From: Jan Cholasta jchol...@redhat.com
To: Adam Misnyovszki amisn...@redhat.com, freeipa-devel@redhat.com
Sent: Friday, February 21, 2014 11:05:12 AM
Subject: Re: [Freeipa-devel] [PATCH] Certificate search
max_serial_number problem fixed
Hi,
On 20.2.2014 18:15, Adam Misnyovszki wrote:
Hi,
this patch fixes ticket https://fedorahosted.org/freeipa/ticket/4163
maximum serial number field now accepts only positive numbers
Thanks
Adam
I think you should also add maxvalue to min_serial_number, so that they
are consistent.
Honza
--
Jan Cholasta
Makes sense, new patch added.
Adam
Thanks, ACK.
Pushed to master: be7b1b94e300b137c34bab80df3dc91195259c89
Adam, you have not updated API.txt. To do this you need to run the
makeapi script when changing the API. When you run `make rpms` you will
be warned if there is a mismatch.
FWIW, I have the following in my .git/hooks/post-commit, so Git alerts
me of problems after a commit:
./makeapi
git status --short # Show modified files, mainly for the case that
makeapi modified API.txt
Honza, please make sure IPA actually builds before you ACK a patch.
Attached fix pushed as one-(well,two)-liner to master:
00d6b529c977c19fc5bb2e230da551ac01c79d79
--
Petr³
From 562617f7a845fe468510ff27688039794ce0dd80 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Tue, 25 Feb 2014 16:20:04 +0100
Subject: [PATCH] Update API.txt
This fixes commit be7b1b94e300b137c34bab80df3dc91195259c89
https://fedorahosted.org/freeipa/ticket/4163
---
API.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/API.txt b/API.txt
index 504a60ff31686cfa828c3a8f17debd6dad3bb60d..070134959dd2cfdd7a281b3e50d8bc92fe21cdeb 100644
--- a/API.txt
+++ b/API.txt
@@ -453,8 +453,8 @@ command: cert_find
option: Flag('exactly?', autofill=True, default=False)
option: Str('issuedon_from?', autofill=False)
option: Str('issuedon_to?', autofill=False)
-option: Int('max_serial_number?', autofill=False, maxvalue=2147483647)
-option: Int('min_serial_number?', autofill=False, minvalue=0)
+option: Int('max_serial_number?', autofill=False, maxvalue=2147483647, minvalue=0)
+option: Int('min_serial_number?', autofill=False, maxvalue=2147483647, minvalue=0)
option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
option: Int('revocation_reason?', autofill=False, maxvalue=10, minvalue=0)
option: Str('revokedon_from?', autofill=False)
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page
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
[Freeipa-devel] [PATCH] 0138 ipa-kdb: in case of delegation use original client's database entry, not the proxy
Hi!
In case we've got constraint delegation, we need to look into the
delegated entry, not the service that is going to delegate it.
I'm not sure we need to pass original entry in both cases but with this
patch we have solved long standing problem of testing AD trusts in
automated CI.
https://fedorahosted.org/freeipa/ticket/4195
--
/ Alexander Bokovoy
From 8e7c41bf35d68bfad2dc5b790cf6f5b964949417 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Tue, 25 Feb 2014 17:50:55 +0200
Subject: [PATCH v1 1/2] ipa-kdb: in case of delegation use original client's
database entry, not the proxy
https://fedorahosted.org/freeipa/ticket/4195
---
daemons/ipa-kdb/ipa_kdb_mspac.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index ff67391..2a0480f 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -1983,12 +1983,14 @@ krb5_error_code ipadb_sign_authdata(krb5_context
context,
bool with_pac;
bool with_pad;
int result;
+krb5_db_entry *client_entry = NULL;
/* When using s4u2proxy client_princ actually refers to the proxied user
* while client-princ to the proxy service asking for the TGS on behalf
* of the proxied user. So always use client_princ in preference */
if (client_princ != NULL) {
ks_client_princ = client_princ;
+kerr = ipadb_get_principal(context, client_princ, flags,
client_entry);
} else {
ks_client_princ = client-princ;
}
@@ -2025,7 +2027,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context,
}
}
-kerr = ipadb_get_pac(context, client, pac);
+kerr = ipadb_get_pac(context, client_entry ? client_entry : client,
pac);
if (kerr != 0 kerr != ENOENT) {
goto done;
}
@@ -2041,7 +2043,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context,
/* check or generate pac data */
if ((pac_auth_data == NULL) || (pac_auth_data[0] == NULL)) {
if (flags KRB5_KDB_FLAG_CONSTRAINED_DELEGATION) {
-kerr = ipadb_get_pac(context, client, pac);
+kerr = ipadb_get_pac(context, client_entry ? client_entry :
client, pac);
if (kerr != 0 kerr != ENOENT) {
goto done;
}
@@ -2094,6 +2096,9 @@ krb5_error_code ipadb_sign_authdata(krb5_context context,
kerr = 0;
done:
+if (client_entry != NULL) {
+ipadb_free_principal(context, client_entry);
+}
krb5_pac_free(context, pac);
return kerr;
}
--
1.8.3.1
___
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
[Freeipa-devel] [PATCH] 546 webui: expose krbprincipalexpiration
Depends on tbabej's patches # 137, 138 and my 546.
https://fedorahosted.org/freeipa/ticket/3306
--
Petr Vobornik
From 7b4a35b811a8918adefa281e00ee06fad5f54064 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Wed, 15 Jan 2014 14:15:24 +0100
Subject: [PATCH] webui: expose krbprincipalexpiration
https://fedorahosted.org/freeipa/ticket/3306
---
install/ui/src/freeipa/user.js | 5 +
1 file changed, 5 insertions(+)
diff --git a/install/ui/src/freeipa/user.js b/install/ui/src/freeipa/user.js
index 6c5fbac4d68586075ff0c99d37f7eb6e96a8742f..e5d49197a6db76037da919e3e1eb7d0bc55e4357 100644
--- a/install/ui/src/freeipa/user.js
+++ b/install/ui/src/freeipa/user.js
@@ -139,6 +139,11 @@ return {
},
'uidnumber',
'gidnumber',
+'krbprincipalname',
+{
+$type: 'datetime',
+name: 'krbprincipalexpiration'
+},
'loginshell',
'homedirectory',
{
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 548 webui: change ipatokennotbefore and ipatokennotafter types to datetime
Depends on tbabej's patches # 137, 140 and pvoborni's 546 and 531-541.
https://fedorahosted.org/freeipa/ticket/3369
--
Petr Vobornik
From 7a9d5636978b77a6e1119bc7e5724a811fcbf669 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Wed, 15 Jan 2014 14:19:41 +0100
Subject: [PATCH] webui: change ipatokennotbefore and ipatokennotafter types to
datetime
https://fedorahosted.org/freeipa/ticket/3369
---
install/ui/src/freeipa/otptoken.js | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/install/ui/src/freeipa/otptoken.js b/install/ui/src/freeipa/otptoken.js
index 1e04b62416d43310feeec99a40eb4907ba24cf4a..dbebeb94046726e9e5971d839e75c157fff18960 100644
--- a/install/ui/src/freeipa/otptoken.js
+++ b/install/ui/src/freeipa/otptoken.js
@@ -174,8 +174,14 @@ return {
name: 'description'
},
'ipatokenowner',
-'ipatokennotbefore',
-'ipatokennotafter',
+{
+$type: 'datetime',
+name: 'ipatokennotbefore'
+},
+{
+$type: 'datetime',
+name: 'ipatokennotafter'
+},
'ipatokenvendor',
'ipatokenmodel',
'ipatokenserial',
@@ -219,8 +225,14 @@ return {
other_entity: 'user',
other_field: 'uid'
},
-'ipatokennotbefore',
-'ipatokennotafter',
+{
+$type: 'datetime',
+name: 'ipatokennotbefore'
+},
+{
+$type: 'datetime',
+name: 'ipatokennotafter'
+},
'ipatokenvendor',
'ipatokenmodel',
'ipatokenserial',
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 549 webui: use unique ids for checkboxes
This is a minor fix. Please don't close ticket 3904 yet if committed.
Checkboxes have not used unique ids across the whole UI. It broke
checking by clicking on label for later displayed instances. It became
serious problem when rcue introduced new checkbox styles with 'label
clicking' as default check method.
https://fedorahosted.org/freeipa/ticket/3904
--
Petr Vobornik
From e64cbab0e4a3ef427e4f74e6f1183a9231dfb6c5 Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Thu, 16 Jan 2014 13:54:03 +0100
Subject: [PATCH] webui: use unique ids for checkboxes
Checkboxes have not used unique ids across the whole UI. It broke checking by clicking on label for later displayed instances. It became serious problem when rcue introduced new checkbox styles with 'label clicking' as default check method.
https://fedorahosted.org/freeipa/ticket/3904
---
install/ui/src/freeipa/widget.js | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/install/ui/src/freeipa/widget.js b/install/ui/src/freeipa/widget.js
index 81db75e5776bd37964efdb1b4feb38ba4355204f..6ee61c6583509301d0aa98f64fefa14d5d27f5ea 100644
--- a/install/ui/src/freeipa/widget.js
+++ b/install/ui/src/freeipa/widget.js
@@ -1201,10 +1201,7 @@ IPA.option_widget_base = function(spec, that) {
that.get_input_name = function() {
if (!that._input_name) {
-var name = that.name;
-if (that.input_type === 'radio') {
-name = IPA.html_util.get_next_id(name);
-}
+var name = IPA.html_util.get_next_id(that.name);
that._input_name = name;
that._selector = 'input[name='+name+']';
}
--
1.8.5.3
___
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
[Freeipa-devel] Thank you for FreeOTP!
Heya, Just wanted to say thank you for FreeOTP, Nathaniel and co. And, of course, more thankful to all the Identity open source/free software from this awesome team! A happy user. -- /kashyap ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA documentation: getting started devel docs (FOSDEM takeaways - Software Archaeology for Beginners)
On 02/25/2014 01:32 AM, Petr Spacek wrote: Hello list, I have seen talk Software Archaeology for Beginners from FOSDEM 2014 [1] and I have couple notes: 1) User docs: Make sure that project's documentation tells its own story: Documentation is not so useful if it is a bunch of unrelated documents. Make sure that there is 'introduction' document starting with project description. The 'story' should continue to installation and very basic configuration and use cases. There should not be a 'gap' between steps like missing steps between installation and client configuration etc. We have something like that in RHEL IdM guide. Should we add Getting Started link to the very beginning of http://www.freeipa.org/page/Documentation#User_Documentation ? Maybe the RHEL guide is too huge and scary for 'getting started' so we would need to write something/compile it from existing blogs posts etc. 2) Pictures with a story are nice: Diagrams with system components are more useful when they *visualize some basic workflows step by step*. I find diagrams very useful for workflows as well. They are very useful when used in combination with your typical architecture diagram. I used http://www.websequencediagrams.com to generate workflow diagrams for the Password Vault design proposal: http://www.freeipa.org/page/V3/Password_Vault I'd recommend trying that tool, as it's really pretty quick/easy to write the code to cretre the diagram, and you don't need to mess around with an actual drawing program. -NGK Imagine one SSSD client and one IPA server and describe what happens if the user enters his username and password to login prompt. - Arrow #0 from NSS db /passwd/ to SSSD component /s1/ with description /d/ - Arrow #1 from SSSD component /s1/ to IPA component /i1/ with description /d/ - Arrow #2 from NSS db /shadow/ to SSSD component /s2/ with description /d/ - Arrow #3 from SSSD component /s2/ to IPA component /i2/ with description /d/ etc. Such diagram not only helps to new developers but also gives tremendous help to people debugging the whole solution. (We have to admit that debugging is always PITA.) As usual, this sounds like a good task for newcomers (sorry Adam! :-). [1] http://video.fosdem.org/2014/Janson/Saturday/Software_Archaeology_for_Beginners.webm ___ 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 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
[Freeipa-devel] [PATCH] 0139 trustdomain_find: make sure we skip short entries when --pkey-only is specified
Hi, Simple patch to fix KeyError as --pkey-only causes no attributes to be returned and trustdomain_find.post_callback checked them unconditionally. https://fedorahosted.org/freeipa/ticket/4196 -- / Alexander Bokovoy From a8540634ddac57ce3c05416b3a08a958b01d99b3 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy aboko...@redhat.com Date: Tue, 25 Feb 2014 19:47:10 +0200 Subject: [PATCH 2/2] trustdomain_find: make sure we skip short entries when --pkey-only is specified With --pkey-only only primary key is returned. It makes no sense to check and replace boolean values then. https://fedorahosted.org/freeipa/ticket/4196 --- ipalib/plugins/trust.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 5ab4b25..050c468 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -1192,6 +1192,9 @@ class trustdomain_find(LDAPSearch): trust_dn = self.obj.get_dn(args[0], trust_type=u'ad') trust_entry = ldap.get_entry(trust_dn) for entry in entries: +if 'ipanttrustedomainsid' not in entry: +# --pkey-only case +continue sid = entry['ipanttrusteddomainsid'][0] if sid in trust_entry['ipantsidblacklistincoming']: entry['domain_enabled'] = [False] -- 1.8.3.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0155] ipatests: Kill winbindd process after uninstall
On Tue, 25 Feb 2014, Tomas Babej wrote: Hi, As a part of a better cleanup procedure in the integration tests, make sure that winbindd is not running after uninstalling the IPA server. Better patch 0140 attached. We simply need to stop and disable winbind in adtrustinstance.uninstall() -- / Alexander Bokovoy From 01c230ddcc3b70ddc147c1b46e766e5cab93c380 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy aboko...@redhat.com Date: Tue, 25 Feb 2014 20:11:50 +0200 Subject: [PATCH 3/3] adtrustinstance: make sure to stop and disable winbind in uninstall() This makes unnecessary Tomas' patch 0155. --- ipaserver/install/adtrustinstance.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index 621e3fd..6e30d5a 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -889,11 +889,14 @@ class ADTRUSTInstance(service.Service): self.restore_state(running) self.restore_state(enabled) +winbind = ipaservices.service(winbind) # Always try to stop and disable smb service, since we do not leave # working configuration after uninstall try: self.stop() self.disable() +winbind.stop() +winbind.disable() except: pass -- 1.8.3.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0155] ipatests: Kill winbindd process after uninstall
On 02/25/2014 01:21 PM, Tomas Babej wrote: Hi, As a part of a better cleanup procedure in the integration tests, make sure that winbindd is not running after uninstalling the IPA server. -9, what a brutal way to kill. Usually when I stop a service this way, systemd restarts it right away. Does that not happen in this case? -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page
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
[Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes
Resending patch 0138 together with another case Simo found out today:
when authdata flag is cleared by admin for the service principal, we'll
get NULL client database entry. In such case we have to bail out.
--
/ Alexander Bokovoy
From 8e7c41bf35d68bfad2dc5b790cf6f5b964949417 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Tue, 25 Feb 2014 17:50:55 +0200
Subject: [PATCH v1 1/2] ipa-kdb: in case of delegation use original client's
database entry, not the proxy
https://fedorahosted.org/freeipa/ticket/4195
---
daemons/ipa-kdb/ipa_kdb_mspac.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index ff67391..2a0480f 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -1983,12 +1983,14 @@ krb5_error_code ipadb_sign_authdata(krb5_context
context,
bool with_pac;
bool with_pad;
int result;
+krb5_db_entry *client_entry = NULL;
/* When using s4u2proxy client_princ actually refers to the proxied user
* while client-princ to the proxy service asking for the TGS on behalf
* of the proxied user. So always use client_princ in preference */
if (client_princ != NULL) {
ks_client_princ = client_princ;
+kerr = ipadb_get_principal(context, client_princ, flags,
client_entry);
} else {
ks_client_princ = client-princ;
}
@@ -2025,7 +2027,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context,
}
}
-kerr = ipadb_get_pac(context, client, pac);
+kerr = ipadb_get_pac(context, client_entry ? client_entry : client,
pac);
if (kerr != 0 kerr != ENOENT) {
goto done;
}
@@ -2041,7 +2043,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context,
/* check or generate pac data */
if ((pac_auth_data == NULL) || (pac_auth_data[0] == NULL)) {
if (flags KRB5_KDB_FLAG_CONSTRAINED_DELEGATION) {
-kerr = ipadb_get_pac(context, client, pac);
+kerr = ipadb_get_pac(context, client_entry ? client_entry :
client, pac);
if (kerr != 0 kerr != ENOENT) {
goto done;
}
@@ -2094,6 +2096,9 @@ krb5_error_code ipadb_sign_authdata(krb5_context context,
kerr = 0;
done:
+if (client_entry != NULL) {
+ipadb_free_principal(context, client_entry);
+}
krb5_pac_free(context, pac);
return kerr;
}
--
1.8.3.1
From d3af14384d6612121dfa8e75b3cb690c490a1004 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy aboko...@redhat.com
Date: Tue, 25 Feb 2014 20:53:49 +0200
Subject: [PATCH 4/4] ipa-kdb: make sure we don't produce MS-PAC in case of
authdata flag cleared by admin
When admin clears authdata flag for the service principal, KDC will pass
NULL client pointer (service proxy) to the DAL driver.
Make sure we bail out correctly.
---
daemons/ipa-kdb/ipa_kdb_mspac.c | 8
1 file changed, 8 insertions(+)
diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index 2170675..771b40b 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -1989,6 +1989,14 @@ krb5_error_code ipadb_sign_authdata(krb5_context context,
int result;
krb5_db_entry *client_entry = NULL;
+
+/* When client is NULL, authdata flag on the service principal was cleared
+ * by an admin. We don't generate MS-PAC in this case */
+if (client == NULL) {
+*signed_auth_data = NULL;
+return 0;
+}
+
/* When using s4u2proxy client_princ actually refers to the proxied user
* while client-princ to the proxy service asking for the TGS on behalf
* of the proxied user. So always use client_princ in preference */
--
1.8.3.1
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes
On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote: Resending patch 0138 together with another case Simo found out today: when authdata flag is cleared by admin for the service principal, we'll get NULL client database entry. In such case we have to bail out. The patches look correct code-flow-wise to me. So tentative ack pending testing. 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 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
On 25.2.2014 18:26, 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. But I think Jan's doc is a good start where he explains which attributes will be used by specific modules eg for searches. This page contains couple interesting links to standards and related software: https://wiki.opendnssec.org/display/DOCREF/PKCS11 -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Reviewer in Trac
On Thu, Feb 20, 2014 at 02:11:08PM -0500, Simo Sorce wrote: On Thu, 2014-02-20 at 17:29 +0100, Petr Viktorin wrote: Patchwork: patch arrives: nothing mark self as reviewer: use web interface send review: reply, find patch in Patchwork, mark status send fixed patch: send the mail, find patch in Patchwork, mark status, find old patch in Patchwork, mark old patch as superseded patch pushed/superseded: find patch in Patchwork, mark as pushed (where find patch in Patchwork is frustrating when done so often) Well now I have patches that do 2 things: Thank you, this is really helpful! 1. accept commands to change state and reviewer via email headers What I do now with my MUA (mutt+vim) is: * in the compose view, hit E which brings me to a view that also allows to edit headers in addition to body * Hit Ctrl+a to ack the patch, Ctrl+t to nack the patch, Ctrl+r to just mark myself the patch as Under review To add the headers I've defined the following macro in ~/.vimrc: function! PatchworkMacros() a - ack nmap C-a ggiX-Patchwork-State: AcceptedCRESC n - nack nmap C-n ggiX-Patchwork-State: Changes RequestedCRESC r - review nmap C-r ggiX-Patchwork-State: Under ReviewCRESC t - take nmap C-t ggiX-Patchwork-Delegate: jhro...@redhat.comCRESC endf autocmd BufWinEnter /var/tmp/mutt-* call PatchworkMacros() (Arguably I could fold C-t into the three combos above, but I'm still experimenting with the setup..) So the added logistics is to learn to press E instead of e in the compose view and one key combo. Of course, the setup is higly dependant on the mail client.. Also, maybe someone with more mutt knowledge will educate me how to define the macros directly in .muttrc so I didn't have to go to the special compose mode with 'E', but my attempts with using my_hdr failed.. 2. automatically marks superseded older patches in the same mailthread This works like a charm automagically. I will install these patches shortly Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 531-541 OTP UI
On 02/24/2014 10:21 AM, Nathaniel McCallum wrote: On Mon, 2014-02-24 at 15:48 +0100, Petr Vobornik wrote: On 24.2.2014 15:31, Nathaniel McCallum wrote: On Mon, 2014-02-24 at 11:04 +0100, Petr Vobornik wrote: On 21.2.2014 20:00, Nathaniel McCallum wrote: Is it possible to do something more intelligent for the key and date fields in the add-token UI? Date fields are currently just a text box. Is there any sort of calendar we could use here? If not, I'm still unsure of what the format should be for this field. It's the format you chose :), try to fill it in CLI, you will have the same proble. From API level it's just string, from LDAP it's generalized time. Is there a better option? I'm open to suggestions. As I mentioned below, it's being implemented. The datetime patches will be send separately. The core OTP UI patches should not be blocked by them. I've an UI patch prepared where you can write it in ISO format, with a validator attached to it, so user will be noticed about the format, but it's waiting for: https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html The key field should probably have a note indicating that it is Base32 encoding. It would also be nice to restrict the input to Base32 characters. Maybe even automatic case correction... Actually I think it doesn't help much. Show me a person who can write base32 encoded string But I agree that a validator with some regex to limit the chars and a note that it should be base32 string is better. The question is what's the purpose of this field from user perspective. Is a human being suppose to fill it or is it meant to be only filled by some provisioning systems? In UI it's just as a backup? If there is a use case where user is suppose to choose the key, it would be better to fill the key and convert it to base32 string on a server. I can't think of any case where a user would use the key field. However, there are at least two important cases where an admin would do this: 1. Hardware tokens 2. Transferring OATH (TOTP/HOTP) tokens from another system Nathaniel What is the input format for these two cases? Is it base32 so admin can enter it into UI or is it plain text so he has to use different tool to encode it to base32 and then fill into UI? In both of the above cases, I suspect the predominant use will be scripts written to take a token store and import the tokens. This is mostly a non-UI case. RFC 6030 uses Base64 for unencrypted tokens. Base32 is also in wide use. This is largely because, with fewer characters and no case-sensitivity, Base32 is easier to type. I don't know of any other encodings in wide use. It would be nice to support both of them, but I'm not sure how this is possible. Suggestions are welcome. I do not think we should allow typing the key (and other attributes) manually. We should rather ask user to import a token or tokens from the XML file that uses RFC6030. There are vendors of the hardware tokens that actually using it to distribute the tokens. Here are the examples http://www.gooze.eu/howto/oath-otp-tokens-howto/seed-codes-sample-files Please click around the site for more info. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- 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] [PATCH] 0138, 0141: ipa-kdb fixes
On 02/25/2014 07:59 PM, Simo Sorce wrote: On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote: Resending patch 0138 together with another case Simo found out today: when authdata flag is cleared by admin for the service principal, we'll get NULL client database entry. In such case we have to bail out. The patches look correct code-flow-wise to me. So tentative ack pending testing. Simo. Just checking - are we ok performance wise? If we for example add one additional LDAP search for every Kerberos authentication, it may increase the load on our LDAP server. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
