[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary Trust x Delegation
Kent Crispin wrote:
>On Thu, May 29, 1997 at 02:11:16PM -0500, Ron Rivest wrote:
>>
>> I disagree with the statement made by Bill Frantz that
>> "I have no technical way to prevent effective delegation, so..."
>>
>> If Alice gives Bob a certificate (say with tag "foo"), then of course there
>> is no way for Alice to prevent Bob from issuing a certificate with tag
>> "foo" to Dorothy.
>>
>> But this certificate issued by Bob is not _effective_ if Alice's certificate
>> has a "don't propagate" bit turned on. (Let us assume for simplicity here
>> that this is the simplest form of propagation control, not "stop at key".)
>>
>> By turning on the "don't propagate" bit, Alice is insisting that her
>> certificate must be the *last* certificate in any valid certificate chain
>> containing that certificate. Thus any certificates that Bob issues can
>> not be effectively utilized in a valid certificate chain. Thus Bob's
>> certificates are ineffective--the certificate he issues to Dorothy will
>> not be usable to sub-delegate any "foo" rights that Alice gave to Bob.
>>
>> Alice need only trust the verifier to honor the correct notion of what
>> a valid certificate chain is; she does not need to trust Bob not to
>> issue further certificates.
>
>Bob doesn't issue a new cert for anyone -- he gives away his cert. In
>such a case it makes absolutely no difference whether Alice has turned
>on the "don't propagate" bit. It's true that Bob may compromise
>himself by doing this, but that doesn't do Alice any good. If she was
>counting on the "don't propagate" bit preventing Dorothy from
>accessing her secrets she will be seriously disappointed. This is
>Bill's point about the "don't propagate" bit being an illusion. You
>were sucked in by that illusion. It's usability is a function of the
>trustworthiness of Bob, not any cryptographic or semantic strength.
>
>For this reason I agree with Bill that the semantics are somewhat
>deceptive. I think a better name for the bit is the "permission to
>create new cert" bit -- this name is less likely than "propagate" or
>"delegate" to create the confusion that Bill identifies.
>
>--
>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
I believe this misses the point that Ron Rivest is making.
In order for Bob to subvert Alice's "no-delegate" instruction, he *must*
either compromise himself, by sharing his secret key with Alice, or he may
simply do Alice's bidding with his own hands. There is no before-the-fact
protection from such betrayal. But in either case, the digital "paper trail"
leads to Bob, who is to held liable for some breach of trust. It is this
linkage, for the purposes of accountibility, that is to be maintained on the
strength of the digital certification.
___TONY___