[702] in WWW Security List Archive
Re: HP e-commerce protocol
daemon@ATHENA.MIT.EDU (Wenbo Mao)
Tue May 16 16:27:22 1995
From: Wenbo Mao <wenbo@wenbomao.hpl.hp.com>
To: hugo@watson.ibm.com
Date: Tue, 16 May 95 17:18:34 BST
Cc: vishnu%cuckoo.hpl.hp.com@hplb.hpl.hp.com, e-payment@cc.bellcore.com,
owner-www-security@ns2rutgers.edu, www-security@ns2.rutgers.edu,
www-buyinfo@allegra.att.com, ssl-talk@netscape.com
In-Reply-To: <199505161507.IAA19739@ns.netscape.com>; from "hugo@watson.ibm.com" at May 16, 95 10:40 am
Errors-To: owner-www-security@ns2.rutgers.edu
Hugo,
Thanks very much for your reply.
> The issues of trust, availability, legal acceptability, on-line vs off-line,
> etc., are all important parameters regarding CA's.
You are absolutely right!
> I do not want to get here
> into an involved discussion on these issues. The only point that I wanted
> to make is that in order to support a local, on-line CA (e.g., run
> by the bank) you do need to go to the additional complexity of your protocol.
Besides the requirement for on-line banks, which seems quite
realistically available nowadays regardless of whether or not in the
WWW setting, I do not see any additional complexity of the HP
protocol. It's almost as the same as the Kerberos and the
KryptoKnight.
> You can have it with the much simpler iKP (which is conceptually simpler,
> more efficient both computationally and communication-wise, and better
> suited to accomodate existing financial models like credit-cards, debit-cards,
> etc). There is nothing in the iKP design (specifically 3KP, where also
> customers have public keys) to prevent the financial institution from
> running an on-line CA (if you prefer that CA model).
Compared with on-line banks, I really believe that the issue of trust
on the *complex* CA hierachy forms the bottleneck in terms of
complexity, as well as in security and in cost. From this point of
view, 3KP really has a complexity problem (I could be persuaded if I
am convinced that the CA hierachy is not complex and the bank is
qualified as the *only* CA in 3KP). I am not very sure whether the
"conceptually simpler" (of RSA?) means anything to a user or to the
efficiency of the protocol. Please could you clarify this?
By all means, when we propose the HP protocol, we do not mean to
replace iKP. We know different users may like different schemes.
>
> Let me add two remarks on your proposal.
> I believe that the use of the terminology "one-way hashed passwords" is
> misleading since there is nothing different in what you do than a regular
> pair of private key (p), and its corresponding (DH) public-key (g^p).
> In my opinion, you should just call it that way: a pair of private and
> public keys.
>
> Also, the use of the word "password" is confusing. Your scheme requires a
> long, random and secret key as is common in DH systems. You
> say that when talking about the necessary added secret salt. But then it is
> not clear what is the point in calling this a password. (Passwords have the
> connotation of being user-memorizable and not requiring a physical
> device for carrying the key. Your scheme cannot use passwords in any of these
> senses).
>
I won't mind the names. However, I would like to re-emphasize my point
that I have made in the webpage: the HP protocol uses *asymmetrical*,
*non-public* keys: the *asymmetricity* gives the non-repudiation
service, and the *non-publicness* cuts the need of employing complex
and expensive CAs.
>
> PS:
> > Please could you first enlighten me what the "DH certificates" are?
>
> DH certificates are just the binding of a user's name with its DH public
> key, both signed by the CA. (Basically, what you describe in the
> second paragraph of page 12).
>
Many thanks for this.
Cheers,
Wenbo
