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

[Stefan Santesson <stefan@xxxxxxxxxxx>]

I totally agree with Steve here.

The approach to let a server manage and use your private keys to sign your
signatures seams to be bad design for the sake of saving a little
processing power in the client. It seams even more bad taken into
consideration that computational power and memory capacity in clients
become cheaper every day.

But creating and maintaining a general super secure multi-private-key
center will not be cheaper and cheaper every day. 

To help viewing and comparing this system design with other systems, I view
the private-key-server as being a part of the client system. This simply
because this server handles the clients keys and will fall under the
clients responsibility.

So the question is if it is wise in some cases to split a normal client
into a sub-client-server system, which from the relying party's viewpoint
still acts like one client.

Using this angle to view this kind of system design makes it quite clear
that this design is simply a matter of local policy which by no means
should affect general PKI standards and technical profiles. 

/Stefan


At 05:47 PM 4/6/99 -0400, Stephen Kent wrote:
>--- Message on the SEIS mailing list (list@seis.nc-forum.com)
>
>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
>
>
>----------------- SEIS mailing list (list@seis.nc-forum.com)
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: info@seis.se
>
-------------------------------------------------------------------
Stefan Santesson                <stefan@accurata.se>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------