Subject: Re: Certificate life-cycle costs.

From: "Bob Blakley" <[email-masked]>
Date: Fri, 21 May 1999 15:22:24 -0500

Ed,

>> I think this is not quite correct because of imprecise phrasing.  What I
>> would have said here is
>
>Bob:
>
>This is a simple confusion, as that quote of mine was written to Bob
>Jueneman, in regard to Bob Jueneman's comments -- not to Bob Blakley
>nor in regard to Bob Blakley's comments ;-) Please check the message.

Actually, it's a more complicated confusion than you imagine!
I did realize that you were answering Bob J.; I was just interposing myself
into the discussion!  Name capture creates ambiguities of all sorts (type 1
*and* type 2 errors!)

>Thus, it will of course NOT apply to what you would have said. Hovewer,
>what I wrote is correct -- independently of where it is applied. Let me
>prove it:
>
>Suppose, as I said, that each attribute and the key have the same lifetime
>"L" -- thus, for N attributes + 1 key, we have:
>
>1/T = 1/L + 1/L + ...+ 1/L +   1/L
>          ^^^^^^^^^^^^^^^       ^^
>             N attributes               1 key
>
>so that:
>
>1/T = N/L + 1/L  => T = L/(1 + N)

All obviously correct but not on the point I was making, which is that there
are
situations where, because of a lack of independence, N attributes do NOT
give rise to N/L, but instead to only 1/L.

An example of this is the following attribute certificate:

            Attribute 1:    eye-color = gray
            Attribute 2:    blood-type = O positive
            Attribute 3:    name = George Robert Blakley III

Here all attributes have the same lifetime in the sense in which I use the
term -
which happens also to correspond to the naive notion of "lifetime" you'd see
in the dictionary.  I don't know what L is, but I do know that L1 = L2 = L3.

Now if I add some other attributes:

            Attribute 4:    hair-color = brown
            Attribute 5:    weight = 150 (well, approximately :)
            Attribute 6:    height = 5'9"

These all have different L's; Attribute 4 is going to have to be changed to
"hair-color = gray"
based on some kind of majority-rule algorithm pretty soon now - hopefully
before L1 expires!

>>     ...the attributes as a whole will very much lower the certificate
lifetime
>> even
>>     if each attribute and the key have the *same* [expected validity
>> duration].
>>
>> Normally when I think of "lifetime" I think of a validity interval, and if
two
>> things have the same lifetime, they come into existence at exactly the
>> same time and cease to exist at exactly the same time.  In this case
>> there is no independence whatsoever, and the two things should be
>> thought of as essentially one attribute (hence my caveats about
>> independence in earlier notes).
>
>This logic is unfounded. Lifetime is a statistical concept by nature -- since
>it pertains to the future and no future is deterministic (it is easy to prove
>that if any future attribute is deterministic to a measure To in future time,
>then the whole universe must be deterministic to measure To).

But I don't think this is really relevant; you can simply re-cast the problem
in terms of open intervals to take care of minor nondeterminism surrounding
the exact moment of expiry.

>The confusion is thus simple -- two things that have the same lifetime
>do not have to begin at exactly the same time

They certainly don't have to, but in many cases they actually DO.  The
example I gave above is one case; the same information encoded
on a driver's license for me is a derivative which exemplifies
a broad class of certification scenarios from the real world which
also have this property.

>> In order to lower the *lifetime* of the certificate, what's required is
that
>> attributes expire at *different* times
>
>No, as above. Also, if the attributes have the same lifetime but their
>decay rates are non-exponential (eg, a square-function)  then they
>will need to be modeled at least as two exponentials (see my former
>workout of David's example) and they will cause different reductions
>as compared to the pure exponential case (see my example above)..

Except again I think this can be abstracted away using a much less complex
analysis in terms of simple probabilities which will be a correct first-order
approximation of the real behavior of the majority of certification systems
we actually build.

--bob

Bob Blakley ([email-masked])
Chief Scientist, Dascom

---

From: Ed Gerck <[email-masked]>
Date: Fri, 21 May 1999 15:37:51 -0700

> into the discussion!  Name capture creates ambiguities of all sorts (type 1

Bob and, perhaps, Bob ;-)

> are situations where, because of a lack of independence, N attributes do NOT

I understood your point and I disagreed with it. That is why I included
two examples which showed that lack of independence is NOT the deciding
issue to change the result  L/(1+N) to L, but lack of exponential decay.
And, I also wrote:

 "... I did not include the word "independent" since the attributes do
  not have to be independent for the phrase to apply."

> term - which happens also to correspond to the naive notion of "lifetime" you'd see

The dictionary definition of lifetime is fine, I have no quibbles about it.  But
because you believe those three attributes *will* have the same lifetime, this
does NOT mean:

1. that they were all created (ie, defined) at the same time
2. that they will all end their validity at the same time
3. that they are all dependent
4. that they will all obey the same validity time-decay law
5. that they will all actually have the same lifetime.

I hope my previous comment is now clearer.

> "hair-color = gray" based on some kind of majority-rule algorithm pretty
> soon now - hopefully before L1 expires!

;-) I hope so -- but my 5 comments above apply in reverse to these other 3
attributes as well, since what you wrote does NOT mean:

1. that they were all created (ie, defined) at different times
2. that they will all end their validity at different times
3. that they are all independent.
4. that they will all obey different validity time-decay laws
5. that they will all actually have different lifetimes.

> > Bob Blakley wrote:
> >> two things have the same lifetime, they come into existence at exactly
> > > the same time and cease to exist at exactly the same time.  In this case
> >...

Still, this does NOT mean that "if two things have the same lifetime, they come
into existence at exactly [with some minor nondeterminism] the same time and
cease to exist at exactly [with some minor nondeterminism] the same time."

As I argued, there is no relationship at all between these events that could
be inferred from equal lifetimes -- thus, assuming it is unfounded. And,
this needed generality is at the base of my previous derivation of the lifetime
equation, as I commented in reference [1] of that posting.

Also, recasting the problem in terms of open intervals where "minor
nondeterminism" could play a role to define neighborhoods for
similar lifetimes does NOT mean that "In this case there is no
independence whatsoever, and the two things should be thought of
as essentially one attribute (hence my caveats about  independence
in earlier notes)."

Further, I note that exactly this point of assuming that attributes that
have the same lifetime are essentially one attribute, and otherwise that
attributes that have different lifetimes are independent, is at the root of
David's remarks that questioned the validity of your intuitive derivation:

DOUBT 3: There is no conventional wisdom about the distribution of
attribute lifetimes, but one would venture that it is a discrete, not a
continuous distribution.  Therefore, one cannot say that  "with
probability 1, attribute 2 doesn't expire at t1".

DOUBT 4: Possibly, attributes within a single certificate will not have
pairwise mutually independent lifetimes, so their lifetimes are more than
likely correlated.

DOUBT 5: The question whether pairwise mutual independence is sufficient
for Bob's formula to hold, or whether the stronger joint independence is
required.

DOUBT 6: The preconditions for Bob's formula to be correct cannot be
demonstrated.

which I showed were irrelevant because the formula you derived was a special
case of an equation that did not include any such assumption. So, funnywise,
my equation supported your formula because it denied the very assumption you
imposed to derive it ;-)

Though I understand you were led to suppose that assumption  in order to be
able to provide at least an intuitive "proof" for that formula. However, the
assumption that lifetime distance is a measure of attribute independence (as
I may recast your assumption) is incorrect and could have led you either to
no result or to a wrong result if it were consequently applied in a
mathematically sound proof.

> a broad class of certification scenarios from the real world which

I disagree. And, there are billions of counter-examples. For example,
if men's biological lifetime is 70 years this does not mean that all men
were born at the same time -- and yet they all have the same lifetime.

> approximation of the real behavior of the majority of certification systems

I think your comment goes back to that assumption.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                 [email-masked]
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 24 May 1999 18:04:22 -0700

Ed,

Not to disagree with your most general findings, but in the case
of "purely dependent" attributes (purely redundant, perhaps) I
cannot see how the formula is to work.

To abstract/simplify Bob Blakeley's example further, I consider
the possible lifetime of my own first name (Anthony).  Let it's
lifetime be given by L, in some formulation.

Consider certifying my following attributes:

1.  First Name = "Anthony"

2.  First Name Writ Backward = "ynohtnA"

3.  First Name all in caps = "ANTHONY"

