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 03:42:10 GMT

Tom St Denis <tomstdenis@iahu.ca> writes:
> In reality PKI should be done with a web-of-trust model through
> auditors. That is say I trust Paul Rubin's public key. Say Paul has
> shopped at "booksrus.com". Paul likes the business so he signs their
> public key [like a vote of confidence]. Now I trust Paul to make a
> sound judgement so I too trust booksrus.com to not screw me.

two basic reasons for the SSL server domain name certificate:

1) is the server i'm talking to really the server I think it is?
(because of perceived trust issues with the domain name infrastucture)

2) trusted public key distribution for that server

since the authoritative agency for domain names is the domain name
infrastructure, even the CA/PKIs that issue SSL domain name
certificates have to check with the domain name infrastructure to see
if somebody requesting a domain name certificate is associated with
that domain name.

because of the original perceived trust issues with the domain name
infrastructure, there are a number of proposal to improve the trust of
the domain name infrastructure. One of them ... somewhat from the
CA/PKI industry is that public keys be registered with the domain name
... eliminating some vulnerabilities that result in being able to
obtain a valid SSL domain name certificate by thinks like a domain
name "take-over" attack on the domain name infrastructure.

However,

1) improving the integrity of the domain name infrastructure improves
the perceived trust in the domain name infrastructure ... mitigating
the perceived requirement for SSL domain name certificates

2) registering public keys with the domain name infrastructure (as
part of improving the perceived trust in the domain name
infrastructure for use by the CA/PKI industry) enables the domain name
infrastructure to distribute trusted public keys ... further
eliminating the requirment for SSL domain name certificates

3) all the upfront certificate related chatter in the SSL protocol can
be eliminated if public key distribution was piggybacked with
IP-address distribution (by the domain name infrastructure).

Fixing the domain name infrastructure trust issues for use by the
CA/PKI SSL domain name industry ... also can pretty much eliminate the
need for SSL domain name certificates.

As part of the original SSL domain name stuff for what is now called
electronic commerce ... we actually looked at pursuing certificates
that were related to the quality of the merchant .... as opposed to
whether it was really the specific merchant (aka "good housekeeping
seal of approval" or BBB type certificates).

It turned out that it wasn't possible to come up with a business model
that met anything. Two of the issues were:

1) the consumers are the relying-parties .... there is essentially no
determination before hand on how many times a merchant might use the
certificate with relying-parties ... as a result it was difficult to
estimate potential liability to the issuing party based on the number
of times that a certificate would be relied upon.

2) the reputation certificate tended to be a very small niche market.
electronic commerce transactions are highly skewed ... the majority of
transactions are done with either 1) well-known merchants and/or 2)
merchants that the person has dealt with before. The need for
reputattion certificates tended to be very small percentage that
involved transactions with a merchant that the consumer had no prior
contact and had no basis for knowing anything about.

3) the emerging ubiquitous, online world tended towards commercial
reputation similar to BBB, call up and get the current, real-time,
dynamic information (not stale, static information that could be
several years old). If it was important enough for a person to check
on reputation, given equal choice between real-time and several year
old, stale, static information ... a person would prefer some sort of
real-time, online check.

So stale, static SSL domain name certificates are totally subsummed by
online, dynamic, trusted domain name infrastructure that is able to
distribute public keys in addition to ip-addresses.

Requirements for reputation referral is a small niche market since it
it tends to be solely first time transactions with totally unknown
merchant (no previous direct and/or indirect knowledge of the
merchant). This is significantly better served by timely, online
information than it is by some stale, static certificate.

You don't particularly mind seeing a BBB sticker in store window (a
form of stale, static credential) ... it may or may not bring some
comfort (thus our coining the term "merchant confort certificate").
However, if it tends to be any issue of importance and significant
value there is a tendency to want to call up the BBB and possibly
other agencies to get real-time information. 

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

Relevant Pages

  • Re: SSL certificates
    ... The public key is, ... > the server certificate itself is created. ... integrity problems with the domain name infrastructure). ... note however there is supposedly a "chain of trust" ... ...
    (sci.crypt)
  • Re: How do I store secrets?
    ... One of the aspects of digital signature verification that is too often ... since encrypted with the PRIVATE key for which you have, and TRUST, ... If the certificate is issued by a KNOWN and TRUSTED CA, ... Then you create a server ...
    (microsoft.public.dotnet.security)
  • Re: New Method for Authenticated Public Key Exchange without Digital Certificates
    ... you are referring to any situation where there might be some trust ... resorting again to the merged security taxonomy and glossary ... as definitions specifically within the context of a Public Key, ... Certificate, Certification Authority environment. ...
    (sci.crypt)
  • Re: verisign security,lol
    ... "Igor Tandetnik" wrote: ... In order to provide this trust, ... > certificate, and keeps the company's vital stats on file. ... Dont believe average user cares what ca is used anyways. ...
    (microsoft.public.vc.atl)
  • Re: What is a Certificate?
    ... > signature on the certificate was generated by its own key, ... basically there you have a trusted repository of public keys. ... CA public keys are also typically in a trusted repository of public ...
    (comp.security.misc)