Update to the design of the Master Key Migration project

Will Fiveash William.Fiveash at Sun.COM
Thu Sep 25 17:23:13 EDT 2008


On Wed, Sep 24, 2008 at 06:56:50PM -0400, Jeffrey Hutzelman wrote:
> --On Wednesday, September 24, 2008 04:15:14 PM -0500 Nicolas Williams 
> <Nicolas.Williams at sun.com> wrote:
> 
> > On Wed, Sep 24, 2008 at 03:43:33PM -0500, Will Fiveash wrote:
> 
> >> I thought about this some more and have a modification to the definition
> >> of the data stored in KRB5_TL_CURKVNO.  It should be an array holding a
> >> variable number of these structs:
> >
> > I like that -- it could be used for any principal, not just K/M or
> > krbtgt/<realm>@<realm>.
> >
> >> struct krb5_curkvno  {
> >>     krb5_kvno curkvno;
> >>     krb5_timestamp start_time;
> >> }
> >
> > Why not also end_time, with 0 -> never?
> 
> You don't need one.  The usage period for each entry is bounded by the 
> start time of the next later entry, and by the principal and key expiration 
> times in the KDB entry.  I see no need for an additional place to store 
> this data.

Right, that is what I was thinking when I came up with the above.

> BTW, I really hope no one is proposing defining the terms of database 
> structures in terms of a C struct.

Sorry, I was thinking in terms of implementation.  Let me rephrase;
KRB5_TL_CURKVNO will be a set of {curkvno, start_time} tuples where
curkvno is the currently active KVNO and start_time indicates when
curkvno is valid for use.

-- 
Will Fiveash
Sun Microsystems Inc.
http://opensolaris.org/os/project/kerberos/



More information about the krbdev mailing list