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

Out on a loop



On Tue, 9 Dec 1997, Carl Ellison wrote:

-> -----BEGIN PGP SIGNED MESSAGE-----
-> 
-> At 02:25 AM 12/9/97 -0200, Ed Gerck wrote:
-> >-> That closes the loop.  
-> >
-> >A loop can only be closed between like quantities. 
-> >
-> >Here, you are equating apples (trust relationships of the root-keys with
-> >each other and with the issuer) with speedboats (trust relationships of
-> >the root-keys with the verifier, by itself), so there is no "loop of
-> >trust".
-> 
-> [snip, dictionary]
-> To me, there are not apples and speedboats.  Rather, there is authorization 
-> which is injected by the verifier into a so-called root key and passed 
-> from that root key through certificates, possibly constrained or restricted, 
-> into the eventual request where it is delivered to the verifier as part of a 
-> request for some kind of action.  This model of trust computation fits all
-> known certification examples.  Even though it is foreign to X.509 thinking,
-> in particular, it applies to X.509.  The authorization in this example flows
-> in a loop (circuit) from verifier back to verifier.  To use an electical 
-> example, the verifier has both battery and ammeter.
-> 

Carl,

This issue bears on your earlier comment that PGP's trust model is not
able to pass full authority, while X.509, SDSI and raw SPKI are able to,
to which I answered negatively, with the partial copy above.  While I
think that PGP is a wee bit out of context here, your mention of X.509
makes me feel a teeny-weeny more confortable to comment further on this
issue -- emphasizing X.509 but with a dash of PGP at the end. 

(Of course, the other issues I have commented on, especifically on SPKI,
still remain pending)

This discussion may be especially interesting because X.509 is often times
seen as a top-down trust structure, that is just dictorially imposed upon
the verifier, while PGP would follow a grass-roots approach. However, both
PGP and X.509 define their central role to be played by the verifier
regarding cert acceptance, while cert metrics is defined in both cases
without any influence from the verifier. Further, both are key-transport
protocols, as well as SPKI/SDSI, and they all depend on two types of
extrinsic references: keys (quantitative) and trust (qualitative).

I think I understood your model of trust computation and, following your
argument, I'll just first rephrase it so that we know if we are talking
about the same apples and speedboats ;-) Please excuse me if it gets
verbose or if it sounds so, but I am just trying to make sure we are using
the same dictionary, as you asked. Thus, out of respect for your work,
please allow me to be a bit redundant, as redundancy may actually improve
communication efficiency here.
 
I can, unsurprisingly, recognize two steps in your model above: 
acceptance of the root-key by the verifier and, its later use by the
verifier in order to accept a certificate. 

Accordingly, let me differentiate these two steps and separately analyse
their behavior before verifying if authorization is flowing in a loop, or
not.

1. COGNITION

The first step will be named cognition [ref.1] and involves two phases:

(1.i) the verifier gathers quantitative knowledge about a root-key that
can be used to sign authorizations on matters of X (eg, its value,
validity period, issuer, CPS warranties, CRL limitations, cert class,
insurance coverage, etc.) and,

(1.ii) the verifier acquires a qualitative level of trust on the
root-key's issuer and its adherence to the practices informed in (1.i) 
above for authorizations on matters of X (eg, on the issuer's procedures
being correct and reliable, trust on the root hierarchy for the
corresponding private-key's security, trust that the certificate data was
correctly copied from the subject, warranties being respected, insurance
being covered, data privacy, etc.).

The first step is thus a prior act (to certification) and establishes that
root-key as known to the verifier, while the verifier also accepts that
the root-key holder (ie, the issuer) is trustworthy to sign authorizations
on matters of X using that root-key. 

Now, what happens after the verifier completes the first step, accepting
the root-key and trusting the issuer?


2. RECOGNITION

The second step is called recognition and would basically depend on the
"memory" data which were acquired by the verifier in the first step. One
may think that such "memory" can be used as is, but that is not so. The
acquired "memory" must be subjected to further semantics, which depend
entirely on the verifier's policies.  Six main effects can change this
"memory" [ref. 2], as seen and evaluated by the verifier:

2.1. trust on the root-key holder (ie, the cert issuer) must neither
increase nor decrease as a function of repeated use of the same root-key,
if the accepted certificates yielded data which were perceived as correct
by the verifier. After all, that's what it was expected to happen,
and trusted, beforehand. 

2.2. trust on the root-key holder must sharply decrease if any valid and
accepted certificate has data which are not perceived as correct.

2.3. trust on the root-key itself must always decrease with time, as the
accumulated probability of fraud/disclosure of the corresponding
private-key increases up to the key's lifetime. This is equally perceived
by all verifiers. For a model, see [ref. 3].

2.4. trust on any certificate signed by that root-key must always decrease
with time, as the probability that an unaccounted for CRL (ie, a CRL not
accounted for in due time, errand, not yet available, not reachable, etc.)
that lists that certificate may exist will increase with the increased
number of certificates issued as a function of time by the root-key. This
trust component drops abruptly when the certificate or the root-key
exceeds their validity, because the issuer has no reason to keep CRLs
up-to-date for the certificate or in general, after either expires. 

2.5. the usefullness of the authorizations derived from any certificate
issued by that root-key may decrease with issuance time, as the validity
of a certificate cannot exceed the validity of its root-key. 

2.6. if the root-key is accepted (as defined by the verifier) as part of a
root-certificate chain of depth larger than one (which needs to be built
in order to allow a certificate to be accepted) then even though all paths
of this chain may be initially trusted to each other, the final acceptance
may have zero belief if intermediate trust values change with time.

etc., as needed.

Taking into account such semantic effects on the "memory" data, as derived
and controlled by policies on the verifier side, the second step involves
two phases:

(2.i) the verifier calculates the current trust level for the desired
root-key for authorization on matters of X,

(2.ii) if the root-key's current trust level is adequate to the verifier
then the verifier uses the trusted root-key and syntatically accepts or
rejects the certificate for authorization on matters of X, otherwise the
certificate is rejected.


3. LOOP OR NO LOOP

After the second step (recognition) is completed, you mention that
authorization is flowing in a loop from verifier back to verifier, from
that root key through certificates, possibly constrained or restricted,
and into the eventual request, where it is delivered to the verifier as
part of a request for some kind of action. 

Now, let's note that the initial authorization that was granted by the
verifier was a direct result of the trust developed in the second phase of
the cognition step -- (1.ii)  above.  But, what did the verifier initially
authorized? Two things: 

(3.i) he explictly authorized an issuer's root-key to syntatically verify
certificates signed by the issuer on matters of X, and

(3.ii) he implictly authorized any such accepted certificate to be
understood as representing data to be interpreted according to the
issuer's (not the verifier's) procedures.
 
In the first step, the verifier initially authorized acceptance of the
issuer's trust relationships and policies (eg, the issuer trusts its own
root-key and the issuer trusts its own procedures).  These are apples,
which are accepted by the verifier and are stored as such (ie, with no
syntatic or semantic change because one may not half-accept the issuer's
declarations).

In the final step, the verifier authorizes syntatic acceptance of the
certificate data after following his own trust relationships and policies
(eg, the semantics of 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, etc.). These are
speedboats, which are defined and used by the verifier himself.

Thus, the initial and final authorizations are respectively apples and
speedboats. They may neither be compared with each other nor thought of as
a type of "authorization loop", because comparisons and loops can only be
formed between like quantities.

Now, for a dash of PGP. The reader may recognize that PGP follows exactly
the same two steps, with the same two phases in each step, albeit with
different semantics. 

Why is this important? Because it shows that X.509 and PGP are equally
effective regarding trust transfer, which is nonetheless always less than
100% efficient. 

In both cases, the verifier's trust on the issuer is transfered (less than
100%) to trust on the subject's declarations obtained from the issuer's
certificate -- as accepted by the verifier's policies and subjected to the
issuer's policies and interpretive values. 

Eletrically if you want, even though it is a poor analogy for reasons to
be shown later, the model here is that of a common-collector NPN
transistor amplifier with voltage gain (trust) smaller than unity ;-),
where you have three ports and not just two, with complete isolation
between collector and emitter.  Here, the "verifier's trust on the issuer"
(a battery)  injects authorizations into the issuer's root-key (the base),
which uses the issuer's policies (the base impedance) to provide a flow of
trusted data from an isolated subject (the collector, polarized at
infinite impedance to the emitter) to the verifier (the emitter), however
as defined by the verifier's policies (the emitter's impedance).

However, unlike an electric model where electrons must follow a loop
because of perfect charge conservation, information such as contained in
trust relationships is not conserved (thank God and the Internet) and
there is no sense in pursuing this example to require for a return
connection between verifier and subject or verifier and issuer. Internet
trust computation is not analogous to an electrical circuit because the
unit of information on trust can be consumed or produced at will, unlike
the eletrical unit of charge. So, your example of battery and ammeter is
flawed on two counts: it does not allow for high-to-low impedance transfer
with source isolation (as a transistor does) and predicates perfect charge
conservation.


References:

[1] http://mcg.org.br/cie.htm
[2] http://mcg.org.br/cert.htm    
[3] http://www.ini.cmu.edu/NETBILL/pubs/certlife/certlife.html     

Thank you,

Ed

______________________________________________________________________
Dr.rer.nat. E. Gerck                        egerck@laser.cps.softex.br
http://novaware.cps.softex.br








Follow-Ups: References: