Subject: RE: Example with sub-attributes,was Re: Attribute certificatelifetimes

From: Peter Williams <[email-masked]>
Date: Thu, 20 May 1999 11:06:18 -0500

If one changes the axis of this argument to
the lifetime of a directory/repository entry, does 
anything change?

The reason I ask is that a certificate is actually
no longer valid in many legalistic practices models when
the "official" certificate management repository is
modified - to reflect the change in status.

A 2459 PKI is perhaps modeled as a function 
of three macro variables - the lifetime of
a cert,  the lifetime of the repository entry, and the 
lifetime of the CRL/OCSP-Responses (if used).

On Wednesday, May 19, 1999 8:50 PM, Ed Gerck [SMTP:[email-masked]] wrote:
> 
> 
> Bob Jueneman wrote:
> 
> > Ed,
> >
> > There must be a pony in here somewhere, but other than an interesting
> > mathematical exercise, I'm not sure that I can put my finger on it yet.
> 
> Bob:
> 
> Well, perhaps this deserves more than just a "pony award" ;-)
> 
> Because, in my view, it answers the fundamental question that must
> be addressed *before* a certificate is ever issued: "What is to be
> this certificate's stated lifetime so that its data is expectedly
> valid during its lifetime?". 
> 
> Additionally, the following list may be helpful to guide your finger ;-)
> and our discussion, where the quotes refers to text in my original 
> posting unless otherwise noted:
> 
> 
> 1. The equation
> 
> 1/T = 1/T1 + 1/T2 + ... + 1/TN               (1)
> 
> is simple enough to be quickly used. It allows one to use engineering
> where before one only had guess-work and a bad formula -- outcounting 
> Blackley's formula, which deals with a particular case but can be cast
> in the same form as Eq. (1).
> 
> 2. "Since any certificate has attributes (e.g., the date it was issued,
> the company name it was issued to, etc.) which may be invalid sooner 
> (e.g., Y2K, misspelling, CA error) than the originally intended key 
> lifetime, this discussion may be important to provide an upper bound 
> for key lifetimes for any type of certificates."
> 
> 3. "Certificate lifetime with M multiple attributes can be modeled 
> in average behavior and without imposing attribute independence, 
> by using an exponential decay formula for each effective attribute".
> 
> 4. "The number N of effective attributes can be larger than the number
> M of original multiple attributes in the certificate, which allows the 
> representation of sub-attributes that are too significant to be ignored."
> 
> 5. Attribute certification is no longer a murky situation as described
> by David, which lifetime behavior cannot be proved or disproved for 
> each calculation. An exponential decay rate can be generally assumed 
> for each attribute, which can be made as accurate as desired by 
> dividing each attribute into sub-attributes and assigning an 
> additional decay rate for each one. This allows even square-function
> and abruptly fall offs to be considered in the same certificate.
> 
> 6. Equation (1) can handle delayed attributes, piecewise exponential
> decays, square-function atrributes and any non-increasing function of
> attribute validity with time, for any number of attributes.
> 
> 7. It is irrelevant whether the mean attribute lifetime is significantly
> shorter than the mean PK lifetime or not, as David questioned.
> 
> 8. The distribution of attribute lifetimes is correctly assumed to 
> be discrete in Eq. (1), answering a concern by David.
> 
> 9. It is irrelevant whether the attributes within a single certificate 
> are mutually independent or not in order to calculate certificate 
> lifetime, answering a concern by David.
> 
> 10. It is irrelevant whether the attributes within a single certificate
> are all jointly independent or not in order to calculate certificate 
> lifetime, answering a concern by David.
> 
> 11. It rolls trippingly off the tongue: "The inverse of the certificate 
> lifetime is equal to the sum of the inverses of each effective attribute
> lifetime". (a previous good-humored requirement by David)
> 
> 12. "The lesson here is that you have to make the key lifetime VERY short 
> compared to the shortest attribute lifetime in order to get the actual 
> lifetime of an attribute certificate close to its nominal lifetime", as 
> written by Bob Blackley when showing why his formula could be useful. The
> same result applies to Eq. (1), of course.
> 
> 13. "Certificate lifetime is always shorter than the shortest lifetime".
> 
> 14. "Key lifetime should be at most 1/3 the shortest attribute's lifetime."
> 
> 15. "Two attributes with lifetime equal to the key will reduce
> certificate lifetime to only 30% of the key lifetime."
> 
> 16. "Three attributes that each have a lifetime equal to twice the key 
> lifetime will nonetheless reduce certificate lifetime to 40% of the key 
> lifetime." 
> 
> 17. "Long-lived certificates should have a least number of attributes".
> 
> 18. "Denies the usefulness of overloading public-key certificates with 
> data in an attempt to increase reliance"
> 
> 19. "Even for no key the least number of attributes will again result in 
> a much longer-lived certificate."
> 
> 20. It allows one to use the same formalism both for a priori certificate
> lifetime calculations as in Eq. (1), as well as for a posteriori 
> certificate lifetime calculations -- also called certificate validation.
> This will be discussed elsewhere but is mentioned in my answer to your 
> question (2).
> 
> 21. Because it is mathematically sound in a very general context, so
> that one can rely on it, forget the math and concentrate on using it ;-)
> 
> 
> > What I'm groping for is something that would tie the expected
> > certificate lifetime back to a useful cost measure, I.e.,
> >
> > 1.  You should use individual attribute certificates rather than
> > compound attribute identity certificates if X>Y, for suitable values of
> > X and Y??
> 
> Yes and No -- and I am not being humorous, it is a fundamental limitation
> (though one that I did not yet address here). You need to compromise:
> 
> - An individual attribute certificate will be more reliable by itself -- 
> so it is a "yes" if your objective is to increase certificate lifetime 
> (see item 17 above).
> 
> - A compound attribute certificate will be more accurate by itself -- so, 
> it is a "no" if your objective is to increase certificate "strength".
> 
> >
> > 2.  If certificate retrieval costs X, the cost of incorrectly relying on
> > an revoked certificate for some transaction is Y, and the time s
> > since the certificate was last validated by CL or OCSP checking is T,
> > then you should/should not revalidate the certificate??
> 
> Well-stated. We need cost-functions and "merit figures" (as usual in 
> engineering) in order to facilitate decisions, and what you suggest
> is one that must surely face a relying-party. I will cut some corners
> below, but hopefully not too many -- I hope it still qualifies for the
> "pony award" ;-)
> 
> Let me change your "T" for D -- to avoid confusion with the given 
> formulas. Here, T is the certificate lifetime.
> 
> Please recall the function C(t) = exp (-t/T) given in reference [1] of
> my original posting -- the a priori certificate validity function. 
> Suppose this function is correctly weighed for its components, so that
> it can also be considered as the probability distribution function for *a 
> posteriori* certificate validity (it can be, if done as in [1], but note 
> that eq. (1) deals with a priori certificate validity). Then,
> 
> Y(s) = (1 - C(s - D)) * S , for s > D,
> 
> where Y and s are as you defined and S is the value at stake.  To simplify the equation, I will forget the insurance cost, the maximum
> risk covered by your insurance policy, the number of times you may
> rely on it per month on average, capital costs and non-financial costs 
> for  failure (such as good-will), for the moment. Then, I define a
> merit-function Q as:
> 
> Q(s) = (X - Y(s))/X
> 
> and state my rule:
> 
> "If Q > 0 then proceed, otherwise validate certificate".
> 
> Note that Y(0) = 0 and Q(0) = 1 -- otherwise, Q(s) < 1 for any s.
> 
> >
> > Any thoughts as to where this can take us?
> 
> Towards a mathematical theory of certification, for which much
> help and discussions will be, undoubtably, necessary. You may
> recall some of the origins of this model of validation, when 
> we both discussed the decay of trust after certificate issuance
> with time, in list and private discussions. The a priori decay
> of trust with time is what makes the attribute validity decay
> for the a priori determination of its lifetime. This also shows
> that a certificate has many unseen attributes, if you recall
> the list I used to discuss the topics, which will nonetheless
> reduce its lifetime. One example, of several discussed in
> http://www.mcg.org.br/cert.htm , is the validity of the CA 
> signing certificate -- which is not mentioned in the subscriber certificate as an attribute but can render it invalid if the CA
> cert expires or is revoked before the subscriber's certificate
> lifetime expires.
> 
> The end objectives are to qualify, quantify and increase 
> certificate accuracy and reliance, as well as to provide support
> for all modes of certification [http://www.mcg.org.br/cie.htm]
> 
> Since this focused list has a different task, my objective here
> was primarily to show that Blackley's formula is not an YARRFS
> (Yet Another Random Result From Statistics) as David Kemp 
> correctly IMO questioned, but rooted in a more general framework
> which validates the intuition behind it and offers some good
> tips -- my list of "finger tip" points 1-21 above.
> 
> Thus, I expect that this can indeed be useful for the PKIX effort
> and for all kinds of certificates, in a simple equation (1) that 
> may accomodate all needs -- so far ;-)
> 
> Comments?
> 
> 
> Cheers,
> 
> Ed Gerck
> ______________________________________________________________________
> Dr.rer.nat. E. Gerck                                 [email-masked]
>

---

From: Ed Gerck <[email-masked]>
Date: Thu, 20 May 1999 12:26:51 -0700

> the lifetime of a directory/repository entry, does

No. The lifetime you mention is simply a sub-attribute
lifetime and can taken into account as another term in
the relevant equation I presented:

1/T = 1/T1 + 1/T2 + ...+ 1/TN

In other words, your example is one unseen or implict
attribute from the certificate's syntax viewpoint. But, I
can also easily include others -- for example, if I include
the expected lifetime of the business entity behind that
directory/repository.

As you may see, this is, in all formal aspects, similar to
the root CA cert case I mentioned in my quoted posting
as an example -- and which may further clarify the issue
by recall:

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

> lifetime of the CRL/OCSP-Responses (if used).

All these issues can be included in the equation I
presented, as well as any explicit or implicit attribute.

To exemplify, if companies A and B certify each other's
public-key  by relying on each other's Verisign certificate
then, clearly, they are legally bound by Verisign's CPS
in relationship to each other in the reverse role of a
relying-party. However, after this X.509/PKIX step,
companies A and B can directly challenge each other's
key and increase their mutual level of reliance if the
challenges are sucessful. Further, as their relationship
progresses over one year of mutually satisfying
business they may decide that they now trust those
public-keys by themselves and not because Verisign
says that they respectively belong to a string named
A and another string named B.  Moreover, they
can so express in contract law terms at any moment
and be even more legally bound to accepting each
other's keys -- even when those two Verisign certificates
are actually no longer valid. After all, they control the
private-keys, they supplied their names and data for
the certificates, they bought the certificates, they were
the ones initially responsible both for CRL request
as well as CRL verification even when Verisign validity
was granted and, nothing that Verisign would do, or not
do, could possibly harm them after that Verisign validity
period is ended.

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

Also, as I showed before, it does not matter if legal reliance
follows a square-function time decay (for example, a CA
contract that is 100% valid for one year and then abruptly
terminates). Still, the equation I presented can be applied
piecewise, for each validity region -- so that the *same*
certificate can even offer a longer expected lifetime afer one
year (when the CA contract is expired) than before.

Your question has thus a further importance in that, IMO,
it clearly shows the broad framework of that equation --
which can encompass all issues relevant to certificate
lifetime and take them into account irrespective of
the axis of the discussion. By properly grouping the
atrributes in the equation, one can also compare classes
of attributes as I commented in reply to Bob Jueneman's
last posting -- that I insert here for completness:

 "But your last phrase is, you may realize, contradicted
 by the equation I presented for the certificate lifetime
 as the inverse of the sum of the inverses of the atttribute
 lifetimes contained in it -- because the attributes as a
 whole will very much lower the certificate lifetime even
 if  eachattribute and the key have the *same* lifetime."

Further, by using the technique of Pade' approximants,
when that equation is expanded in continued fractions,
I can build a convergent series of approximants where
attribute lifetimes are taken into account by their relative
values -- instead of just truncating the equation at some
index, which would mean an absolute cut-off with an
arbitrary reference. This illustrates a third important point
to be derived from your question -- that different argument
axis (i.e., different attribute class in focus) may be relatively
rated so that we can taken into account first those attribute
classes that have a higher relative importance for the problem
at hand -- which class may differ from relying-party to relying-
party.

Cheers,

Ed Gerck