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