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

Re: The role of trust in certification



On Thu, 12 Feb 1998, Tony Bartoletti wrote:

-> At 09:54 PM 2/12/98 -0200, you wrote:
-> 
-> >Suppose Skywalker would acquire somewhere a list of TTPs so that Skywalker
-> >would input it to his server and then be ready for e-commerce transactions
-> >with Alice -- and Alice would do the same for her browser.
-> 
-> This is a decent starting point, for purposes of refinement.  The crucial
-> point needing refinement being "acquire somewhere a list of TTPs":
-> 
-> 1) acquire why?  Why was this particular source for TTP's selected?
-> Read about them in a magazine?  Saw them on TV?  Recommended by your analyst?

Not specified, on purpose. Very good.

-> 
-> 2) acquire how?  email? ssh with previously trusted keys?
-> certified-snailmail? bonded courier?
-> 

ditto. Perfect.

-> 3) acquire for?  How to judge suitability to purpose?
-> 

ditto. Excellent.

-> Help refine these points (several options here) and then we have something
-> less academic to chew upon.
-> 

Tony:

;-)

The example wass intended to be used as stated and the lack of the
definitions you correctly asked for was also entirely intentional.

Why? Because if you go through your questions, you see that you need to
know whether the TTPs/CAs will certify as *you* need it, **before** you
can trust them. For example, you wrote as a requirement "to chew upon"
that you needed to know: 

 "How to judge suitability to purpose?"

Which means, that indeed "certificates are trusted because they certify".
First, suitability to purpose, etc., then trust.
 
Now, such statement is not a play on words and I would like to re-quote
some implications, but slightly modified to improve readability: 

 The logical expression "certificates are trustful because they certify"
 has a far reaching consequence: that trust on the certificate will be
 transfered to the user not from the certificate itself but from the 
 user's perceived assurance that the certificate will work as desired
 -- i.e., that it will certify according to the user's needs.

 Therefore, one may say that a certificate is like a tool, that is trusted
 because it is expected that it will work and not that it will work
 because it is trusted. On the other hand, trust is a result of the user's
 perceived assurance on a set of declarations. The role of trust in
 certification is thus to be earned, not merely assigned. 

Thus, the first provided example already hopefully showed (in a didactical
way) that indeed "trust is in the eyes of the beholder", from which
everything else is a direct conclusion. 

One may note the similarity between this concept and Carl's insistence on
local trust use in SPKI. 

However, without any desire to start a controversy here, the difference
(as we are talking about) with the current specs of SPKI is that trust is
only assigned after the user "judges suitability to purpose" (to quote
you) in its own reference frame and not that the cert will be accepted
initially because the issuer is trusted to issue certs on matters of X on
his reference frame. So, again, thrust is earned and not simply assigned. 

A further difference is that global certs/names are not precluded because
you can plug-in the Trust algebra described in
http://www.mcg.org.br/trustdef.txt and allow soft-Trust to bridge the gaps
between the local domains of trust. 

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: