Subject: RE: Certificate life-cycle costs.

From: Alan Lloyd <[email-masked]>
Date: Tue, 25 May 1999 12:54:20 +1000

I am lost on this one.

I am sure that those who provide products and services that apply
certificate  functionality will work out the deployment costs as part of
the risks, ILS/LCC analysis. As certs may be used for bus tickets,
vehical tags, licences, identity, information integrity, etc, etc.. Its
hard to determine life cycle "costs" without knowing the application -
trust, risk, market share, customer distribution and revenues.. Costs,
be they called high or low are normally determined as a percentage of
revenue...

Whats the context of this?

regards alan
> -----Original Message-----
> From:	Tony Bartoletti 
> Sent:	Tuesday, May 25, 1999 11:04 AM
> To:	Ed Gerck; Bob Blakley
> Cc:	Bob Jueneman; [email-masked]
> Subject:	Re: Certificate life-cycle costs.
> 
> 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___ 
> 
> 
> At 03:37 PM 5/21/99 -0700, Ed Gerck wrote:
> >
> >
> >Bob Blakley wrote:
> >
> >> 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!)
> >
> >Bob and, perhaps, Bob ;-)
> >
> >> >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.
> >
> >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."
> >
> >> 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.
> >
> >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.
> >
> >> 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!
> >
> >;-) 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:
> >> >>
> >> >> 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
> >> >...
> >>
> >> 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.
> >
> >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.
> >
> >> >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.
> >
> >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.
> >
> >
> >> >> 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.
> >
> >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  ---
> >
> >
> >
> >
> 
> 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 12:10:54 -0700

> Whats the context of this?

;-) Costs, in several contexts -- including the one you mention. For example,
in answering the questions:

1. In terms of  the costs of "overloading" a certificate with additional information,
should you use M individual attribute certificates rather than one compound
M-attribute identity certificate?

2. If certificate retrieval costs X, the cost of incorrectly relying on an revoked
certificate for some transaction is Y, the value at stake is S and the time t since
the certificate was last validated by CRL or OCSP checking is T, then when
you should/should not revalidate the certificate?

For answers to these two questions, please check the last messages in the thread
on "Re: Example with sub-attributes, was Re: Attribute certificate lifetimes" --
which provide the context for this thread. See also the first two messages in this
thread, by Bob Jueneman and myself.

Cheers,

Ed Gerck