Re: when can an entry not appear on a CRL?

[Juergen Walter <walter@xxxxxx>]

Hi Mez,
Hi Al,

I think, that your question is strongly related to the concept of
validity of signatures. It remains undone in the current PKIX draft. The
certificate path validation there specified covers essentially two cases
(see Remark below). I want to refer to these cases as short-term
signatures and long-term signatures, respectively.(I will not consider
path validation for simplification.)

A short-term signature is valid if and only if
(i) the signature is correct, and
(ii) the corresponding certificate is AT THE TIME OF VERIFICATION within
its validity period, and
(iii) the CURRENT CRL doesn´t contain an entry for this certificate.

This concept of validity doesn`t fit for those communities where
non-repudiation is needed. Hence, it makes sense to remove the expired
certificates from the CRL. After the certificate is expired all
corresponding signatures are invalid, whenever the signature was
generated.

Secondly, a long-term signature is valid if and only if
 (i) the signature is correct, and
(ii) the corresponding certificate is AT THE TIME OF SIGNATURE
GENERATION within its
validity period, and
(iii) this certificate was not revoked AT THE TIME OF SIGNATURE
GENERATION.

The second concept may give non-repudiation services. All signatures
that have been produced before the corresponding certificate was revoked
or expired are still valid. Hence, the relying party needs the CRL entry
beyond the _notAfter_ date. I think the minimum requirements to CRL
management are (i) the CRL issued next to the revocation date of the
certificate must contain the adequate CRL entry, and (ii) the relying
party must have access either to this CRL or to this CRL entry on any
on-demand CRL.

Provided that these requirements are fulfilled, a relying party may
"hunt" through the issued CRLs. Whether the relying party has success or
has not, it depends on the application used. I think, that Mez wanted to
make the point, that this "hunting" isn`t  simple at all. Especially, if
the CA provider supports only short-time signatures, then the result of
the "hunting" through CRLs may be the following. The signature is valid.
But, the PKI may be designed only for short-time signatures. How does
the relying party know that?

Firstly, I don`t want to advocate such "short-term" PKI designs. But, it
may happen in the real world. Secondly, in general, one can not expect,
that the certificate validation is simple, but the discussion about
invalidity dates has shown that the _revocationDate_ may be not a
constant. Provided that the _revocationDate_ may vary, the signature
validation becomes a hard job. Is there someone interested in a concept
of signature validation, which may be formulated at the requirement
level? I would prefer the requirement level because I don`t see a
consensus about the underlying bussiness models.

Does the non-repudiation bit come into question? If the non-repudiation
bit of the keyUsage field of the certificate is seated, then this
implies that the on-demand/current CRL will contain all revoked
certificates including the expired certificates. And, in addition, that
the CRL information is still available. I would argue that this
implication is well.

Remark. The PKIX Part 1 draft contains a certification path validation
chapter (chapter 6). There the variable T refers to time. The lower
limit "T = date of signature generation" corresponds to the long-term
signatures, whereas  the upper limit "T = date of signature
verification" corresponds to the short-term signatures. I will not
consider T earlier than date of signature. Nevertheless, it is allowed
that T is an element of the full intervall between the two mentioned
extremal points.

Juergen 

Mary_Ellen_Zurko@iris.com wrote:
> 
> And while I'm airing my confusions about revocation, I have another.
> Section 3.3 states:
> " An entry may be removed from
>    the CRL after appearing on one regularly scheduled CRL issued beyond
>    the revoked certificate's validity period."
> This seems to be there to ensure that a revoked cert actually appears on
> some regularly scheduled CRL, which seems sensible. The text is silent
> on what to do for an on-demand CRL. It seems that no entries that are on
> the "current" scheduled CRL should be removed from any on-demand
> CRLs, as that would mean applications who picked up the on-demand
> CRL but not the regularly scheduled one would miss the event. Does
> that seem sensible? Does it cover the motivation of that statement?
>      Mez

--