[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 
more-likely-to-be-true-in-the-first-place certificates, 
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?

Cheers,
Frank O'Dwyer
References: