[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re[2]: Comments on SPKI draft of 25 March 1997


>>>>> "John" == John Reinke <John_Reinke@pcmailgw.ml.com> writes:
    John> The one I am most familiar with was I was X the VP.  I hired
    John> Y and did the grant. Y then hired his staff of Zs doing the
    John> appropriate grants.  Y got laid off.  I revoked Y.

  I figured this was the case.

    John> collapsed in a cascade of revokes.  When the dust settled,
    John> we created generic ids in the middle.  Security was poorer;
    John> but one revoke did not tumble the house of cards.

  In the certificate case, this means that we are passing a private
key from one individual to another. 
  I think that either Y should have had a protocol to "introduce" Z's
to X, or straight delegation shouldn't have been used. The combination
of a certificate from Y, plus a timestamp from a trusted timestamping
service should have been used. One could then issue a certificate with
a limited time, and allow Y to delegate for a limited time. 

  The *authorization* that Y is delegating would have a seperate
expiry time. So, when Y get's revoked, only *new* statements from Y
become invalid. Z's certificate is still valid.

  The only issue is that when X delegated to Y, they have to be aware
of the problem of what happens if Y delegates.

   :!mcr!:            |  Network security consulting and 
   Michael Richardson |      contract programming
 WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.

Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface