On 09/07/2013 06:28 PM, Simo Sorce wrote:
On Thu, 2013-09-05 at 00:38 -0400, Nathaniel McCallum wrote:
On Thu, 2013-09-05 at 00:25 -0400, Nathaniel McCallum wrote:
This patch has a few problems that I'd like some help with. There are a
few notes here as well.
1. The handling of the 'key'
Another question:
Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive
set of trusted CAs, or is using one set for everything good enough?
Using distinctive sets would allow granular control over what CA is
trusted for what service (e.g. trust CA1 to issue certificates for
On 09/07/2013 04:45 PM, Simo Sorce wrote:
Sorry to come late to this thread.
I think I like some of Petr plan, but not all of it.
On Fri, 2013-09-06 at 08:46 -0400, Rob Crittenden wrote:
[...]
I'm not sure I follow, what are you trying to achieve here? The more ACIs the
slower the
On 09/04/2013 03:28 PM, Ana Krivokapic wrote:
On 09/03/2013 01:15 PM, Petr Viktorin wrote:
On 09/02/2013 05:05 PM, Ana Krivokapic wrote:
Hello,
This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3797.
Thanks! I have a question.
-# retry several times -- logic
On 09/04/2013 04:13 PM, Ana Krivokapic wrote:
Hello,
This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3758.
Thanks, ACK, pushed to master: 66242e6ab0ab21eb39f3fbdaa586e8e38663faae
--
Petr³
___
Freeipa-devel mailing list
On 09/05/2013 06:04 AM, Nathaniel McCallum wrote:
patch attached
Thanks, some comments below.
Git complains about trailing whitespace in the patch, please strip it.
freeipa-npmccallum-0015-Add-support-for-managing-user-auth-types.patch
From 757436ccc431d26a3e62de830dad0b107a6c48ff Mon
On Mon, 2013-09-09 at 11:17 +0200, Jan Cholasta wrote:
Another question:
Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive
set of trusted CAs, or is using one set for everything good enough?
Using distinctive sets would allow granular control over what CA is
trusted
On Mon, 2013-09-09 at 13:00 +0200, Petr Viktorin wrote:
On 09/07/2013 04:45 PM, Simo Sorce wrote:
Sorry to come late to this thread.
I think I like some of Petr plan, but not all of it.
On Fri, 2013-09-06 at 08:46 -0400, Rob Crittenden wrote:
[...]
I'm not sure I follow, what are you
On 09/09/2013 10:02 AM, Nalin Dahyabhai wrote:
On Mon, Sep 09, 2013 at 11:17:02AM +0200, Jan Cholasta wrote:
Should each IPA service (LDAP, HTTP, PKINIT) have its own
distinctive set of trusted CAs, or is using one set for everything
good enough? Using distinctive sets would allow granular
On 9.9.2013 15:36, Simo Sorce wrote:
On Mon, 2013-09-09 at 11:17 +0200, Jan Cholasta wrote:
Another question:
Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive
set of trusted CAs, or is using one set for everything good enough?
Using distinctive sets would allow granular
On 9.9.2013 16:05, John Dennis wrote:
On 09/09/2013 10:02 AM, Nalin Dahyabhai wrote:
On Mon, Sep 09, 2013 at 11:17:02AM +0200, Jan Cholasta wrote:
Should each IPA service (LDAP, HTTP, PKINIT) have its own
distinctive set of trusted CAs, or is using one set for everything
good enough? Using
On Mon, Sep 09, 2013 at 10:05:59AM -0400, John Dennis wrote:
On 09/09/2013 10:02 AM, Nalin Dahyabhai wrote:
I'd expect it to depend heavily on whether or not you're chaining up to
an external CA. Personally, I'd very much want to keep a different set
of trust anchors for PKINIT in that
On 09/09/2013 10:24 AM, Nalin Dahyabhai wrote:
On Mon, Sep 09, 2013 at 10:05:59AM -0400, John Dennis wrote:
On 09/09/2013 10:02 AM, Nalin Dahyabhai wrote:
I'd expect it to depend heavily on whether or not you're chaining up to
an external CA. Personally, I'd very much want to keep a different
On 9.9.2013 16:02, John Dennis wrote:
On 09/09/2013 05:17 AM, Jan Cholasta wrote:
Another question:
Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive
set of trusted CAs, or is using one set for everything good enough?
Using distinctive sets would allow granular control over
Hi,
the attached patch fixes https://fedorahosted.org/freeipa/ticket/3915.
Honza
--
Jan Cholasta
From 2021327828cd4245a5a92fa9093f68d76e00e6b5 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Mon, 9 Sep 2013 08:15:11 +
Subject: [PATCH] Fix nsslapdPlugin object class
Petr Viktorin wrote:
On 09/09/2013 03:46 PM, Simo Sorce wrote:
On Mon, 2013-09-09 at 13:00 +0200, Petr Viktorin wrote:
On 09/07/2013 04:45 PM, Simo Sorce wrote:
Sorry to come late to this thread.
I think I like some of Petr plan, but not all of it.
[...]
It could get ugly real fast, and
Jan Cholasta wrote:
On 9.9.2013 16:02, John Dennis wrote:
On 09/09/2013 05:17 AM, Jan Cholasta wrote:
Another question:
Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive
set of trusted CAs, or is using one set for everything good enough?
Using distinctive sets would allow
On 09/09/2013 03:46 PM, Simo Sorce wrote:
On Mon, 2013-09-09 at 13:00 +0200, Petr Viktorin wrote:
On 09/07/2013 04:45 PM, Simo Sorce wrote:
Sorry to come late to this thread.
I think I like some of Petr plan, but not all of it.
[...]
It could get ugly real fast, and potentially cause a lot
Hello,
Thank you very much for your time and attention.
I changed client side code (kinit.c) but it requires to change all clients.
Now, I decided to change server side code.
I thought it may be better choice. Should I change policy.c file to change
ticket policies? It does not require
On 09/09/2013 04:44 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
[...]
There needs to be some mechanism for us for force-replace existing ACIs
in the case of a security issue.
Under my proposal, we can just remove the offending attribute from the
default list, and trust that the admin
On 09/06/2013 02:58 PM, Ana Krivokapic wrote:
Hello,
This patch fixes the regression introduced by the original fix for ticket #3867.
https://fedorahosted.org/freeipa/ticket/3867
Thank, ACK, pushed to:
master: a70b08e9aea891555ebee512de196748a835acb8
ipa-3-3:
On 09/09/2013 05:17 AM, Jan Cholasta wrote:
Another question:
Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive
set of trusted CAs, or is using one set for everything good enough?
Using distinctive sets would allow granular control over what CA is
trusted for what
On 09/09/2013 10:55 AM, Mahmoud wrote:
Hello,
Thank you very much for your time and attention.
I changed client side code (kinit.c) but it requires to change all
clients. Now, I decided to change server side code.
It seems that you should try to contribute code upstream if you want to
end
On Mon, 2013-09-09 at 16:19 +0200, Jan Cholasta wrote:
On 9.9.2013 15:36, Simo Sorce wrote:
On Mon, 2013-09-09 at 11:17 +0200, Jan Cholasta wrote:
Another question:
Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive
set of trusted CAs, or is using one set for
Hello Mr. Dmitri Pal
Thank you very much for your help.
I tried to change source code to have more option. It was difficult for me
to understand FreeIPA source code. Hence, I decided to change Kerberos
source code. I want to add more features to Kerberos. For example, I like
to have two (or
On Mon, 2013-09-09 at 16:40 +0200, Petr Viktorin wrote:
On 09/09/2013 03:46 PM, Simo Sorce wrote:
On Mon, 2013-09-09 at 13:00 +0200, Petr Viktorin wrote:
On 09/07/2013 04:45 PM, Simo Sorce wrote:
Sorry to come late to this thread.
I think I like some of Petr plan, but not all of it.
On Mon, Sep 09, 2013 at 10:32:08AM -0400, John Dennis wrote:
Good point. Isn't there an X509 extension (possibly part of PKIX?) which
restricts membership in the chain path to a criteria. In other words you
can require your sub-CA to be present in the chain. Sorry, but my memory
is a bit fuzzy
On Mon, 2013-09-09 at 10:40 -0400, Rob Crittenden wrote:
Jan Cholasta wrote:
On 9.9.2013 16:02, John Dennis wrote:
On 09/09/2013 05:17 AM, Jan Cholasta wrote:
Another question:
Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive
set of trusted CAs, or is using one
Aren't the implementations of name constrains generally buggy, and therefore
not usable in real life?
On Sep 9, 2013, at 9:02 AM, Nalin Dahyabhai na...@redhat.com wrote:
On Mon, Sep 09, 2013 at 10:32:08AM -0400, John Dennis wrote:
Good point. Isn't there an X509 extension (possibly part of
I would strongly argue for a separate CA list for PKINIT (service or
workstation login) vice HTTP (web browsing of semi-unknown sites). The trust
models are fundamentally different.
In the former case you are saying who is allowed to issue (conceivably
fraudulent) client certs that allow
On Mon, Sep 09, 2013 at 01:07:09PM -0700, Henry B. Hotz wrote:
On Sep 9, 2013, at 9:02 AM, Nalin Dahyabhai na...@redhat.com wrote:
On Mon, Sep 09, 2013 at 10:32:08AM -0400, John Dennis wrote:
Good point. Isn't there an X509 extension (possibly part of PKIX?) which
restricts membership in
On 09/09/2013 12:49 PM, Mahmoud wrote:
Hello Mr. Dmitri Pal
Thank you very much for your help.
I tried to change source code to have more option. It was difficult
for me to understand FreeIPA source code. Hence, I decided to change
Kerberos source code. I want to add more features to
The Dogtag team is proud to announce the fifth errata build for
Dogtag 10.0.
Builds are available for Fedora 18 and Fedora 19 in the updates-testing
repositories. Please try them out and provide karma to move them to the
F18 and F19 stable repositories. Karma can be provided at
Hello,
Thank you for your response.
When a user get tgt ticket, he can get service tickets without typing
password. I like to have several level of users. As high level users have
more access to resources, I want to grant a ticket with less validation
time. In other word, I want to have several
34 matches
Mail list logo
