Subject: RE: General formula

From: Alan Lloyd <[email-masked]>
Date: Wed, 2 Jun 1999 15:11:38 +1000

I still do not understand how anyone on this planet can predict this
without the real application. 

	snip.

> I never [yet ;-)] said that the equation I derived is "universal".
> But,
> that it is based on assumptions which are generally valid for PKIX
> certificates. In fact, I know no counter-examples.
> 
> And, one of the predictions of the equation I derived is that "the
> lifetime of a certificate is inversely proportional to the number of
> its attributes".
> 
	However, if the certificate has a validity period of 20 seconds
- then it wont last long anyway. And if the certificate attributes are
in fact all the paragraphs and pages of the bible that are digitally
captured - at a certain time and the validy is set to 20 years then this
certificate is a lot bigger and lasts a lot longer than the first case.

	What are these attributes representing? The authentication
points of the subject, the management of the certificate, the validation
policy environment for the certficate or some data that the Issuer is
providing integrity over. Its not a question of quantity - its a
question of application and use.

	regards alan

> Which means "good news" when compared with what was
> previously believed (though without proof) and which you first
> questioned on the list -- providing both a reason and an excuse
> for my posting with that equation. As I wrote last week,  my
> posting was  excerpted from a paper which I expect to be
> ready from review this week. I hope the paper will provide
> (at the expense of reading time) for a more comprehensive
> context.
> 
> Cheers,
> 
> Ed Gerck
>

---

From: Ed Gerck <[email-masked]>
Date: Tue, 01 Jun 1999 23:07:38 -0700

> without the real application.

see below.

> certificate is a lot bigger and lasts a lot longer than the first case.

So, you conclude that the predicition is wrong because
20 seconds << 20 years? Well, aren't you just trying to compare
apples with speedboats? See, the prediction says "proportional"
-- so, you must compare like things.

Let me exemplify. The force of gravity is inversely proportional to the
square of the distance between two masses. So, if you take two masses
and they are atracted by a gravity force of 20 Newtons at distance X
and you take two other masses that are attracted by a gravity force of
20,000 Newtons even though they have a much larger distance of
1,000*X between  them -- what can you say? Was Newton wrong?
No, the masses are different.

Likewise, when I say that "the lifetime of a certificate is inversely
proportional to the number of its attributes" do I care what the
application is? What are these attributes representing? About the
authentication points of the subject, the management of the certificate,
the validation policy environment for the certificate or some data that
the Issuer is providing integrity over? Is it a question of application and
use? NO -- I just care that the *same* situation is used when you vary
the number of attributes.

Thus, for the *same* situation (Bible or ticket to Hell), the lifetime of a
certificate will decrease to half if you double the number of attributes,
to one-third if you triple, etc. In other words, it is inversely *proportional*.
If it was 20 years for N attributes, it will be 10 years for 2N attributes;
if it was 20 seconds for N attributes, it will be 10 seconds for 2N attributes;
etc.

Of course, this is valid if all the attributes have similar values -- otherwise,
just apply the full equation:

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

But, the usefulness of my comentary does not depend on its (inexisting)
exactness for Ti <> Tj, but because it provides a correct designer feeling
for the decrease of certificate lifetime with the number of attributes --
double the number of attributes and certificate lifetime will likely decrease
to about half of what it was. Not to about one-quarter, or one-tenth.

Cheers,

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