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

Re: on the nature of trust

On Fri, 13 Feb 1998, Camillo Särs wrote:

-> I'm trying to cut in only the relevant parts here, I hope I don't cite
-> anything too much out of context.
-> 
-> Ed Gerck wrote:
-> > I think that I could generalize (for the sake of understanding) and 
-> > say that *all* certification procedures exist in order to transfer 
-> > information according to some security model. Agreed?
-> 
-> And to transfer information, we need to establish trust.  This trust must
-> be in a form that is independent of the channel used, and cannot contain
-> semantic information in regards to that particular channel. Else we would
-> not be transferring trust according to your definition below.

;-) This section of my msg was cut by you, but is in the same posting:

 I would just remark
 that IMO *all* certification procedures need to also transfer trust,
 however minimal

so we are in violent agreement here!


-> 
-> >  Trust: "Trust is that which is essential to a communication channel 
-> >          but which cannot be transferred from a source to a 
-> >          destination using that channel"
-> 
-> > This also means that the least the amount of Trust you need to 
-> > transfer, the more the other party can rely on your information.
-> 
-> The implications of this statement is what intrigues me.  If you
-> automatically transfer a large amount of trust, you run the risk of
-> tainting the information.  This seems to be something very similar to the
-> principle of "least privilege" in computer security.  I believe that the
-> similarity is no coincidence, it may in fact be that the principle of
-> "least privilege" is a direct result of this statement.
-> 

Yes. 

-> Now, wouldn't this imply that when you need to transfer authority (the
-> issue we are primarily concerned with), you must keep the amount of trust
-> transferred to a minimum to avoid tainting other transfers?  And that
-> transfer of unspecified authority á la X.509 essentially nullifies any
-> trust that can be placed on the certification, because the trust is common
-> to all channels?  Whereas transfer of trust in regards to a clearly
-> restricted authentication as in SPKI can be done more reliably?
-> 

How does one defines authorization here? Clearly, such definition must be
done coherently with the definition of Trust and Information. In the
theory, I define Authorization by studying a process that combines inputs
which include Information and Trust and produces an output called Action,
which has zero Trust. It is important to note that Action is Information
and has zero Trust, otherwise it would need at least one unspecified
additional channel in order to be transfered and used. 

In other words, after you calculate the Action, there is no more semantics
in it -- though you have semantic information before. So, Action can be
used syntatically and produce immediate results.

Actually, Authorization is defined as a verb, Authorize, and Action is a
noun -- which leads to a syntax ***loosely described*** here as 

| Action >  = < Trust | Authorize | Information >, where Action obeys
< Trust | Action > = 0

so, neither Trust nor Authorization have any loop problems (which
inexcapably introduces a dimensional problem). Trust then is able to
change the authorization vectors so that Information is transferred to
Action according to such changes, while eliminating any overly-variable
quantities which would introduce Trust into the Action.

-> And above all, how would one reliably model the separate transfers of trust
-> and authentication that occur in most current certification schemes?  Can a
-> single syntactic channel, such as an SPKI certificate, be considered as
-> consisting of separate semantic channels, one (or more) for trust and one
-> for information (the authorization itself)?
-> 

As above. Regarding channels, note that Trust *is* Information and so can
use any communication channel -- including the channel used to transfer
Information. However, it cannot only use THAT channel.

Cheers,

Ed

______________________________________________________________________
Dr.rer.nat. E. Gerck                     egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---
References: