directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject Re: [Kerberos] Ticket structure
Date Mon, 29 Oct 2007 03:47:58 GMT
On 10/26/07, Emmanuel Lecharny <> 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.


View raw message