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

Re: definition of cert - trust in SPKI certs

> 
> 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.  How the trust in that issuer's
key is established is outside the scope of this one certificate.


> 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).
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.

> 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.

> 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.

I will read the MC proposal more thoroughly, but caution, as have
others here and in the PKIX discussions, that PKIs are strictly
mechanisms of assurance over limited fact domains, and the best ones
will offer the simplest and least ambiguous means of assuring that our
wishes are carried out in cyberspace.  The appropriateness of those
wishes, and enforcement of promises upon which we depend thereby, are
still in the domains of society and law to which we are subject.

>  Thanks, greetings, Stef

And to you.

brian


Brian Thomas, CISSP - Distributed Systems Architect  bt0008@entropy.sbc.com
Southwestern Bell                                    bthomas@primary.net
One Bell Center,  Room 34G3                          Tel: 314 235 3141
St. Louis, MO 63101                                  Fax: 314 235 0162
Follow-Ups: