[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

epoch certs





CRLs are a source of liabilities for issuers and users, which depend
on several factors and include the issuer, subscribers and users in
binary, tertiary and m-ary relationships. In SPKI, the issuer can
also incur in delegation liabilities and fourth-party links must be
included even in a simple binary model of assumptions, liabilities
and duties. The discussion below uses the name issuer to mean either
the CA in X.509 or the issuer in SPKI. The word trust is used to
denote "estimated reliance regarding unsupervised acts". 

By modelling some of the issuer's m-ary trust relationships [1], one
is suggested that a good issuer strategy would be to offer optional
safer one-year certificates -- based on (for example) 30-day
certificates, renewable 11 times, what could be called epoch certs.

This would not aim to solve the very low private-key lifetime
(perhaps as low as four weeks) that an average subscriber might have,
but to decrease issuer and subscriber exposure without any need for
CRL reliance after 30 days. The renewed epoch certs would still
automatically reference the *same* subscriber public-key **if and
only if** that key has not being notified as revoked in a CRL -- or,
otherwise, the subscriber must require that a new key be referenced
in a new epoch cert (possible price tag there).

For some applications and environments, the 30-day time limit can be
reduced for some applications. This is similar to the same result
known from Kerberos, that you increase security as you decrease the
ticket's time-window, but with a twist. As provided by the auth-logic
in SPKI (in X.509 by the critical bits) one can subdivide the 30-day
"real-state" into not only time-oriented but name-oriented or
authorization-oriented slots, allowing (for example, and as chosen by
the subscriber):

- reliance tapering: a certificate scope can decrease as a function
of time,

- no CRLs within an initial period: a certificate might need a
negative CRL confirmation after 15 days if used for anything but
simple queries, but not before, in the initial period,

- firm warranty: a certificate might have a guaranteed validity of
seven days for purchases up to $ amount,

- etc.

Allowing for a step-wise (can be quasi-continuous if desired) 
decreased cert scope as a function of time is very appropriate,
because the user's estimated reliance on the certificate's data (aka
trust) must also decrease with time [2]. This would also allow an
user to rely on a cert which has an initial issuing date of almost
one year but with an equivalent confidence as if the cert would have
been issued that month, or that week. Since epoch certs may allow for
reliance tapering (see above), an one year old cert may still span
the whole trust spectrum defined by the subscriber as a function of
time in *each window* of automatic reissuance.

Thus, an epoch cert can be seen as a saw-tooth wave, for user and
subscriber reliance as a function of time.

Allowing for automatic validation epochs in relationship to users,
within a broader certification contract between an issuer and a
subscriber, is also useful to strongly reflect the subscriber's
security policy *independently* of the issuer's actions (to some
extent) and to allow for a simpler issuer-subscriber relationship.
After all, it's the same cert which is just periodically reissued by
the issuer and within the same issuer-subscriber contract. It has
similar benefits as a newspaper subscription service, for buyer and
seller. 

This is positive control, whereas the periodic issuing of a CRL by
the issuer is negative control -- which may fail by lack of action.
Positive control, OTOH, does not fail by lack of action.

As a side benefit, epoch certs can reduce an issuer's liability
window by orders of magnitude since exposure mounts exponentially in
time. 

(Applied to X.509, this may furher decrease CA liabilities [3], but
this is proposed here neither in detriment of the subscriber nor of
the user -- but as a clear win-win situation.)


Cheers,

Ed


References:

[1] http://www.mcg.org.br/trustdef.txt

[2]
http://mcg.org.br/cgi-bin/lwg-mcg/MCG-TALK/archives/mcg/date/article-334.html

[3]
http://mcg.org.br/cgi-bin/lwg-mcg/MCG-TALK/archives/mcg/date/article-430.html

______________________________________________________________________
Dr.rer.nat. E. Gerck                     egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
    --- Meta-Certificate Group member, http://www.mcg.org.br ---