directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: About Haox project
Date Sat, 27 Dec 2014 07:38:51 GMT
Le 27/12/14 02:36, Zheng, Kai a écrit :
>
>>> I wanted to build a ASN/1 compiler (see http://svn.apache.org/repos/asf/labs/dungeon/)
>>> Implementing a new Codec requires a huge effort, even for me.
> It's very interesting about the compiler. Actually it was in my mind to support such
compiler for haox-asn1 library, enabling to compile an ASN1 definition module (like krb5.asn1)
and automatically generate all the necessary Java types (like Kerberos codec classes), and
we don't even bother to code them manually.  Yes it's hard, huge effort is involved, not easy
for me either.

The major pb with this compiler is that we have to be able to process
teh full ASN.1 grammar, and it's quite complex. We also have to think
about the generator, and we don't have only one target : DER/CER/BER is
simple, XER is probably useless, but PER is mandatory and this is really
the complex one. All in all, this is not simple...

>
>>> I would rather first check what Bouncy Castle has to propose in this area. I'd
be really careful here, implementing some crypto amgorithm is seriously complex, and require
a lot of care.
> Sorry I'm confusing and have to be clear here. When I mentioned "implement all the encryption
types and checksum types that MIT Kerberos supports, like DES, DES3, AES, RC4, CAMELLIA",
I mean we need to implement the Kerberos encryption types and checksum types which are often
mentioned as Kerberos crypto. Such crypto isn't the one in JCE neither any in BC, where only
covers concrete encryption algorithms. Kerberos crypto is based on concrete encryption algorithms
and implementations, but would never bother to define and implement any encryption algorithms
itself.
>
> Yes we could rely on the Kerberos crypto implemented in JRE, as existing ApacheDS Kerberos
implementation does. The problems are: 1) JRE doesn't expose the functionalities fully and
is very limited; 2) It's not complete and we can't guarantee full interoperable with MIT Kerberos
and MS-AD; 3) Relying on JRE means we'll never be able to go beyond that, if the corresponding
support isn't available in JRE, then we'll stop there. You might agree that many modern Kerberos
features are just not available yet.
>
> In my view we have to tweak it for ourselves, that's why I spent so much time on it.
The framework originates the one from MIT Kerberos and is very flexible, say once a new encryption
type is up then it's easy to add it accordingly so we are updated! The support is complete
and all the ones provided in MIT Kerberos are done. I'm confident with it, basically I would
think it's the core part that's essential for a Kerberos implementation. Without it, maybe
it's fine for us to just replace the Kerberos codec part based on existing Kerberos implementation.
Yes we must be careful with the codes. I would be very happy for your review of it and make
it strong enough. 

Ok, seems like I have to do my homework in this area ;-)


>>> has also to be considered is the configuration part, and integration with Studio.
> Yes agree. Regarding Kerberos configuration either in client side (krb5.conf) or server
side (kdc.conf), I guess we'd better make it compatible with MIT Kerberos so that administrators
won't have to learn about it. Also in our documentation for simple we would just say "please
reference MIT Krb5 doc" as we're going the same way. A contributor is work on it and will
commit the codes once the codebase is imported.
That's not that simple. Of course, we should support MIT based
configuration, but you also have to consider those admin who have to
install a kerberos server and don't know about tjose files : they most
certainly expect the product we deliver to take care of the config
without having to deal with .conf files...




Mime
View raw message