[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: definition of cert - trust in SPKI certs
> 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.
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. 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.
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.
> However, trust is not transitive.
Of course not. 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.
> 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.
> 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.
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)
--------------------------
* Don'tcha just love that word "infuses". Thanks to Joe Sugarman for
all those JSA catalogs!
Follow-Ups: