Re: Invalidity Dates

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Juergen,

Ooops. I should have taken a look again at  the draft before answering !
Everything is there indeed.

> [snip]
> >
> > We should recognize that both dates are in fact interesting. The problem we have is
> > that there is currently a place for one date only.
> >
> > So the question is how should we advertise both dates ?
> >
> > Denis
>
> The OPTIONAL _invalidityDate_ is still in the current PKIX draft and
> more  "Whenever this
>    information [_invalidityDate_  JW] is available, CAs are strongly
> encouraged to share it
>    with CRL users."
> The draft is not strictly restrictive in the usage of the invalidity
> date. There is enough space for interpretations.

In fact the text is rather explicit:

   The invalidity date is a non-critical CRL entry extension that pro-
   vides the date on which it is known or suspected that the private key
   was compromised or that the certificate otherwise became invalid.

In practice the user (system) can "remember" when the key was used safely by himself for
the last time, the invalidity date should be set shortly past that time.


> A more detailed
> specification would lead to the exclusion of some models or to more
> exactly defined dates. While I was following the discussion I recognized
> that even the reason code (e. g. "on hold") has influence on the usage
> of _invalidityDate_.
>
> So, the problem we have is that the certificate path validation software
> relies on it. The answer "valid" or "invalid" is not enough. Otherwise,
> the answer "maybe" is not quite useful, especially in the case that the
> verifier is not human (e. g. server)(please see Russ` mail). In
> contrast, I don`t see any reason that CAs doesn`t share additional
> informations like the following with human verifiers.
>
> "certificate is valid -  the certificate holder repudiates all
> signatures after _invalidityDate_"

I am not sure I understand correctly. In practice you test the validity of a certificate
*for the signing time* against a security policy. The answer is either "Valid", "Invalid"
or "Don't know yet" (i.e. come back later on - this is the "hold on" situation"). The
"don't know yet" situation should be interpreted in the following way: if the requester
cannot afford to come back later on, then the answer is "Invalid".

Regards,

Denis

> That`s real bussiness life. This is similar to a bounced cheque. As a
> consequence, the relying party may suddenly stop all deliveries to the
> certificate holder.
>
> Juergen