[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: definition of cert - trust in SPKI certs
On Fri, 23 May 1997, David P. Kemp wrote:
->
-> > From: "E. Gerck" <egerck@laser.cps.softex.br>
-> >
-> > -> 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.
->
->
-> Certificates of any form (x.509, sdsi, spki, pgp) have nothing to do with
-> "spoofing, collusion, denial-of-service, or mitm". You are comparing
-> apples and speedboats.
->
I disagree. First, the statement I was questioning was:
X.509, SDSI, SPKI, etc. provide, with varying degrees of difficulty,
effective mechanisms for "practical assurance of compliance with stated
trust policies".
What is meant by "practical assurance of compliance with stated trust
policies"? Means, IMHO, how the certificate specifications deal with
possible attacks in practical cases, such that it assures compliance with
stated trust policies. That is, the very architecture and specs of the
cert may flaw it at birth. Thus, if that is the case, it would not
"assure compliance".
A conceptional/conceptual problem. Some may be solved, some may not.
For example, PGP. Everyone knows that PGP's trust-bits are NOT signed and
thus can be easily changed without the owner knowing. This is an apple in
a speedboat, wouldn't you think ;-)? Could even stop the speedboat.
Another example for PGP. A spoofed "trusted introducer" that is found but
is not checked in all key-rings (a key-ring is not a loop, but a
mathematical set) -- because PGP does not have a coherent procedure for
deleting entries in all chained key-rings -- will make all such key-rings
unsafe. Another apple in a speedboat.
Take now X.509. Think about CRLs. Another apple stopping a speedboat.
-> The security service provided by the PKI (the mechanical implementation
-> of which includes certificates) is a binding of a public key
-> to a set of attributes (identity, authorizations, etc).
->
-> The certified public key is then used by some other mechanism /
-> communication protocol (ipsec, ssl, s/mime, pgp, ...) to provide protection
-> against the attacks listed. To the extent that the PKI has done it's job,
-> the protocols that depend on it can do theirs, but a perfect PKI provides
-> no protection against a poorly designed communication protocol.
->
-> >
-> > -> > 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.
->
-> The verifier in every certificate model (again: x.509, sdsi, spki, pgp, ...)
-> is fully and wholly responsible for choosing who to trust. This is
-> apparently a matter of great confusion, and Carl has done an admirable
-> job in preaching at every opportunity that trust always originates with
-> the verifier.
The last phrase is true but nonetheless X.509 disregards it. PGP also.
So your two phrases clash. Maybe that's why Carl had so much work ;-)
(No comments on sdsi/spki, because we dont't have a working sdsi/spki
implementation)
As a simple test, take now, please, your browser and see if you can choose
Thawte as your CA when you connect to a site that uses Verisign to certify
certs. Too bad if you don't want Verisign -- that's what you have -- and
the decision of trust is from the begining NOT in your hands. You can NOT
choose whom to trust.
There are many other such examples, just with X.509s. For example, do you
have the option (the right?) to check CRLs before your browser
automatically accepts a "hard-wired" cert?
One thing is *us* knowing it is true, another is it being allowed, still
another is for it to be actually implemented.
That's why I said "The question is not only letting the verifier be
responsible for his choices but to give the verifier tools that he
trusts", so these choices MUST become real choices, with trusted tools.
Of course, you can always hit the "off" button, but that's hardly a
choice, even though very trusted ;-)
-> Unfortunately, not everyone understands that simple
-> concept - I see many references to "self signed certificates" and
-> "root certificates" as if signing one's own cert or being the root of
-> a heirarchy magically infuses* a certificate with the property of being
-> trustable. But trust originates in the 3d world, based on whatever
-> criteria the verifier thinks are important. That trust is then
-> abstracted and mechanized using certificates.
->
Agreed 100%. I am also preaching that ;-). I just note that trust also
originates in the conceptual world (no 3D), such as the factorization of
large numbers being a difficult problem ( a soft-type of trust) or
trusting Fermat's Theorem to be true (a hard-type of trust).
I also believe (if I read correctly between your lines) that trust from
the Image-Space world (the effect-world, non 3D) does not go to trust in
Domain-Space world (3D, the cause-world of persons, corporations,
machines, etc.)
-> The various certificate formats differ in their ability to mechanize
-> the variety of trust flows that occur in the real world. The single
-> level model, as represented by the first version of spki, or the
-> "intranet" usage model of x.509, is trivial: authenticate the other
-> party using 20 questions, in-person visual recognition, second-channel
-> transmission of a PIN or passphrase, presentation of a driver's license
-> or company badge, or whatever other means you deem appropriate, and
-> then issue them a certificate yourself.
->
The point is also that even other types of certificates still operate in
the paradigm of data structures. Sometimes allowing for an algorithm (such
as logical inference). But the real change is to use objects, when you
allow for 3 quantities: data, methods and the respective binding (ie, not
any data with whatever method).
When you allow these objects to be remote, mobile and persistent, then you
are starting to use a model that can represent trust in various capacities
and uses, in a mathematical and secure way.
-> > However, trust is not transitive.
->
-> Of course not.
Thanks!
-> Things get a bit more complicated when you have multiple
-> levels of certificates. Different certificate formats address trust
-> delegation with different mechanisms, but all recognize the common sense
-> notion that trust decays with increasing path length. PGP uses a scalar
-> "level of trust" and the multiple-introducer model; sdsi/spki has a simple
-> scalar or binary "delegation" parameter and the notion of global (!!)
-> names, and x.509 provides fine-grained control through the use of basic
-> constraints, name constraints, policy constraints, etc.
->
Very well explained. The "entropy of trust" or "the notion that trust
decays with increasing path length" can be however a discontinuous
phenomenon, which may go from 100% to 0% in one step.
That is one of the reason why trust is not transitive. Without wishing to
provoke another deluge in this list, I would also say that
"trust is not transitive, not distributive and not associative"
That makes the spki/sdsi model need to introduce a "leap-of-faith" when it
postulates delegation as part of the model.
As I wrote before, that is not becessarily bad but it is sure an apple
among speedboats, as the current proposal stands.
One way to solve this, without mixing apples and speedboats, is to use
gauge-functions, as is done in the work on Meta-Certificates, and proper
semantic rules for left-, right-, sym-, or no-binding on trust
delegations, and other features.
->
-> > 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).
->
-> As noted above, this comparison does not make sense. Certificates are
-> data structures that provide a static binding of information. Communication
-> protocols provide communication channels. One can communicate certificates
-> over a channel (trusted or untrusted), and one can use certificates to
-> provide trust to a channel, but they are not the same thing.
->
This comparison makes sense in the same way as I explained above. You must
be a little more flexible here and view (for example) X.509 certificates
as degenerate (in the mathematical sense) objects that are just data
structures with flat methods. But not all certificates must have that
"birth-problem". A cert may be an object, with fully implemented methods
to it can speak, hear and see by itself: it can communicate, besides being
transported (be communicated).
Thus, you must distinguish between communicating a certificate (what you
said) from a certificate communicating. In the second case, a certificate
has built-in channels of communication -- for its own use as it was
programmed and signed at birth.
->
-> > 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.
->
-> Tools and applications are a third component, independent of certificates
-> and communication channels. An application implements CRL checking, etc
-> using it's path validation rules, and those rules are to some extent
-> independent of the certificate format. (More capable certificate
-> formats enable the use of more elaborate path validation procedures,
-> but the basic checks can be done with any cert format.) And again, one
-> *always* starts at the verifier.
->
Integration of said "components" and actually making them dependent on the
verifier is a way of achieving a higher security standard. You cannot
leave vital things like CRLs to be a type of "optional life-savers" or
"optional seat-belts". There must be a way for the verifier to request
them -- what, again, does not exist today as a simple browser trip might
show you.
->
-> The meta certificate discussion could be greatly improved by making a
-> clearer distinction between:
->
-> 1) data structures (certificates),
-> 2) communication channels and protocols, and
-> 3) applications (validation procedures and user interface)
->
The MC discussion starts from the point that these three quantities are
part of an object and, thus, are in tight binding:
"A Meta-Certificate (or MC) is a unit of data and code, cryptographically
signed, that allows entities, attributes, authorizations,
public-keys, methods, etc. to be distributed, redistributed and
certified. All MCs are subsets of characteristics (data, data
types, methods, policies, etc.) from a given standard."
The MC-FAQ is still a work-in-progress but can be seen at
http://novaware.cps.softex.br/mcfaq.htm
or at a mirror site
http://www.iks-jena.de/mitarb/lutz/certification/mc/mcfaq.htm
Yours,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@laser.cps.softex.br
http://novaware.cps.softex.br
P.O.Box 1201, CEP13001-970, Campinas-SP, Brazil - Fax: +55-19-2429533
References: