Re: Proposal for a new PKI model (At least I hope it's new)

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 09/05/03 

Date: Fri, 05 Sep 2003 15:45:04 GMT

George Ou <533george_ou234@netzero234.com> writes:
> 1. How is it stale if the CRLs can now be real-time because the work
> load is distributed and delegated under my proposal. Under this
> proposal, it is online and it is dynamic. Before you start any
> transaction, you first check with the root CA if the Domain cert
> you're looking for or any other cert has been revoked. Then you check
> with the domain's CA if a certain user or host has been revoked.
>
> 2. What is your solution in place of PKI and certificates? You can
> be online all you want, but if you're meeting someone you've never met
> before, you have to have some kind of trusted 3rd party to help you
> decide if you trust the other party. Are you suggesting that you
> contact the trusted 3rd party each and every time? Don't you think
> they're start dinging you per transaction that way? What the hell
> difference does it make? I'm proposing a delegated PKI and
> distributed real-time CRL model.
>
> 3. Again, you keep comparing certificates to "sailing orders". You
> keep trivializing the significance PKI and PKC. Don't you understand
> that "sailing orders" weren't tamper proof nor where their signatures
> tamper proof nor were they encrypted? You can't possibly make that
> comparison. Under a new PKI model, you would call HQ to see if any
> "sailing orders" were revoked since you last checked. If the answer
> is no, you know you're good to go. You sound like a broken record in
> your opposition to digital certificates and you keep repeating the
> word dynamic. How in the world is that any different from real-time
> CRL checks.
>
> Anyways, you seem to be on a vendetta against digital certificates. I
> don't buy the "sailing orders" comparison, because that is ludicrous.

I'm on a vendetta against trying to use something designed for purely
offline operation in an online world .... it is like trying to fit a
round peg into a square hole ... it is bad business practice. It is
something like trying to use a 2.5 ton flat bed truck for hauling
concrete ... a flat bed truck was not designed to haul concrete. I can
imagine that if all somebody understood was flatbead trucks, they
would try and design some rube golberg contraption to use it for
hauling concrete ... say, wooden sides lined with multiple layers of
plastic tarp ... and hopefully it doesn't set up before arriving at
the destination.

So the first thing that low-value offline certificates came face to
face with was that if the information was no longer valid ... what do
you do? Well the pre-70s, credit card model was you maintain an
accurate list of all the relying parties ... and once a month you
would mail out a paper booklet of revoked credit card numbers to every
merchant. So that is exactly what several of the original low-value
offline certificate infrastructures came up with .... they would
absolutely know all possible relying parties ... and mail then a
electronic list of revoked certificates and they called it a revoked
certificate list and the infrastructure was called a PKI.

So the next scenario from the early '90s ... was what if you were
dealing with higher value situations ... the solution was to send out
the CRL more frequently or send out the CRL proportional to the value
involved in the infrastructure. Identified problems

1) contractual relationship is between the certification authority
and the public key owner. there is no contractual relationship
between the relying party and the certification authority

2) the value of the operation is known by the relying party, not the
certification authority ahead of time, so unless you were dealing with
an absolutely homogeneous value infrastructure ... the value of the
transaction and therefor the timeliness needed for the CRL interval is
established by the relying party ... not by the certification
authority.

3) the CRL needs to be sent out by the certification authority, but
the identification of the relying parties is selected by the public
key owner, not the certification authority.

So the worst case scenario from the mid-90s ... was that all
certification authorities had to send out CRLs once every 30 seconds
to all possible relying parties (numbered in the millions), and there
had to be contractual relationship established between all possible
relying parties and all possible certification authorities prior to
use of certificates.

So, a partial kludge is the current Federal GSA PKI ... where all
possible relying parties have contracts signed with GSA ... and all
possible certification authorities have a contract with the GSA where
they issue certificates as agents of the GSA (creating the legal
appearance that relying parties have legal contract with certification
authorities). This doesn't address the mailing out of CRLs to all
possible relying parties every 30 seconds.

The CRL frequency proportional to value, was established as a relying
party determined value not a CA determined value. Furthermore, large
number of hypothetical PKI models was such that the CA would never
know all possible relying parties. In the credit card model, the
merchants were the relying parties ... and had to be preregistered
with the credit card infrastructure ... so it was knowable who to mail
the credit card revokation booklets to. In the SSL domain name
certificates, all possible clients in the world are the relying
parties ... which is pretty unknowable (although the spammers are
trying). The suggestion was that for SSL domain name certificate
infrastrucutre to graduate from "certificate manufactoring" to PKI,
the CRLs would have to be mailed to all possible internet users in the
world at least once a day (some of the large scale spammers are trying
to accomplish). Then there is an issue of being able to reliably
determine if all possible relying parties (all internet users in the
world) actually received and processed their daily CRL list.

So the credit card industry in the '70s were interested in doing
trusted transactions and moved to a paradigm of online transaction
verification. The certification authority industry is interested in
selling certificates designed for an offline paradigm; as a result
rather than moving to an online paradigm for an online environment;
the certification authority industry tries to force fit a flat-bed
truck into use for hauling concrete (my uncle somewhat did the
reverse, he bought up some number of concrete hauling trucks at
auction that were without the rotating tank ... and put fifth wheels
on them and used them as semi-tractors for pulling trailers).

So some of the scenarios are relying-party-only certificates for
purely closed environments ... where the relying party is also the
certification issuing authority. Then the certificates are static,
stale copies of information on file with the certification authority.
However since the relying party is also the certification authority,
the relying party then has access to the timely, dynamic, online
information. But if the relying party has access to the timely,
dynamic, online information, then the existing of the static, stale
relying-party-only certificates are redundant and superfluous.

Anothor scenario that could be considered to grow out of this period
was OCSP. Now back to the credit card industry, if the point of the
industry was trusted transaction, there is no vested interest in how
you get trusted transactions. If you have a purely offline
environment, you can go with a form of static, stale credentials
designed for the offline world. If you have an online environment, you
can design online transactions designed for an online world. The issue
in the PKI and certification authority industry is the focus is on
selling (static, stale) certificates. So if you have an online
environment, but a solution for an offline world ... rather than
converting to a paradigm for an onlne world; an attempt is made to
cobble together lots of online features wrapped around a solution
designed for offline environment.

One of the problems with the rube golberg cobbling is that if you
really make the online features wrapped around the offline
infrastructure too sophisticated, then it becomes trivially apparent
to everybody that the offline, static, stale certificate piece is
redundant and superfluous (as in the relying-party-only certificate
scenario). So the online "fixes" to the offline solution, have to just
be marginally sufficient, but not sufficient enough to make it grossly
apparent to everybody that the static, stale offline certificates are
redundant and superfluous.

At some point in transition from the offline paradigm to the online
paradigm, it becomes terribly obvious that static, stale certificates
designed for a offline environment and redundant and superfluous when
everything is timely and dynamic. This transition is much simpler when
the infrastructure is primarily interested in the execution of trusted
transactions rather than in the sale of trusted credentials.

The assertion was that it was immediately obvious in the payment card
industry (both credit and debit) to use magstripe for transition to
trusted, dynamic, timely, online transations ... being able to
eliminate the kludges that they were wrapping around an offline
paradigm.

Such a transition is much more difficult for some parts of the public
key industry, because their vested interest is not in the use of
public key for trusted transactions ... but in the use of public key
attributes as marketing support for selling their certificates. There
is lots of interest in making transition to dynamic, timely, modern,
online environment with trusted transactions .... but if the vested
interest is selling stale, static certificates designed for solving a
problem in the offline world ... that transition becomes much more
difficult because it requires recognizing that the static, stale
certificates are redundant and superfluous. 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ 
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Relevant Pages

  • Re: X.509 and ssh
    ... Similar improvements are realized if certificates ... TTP/CAs were looking at making the identification useful for relying ... signatures and attached digital certificates to financial transactins ... would modernize financial transactions. ...
    (comp.security.ssh)
  • Re: New Method for Authenticated Public Key Exchange without Digital Certificates
    ... require a contract with every other financial institution. ... with an online environment ... ... model for the existing SSL domain name server certificates to directly ... to an online authentication oriented operation ... ...
    (sci.crypt)
  • Re: 1911 Census: Specific address search question.
    ... Even if you order one online, it still costs seven ruddy quid! ... The government already wastes billions on failed or failing IT ... certificates and a fairly large staff bill. ... Surely you meant to say GREAT-grandmother's eggs! ...
    (soc.genealogy.britain)
  • RE: CLR and AIA publishing properties unclear
    ... enterprise issuing CA and a web server hosting CRL and AIA for external ... include path in certificates. ... I do however publish CRL and deltas, CRL path should be ... should be included in certificates and delta CRL path in CRL's. ...
    (microsoft.public.windows.server.general)
  • Re: X.509 and ssh
    ... digital certificates are just electronic analogs of their physical world counterparts, meeting the same business requirements ... ... police officers at that time were already in transition to much higher value online transactions. ... Any information in the drivers license, ...
    (comp.security.ssh)