[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Certificate depreciation & 'fuzzy' verification models (SPKI)
> The idea of, shall we say, certificate depreciation, introduced below by
> Frank O'Dwyer is indeed fascinating. If generalized, it could serve to
> significantly reduce overhead in network traffic, especially in the short-
> term cert model.
> I envision some way of codifying, either in the certificate or in the
> certifying agent's policy, a depreciation formula that can be resolved
> by the relying party at key-usage time to a value in the range [0,1].
> This value would represent a multiplier affecting the CA's acceptance
> of liability regarding the key's misuse (effectively shifting liability
> back in the direction of the relying party.)
I think this is an interesting idea too (not surprisingly)
but I'm not sure that it needs to be standardised (and still
less sure that it needs to be done by SPKI, which is
supposed to be simple).
However I'd like to point out that the liability need
not be assumed by the CA. The scenario I have in mind
is point of sale: a physical shop (remember those? :-).
It's easy to imagine a network partition isolating a
physical shop in such a way that it couldn't do an
online CRL/cert fetch for some customers wishing
to part with some money. Bandwidth is not the problem
here; imperfect connectivity is. To the shop,
the risk model is the risk of fraud versus the risk
of missing the business. Given some kind of reasonably
recent credential, and a low-fraud environment, the
shop might take the business at its own risk, and this
is really no concern of the CA other than it might want
to explicitly _disclaim_ such liability. After all, at
the moment it's the shop's problem if takes a
counterfeit note (at least it is in this country).
The relevance to SPKI is really that the definition
of 'counterfeit' better not be so rigidly defined
around validity periods etc., that building fuzzier
systems on top is impossible. Concepts such as
fraud, trust, need to be deferred to (or overridable
by) the application, and not cast in stone by the
PKI. Certificates are means and not ends, and different
people will be faced with (and willing to accept) different
risks, even for the same application.
As far as 'depreciation' goes, another kind
of application I can see is where you have a "lazy CA",
i.e. the certified statement is costly to make and
therefore not made very often, and concerns some
assertion whose truth is likely to change
with increasing probability over time. (I don't
know if any applications fit this model, but it is
plausible that some will.) The verifier's faith in
such a statement could be a function of how long
ago the statement was made, the verifier's estimate
that the certificate was true when it was created,
and the verifier's estimate of the probability
(or frequency) of change in such a certificate's truth.
Here the 'depreciation' optimisation works in favour of the
CA, who doesn't have to bear the cost of making a
certificate quite so often, and against the verifier, who
bears more risk in working with somewhat stale data. Maybe
the verifier would have to pay the CA more to either
create certificates more often, reducing the verifier's
risk, or for the CA to invest more effort in making
which also reduces the verifier's risk. This would seem
to suggest a 'fuzzy' verification model, rather than the
usually envisaged boolean stuff, but again, this
is perhaps not appropriate for SPKI but is something
that might be built on top of SPKI?