[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
xmass
Well, Merry Xmass to all...
Even if this is for PKIX only... We can all say Merry Xmass....
aaron
Aaron S. Carmichael
VP Information Technology
TimeCertain, LLC.
202-244-3243 (voice)
202-244-5694 (fax)
aaron@timecertain.com
http://www.timecertain.com
----------------------------------------
This message is for the named persons use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission. If
you receive this message in error, please immediately delete it and all
copies of it from your system, destroy any hard copies of it and notify the
sender. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient. Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is
authorized to state them to be the views of any such entity.
-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren@telia.com]
Sent: Saturday, December 16, 2000 3:27 AM
To: PKIX-List; Stephen Kent
Subject: Digital Signature Infrastructure Was: Classic PKI vs Thin
PKI/S2ML
Steve,
> The financial community has a set of concerns that are entirely
> valid, and are NOT the whole of PKI.
maybe not, but their basic model for domain-security, and general trust
model does IMO apply to
practically the entire O2O/B2B-field. 95% or more is my educated guess.
Here is an extremely condensed version of my (unfortunately refused) RSA2001
paper on the subject.
Just to take a very simple example from the health-care sector (to get away
from the proprietary stigma
of the financial sector). An outside service provider like a catering
company that is getting orders
from "a PKI-enabled healthcare community":
Using Classical PKI, the biggest problem (except who is going to issue
certificates, potentially containing role
data) with such signatures are:
- Authority. Who has the right to perform a certain signature? And how do
you express it?
- Trace ability. How do you save signatures (i.e.
decisions/orders/prescriptions)?
- Relying party. What to interpret and trust?
Using Thin PKI the solution gets very simple although [maybe] incompatible
with current signature laws:
A. An organization representative signs using an individual cert+key. The
cert does not even have to say
that the representative is employed by the organization or has some
particular function.
B. The signed transaction is sent to an
"organization-authority-and-signing-server" that
B.1 Checks that the cert is not revoked and coming from a trusted issuer
B.2 Checks that the individual is working for the organization and is
AUTHORIZED
to perform the signature operation
B.3 Saves the transaction as a receipt versus the representative
B.4 Removes the representative's signature. Sheltering individuals/employees
is a requirement.
Contact information is another thing which should be supplied in the
transaction as attributes
B.5 Adds an "organizational signature" (=stamp) to the unsigned transaction
B.6 Saves the re-signed transaction as a receipt versus the "outside" /
receiver
C. Sends the re-signed transaction to the end-destination
The Stamp (organization certificate) can preferably be issued by a TTP and
be published on the
organization's home-page for easy reference. Can PKI be simpler? You may
think that this
trust model is very primitive as there is no [external] granularity, but
this is by design. Simplicity
has an advantage: It can be communicated and implemented. Organization
certificates then become
the true digital replacements to company letterheads. For the rare
instances you [externally] need
tighter bindings, you can always dual-sign transactions, add TSP etc. The
bottom
line is that the basic infrastructure is still intact!
Using the above approach the "information tunnel" between organizations is
minimized and
scalability is optimized. And with backtracking and archiving is built-in.
This is actually the way banks operate. I.e. their clients are only [fully]
known and trusted locally,
while the banks as organizations have their own interoperable and trusted
domain .
And in similarity to banks this allows the clients security solutions
develop in
a different pace (and uncoordinated among organizations), versus the
inter-organization
security solutions.
Using TTPs and ASPs, Thin PKI scales downwards as well. Any organization
will be able to use digital signatures with ease. As they already can with
Internet-banks.
Note1: I have yet to see a single classical PKI program having acceptable
(and particularly
DEPLOYABLE) solutions to archiving, authority control, and backtracking.
Note2: I did not invent this model. The banks did (in principal). 200-300
years ago...
Using PKI, secure servers, LDAP and transaction databases, it gets really
cool!
Anders Rundgren
co-founder
X-OBI
+46 70 - 627 74 37
BEGIN:VCARD
VERSION:2.1
N:Carmichael;Aaron
FN:Aaron S. Carmichael (E-mail)
ORG:TimeCertain
TITLE:VP Information Technology
TEL;WORK;VOICE:(202) 244-3243
TEL;HOME;VOICE:(202) 244-5125
TEL;CELL;VOICE:(202) 255-2502
TEL;WORK;FAX:(202) 244-5694
ADR;WORK:;;2840 Chesapeake St. NW;Washington;D.C.;20008-1044;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:2840 Chesapeake St. NW=0D=0AWashington, D.C. 20008-1044=0D=0AUnited States o=
f America
REV:20000802T043915Z
END:VCARD