Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of ayyagarikiran@gmail.com
 designates 209.85.212.50 as permitted sender)
MIME-Version: 1.0
Sender: ayyagarikiran@gmail.com
In-Reply-To: <50864C7F.80609@gmail.com>
References: 
 <CABzFU-enZiw-xN+JkHTh7oASF6btYDp115nxZrDWaKNc9kYFrw@mail.gmail.com>
	<50864C7F.80609@gmail.com>
Date: Tue, 23 Oct 2012 14:32:17 +0530
Message-ID: 
 <CABzFU-cb7Q8V32Yrzer9veL=2J9ZPmp3_q1V5xHEmwgdkYvnPg@mail.gmail.com>
Subject: Re: [ApacheDS] adding a global trust manager
From: Kiran Ayyagari <kayyagari@apache.org>
To: Apache Directory Developers List <dev@directory.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 23, 2012 at 1:21 PM, Emmanuel L=E9charny <elecharny@gmail.com> =
wrote:
> Le 10/23/12 8:09 AM, Kiran Ayyagari a =E9crit :
>
>> Hi All,
>>
>>      I am currently implementing an X509 trust manager that is used for
>> checking client certificates while using TLS for replication.
>>
>>      This trust manager can work in any one of the two modes
>>              1. trust all (default mode)
>>              2. trust only the specified certificates
>>
>>      In the 2 mode trust manager loads a set of certificates stored in
>> DiT under ou=3Dcertificates,ou=3Dsystem (a new branch) [1]
>
>
> Will it be a separate partition ?
>
no, this is just a branch under ou=3Dsystem partition
>
>>      and checks against this list. The certificate that is not present
>> in this list but is signed by a known CA will be trusted
>> automatically.
>>
>>     The initial idea is to use this trust manager only for replication
>> connections, but I would like to know your thoughts about using it
>>      in StartTLS and LDAPS connections by default?
>
> Well, usually, we fetch the certificate from the user entry, so we only h=
ave
> one place to store every piece of information relative to a user. Typical=
ly,
> there is no specific reason to not store the public key certificate of a
> user somewhere else than in the user's entry.
>
yeah, a common area where all trusted certificates are stored is much easie=
r to
handle (assuming the case where not all user entries contain
certificates unless in a PKI like env.)
> Now, we can certainly imagine a situation where you want to gather may
> certificates in a simple place.
>
> Keep in mind we can also add an index on certificate (although we will ha=
ve
> to write a specific matching rule to the associated comparator in order t=
o
> avoid doing a plain byte[] comparison of certificates. I'm sorry, but her=
e I
> have not enough knowledge to foresee all the consequences of such a
> modification, I hav to do my homework :)
>
> Anyway, this is certainly an area we have to investigate !
>
currently searching is not the main concern here, but I agree with your poi=
nt
>>
>> [1] am thinking of replacing the unused
>> prefNodeName=3DsysPrefRoot,ou=3Dsystem branch with
>> ou=3Dcertificates,ou=3Dsystem, please raise any
>>       objections you may have w.r.t this change.
>
> Well, I'd rather keep this branch, and create a new one atm. We can delet=
e
> the prefNodeName later if needed.
>
> Btw, will it impct the configuration ?
>
no, this is branch is not in use anywhere except in some tests while
comparing the DNs of search results
>
> --
> Regards,
> Cordialement,
> Emmanuel L=E9charny
> www.iktek.com
>


--=20
Kiran Ayyagari
http://keydap.com