Some thoughts on high-assurance certificates

Ed Reed ereed at novell.com
Tue Nov 1 13:44:28 EST 2005


Peter - 

In the absence of a legal framework for defining, limiting and
allocating liability, there's going to be nothing much better than
reputation-based assurance for certificates, I'm afraid.

The issues are systemic, and broad.

They begin with the registration problem you cite.  The problem you
describe derives from trying to use a credit-card liability limit
oriented business process to support financial institution international
letter of credit transactions.  Won't happen.  Can't happen.

When insurers have looked at what they need in order to satisfy
themselves that their liability for potential loss has been adequately
limited, they've focused on a few areas:

1) is the liability being distributed sufficiently that each bearer
can, indeed, meet their duties should losses be incurred?
2) is the likely hood of loss increased once the first lost has
occurred?  In other words, do the backers face the prospect of a
catastrophic cascade of losses, or is the likelyhood of loss #2
unrelated to the prospect of loss #1?
3) are the parties in the system competent and able to perform their
duties, and is that demonstrable or simply a matter of faith?

The sort of high assurance certificates business I've investigated in
the past has involved the need to support potential losses across the
system in the $600,000 Million range.  Beyond the capacity for any one
insurer, and so requiring more than just "good faith and judgment" by
one backer.

There is a technical component to the solution that requires something
more than "well, I think so" confidence in the duties you ask the
parties in the system to perform.  Lacking scientific, analytical
support for claims that keys are protected, that their use is as
intended, and that relying parties have documentary evidence of the
claims being made and liabilities being accepted (or not), you fail both
#1 and #3, above.

The ability to stop a loss from cascading is crucial - Phishing is one
thing, or 419 scams that prey on individuals, but breakdowns in trust
that span an entire supply chain or an industry is something else
entirely.

One approach that's been proposed has been to focus on the minimal
liability each player must accept, and to make sure they have concrete,
demonstrable means to manage their risk.  For instance, if an
intermediary CA needs only to be able to guarantee two things - not to
issue different certificates with the same identifier, and to protect
the signer's private keys - they may be able to do that in a fashion
that can be warranted by insurers.

Interestingly enough, if you follow that approach, the whole PKI
business turns into providing non-repudiable certificates of insurance
or warranty.  Insurance folks already have ways and means of calculating
risk and pricing insurance and warranties.  The certificate, signed by
an insured CA, simply represents the insurance coverage provided for
breach of the claims made in the certificate being signed.  That the
CA's certificate is signed means the claims in the certificate are
warranted by the signer - an insurance company, for instance.

The strength of the non-repudiation claims, and the breadth of claims
that are warranted, are going to be based in the technology protections
provided against fraudulent misrepresentation, and the processes
(minimal as possible) associated with them.  That includes high quality
crypto, high assurance operating systems, and high integrity business
practices.  Each are measurable, comparable, 

Is this person an employee of this company?  Dunno, who's paying their
workman's comp (here's the insurance company certificate saying they're
covered).  If no one is paying, that's an indication.  If someone stops
paying, that's another indication (they let the certificate expire, in
conjunction with the insurance coverage).

Getting PKI baked into the every day representations people routinely
manage seems desirable and necessary to me.  The pricing model that has
precluded that in the past (you need a separate PKi certificate for each
INSURANCE policy?) is finally melting away.  We may be ready to watch
the maturation of the industry.

Ed



>>> On Mon, Oct 31, 2005 at  8:38 am, in message
<E1EWZru-0004S9-00 at medusa01.cs.auckland.ac.nz>, Peter Gutmann
<pgut001 at cs.auckland.ac.nz> wrote: 
> A number of CAs have started offering high- assurance certificates in
an
> attempt to... well, probably to make more money from them, given that
the
> bottom has pretty much fallen out of the market when you can get a
standard
> certificate for as little as $9.95.  The problem with these
certificates is
> that, apart from the fact that the distinction is meaningless to
users (see
> work by HCI people in this area), they also don't fit the standard CA

> business
> processes.  CAs employ people whose job role, and job expertise, lie
in
> shifting as much product as possible as quickly as possible (as has
already
> been demonstrated in the race to the bottom for supplying standard
> certificates), not in enforcing PKI theology on their clients.
> 
> There are only a very small number of people who understand the
theology
> behind certificates sufficiently to be able to explain the motivation
behind
> the various steps in the process of issuing them, and none of them
are going
> to be employed in doing certificate checking for CAs.  Instead, the
task 
> will
> be managed by, and performed by, the same people who spam everything
in the 
> US
> that has a pulse with pre- approved credit card applications, loans,
and
> similar items.
> 
> Here's a real- world example of this process in action.  A user
approached a
> large public CA for a high- assurance certificate and specifically
requested
> that his identity be checked thoroughly via his hard- to- forge paper
documents.
> The CA did the usual standard- assurance checking (whois lookup,
email to the
> whois contact address, caller ID check on the calling number, all
easily
> spoofed), and then announced that the user had been pre- approved for
the high-
> assurance certificate, *before* the user had supplied his
authenticating
> documents.  Made perfect sense, they'd done the equivalent of running
a 
> credit
> check before pre- approving a credit card or loan or whatever. Their
proactive
> service and rapid attendance to the customer's needs put them ahead
of the
> competition...
> 
> ... except that this isn't something like a standard credit- check
business.
> The user tried explaining this to the CA employees doing the
checking, but
> they just didn't understand what the problem was.  They'd done
everything
> right and provided outstanding service to the user hadn't they?
> 
> And therein lies the problem.  The companies providing the
certificates are 
> in
> the business of customer service, not of running FBI- style special
background
> investigations that provide a high degree of assurance but cost $50K
each 
> and
> take six months to complete.  The same race to the bottom that's
given us
> unencrypted banking site logons and $9.95 certificates is also going
to hit
> "high- assurance" certificates, with companies improving customer
service and
> cutting customer costs by eliminating the (to them and to the
customer)
> pointless steps that only result in extra overhead and costs.  How
long 
> before
> users can get $9.95 pre- approved high- assurance certificates, and
the race
> starts all over again?
> 
> Peter.
> 
>
---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
majordomo at metzdowd.com


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list