Anish,
Your message clearly indicates the need to nail down the
semantics of the CRLs more specifically.
As I understand it, a CRL is issued, and the "lastUpdate" field is
set to that issue date. This CRL will be valid until the time noted
in the "nextUpdate" field, at which point a new CRL will be issed to
replace the expired one. During the time in between, it is possible
that one or more certificates may be revoked. Hoewever, that revocation
will not be reflected until the nextUpdate of the CRL.
I certainly hope that the last sentence isn't true. I don't have the RFCs
in front of me, but it was always my assumption that if an emergency
CRL were issued by a CA, the PCA would post it (i.e., make it
available for at least a "pull" type of access) IMMEDIATELY. If there
is any ambiguity in the RFC on this issue, we should fix it post haste.
There has been some discussion as to what the nextUpdate field should
be set to in this case -- should the issuance of an emergency CRL
reset the clock. I believe that most people have agreed that it should
not reset the clock, because that would tend to invalidate most user's
scripts for getting the next update.
So I would recommend that:
1. Revoked certificates should be posted immediately, both to and
by the PCA, and optionally (but encouraged) by the CA.
2. In the event of an emergency (out of cycle) CRL being issued,
the lastUpdate field should be uipdated, but the nextUpdate field
should remain the same. The lastUpdate field will be a "valid as of"
date.
3. The nextUpdate field is provided primarily for synchronization,
so that a user will know if his CRL database is out of whack.
4. User agent software should provide a mechanism whereby
the user can establish how "stale" a CRL is allowed to be, regardless
of the policy established by the CA or PCA as to the maximum interval
between scheduled updates. If a current CRL is not available, the
user agent should either go get the CRL or at least warn the user.
5. The lastUpdate date and time contained in the CRL should be
regarded as DEFINITIVE. This way, we won't get into any arguments
as to what type of clock accuracy and reliability is required. To
whatever extent the user and/or the user's CA have or share
any liability for their digitally signed messges, that liability should
extend up to the lastUpdate time in the next posted CRL. However,
the CA and/or the PCA should be considered negligent if either
fails to post the CRL "promptly," and the user and/or CA suffered
any losses as a result. The definition of what is considered "prompt"
posting should be spelled out in the PCA policy.
Of course PCAs and CA are free to set up whatever schedule they
wish with respect to the maximum interval between CRLs. However,
at least for "commercially" oriented PCAs such as the RSA Commercial
Hierarchy and the COST PCA, I think there would be significant merit
in establishing a maximum interval between updates of 14 days, and an
expected interval of approximately 7 days. As a CA administrator,
I would routinely generate a new (normally empty) CRL every Friday
morning and transmit it to the PCA that day, so that it would be available
to users for downloading on Saturday and Sunday. However, if a
transmission or posting error occurred, the CA administrator and
the user would have another 5 days before the CRL would expire.
I believe that such a policy would provide for routine updates to
the CRL list with sufficient frequency that for most users and most
applications it would not be necessary to go check the up-to-the-minute
status of a certificate, but as we have discussed before I believe that
the user agent software should have the ability to go get the current
CRL on demand.
I would also like to see us begin to develop a standard request format
and response for the positive certificate confirmation that
Sead Muftic and I have discussed. Any volunteers to draft either
an amendment to the RFCs or a new RFC? How about it, Sead, want
to establsih a de facto standard?
Bob Jueneman