Re: Summary, was Re: Every time ..., was Re: General formula

[Ed Gerck <egerck@xxxxxxxxxx>]

Tony Bartoletti wrote:

> At 09:53 AM 6/4/99 -0700, Ed Gerck wrote:
>
> [snip]
>
> >Thus, slightly paraphrasing Andrew's following text, I may say:
>
> [snip]
>
> >The user does not need to make any assumption about attribute
> >dependency besides the trivial case of not using fully redundant
> >(whatever this may mean in the operational context) attributes; such
> >as repeatingly using the same attribute lifetime in the equation if the
> >attribute happens to repeated verbatim in the certificate -- since the
> >attribute is essentially "one" if simply repeated."
> >
> >Hope it is clearer.
> >
> >Cheers,
> >
> >Ed Gerck
>
> But is this "trivial case" always obvious?

Tony:

Good question. The answer is indeed a NO (as you imply) because of
the caveat above "(whatever this may mean in the operational context)".
It is trivial (a word often used in science to mean that the math is easy)
since you have nothing to calculate ... but deciding it may not be obvious.

For example, some postings ago you presented the following interesting
case:

T> Consider certifying my following attributes:
T>
T> 1.  First Name = "Anthony"
T>
T> 2.  First Name Writ Backward = "ynohtnA"
T>
T> 3.  First Name all in caps = "ANTHONY"

which you thought (in your operational context) to be 100% redundant.
However, I provided a different operational context (perverted?) where
you could have reached a different conclusion:

E> For example, if those 3 attributes were to be interpreted as three different
E> things as viewed from your computer (as the observer):

E> 1. "Anthony" is your login
E> 2. "ynohtnA" is your initial password
E> 3. "ANTHONY" is your email address at the maihost.
E>
E> Now, of course, each one of them has a different meaning and denotes
E> a different entity to the observer (the computer) -- and each one is also
E> quite independent in their lifetimes.

As I hinted then, we need to recognize that 100% redundant terms carry no
information (in IT terms). Thus, there is no sense in distinguishing among
them if they are indeed 100% redundant. So, they should NOT be
included in the equation  -- this is the simple answer.

Why? Because the equation 1/T = 1/T1 + .. +1/TN was derived *for
each* attribute that can be *recognized*. In other words, if there is no
information (surprise) for an attribute, it must not be counted -- since it
was already counted.

However, and here lies that subtle (so, certainly also not obvious) point,
the measurement of information (hence, redundancy) depends on the
observer -- as I showed then using your own example (and, copied
above).

> This issue is rarely one
> where we disagree axiomatically with statements like "Under these
> premises, this formula holds true".  Rather, the disagreements arise
> in assuming particular case data satisfy the formula's premises.

Yes, and this must be very clear to the user, as I commented in my
sixth point in this thread (previous msg):

"Gerck's certificate lifetime equation requires the user to input their
assumptions on each presented attribute validity lifetime (an average)
of a *given* certificate, when a single exponential decay is assumed for
each attribute validity.  When this is not true for an attribute (eg, in the
case of a square-function validty) but the attribute can be described
by a piecewise exponential decay (as it generally can, at least
approximately) then the user must define and assume enough delayed
sub-attributes ..."

In all, the "equation user" is central. And, most surely *different* users will
disagree! But, how can that be possible? Or, useful? Because we are
dealing here with an intersubjective evaluation -- much like the medical
diagnosis of a patient, which, acceptably, is not unique. See "intersubjective"
in http://www.mcg.org.br/trustdef.htm for definition and examples.

Mind you, the same applies to the calculation of entropy in Physics.
Without wishing to open another can of worms (not this time), it
is entirely possible that two competent physicists justifiedly disagree
on an entropy calculation. And yet, Thernodynamics is a very useful
science.

