[4066] in cryptography@c2.net mail archive
Re: lifetime of certs now in circulation
daemon@ATHENA.MIT.EDU (Ed Gerck)
Mon Jan 25 19:42:11 1999
Date: Mon, 25 Jan 1999 21:55:59 -0200 (EDT)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: cryptography@c2.net
In-Reply-To: <Pine.BSI.3.91.990125160738.20607D-100000@ivan.iecc.com>
On Mon, 25 Jan 1999, John R Levine wrote:
>> The ones that are in the 2020 foresight group,
>> VeriSign, Microsoft, TC TrustCenter, and Thawte
>> really ought to have their heads examined or I'm
>> too dense to get the joke.
>
>I suspect that the message here is that they're more worried about user
>browers popping up "this certificate has expired" messages as happened to
>Thawte customers with users running slightly old versions of Netscape, than
>are worried about their certs being cracked.
I believe it is a bit more involved than that -- as it revolves
around X.509's "cold start" problems (item vii below).
Two years ago, in 1997, this was explained in "Overview of
Certification Systems: CA, X.509, PGP and SKIP", available at
http://www.mcg.org.br/cert.htm and downloaded more than 60,000 times
so far, as:
(iv) The lifetime of a certificate also depends on various factors,
as pointed out by Ian Simpson [Ian's link]. A simplified
mathematical analysis and simulation shows that optimal certificate
lifetimes may be as short as a few weeks rather than a year or more
as is the case of some current commercial CA infrastructure [see
link #8] offerings. Note that such short lifetimes mean a large
overhead in costs, time and effort.
And, the link #8 is:
8. Too long expiration dates: As commented in item (vi), top level
CAs may choose too long lifetimes, that may jeopardize security --
especially in view of actual possible short lifetimes, of the order
of weeks as estimated in item (iv). This example, shows an actual
root CA certificate that has a lifetime of twenty (20) years. Note
also that there is no e-mail information, telephone, etc., to help
the user decide if that certificate is valid, still, or if it
actually belongs to the self-certified owner.
and, now, following back the link #8 to (vi), one of the reasons:
(vi) The Certification Authority's public key might be the target of
an extensive decryption attack. For this reason, CAs should use very
long keys and change keys regularly. Top-level CAs unfortunately are
exceptions: it may not be practical for them to change keys
frequently because their keys may be written into software (such as
the browser you are using now) used by a large number of verifiers.
Thus, the very CA's that may be the most probable targets are the
ones that offer the smallest protection level. Protection, in this
case, is an inverse function of worth.
but, the most important reason for such questionable behavior is
however correct *in X.509 terms* -- X.059 cannot "cold start":
(vii) There is also a serious question of how one would distribute
an updated top level CA certificate, when the expired certificate is
"hardwired" in the software. Unless there is a second trusted CA who
can sign the distribution, the new certificate cannot be certified.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@mcg.org.br
http://novaware.com.br
--- Meta-Certificate Group member -- http://www.mcg.org.br ---
