[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 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).
[many good points omitted]
>Cheers,
>Frank O'Dwyer
Agreed. It is my attraction to the "short-term-cert, CRL-optional" model
that leads me to consider depreciation as a means of optimizing that model.
In that vein, a placeholder like
cert = { ... Validity: [Interval=<...>][CRL=<...>][Depreciation=<formula>]...}
is simply offered as food for thought. We really do need to focus upon the
fundamental models, examine the interesting "cert-usage" examples that have
been offered in terms of these models, and determine the minimum certificate
structure needed to support reasonable usage.
Aside: Your MITM posting was right on. ID-based not only fails to defeat
MITM, it tells the interloper exactly where to stand. You trade many small
small risks for a single-point-of-failure catastrophe.
___TONY___
Tony Bartoletti LL
SPI Project Leader LL LL
Computer Security Technology Center LL LL LL
Lawrence Livermore National Lab LL LL LL
PO Box 808, L - 303 LL LL LLLLLLLL
Livermore, CA 94551-9900 LL LLLLLLLL
email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL