RE: draft-ietf-pkix-warranty-ext-01

[lynn.wheeler@xxxxxxxxxxxxx]

somewhat aside, note that most financial risk management has moved past
stale, static data ... even on a per transaction basis .... since the
exploits/attacks on such infrastructures started using aggregation. the
old-style "signing limit" checks attempted to manage risk & liability on a
per transaction basis .... but quickly found that they were extremely
vulnerable to aggregation risks. That is one of the forces leading to
online operation in the financial industry (as opposed to an offline
operation with trivial per transaction limits and no support for online
management of aggregation).

A similar model might be various kinds of automobile insurance with per
transaction limits .... however any aggregation risks tend to happen over a
long enough period that processing tends to occur in "relative" real time
(and they have been able to manage aggregation risks ... if nothing else by
canceling the policy).

The problem for the insurance industry is given the alternatives between an
offline paradigm and an online paradigm .... where the offline paradigm
with basically per transaction limits .... and an online paradigm that can
handle both per transaction and aggregation limits .... the offline
paradigm leaves them wide-open to aggregation attacks/risks.  The problem
for a certificate is that the policy & representation is static per
transaction risk/limit ... and any migration to an offline paradigm with
both support for per transaction as well as aggregation risk/limits
obsoletes the requirement for the certificate.

Somewhat analogous is the hardware token (as a credential) ... when used
purely in an offline mode, there have been  all sorts of aggregation risk.
Typically the remedial action is to limit the per transaction exposure to a
very trivial dollar value .... as a mechanism for attempting to bound the
aggregation risk/exposure.

The problem for an indusrance industry risk managing in establishing policy
rates .... isn't the per transaction limit risk .... but what is the worst
case risk scenario for an offline paradigm with regard to transaction
aggregation. The certificate doesn't contain a dynamic transaction count
and/or any sort of dynamic value aggregation .... and/or even idea of how
many times it has been used ... which is the unknown exposure facing the
risk manager having to establish policy rates aka when they look at the
risk exposure for establishing insurance rates .... it is the total risk
exposure. A single per event bound doesn't tell them anything unless they
can also put a reasonable bound on the maximum number of such events ....
to arrive at the total risk.