[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on short-lived certificates in "Generalized Certificates"
-----BEGIN PGP SIGNED MESSAGE-----
content-type: text/plain; charset=us-ascii
Towards the end, you bash CRLs; I heartily agree with this. Here's
some additional things to chew on with respect to short-lived
The delay of messages on the net prevents you from having validity
periods less than some threshold (perhaps a second), even if you
demand that everyone ask you on-line for certificates which you
generate on the fly, so you can't avoid some Validity period.
Moreover, not everyone is running NTP, so you can't count on your
clocks to be synchronized that closely.
As an example of what existing protocols do for short-lived
certificates: Kerberos v5 gives an implicit 5-minute "grace period"
for ticket [certificate] lifetime to allow for clock skew and message
I have a fair amount of experience making very-short-lifetime tickets
with automatic renewal work for "real-time" (i.e., not store &
forward) communication within DCE.
The least complicated approach is a variant of "be conservative in
what you send, and liberal in what you accept".
Assume the particular time range in a certificate is [Tstart .. Tend].
For a given transaction, you pick *one* timestamp at the sender
(Tsender), and *one* timestamp at the recipient (Trecipient), where a
transaction is said to have happened.
We also assume a "grace period", Tgrace, during which the recipient
will continue to honor a message.
A sender should refuse to send a message if Tsender is not within
[Tstart .. Tend].
A recipient should refuse to accept a message if Trecipient is not
within [Tstart - Tgrace .. Tend + Tgrace].
For kerberos, Tgrace is an architectural constant equal to 5 minutes,
though there's no particular reason why this would necessarily be the
case (for instance, it could just be another field in the
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----