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

[Al Arsenault <aarsenault@xxxxxxxxxx>]

Juergen,

At 01:21 PM 12/16/98 +0100, Juergen Walter wrote:
><snip>
>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.
>

AWA:  this is almost correct.  You do have to deal with those cases at the
fringes of certificate validity.  For example, suppose that a certificate
expires at 120000Z (Noon, GMT) on 16 December 1998.  That certificate's key
is used to sign a message timestamped 110000Z on 16 December 1998.  Because
of network  delivery problems, the recipient doesn't get the message until
110000Z on 18 December 1998 (two days later).  If you use TIME OF
VERIFICATION, you reject this message; if you use TIME OF SIGNATURE, you
accept it.  Mostly, I've seen TIME OF SIGNATURE used in this case, although
if you're willing to accept unnecessary rejections (or possibly the
acceptance of messages sent minutes/hours actually sent after cert
expiration), you can probably use either one.

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

AWA:  Okay, I think I agree with this, given the standard disclaimers about
needing to have a reliable time source.  I keep having to remind potential
users that a signature key which is compromised can be used to sign
information with any arbitrary date on it, so unless you've got a reliable
time stamp or notary service, you don't have non-repudiation.

>
>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?
>

AWA:  the only way I know of is to put that information in the CP and/or
CPS.  But then you're back to the previously-unsolved problem of how the
relying party really understands what's in any CP or CPS.

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

AWA:  I don't think that the revocationDate should change.  That indicates
the time at which a CA formally declared a certificate to be revoked.  That
shouldn't change.  It's possible that an invalidityDate would change, based
on further investigation, but I'd personally oppose that, too.  Once a CRL
entry is created, it shouldn't change.

<snip>

					Al Arsenault