On 10/26/07, Emmanuel Lecharny <[EMAIL PROTECTED]> 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.
>
> 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." 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.
Enrique