etc.  I suppose I could go on for several hundred such "attributes"
if I had to.  And yet I cannot see how the lifetime of the collection
could be different from the lifetime of the first.  Indeed, they are
really one attribute presented as many.  Easy to see that in this
particular case, but how to recognize such in general?

Comments?

___tony___ 

>I think your comment goes back to that assumption.

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8002               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

---

From: Ed Gerck <[email-masked]>
Date: Tue, 25 May 1999 10:21:08 -0700

> cannot see how the formula is to work.

Tony:

It might seem like you have answered your question yourself. "Purely
dependent" or "purely redundant" attributes are, as you say, purely
dependent. In other words, 100% redundant terms carry no
additional information. 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 a subtle point, the measurement of information
(hence, redundancy) depends on the observer -- as I will show using
your own example below.

> really one attribute presented as many.

Fine,  if you say they are only one attribute to you, then do count
them just as one -- since you trust them to be only one. As you may
note, you have already provided the correct answer according to
your reference frame.

Now,  let me see this from a different reference frame -- a different
observer. After all, a certificate from you to yourself is not very much
useful -- you *want* it to be interpreted by others.

First, let me note that you have constructed 3 examples that are
syntactically different but which you, in your own trust basis, connected
to the same sense (meaning the common name "ANTHONY") and to
the same entity (you).

But you may agree that another observer, in another trust basis, may
connect those 3 examples to completely *different* meanings and even
completely *different* entities. In fact, a different observer may connect
all hundreds of different syntactic variations that *you* associate with
"your name" and with "yourself", to completely different meanings
and entities.

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

1. "Anthony" is your login
2. "ynohtnA" is your initial password
3. "ANTHONY" is your email address at the maihost.

Now, of course, each one of them has a different meaning and denotes
a different entity to the observer (the computer) -- and each one is also
quite independent in their lifetimes. For example, a hacker can easily
change your password at your computer but may not be able to easily
change your e-mail address at the mailhost (which, suppose, has a
higher security). Knowing this, you would also be entirely justified to
assign a longer lifetime to the third attribute when compared to the first.
And, as usual, you will want to assign a much shorter lifetime to the
second attribute, your password.

Thus, this somewhat contrived example is simply based on the often
neglected fact that redundancy (as well as information) depends on the
observer. As I commented to you once, in another thread, and exemplified
that randomness also depends on the observer.

Therefore, since a certificate's attributes must be relied upon by different
observers, you must take this aspect into account when you design
a certificate and calculate its a priori lifetime -- in other words, its expected
validity period as you (the issuer) define it. Which is one of the things that
the equation I derived allows you to do, when you are taking into account all
attributes that you can *recognize* as significant to that certificate's validity.

Which could (possibly, must) include sub-attributes as I commented in my
replies to Bob J. and Peter -- though they may NOT be visible at all in the
certificate itself.

> Easy to see that in this

Clearly, if I am only basing my certificate validity choices on syntax then
I would be only talking about attribute *equality* and comparing strings
-- for example, if the strings match byte by byte, then they are equal and
should NOT be included in the lifetime equation more than once.

And, this is the case for PKIX standard usage -- which is to be supported
by the RFCs themselves, and the issuer's policies. But, as above, there
is more to "equality" than meets the eye of one observer.  It depends, for
example, whether "a PKIX application SHOULD interpret the DN field
as case-sensitive" or if "a PKIX application MUST interpret the DN field
as case-sensitive". Two different "equality" metrics, of many possible.

What makes your question non-trivial *in general terms* is thus that syntax
cannot be self-measured. As we both have discussed elsewhere in trust
theory terms, one needs a trust basis in order to define and recognize
even pure syntax (not to mention semantics and entity denotation). But,
again, *in PKIX terms* one should have a reasonable and coherent answer
to your question by reading the relevant RFCs and issuer's policies.

In summary of all the above, a general answer is possible to your question.
Include in the lifetime equation 1/T = 1/T1+ ...+ 1/TN the lifetimes Tn of
all those attributes which are *different* (whichever way you and all the
relying-parties define by that) regardless whether the lifetimes themselves
are different or not, numerically.

Again, as in my reply to Blakley,  lifetime distance is NOT a measure of
attribute independence.

Cheers,

Ed Gerck
  ---  Meta-Certificate Group member -- http://www.mcg.org.br  ---