directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject Re: Incompatible HostAddressType with RFCs
Date Mon, 02 Jul 2007 09:05:13 GMT
On 6/26/07, Emmanuel Lecharny <> wrote:
> Oh, ok.
> I was also thinking about switching from Class to Enum for those types.

I like the way the current Class enumerators allow for a descriptive
toString(), which is useful during logging.  I didn't think you could
replicate that with enums.

> FYI, I have started to write some encoders for simple Kerberos
> constructs (like PrincipalName, EncryptionKey,etc) and it works pretty
> well. The idea is to extend the existing classes by adding a couple of
> methods, so that you ask them to 'encode' themselves :

OK, so it sounds like the message class and its codecs are combined,
similar to how JAAS KerberosTicket works.

Sounds good, especially the speed boost.  FYI, the most important
class, which directs the heavy lifting, is CipherTextHandler.
CipherTextHandler contains the static hashed adapters that actually
make use of the Encoder/Decoder interfaces, so this is where
compatibility with the new codecs is key.  This is for the "one-shot"
codec use.

>                 PrincipalName principal = new PrincipalName(
> PrincipalNameType.KRB_NT_PRINCIPAL, "Test" );
>                 ByteBuffer encoded = ByteBuffer.allocate( principal.computeLength() );
>                 principal.encode( encoded );

Is this for the "one-shot" use or also how the codecs are used in the
codec filters?  I ask because all of the JCE crypto works with byte[]
so anytime one of the current Encoder-using Kerberos objects is
"one-shot" encoded it is immediately encrypted using the byte[] form.
If this is a no cost operation than it is OK but I thought you should
be aware.  It may be slightly nicer for the API to use a byte[].


View raw message