Is cryptography where security took the wrong branch?

Anne & Lynn Wheeler lynn at garlic.com
Tue Sep 9 21:24:46 EDT 2003


At 05:07 PM 9/9/2003 -0700, Joseph Ashwood wrote:
>Now that the waters have been muddied (by several of us). My point was that
>3D-Secure (and SET and whatever else comes along) covers a different
>position in the system than SSL does (or can). As such they do have a
>purpose, even though they may be horribly bloated and nearly non-functional.
>Visa at least seems to be supporting the 3D-Secure concept (they should,
>they developed it), and looks like anyone can grab the spec from

... while SET, 3d-secure, etc may have been designed for all sorts of 
reasons .... I guess my point was that w/o a adequately specified threat 
model .... for the primary vulnerabilities ... there turned out to be 
little effective difference between the use of SET and the use of SSL 
(regardless of what the designers may have original thot). Also technology 
adoption/uptake typically requires the transition to be less painful than 
the problem it is fixing. SSL was already in the market space ... so SET 
had to demonstrate that it was incrementally better (not effectively the 
"same as" for the major vulnerabilities) in order to justify its 
significantly more difficult and costly deployment.

The other issue that has been the bane of major PKI/certificate deployments 
(and I've repeatedly raised the issue) ... is that certificate-based 
operations typically have the key owner paying for the certificate .... 
while the major benefit accrues to the relying-party ... the the 
key/certificate owner. In the case of SET ... there was the consumer payng 
for their certificate ....  and the merchant not only receiving a better 
than MOTO-discount (making interchange transactions with the "SET" flag 
turned on ... somewhat suspecious) ... but also the possibility that the 
transaction would be treated as "authenticated" and potentially shifting 
the burden of proof in a dispute from the merchant to the consumer. There 
was the possibility that not only would the consumer be footing the bill 
(buying their own certificate) for the sole benefit of reducing what the 
merchant paid on the transaction .... but there was also speculation that 
it might also be used to make it more difficult for the consumer (there was 
sporadic mention of shifting the burden of proof from the merchant to the 
consumer in a dispute).

At least in the SSL domain name certificate, the merchant pays because of 
some belief that it will help attracted (internet) consumers/business.

In the SET/PKI scenario ... it was nearly impossible to figure out a value 
proposition for the consumer .... where the consumer is footing the 
(certificate) bill ... that turns out to be totally for the benefit of the 
merchant.  It wasn't so much that "cryptography took a wrong branch" ... 
but many of the PKI business models don't conform to any sane business 
operation .... with the entity (key-owner) footing the bill not getting any 
benefit ... and all the benefit going to the relying-party.

The other generalized PKI issue (again not just SET) ... is "any" contract 
tends to be between the CA?PKI and the consumer .... aka the entity in a 
contract that purchases something. Frequently is no contractual 
relationship between the relying-parties .... who effectively the sole 
reason that the certificates exist ... and the CA/PKI. As mentioned 
elsewhere, the GSA PKI has attempted to somewhat address this by having all 
relying-parties sign contracts with the GSA .... and all the CA/PKI 
certificate issuing entities have a contract with the GSA where they are 
effectively issuing certificates on behalf of the GSA. Those set of 
contracts then preovide the legal foundation for some generic reason for 
relying-parties to do anything with certificates (since the relying-parties 
and the CA/PKI agency, aka GSA ... have contractual relationship and 
therefor a legal reason to deal with certificates). The slightly different 
SET scenario ... the associations just told the merchants that they would 
be charged less per transaction ... aka instead of MOTO (mail order, 
telephone order) discount, they could get something closer to card present 
discount.


--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
  


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list