> And "verbatum repetition" need not characterize "perfect redundancy".
> My silly example:
>
> We certify that person X is named "fred", person Y is named "john".
>
> Fred's cert has one attribute:
>
> 1   Person's name = fred
>
> John's cert has 5 attributes:
>
> 1   Person's name = fred

simple mistype:

1   Person's name = john

> 2   First letter of person's name  = j  (or first letter of attribute 1)
> 3   second letter of person's name = o
> 4   Third letter of person's name  = h
> 5   Fourth letter of person's name = n
>

Your example is not silly -- it is actually much more difficult than several
very complicated  examples I have seen.

> I would love to see example lifetimes assigned to these attributes,
> and how the formula might be applied.  Should the second certificate
> have a shorter lifetime?

If both have the same operational context, I can safely say that
they should have the same a priori lifetime.

> Can we "hide" redundancy even further?

;-) Well, there are many things that you have "hidden" already in
that example -- just look at the whole backward trust chain you
are taking at face value even for that declaration:

person  X is named "fred"

not to mention the validity of the CA root key, for example
(which is NOT part of the cert's *visible* attributes).
See also my previous comments to Bob Jueneman on this:

E> The a priori decay of trust with time is what makes
E> the attribute validity decay for the a priori determination
E> of its lifetime. This also shows that a certificate has many
E> unseen attributes, if you recall the list I used to discuss
E> the topics, which will nonetheless reduce its lifetime. One
E> example, of several discussed in
E> http://www.mcg.org.br/cert.htm , is the validity of the CA
E> signing certificate -- which is not mentioned in the
E> subscriber certificate as an attribute but can render it
E> invalid if the CA cert expires or is revoked before the
E> subscriber's certificate lifetime expires.

and, as I commented to Peter Williams on this:

E> As exemplified above, the *same* certificate could afford
E> increased lifetimes in the progression of the different
E> contexts presented -- even legally. And, in all cases,
E> the same lifetime equation would apply, though with
E> a different number of attribute lifetimes and respective
E> values.

> Yes, almost anyone can see the strict dependency of attribute 1 with
> attributes 2 .. 5 in the second cert.

Not everyone will see it in the same way, though. For example,
if that cert was created *that* way, then it may be verifying the
correct decoding of r-p's UNICODE platform when (for some
lamguages) there may be more than one coding for a single word,
though each single letter codes uniquely.

Again, it depends (as we both already agreed in this thread) on the
operational context.

>  But it seems intuitive that
> in cases where attributes only "tend toward" perfect dependency, the
> formula must yield a value that "tends toward" the value of any single
> attribute.

Yes, for sure -- for that *same* operational context though

> I wish I could construct an example for (say) 100 "almost dependent"
> attributes, each with expected lifetime t.  As "almost dependent" tends
> toward perfection, intuition says that the collection must have an
> expected lifetime that approaches t. I fail to see how the formula
> can behave so.

There are two different issues here (see my sixth point,before, at
the end):

1. Direct use: The equation does not calculate attribute lifetime -- it
calculates the average certificate lifetime *given* all the attribute
lifetimes which the user has decided upon. Then, simply, the
certificate lifetime will change (increasing *or* decreasing) as
you increase the inter-attribute dependency from "almost
dependent" to "100% dependent".

2. Inverse use (your case, above): You have a given certificate
lifetime you want and you investigate how many "almost dependent"
attributes you need in order to obtain  lifetime To -- as a function
of what you mean by "almost dependent". As you write the formula
starting with attribute 1, the certificate lifetime must decrease with
each term you add for that specific value of redundancy -- so you
must then stop adding attributes when you are in a neighborhood
of the desired lifetime To. Now, as you do various tests (note, it is
you that inputs the attribute lifetimes) and  increase inter-attribute
redundancy, each individual attribute lifetime  will change and this
will allow the inverse of the sum of their inverses (ie, certificate
lifetime T) to also change until To is reached when you have
only that *one* attribute (100% redundancy) and 1/T = 1/To,
so that T = To.

Comments?

Cheers,

Ed Gerck