Re: A $25,000,000,000 PKI Was:Spec. on QC-low-fat & QC-heavy-bio

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

Is this a battle between two Swedes only? Come on guys!

Stefan, my original spec on the low-fat/heavy-bio, did never got a reaction.

<snip>

>The thing that interests me is who have the exclusive right to use the key,
>and that this right is protected. 

Agreed, except that I don't see why such a right should/must be exclusive.

>>2) I think that the thin client solution has more with sw distribution which
>>is a true bottleneck recognized by most of the IT-industry 
>
>You are solving yesterdays problems. 
>
>The problem with exporting client software is a general problem which a
>whole industry is working on. Java is one step along the line and we will
>see more and better solutions. In a world where bandwidth are increasing we
>will se more of "download what you need, when you need it" type of
>approaches. 

You are almost right.  Security-critical sw developed by several different 
companies requires signed code that you must trust.  This complicates
things considerably.  My approach does probably (not 100% sure here since
CyberPhone is currently only a glossy broschyre) NOT require download
of security-code from independent sources as it is a "Generic Security Platform".

>This does not require the private keys to be used within a server.

This is definitely another question and I would say (while taking on my
marketing hat) that CyberPhone is a "thin PKI" (new sexy term born
this very second) solution that could solve even harder problems than the
"thin client" did.

> But I'll never like as a general tradeoff that private keys MUST be operated by
>the server. 

They don't.  Only in the case they belong to a server-based resource like
a SET account, OBI purchaser

<snip>
>>So I do really believe there is room for a "third wave"

>Yes there are, but is surely won't be private key servers.

>However, a layered structure with a few long lived general certificates
>(QC) that support a large number of specialized short lived certificates,
>may very well be part of that "third wave".

Hum, another IETF-Swede said in another mailing-list that the need for a static
indentity (like an SSN) in a cert is not at all required to maintain a long-lasting
certificate-based relationship in a convenient way.  I asked him if for a
high-level spec. on how he thought that that would work.  He never did it.  I
feel the same thing for your suggestion.  How?  Please...

If you take my "Dynamic Certificates" paper and try to cast that
into conventional PKI you will end up in misery.  Misery = twice the cost,
twice the PITA. and a big chance to be bypassed by other solutions.

Anders