Re: [IETF-PKIX] Multiple Certificates

["Brian M. Thomas" <bt0008@xxxxxxxxxxxxxxx>]

> In addition to the four operational disadvantages listed in a prior
> message, I thought up the following actual attack this morning
> in the shower :-)

Those are the best kind.


> Consider two credit cards with different policies: the Green card
> is free and offers no benefits; the Gold card costs .1% per transaction
> but offers replacement insurance up to $1000 on goods purchased.
>
> It is in the user's interest to use the Green card for every transaction,
> unless the goods received turn out to be defective, in which case the
> user might try to substitute the Gold card on the purchase transaction.
>
> The credit card company has the opposite incentive, to switch all
> transactions to the Gold card.  And if the merchant pays a different
> fee or gets a different commission from the two cards, the merchant
> has an incentive to swap certificates too.
>
> Certificate substitution would be prevented by using different keys,
> by binding the cert to the transaction, or both.  In the case of
> credit cards, any reasonable commerce protocol would bind the cert
> into the transaction.  But the attack applies whenever there
> are certificates with a shared key and conflicting incentives;
> the incentives could be information-based rather than monetary.
> Few application protocols (and according to the chair of the S/MIME
> working group, *no* email protocols) include any means of preventing
> certificate substitution, so key sharing is a vulnerability.
>
> Am I missing something?
>

I don't think you're missing anything, really.  In my yet-incipient
concepts of electronic transactions, it seems absolutely essential that
all terms of an agreement be explicit, incorporated by reference, or
legally inferrable from the transaction itself.  The key itself offers
no such evidence; only the certificates that confer the authorization
to spend the money in the accounts.  Therefore the transaction does not
say merely "I will give you some money" but "I authorize payment by this
means and under these terms ..." specifying the payment mechanisms, account
numbers, etc.  The other party would only accept the contract if these were
all spelled out as part of the contract.  So I would agree with the notion
that the authorizing certificate needs to be a part of any signed contract,
irrespective of your position on multiple certs per key.

brian

Brian Thomas, CISSP - Distributed Systems Architect  bt0008@sbc.com
Southwestern Bell                                    bthomas@primary.net
One Bell Center,  Room 34G3                          Tel: 314 235 3141
St. Louis, MO 63101                                  Fax: 314 235 0162