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

Re: definition of cert - trust in SPKI certs

On Thu, 22 May 1997, Brian M. Thomas wrote:

-> > 
-> > 1 Many certs in SPKI will be signed by the subject. In X.509,
-> > "to certify" means your key is signed by some one else; and
-> > "to sign" means you sign something yourself.
-> > So all signed messages are certficates in SPKI?
-> To answer your question directly, no.  In SPKI parlance, a certificate
-> is a specific instrument by which:
->   one party (the issuer, identified by a key)
->   asserts
->     the binding of another key (the subject)
->     to one or more attributes (the "auth" field)
->     under certain circumstances (the validation field).
->   by signing a message to that effect.
-> The import of this is that anyone who trusts the issuer's key as
-> authoritative trusts the statement that is made by the certificate,
-> if the signature checks by that key.  

However, trust is not transitive. 

This means that you could trust 100% the issuer's key as authoritative to
do the binding of another key (the subject) to an auth field under the
validation hypothesis and, yet, you do not trust that other key (ie, the
subject) in relationship to those attributes in the auth field. 

In other words, the fact that you trust Jon as the Bank President does not
mean that you must trust Mary as your account manager -- as she was just
appointed by him! So, you cannot accept Jon's certificate -- even though
it is a valid certificate by SPKI's rules. 

Another point is that Mary may not have agreed with Jon's appointment and
the verifier has no way of knowing this because the certificate is signed
by Jon only. 

However, if Mary also co-signs the certificate that still proves nothing
because the verifier has no way of knowing that Mary *is* Mary -- say, by
independent channels of information and must only trust Jon, again.

-> How the trust in that issuer's
-> key is established is outside the scope of this one certificate.

This is an interesting question, because as the certificate does not say
that -- how and to what effect trust was established -- it is difficult
for the verifier to "remember" exactly how it was that such trust was
established and what are its limits, both in time as well as in scope.

-> > 2 X.509 talk about a CA hierarchy, in SDSI, there are some
-> > CA roots. Does SPKI also defines a way to put trust in the
-> > certficates?
-> > This looks to me the biggest problems of PKI's: how to let
-> > people trust a cert... 
-> To my mind, there are only two ways (from within a program) to
-> establish the trust I described above:
->  + directly, by proof that the trusted key is my own;
->  + or indirectly, by a certificate signed by a key that I trust
->    (how? see above).

This is valid in a hierarchical chain, in which trust is "borrowed" from a
higher step to "validate" inferences in a lower level. But, to a large
extent such "validation" is actually a "leap-of-faith" (see above) because
trust is not transitive.

-> Ultimately, therefore, the only truly trusted root is the verifier's
-> own key, and the owner of it must use it to certify any other key that
-> is to be trusted, be it called a "root" by someone else or not.  This
-> allows for the multiple paths you speak of, as does SDSI.

Of course, a verifier's own key could not be used to certify any other key
that is to be trusted by other people, because the verifier could be
unknown to other parties that wish to trust that other key. 

If, on the other hand, you mean that the verifier "marks" the keys he
has developed trust for by signing them, this still does not explain how
he did establish such trust in the first place -- which is the question.

If you change the words in "owner of it must use it to certify any other
key"  such that one would read "owner of it must use it to sign any
other key" then we would be in close agreement but, again, that does not
answer the question.

-> > X.509 alone may not be enough for this, they need the help 
-> > of laws and regulations about CA's. 
-> X.509 alone isn't enough; neither is SPKI, SDSI, or any other
-> purely technical solution, if the problem is appropriateness of
-> trust, which is a social and legal question.  If the question
-> is practical assurance of compliance with stated trust policies,
-> they all provide, with varying degrees of difficulty, effective
-> mechanisms.

Focusing the question of practical assurance, how well do you think these
mechanisms deal with spoofing, collusion, denial-of-service or
man-in-the-middle attacks? Seems to me they do not provide effective
solutions against such attacks. 

-> > MC (Meta Certificates, http://novaware.cps.softex.br/mcg.htm)
-> > solves the problem by giving the users multiple authentication
-> > channels and letting him be responsable for trusting a public 
-> > key.
-> > How will SPKI do this? Other ways, the same ones, a mix, ...?
-> Regardless of the choice of mechanism, the user (verifier) is *always*
-> responsible for his choice to trust a public key, and the SPKI proposal
-> not only allows but seeks to enforce this, because the basic discipline
-> is: find a certification path from the verifier's own key to the
-> requestor's, granting the requested privilege.

The question is not only letting the verifier be responsible for his
choices (which he isn't allowed to influence much in X.509 -- for example
the verifier cannot choose a CA that he trusts, cannot choose a CA that
depends on a CA that he trusts, etc.) but to give the verifier tools that
he trusts in order to obtain results he could trust. 

One such tool, missing in X.509 and SPKI, is the use of multiple
simultaneous different channels of information (which is not the same as
having different certification paths to the same information).

Other tools are automatic previous checking of revocation lists, automatic
previous checks of outdated and invalid signatures in higher layers of the
hierarchy (which would compromise all signatures that were vouched by that
signature), automatic checks of untrusted CAs in relationship to the
verifier, etc. 

One could also add that paths from the verifier's own key to the
requestor's might include "unfriendly" paths -- which could be found
first, unfortunately.

Thank you.


Ed Gerck
Dr.rer.nat. E. Gerck                        egerck@laser.cps.softex.br
P.O.Box 1201, CEP13001-970, Campinas-SP, Brazil  - Fax: +55-19-2429533  

Follow-Ups: References: