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

Re: The role of trust in certification

On Thu, 12 Feb 1998, Uri Blumenthal wrote:

-> Ed Gerck says:
-> > Suppose we would paraphrase Augustine of Hippo (Ts. 132) and would
-> > discuss: "whether certificates are trustful because they certify, or
-> > certify because they are trustful.". Then, like him, we might give the
-> > "doubtless reply" that they certify because they are trustful. 
-> 
-> (:-)
-> 
-> > Thus, for certificates, "trust is relative to the user" and "certificates
-> > are trustful because they certify" -- not the other way around. 
-> 
-> Respectfully disagree. Since I chose to "trust" the given CA, certificates
-> issued by it are "trustful" and thus "certify" - "not the other way around".

It's not bad to agree with Augustine ;-) 

However, the logic is (following your words) that if you chose to "trust" 
the given CA this "trust" is surely not like a blank check -- you chose to
"trust" it for a purpose which wass to provide certificates that certify
(correctly). Thus, the inexcapable conclusion is that you decided those
certificates would be trustful because they certify andyou did that
*before* you accepted them. 

This is not a play in words. Suppose you are looking for a hammer to
hammer in 3 inch nails, so that you can trust it. Do you decide to call
your hammer trustful because it hammers 3"s or do you decide to use it to
hammer 3"s because it is trustful?

I'll quote below a reply I received, which sheds further light on this:

<quote>

 I believe that one of the big reasons why the Computer Crypto
 Community has long been going down the wrong (certify because they are
 trustful) path is because the early players were dominated by Military
 Intelligence players, and CIA/KGB minded folk.

 And, I believe it is true [that in] their world they need to use "certify
 because they are trustful" logic.  In that world, a spy contracts to
 work for a spymaster who gives him codes and instructs him to trust
 the people the spymaster tells him to trust.  That is not the "other
 world" of business where trust is earned, not merely assigned.

 In the spy world, it is not possible to not trust your handler, as
 there is no one else to trust, or you must turn to your enemy and
 accept a new list of trusted parties, using the same trust model.

 it is my belief that this has long tainted the whole area of research
 and development of certificates, et al.       

</quote>

-> 
-> >  In any certification system, what makes a certificate trustworthy is not
-> >  any magically infused trust from the certificate's issuer (eg, the CA). 
-> >  Rather, a certificate is trustworthy as decided by the user (ie, the
-> >  party that relies on the information -- who is at risk), based on the
-> >  trust the user decides to place in the certificate's issuer and as a
-> >  function of perceived risks, costs, threats, situation, etc. 
-> 
-> If a user "doesn't trust" a given CA, there's no reason why certificates
-> issued by it would "certify" anything to him.
-> 

A CA can't be trusted because it tells you it should be trusted. The
situation starts like an empty statement, when you must receive
out-of-band information that can allow *you* to assign a trust level to it
-- which is assigned as a function of the job it purports to do (certify)
and to the exact extent of such job (eg, CPS).  So, at the end of this
acquisition process (cf my mail last December) you decide to trust (or
not) certs issued by that CA because they certify (correctly) to the
extent needed by you. No?

-> On the other hand, if a user "trusts" this CA, I can't see how this user
-> would do other than accept that any certificate from this CA "certifies"
-> and it "trustful".
-> 

yes, but such a trust was then a prior act, when the user decided to
trust the CA because it issues certs that the user considered acceptable.
So, trust must be earned and cannot be assigned.

-> 
-> A question might be - what exactly do the certificates "certify"? 
-> Identities? If so - how much of it? Is it "Joe Shmoe"? Or "Joe
-> Shmoe who lives at ..."? Or "Joe Shmoe who lives at..., works
-> at ... and has been paying his loans well till now"?
-> 
-> Because I may well "trust" that the person behind that certified key
-> indeed is Joe Shmoe - but unless I already have a policy installed
-> that tells me precisely what Joe Shmoe is allowed to do (or to
-> receive from me), just "knowing" the identity gives me little.
-> I need more [certified] information...
-> 

Yes, this is the point. To think that a cert is like a passport or ID is a
bad analogy and has tainted cert discussion for too long also. A cert has
purpose, a cert is a tool (even if this tool only says that you are Bob
Smith and that you use public-key K -- because the job is to associate K
with Bob Smith). 

When you buy a tool, you buy it because it can do the job, not because it
has a nice photo of the tool doing the job.  So, you have trusted the tool
to do the job *before* you bought it.  Otherwise, you would buy a tool
because you saw the photo.. 

-> 
-> Now, what were we talking about? (:-)

The much over-used words: paradigm shift ;-)

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 ---
Follow-Ups: References: