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

[Stephen Kent <kent@xxxxxxx>]

Anders,

>>As far as a relying party is concerned, applying the signature consistent
>>with the certificate associated with the transaction is the basis (though
>>not the whole story) for non-repudiation of the transaction. All of the
>>digital signature laws and guidelines embody this notion, as do all
>>technical standards with which I am familiar.
>
>Of course, they are built on the fundamental principle that the
>client always has the "final" cert and key.  CyberPhone is not.

Yes, this is the assumption, and it is a widely held one.  To change it a
lot of folks will need to be convinced otherwise.  You have a lot of work
ahead :-)!

>>If one has a security failure
>>at the server, it's not the relying party's problem, it is the client's
>>problem.
>>This sort of server design introduces a new component to the
>>system that must be trusted by the client
>
>The real "Client" in a business-to-business situation is the company (and
>their server)
>that have much more problems with their employees and certificate
>distribution than they have
>with unsecure servers.  By having the "person-client" sign a transaction
>as well you are technically on the safe side.   Did you actually read the
>dynamic certs paper?

Yes, and I don't buy all of it's premises.  The companies are the ones on
the hook, as you say, but they also need individual accountability, hence
the need for individual certs.  Nobody has a lot of experience with large
scale deployment of PKIs in these contexts, so a statement about the
relative difficulties of deployment of certs to end users vs. the approach
you propose is premature. Insecure servers are a growing problem for
businesses, so I also challange your second assertion.

>>and creates a higher value target if the server is shared by more than one
>>user.  I'd say that makes this type of approach, in your system or any
>>similar one,
>>potentially a lot less secure than systems in which the signing is
>>performed solely by the
>>client.
>
>You say: "You can't build a secure server".  I say: "Every Internet-bank
>system needs
>the same security level that a CyberPhone intermediary server requires"

Not necessarily.  The Internet banking we see today lacks non-repudiation,
for one thing.

>>While I can't prevent people from making a security implementation
>>tradeoff in favor of systems of this sort, I certainly would not endorse
>>any accommodations to a standard to facilitate system design approaches of
>>this sort, due to the adverse secruity implications.
>
>I would not be so sure about that since there are TONS of advantages to
>gain if you read carefully the around 25 pages of information on the site.

What I read was probably less than the full 25 pages, given that I printed
it and it didn't look that thick.  However, my tolerance for market
literature as a means of technical communication is limited ...

>And then there is the cost issue.  This is CHEAP, mass-produced stuff.
>
>Imagine a PKI that 2005 has 1 billion users (projected mobile phone
>deployment)
>where each user pays $25 to have his/hers CyberID.  That is
>
>    $25,000,000,000 / Year !!!!
>
>VeriSign, Thawte, are you listening?
>
>It is absolutely worth HUGE sums to create secure servers and even
>"adjust" laws on
>digital signatures.  Maybe BBN could be interested in the server business? :-)

Well, CyberTrust, the organization for which I am the CTO, is in the CA
business and we understand how hard it is to make CA systems secure,
despite the relatively restricted interfaces they exhibit.  I'm not saying
that one can't develop and manage such secure servers, but it is very hard.

Finally, your proposal is clearly focused on one particular deployment
model, which may or may not be realized.  There are others, based on more
computationally capable, mobile, personal devices, e.g., PDAs.  As I said
before, you should pursue any implementation approach you think is
fruitful, but don't ask this standards body to tailor parts of its work to
facilitate your (decidely nont mainstream) approach to using certs.

Steve