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...
