directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <enriqu...@gmail.com>
Subject Re: [Kerberos] Ticket structure
Date Mon, 29 Oct 2007 03:47:58 GMT
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.

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

Mime
View raw message