directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: [Kerberos] Encryption types branch stabilized
Date Tue, 08 May 2007 09:22:13 GMT
Enrique,

just wondering, is all this code complies with US rules about 
cryptography ? I mean, there are some restriction on what could be 
exported out of USA, and we have to take care of those rules.

Can you check this point?

Thanks !!!

Enrique Rodriguez a écrit :

> On 5/6/07, Emmanuel Lecharny <elecharny@apache.org> wrote:
>
>> ...
>> hey, thanks for all this code ! We now have to check it before merging
>> it, and we will do it this week, so that we will be both ready at the
>> same time to merge the code into the trunk !
>> <snip/>
>
>
> One thing to watch for is that AES256 requires "unlimited strength"
> policy in the JRE.  I tried to make sure to handle its absence
> gracefully and to comment-out relevant unit tests.  But, I haven't
> tested it on any platforms except Linux or VM's except Sun.
>
> I think this branch (encryption types) should merge in before the SASL
> branch.  Once the new encryption types are in trunk, I'd like to
> revisit the SASL branch since there is some interop with SASL GSSAPI
> and Kerberos that I'd like to ensure is working.
>
>> > The interceptor works great whether the 'userPassword' is changed over
>> > the LDAP protocol, by the ChangePassword protocol, or by LDIF load.
>> > This is a testament to the interceptor service chain in the core.  The
>> > interceptor will make working with Kerberos principals much easier.
>>
>> Just great !
>>
>> I can't wait to see all that alive in trunks ! Ok, svn co
>> kerberos-branch running :)
>
>
> The more I think about it, the more I'd like to get a password policy
> interceptor in there.  Now that key derivation/generation is
> centralized, it makes even more sense to centralize password policy
> enforcement.  There is a basic password policy validator in the Change
> Password and I'd like to convert this to an interceptor.  I'm thinking
> I would model it after the AuthenticationService, w.r.t. how
> Authenticators are "pluggable."  I would commit a policy validator
> based on the one in Change Password and we'd have this extension point
> available for other custom policies.
>
> Also, I'm going to start in on "key export" now, re: Realm Control
> Initiatives [1].
>
> Enrique
>
> [1]  
> http://cwiki.apache.org/confluence/display/DIRxSBOX/Realm+Control+Initiatives 
>
>


Mime
View raw message