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 elecharny@gmail.com
 designates 209.85.134.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=NidYySccoemDZJngupa3+zn+LNtmcbVrDdyolYue0YrH4JDWjjMQvnAphK+m2XdSeVezW3rGDaq+wzyOCUrO+KcFVIAkdVFKiFfGjm7LoTlp5rbA5eY9N3PmokrI1OthHaXucnkAA2+PRIEBCdzS6vJfGAZz467K7r4WFBDe4Fg=
Message-ID: <47259A9C.3060809@gmail.com>
Date: Mon, 29 Oct 2007 09:32:28 +0100
From: Emmanuel Lecharny <elecharny@gmail.com>
User-Agent: Thunderbird 1.5.0.14pre (X11/20071023)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [Kerberos] Ticket structure
References: <472247BB.4050805@gmail.com>
 <568753d90710282047l48072e2axece22f21060cf641@mail.gmail.com>
In-Reply-To: <568753d90710282047l48072e2axece22f21060cf641@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Enrique,

Enrique Rodriguez wrote:
> On 10/26/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>   
>> Hi,
>>
>> I'm currently reviewing the Ticket structure, and I'm wondering why we
>> do store the  encrypted data _and_ the encrypted ticket part,
>> considering that the first structure is a sealed version of the second
>> one ? I understand that it is an optimization as we will manipulate a
>> lot the data from the second structure, but why can't we simply extend
>> the Ticket class to add a new field (this encTicketpart) in the
>> inherited part?
>>     
>
> I think of the Ticket as existing in 2 states:  sealed and unsealed.
> Therefore, it makes sense to have one Ticket but have it handle the 2
> states better, such as returning an IllegalStateException instead of
> the current NPE if an attempt is made to access the EncTicketPart
> without decrypting it first.
>   
It makes sense. As we have to access this unsealed data everywhere in 
the code (I have discovered this while browsing the code), keeping both 
sealed and unsealed values within the Ticket structure is better.

Now, I'm wondering if it's a good thing to also provide the accessors to 
this unsealed value in the Ticket class. I would favor this kind of access :

ticket.getDecryptedTicket().getClientAddresses()

instead of :

ticket.getClientAddresses()

At first sight, it seems that the second form is lighter, but it has the 
big inconvenient to duplicate the accessors : you already have a 
getClientAddesses() method in the EncTicketpart class.

>   
>> Something like :
>>
>> Ticket
>> {
>>     int versionNumber;
>>     KerberosPrincipal serverPrincipal;
>>     EncryptedData encPart;
>> }
>>
>> and
>>
>> TicketWithTicketPart extends Ticket
>> {
>>     EncTicketpart encTicketPart;
>> }
>>
>> I don't know... wdyt ?
>>
>>     
>
> This might work.  I can see how the API would return the 2nd form
> after a decrypt.  Though, it might be better named as "Ticket" and
> "DecryptedTicket."  
Very true. Excuse my deficiencies in english :)

> With both the names your are suggesting here and
> the other renames you have made I believe you are coming at an
> understanding of Kerberos from the ASN.1 structures, when the
> higher-level (and less literal) naming will be better with the
> protocol workflow in mind.
>   
I like to have basic structure being as close as possible to the ASN.1 
names, because it helps people who read the RFCs to get a quick 
understanding of the code. But I also have some concerns when it comes 
to implement, say, 'sname'. Ticket.getSName() is really not the best 
method call I ever saw, compared to Ticket.getServerName().

I don't know. The idea is to discuss all those kind of questions in 
order to share the ideas and have the best solution, as a community.

If you tell me that getSName() is far from being perfect, I will just 
switch back to the previous name :) (anyway, I don't like this name 
either... )

Thanks !