MasterCard and SET (heresay)

[Michael Richardson <mcr@achilles.net>]

At 10:55 AM 3/1/96 -0500, you wrote:
>I see what you mean here, but in my opinion, Mastercard shouldn't be
>issuing certificates AT ALL. Why? Because any customer charge is going

  My knowledge of the Mastercard protocol is limited to what I read and heard
at ISOC NDSS.
  I know the papers are supposed to available online soon: I think Clifford
Neuman 
should know when/where. 

  This is what I understand:
        - MasterCard signs the bank's key. 
        - MasterCard signs the mechant's key.
        - Customer has MasterCard's key in their software as the root CA.
        - Customer talks to mechant. I'm not clear if the Merchant's key is used
        to provide any security, ala SSL. 
        - Customer encrypts their MasterCard number with the *BANK'S* public
key. This
        is sent to the merchant. The Merchant attaches their public key,
signs, encrypts
        this info to the Bank. 
        - Merchant sends all this to the Bank. Bank uses MasterCard CA key
to verify
        key provided by Merchant, decrypts all of this. Checks out account
using the            enclosed MasterCard number.
        - The Bank then provides the merchant with a signed certificate (the
        equilavent to the authorization number you get by phone now).
  Notes: -the merchant never sees the MasterCard number, only the bank does.
        -as far as I could see, the customer never had a private key of any
kind. That
        would be a future enhancement.

  There was another diagram that showed MasterCard being before the Bank in
the chain.
I can't pull that out of memory right now.

---

• Prev by Date: bootstrap of key-centric binding of person to key
• Next by Date: can CRL's and short-life certs coexist?
• Prev by thread: Re: bootstrap of key-centric binding of person to key
• Next by thread: short-life certs vs. CRLs
• Index(es):
  • Main
  • Thread