public inbox for cygwin-talk@cygwin.com
 help / color / mirror / Atom feed
From: Warren Young <warren@etr-usa.com>
To: The Vulgar and Unprofessional Cygwin-Talk List <cygwin-talk@cygwin.com>
Subject: Re: The statistics of certification authorities
Date: Thu, 23 Jul 2009 01:26:00 -0000	[thread overview]
Message-ID: <4A67BBEF.3040603@etr-usa.com> (raw)
In-Reply-To: <4A66E038.1000808@gmail.com>

Dave Korn wrote:
>>  Which would you trust more, a statement from N months ago that a^y mod m
>> = b, or a statement from 6 years ago that c^y mod m = d ?
> 
>   Why would how long ago the statement was made have any bearing on its truth
> or falsity if maths hasn't changed in the mean time?

The mathematics of crypto don't enter into it.  Cert expiration is 
useful because the entities that acquire certificates -- individual 
humans, corporations, fringe cults, hyperintelligent shades of the 
colour blue... -- change over time.

Let's continue thinking mathematically about it.

A cert lets us assign a probability and confidence interval to the 
statement that blob N was signed by entity X.  That is, we can imagine a 
statistical algorithm that takes various facts about the cert, the CA, 
etc. and comes up with a probability that we can trust that the blob 
came from the entity it claims to, and a confidence interval for that 
probability.  We can call this our trust statistic.

One of these facts must include how long ago the cert was assigned to 
entity X, because the chance that entity X has changed in some way which 
means we can no longer trust blobs claiming to be signed by it increases 
over time.  Our trust statistic is highest at the instant the cert is 
issued, and declines over time as the chances increase that the entity 
changes in some way harmful to the trust statistic.

Example: An employee of a company buys a certificate, then later gets 
fired for some violation of trust within the organization.  If we were 
to learn this fact, it would certainly damage our trust statistic for 
that cert.  We normally will not learn about such things, but we must 
assume they will happen, so we have to work out some kind of probability 
that this has happened, which must be an increasing function of time.

A CA makes a decision about the maximum amount of time it is willing to 
assume that the details about the entity it is certifying do not change, 
and sets the cert's expiration time accordingly.  The certification fee 
is really a side issue; many CAs charge nothing, directly, as in the 
case of a large organization that runs an internal CA.  Every CA has an 
incentive to put a lower threshold on the trust statistic, because our 
trust of the CA is bound up in how much we trust the certs it issues. 
If it issues 5-year certs, we know the chances that some of them certify 
things that are no longer true is higher than a CA that only issues 
1-year certs.  (Assuming a large enough sample size, similar population 
distributions, etc.)

You are quite free to choose a trust statistic threshold lower than that 
of the CA.  You can decide to trust a blob signed by an "expired" cert.

  parent reply	other threads:[~2009-07-23  1:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-20  3:03 Zone alarm, you have failed me for the first time... and the last. (BLODA news) Dave Korn
2009-07-20 21:42 ` Warren Young
2009-07-22  0:00   ` Dave Korn
2009-07-22  0:23     ` Warren Young
2009-07-22  9:34       ` Dave Korn
2009-07-22 10:03         ` Corinna Vinschen
2009-07-22 10:19           ` Dave Korn
2009-07-22 18:54             ` Morgan Gangwere
2009-07-23  1:26         ` Warren Young [this message]
2009-07-26 17:38 ` Dave Korn
2009-07-26 19:45   ` Morgan Gangwere
2009-07-26 20:50     ` Dave Korn
2009-07-26 22:39       ` Morgan Gangwere

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A67BBEF.3040603@etr-usa.com \
    --to=warren@etr-usa.com \
    --cc=cygwin-talk@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).