Subject: RE: Spec. on QC-low-fat & QC-heavy-bio

From: Anders Rundgren <[email-masked]>
Date: Tue, 6 Apr 1999 17:59:16 +0200

Steve,
>I visit your web site and reviewed the marketing white papers there.

Thank you for taking some of your precious time to read this!
I hope that you do not only regard this as "marketing" material although
the language is of that kind.  By design so to say :-)

>One feature of the system you propose, but that has not been mentioned before,
>is that this proposal calls for users to cede control of certificates to a
>server, which acts on their behalf.  The user employs one (local) cert to
>authenticate himself to this server, and to direct it to act as his
>intermediary.

You got it!  This is a good description of CyberPhone when you use SET, OBI etc.

>This raises serious secruity issues, especially wrt non-repudiation.

Well, it does raise security issues, but (hopefully) not unsolvable such.

Actually there are commercial products like the GlobSet ServerWallet that
builds on the same basic principle.  Similar solutions have also been launched by
Brokat and BankGate.  The difference is that CyberPhone generalizes this
principle so that it becomes a "Universal Client PKI Platform" that though
requires some special hardware as well.  

But let's get back to the security issues wrt non-repudiation!

Client - IntermediaryServer(IS) - RP

When you use a "virtual" certificate (intermediary server with your terminology)
the non-repudiation issue for IS (that has the wanted resource) versus the RP is as today.

But then we have the relation between the client and the IS
that may or may not require a client-signed transaction.
This is a matter of trust between the client and the intermediary server.

I.e. you COULD require the client to sign a transaction and then
the Intermediary Server would save the signed transaction (in case
of disputes with the client), strip of the client's signature and add its
own signature (SET, OBI, or something). 

Regards
Anders

---

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Apr 1999 15:38:18 -0400

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. 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, 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.  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.

Steve