[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: three digital signature models ... for x9.59
>from the continuum perspective ... i would consider that we
>are in violent agreement. it may be some of the
>perspective of the details that we differ. Also presenting
>different models/points on the continuum sometimes
>helps with the understanding. I didn't want to preclude
>any other models/points on the continuum ... but just
>present the x9.59 account-based position with a little
Probably. The point I'm trying to make is that it is not
necessary to make any particular assumptions about
how the architecture is used. There may be no 'best'
I would analyse the retail example you give in terms of
transfer of liability. Each communication (or offer thereof)
in effect causes a transfer of responsibility.
The merchant starts by accepting a card from the customer
let us assume that initially the liability rests with the card
issuer since the card has the issuers logo.
The issuer can transfer liability to the merchant in with
respect to a collection of cards by issuing a CRL.
The merchant can then return liability to the issuer by
checking the card against a current CRL and recording
proof to this effect.
The Acquirer can intermediate the process of CRL
distribution, reducing the cost of processing
CRLs, accepting liability for verification in the process.
So if the acquirer cannot support online verification
during the peak Xmas rush it gets silently turned off
and at this point the acquirer is accepting the risk.
In a rational market each party can make whatever decisions
represent the lowest cost in terms of expenditure and
loss. Essentially it becomes an insurance business.
I suspect that most end users will find their certificate
validation needs satisfied best through OCSP like online
verification. The issue is then how a distributed OCSP
infrastructure is supported. I believe that this is where
CRL push/pull becomes relevant, exchanging data between
Minimizing the cost of validation services may involve some
more complex arrangement in which end users subscribe
to revocation notification for a limited subset of their most
frequently used certificates. This is essentially a caching
problem. The starting point is that there is a mixture however
and that each individual solution will involve some balance
of the 3 basic solutions.