[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

[http://www.clark.net/pub/cme/html/cert.html]

Towards the end, you bash CRLs; I heartily agree with this.  Here's
some additional things to chew on with respect to short-lived
certificates:

   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
latency.

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
certificate).

                                        - Bill




-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMTIgkVpj/0M1dMJ/AQEtlgP9GylQL5ydwGmFv+72CR2clguXDZE8JeSe
TfTa7zcEyy16ksdMENDYU3TMoj8EOODW6H8XfcpYzmdEWFP63dVg1pSdcM2lzHPL
FNpBv0bZrcF1QFVqqRspJU5+WbX7lZUYePveAZdai4xIY1svVbI8mRezxSTyLeFs
XPBNn3LtXq8=
=Y/B0
-----END PGP SIGNATURE-----
Follow-Ups: