[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Summary Trust x Delegation
(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.
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. 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.)
Cheers,
Ron
Follow-Ups: