On Wed, 2011-02-23 at 08:05 +0100, Stefan Santesson wrote:
> Yes, that all sound logical. However on a practical ground that is
> quite hard to code into a crypto API. There you need more distinct
> rules and predictable outcome.
I second that. Theoretically, each RP would decide, according to its own
arbitrary policy, whether a given CRL is fresh enough. But the rules for
appropriate freshness depend upon the context and are likely to be
CA-specific. Revocation is mostly a kind of damage containment: a way to
"cancel" an existing certificate, even though the signature on the
certificate is cryptographically verifiable, in order to cope with an
unfortunate occurrence, e.g. a key compromise. The revocation
information freshness is a measure of the time-wise extent of the issue:
by accepting a week-old CRL, the RP effectively accepts the risk that it
could be fooled into using a public key which has been compromised
during the last week.
How much freshness is needed ? It really depends on the procedures
deployed by the CA to detect the revocation-implying occurrences, and
how fast it can publish revocation information. Those procedures are
normally described in the Certification Policy Statement of the CA, and
supposedly are compatible with the CPS of the CA's CA, and so on.
Ultimately, this leads to the trust anchor's CPS; however, the TA CPS is
not necessarily precise about applicable freshness for all CA which it
has directly or indirectly issued.
One point of PKI (maybe _the_ point of PKI) is to be able to validate
links between public keys and identities, for an arbitrary large set of
identities and public keys, using a small, fixed set of a priori known
information (the trust anchors). We want to be able to validate
certificates issued by intermediate CA about which we had no prior
knowledge. We cannot have CA-specific knowledge for all possible CA.
Hence, the policy which a RP will use to decide CRL freshness must feed
on whatever CA-specific information it can get hold of, and the only
validated sources it can get, in all generality, are the CA certificate
and the CRL itself (and the CRL issuer certificate, if distinct from the
CA). Whatever CPS say in human language, the validation process is,
ultimately, executed by a computer, which needs Turing-compatible rules.
Using the nextUpdate field as an end-of-validity date is not incorrect.
This is certainly allowed by RFC 5280; if the freshness-decision is a
matter of local policy, that local policy can certainly be: "use
nextUpdate as an end-of-validity date". RFC 5280 even hints at that
usage, in the 6.3.3 section ("CRL Processing"): it is said that the
"local CRL cache" should be updated with a "current CRL" if the
nextUpdate field of the most recent CRL is in the past (RFC 5280 does
not tell what should be done if such an update fails). Moreover, using
the nextUpdate as end-of-validity is not a bad policy, as policies go:
basically, it is the policy known as: "issuing CA knows best". Since
appropriate freshness is CA-specific, it makes sense to follow the rules
used by the CA. Ideally, the CA would publish the CRL end-of-validity
date, which should be at some date after the nextUpdate (there should be
no date without a valid CRL at all): the nextUpdate is a lower bound for
the CRL end-of-validity. If more extensive information is not available,
then the best that can be done is to use the nextUpdate as an
approximation of the end-of-validity.
The point, here, is that whatever entity implements the certificate
validation process needs information, which must be:
1. processable by a computer;
2. CA-specific, for CA which the RP might not have been aware of
beforehand.
As I see it, given the current state of standard certificate and CRL
extensions, the nextUpdate field is the only information source that can
be used for that. This does not prevent other freshness policies from
being also correct in the RFC 5280 sense, and possibly appropriate
(although the widespread policy known as "meh, no need to check, it is
probably not revoked anyway" kind of stretches my notion of "appropriate
freshness check"). But the "nextUpdate as end-of-validity" policy is a
good policy, or, at least, as good as a generic policy can get in that
matter.
> To standardize on such extension may however be the least evil thing
> to do.
As I explain above, such an extension is a way for the CA to make a
statement about what freshness measure is appropriate for the procedures
that it applies to decide about the revocation status. It is a good
thing (as long as the CA does not botch it by publishing an
end-of-validity date which is _before_ the nextUpdate).
"Standardize" is an important word. In many usages of validation, we not
only want to have a validation process which yields a trustworthy
answer; we also want it to yield the same trustworthy answer than for
other people. For instance, in the context of a signed contract, I want
my system to accept the contract as signed only if a judge, applying
validation on the same signature, would also declare it as valid and
binding. Right now, this entails using nextUpdate as an end-of-validity
date because, whether you like it or not, that's what everybody does.
--Thomas Pornin