Digital Signature Infrastructure Was: Classic PKI vs Thin PKI/S2ML

["Anders Rundgren" <anders.rundgren@xxxxxxxxx>]

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