[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: Comments on SPKI draft of 25 March 1997
- To: firstname.lastname@example.org
- Subject: Re: Re: Comments on SPKI draft of 25 March 1997
- From: Michael Richardson <email@example.com>
- Date: Mon, 31 Mar 1997 17:08:17 -0500
- In-Reply-To: Your message of "Mon, 31 Mar 1997 15:32:43 EST." <00003DC3.@pcmailgw.ml.com>
- Sender: firstname.lastname@example.org
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "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">email@example.com</A>. PGP key available.
-----BEGIN PGP SIGNATURE-----
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
-----END PGP SIGNATURE-----