Maybe It's Snake Oil All the Way Down

Anne & Lynn Wheeler lynn at garlic.com
Fri Jun 6 12:34:41 PDT 2003


At 04:42 PM 6/4/2003 -0700, Eric Rescorla wrote:
>Nonsense. One can simply cache the certificate, exactly as
>one does with SSH. In fact, Mozilla at least does exactly
>this if you tell it to. The reason that this is uncommon
>is because the environments where HTTPS is used
>are generally spontaneous and therefore certificate caching
>is less useful.


there are actually two scenarios .... one is to pre-cache it (so that its 
transmission never actually has to happen) and the other is to compress it 
to zero bytes. detailed discussion of certificate pre-caching and 
certificate zero byte compression:
http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2

the typical use for HTTPS for e-commerce is to hide the account number on 
its way to the financial institution. for the most part the merchant is 
primarily interested in the response from the consumer's financial 
institution on whether or not the merchant gets paid. If it weren't for the 
associated business processes, the merchant could get by with never knowing 
anything at all about the consumer (the merchant just passes the account 
number on ... and gets back what they are really interested in .... the 
notification from the bank that they will get paid).

So a HTTPS type solution is that the consumer pre-caches their bank's 
certificate (when they establish a bank account). .... and they transmit 
the account number "hidden" using the bank's public key. This happens to 
pass thru the merchants processing .... but for purposes of the 
authorization, the merchant never really has to see it. The protocol would 
require minor issues of replay attacks .... and be able to be done in a 
single round trip .... w/o all the SSL protocol chatter. Actually, is isn't 
so much pre-caching their bank's certificate .... as loading their bank's 
public key into a table .... analogous to the way CA public keys are 
loading into tables (aka using out-of-band processing .... the convention 
that they may be self-signed and encoded in a certificate format is an 
anomoly of available software and in no way implies a PKI). The primary 
purpose of HTTPS hasn't been to have a secure channel with the merchant, 
the primary purpose of the HTTPS is to try and hide the consumer's account 
number as it makes its way to the consumer's financial institution.

The other solution is the X9.59 standard (preserve the integrity of the 
financial infrastructure for all electronic retail payments, not just 
internet, not just POS, not just credit, ALL; credit, debit, stored value, 
etc) that creates authenticated transactions and account numbers that can 
only be used in authenticated transaction. The consumer's public key is 
registered in their bank account (out of band process, again no PKI). X9.59 
transactions are signed and transmitted. Since the account number can only 
be used in authenticated transactions .... it changes from needing 
encryption to hide the value as part of a shared-secret paradigm to purely 
a paradigm that supports integrity and authentication. As in the above, 
scenario, the merchant passes the value thru on its way to the consumer's 
financial institution; and is focused on getting the approved/disapproved 
answer back about whether they will be paid. As in the bank HTTPS scenario 
where the bank's pubilc key is pre-cached at the consumer, the pre-caching 
of the consumer's public key is pre-cached at the bank .... involves no PKI 
business processes (although their may be some similarities that the 
transport of the public key involves encoding in a certificate defined 
format).  misc. x9.59 refs:
http://www.garlic.com/~lynn/index.html#x959

Both pre-caching solutions are between the business entities that are 
directly involved; the consumer and the consumer's financial institution 
based on having an established business relationship.

The invention of PKI was primarily to address the issue of an event between 
two parties that had no prior business relationship and possibly weren't 
going to have any future business relationship and that they would conclude 
their business relying on some mutual trust in the integrity of a 3rd party 
w/o actually having to resort to an online environment. The e-commerce 
scenario is that there is real-time, online transaction with the trusted 
3rd party (the consumer's financial institution) involving prior business 
relationship. This negates the basic original assumptions about the 
environment that PKIs are targeted at addressing.
--
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 cypherpunks-legacy mailing list