the other problem with the CA approach is what is the CA certifying. Are they
purely certifying the name of the company producing software applications ... or
are they certifying every application that each software company produces. If I
have to decide every company that I'm willing to accept software from ... then
I've gone to a per company process that can be done with online authority and
I'm maintaining a list of per company-based accpetable software sources. I don't
need & am not using a hiearchical CA-based trust infrastructure (possibly other
than in a purely contrived manner).
For the CA-based trust infrastructure to work for this scenerio ... the CA needs
to be asserting the trust/quality/integrity of applications produced by each
software company (so that I only need to record CA-level trust decisions) ...
once I need to record vendor-level trust decisions then I've truncated any trust
hierachy (embodied by a CA which then becomes superfulous/redundant).
"Bill la Forge" <[EMAIL PROTECTED]> on 01/11/2000 01:19:34 PM
To: Lynn Wheeler/CA/FDMS/FDC@FDC, "bram" <[EMAIL PROTECTED]>
cc: "Peter Cassidy" <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Killer PKI Applications
> Once the user decides not to trust the CA as to whether programs from
individual
> vendors are to be accepted ... then the user creates their own table of
> acceptable public keys (not relying on the CA/PKI trust infrastructure).
Part of the problem with taking the CA approach is in dealing with multiple
roots.
We've drilled down on this problem a few times and having a signed list of
acceptable
keys is a solution that keeps coming back up.
Frankly, I think this is an area where XML is going to play quite well. And I'm
delighted
with the latest draft on XML-based digital signatures:
http://www.w3.org/TR/xmldsig-core/
Bill la Forge, CTO
JXML, Inc.
