[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary Trust x Delegation
On Thu, May 29, 1997 at 05:27:08PM -0500, Ron Rivest wrote:
>
> (I apologize for coming in late on this thread...)
>
> If Alice issues Bob a certificate, then Bob can delegate his received
> authority to Dorothy by issuing a second certificate. For this
> second certificate to be effective, the first certificate must have
> allowed this "propagation".
>
> If the first certificate prohibits propagation, then the only way that
> Bob can further "delegate" his authority is to give away copies of
> -his- -private- -key-.
>
> It doesn't work for him merely to give away copies of the first certificate
> that he received. Possession of the certificate does not imply authorization.
Yes, of course. That's why I said "he may compromise himself".
However, given the uses considered for SPKI certs, giving away the
private key may not be such a big deal. The private key may very
well not be all that significant to an individual. For example, the
cert could provide access to some database. I as an employee may
have a private key that identifies my role in a company. I am away
from the office, but I need some information. I call a co-worker,
and give them the pass-phrase over the phone.
> Possession of the secret key corresponding to the public key in the subject
> field of the certificate implies authorization. (Assuming appropriate
> time-of-day etc...)
>
> Users need to be motivated not to give away their secret keys, or
> restricted not so as not to be able to do so. If the public key
> serves multiple authorization functions, that may be sufficient to
> deter disclosure. Tamper-proof hardware can keep most users from
> giving away their keys.
My retina is pretty tamper-proof, and I can't give it away, but I
could still open a safe keyed to my retina and show someone else the
contents. You couldn't count on that lock to only allow me access to
the contents. Bill is saying, I believe, that the "do not delegate"
bit is false advertising, equivalent to selling the retina locked safe
using claims that only the people you give access to it can view the
contents.
> Or, in some applications, one might only
> certify "bonded" keys. (I use the key to sign a statement saying that
> anyone (or at least the first one) in possession of the corresponding
> secret key can claim $1000 from my checking account.)
Sure, that's all correct. But Bill is correct, also. The "don't
delegate" bit sounds impressive, but in fact it depends completely on
the trustworthiness of the person (or program) that currently
controls the cert. It's true (as Tony mentioned in another post)
that Bob could be perhaps be sued for allowing someone to use his
key, but that's only if the transgression is caught.
--
Kent Crispin "No reason to get excited",
kent@songbird.com the thief he kindly spoke...
PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html
References: