Re: Invalidity Dates

[Juergen Walter <walter@xxxxxx>]

Denis,

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

This is the lower limit. The upper limit is the date, when the
revocation request was reported to the CA, in my opinion, but I am aware
that the generally recognized upper limit is the _revocationDate_.

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

I agree with you, that "Don`t know yet" is quite easier to understand.
Like a yellow traffic light (see Bob`s mail).

I apologize I was not clear. The following example may help. The
certificate holder sends a revocation request at T1 to the CA and
reports ´I have lost my smart card and used it last at T2.´ Plainly,
T2<T1. The CA issues a CRL at _ThisUpdate_ > T1 with following setting:
1. revocationDate = T1 (or, close to)
2. invalidityDate = T2
3. reasonCode = keyCompromise.
(Besides, there arises additional problems, if T1 is not close to the
revocationDate, when the CRL entry was processed.)

The well-recognized (?)  handling is different:
After the revocation request the CA issues CRL 1 with reasonCode =
onHold. After dispute solution the CA issues CRL 2, say with reasonCode
= keyCompromise and an invalidityDate which the CA warrants for. I think
that dispute solution may take time. A court may be involved. As I know
German courts, their flow-rate is few. So, the relying party may wait
for the sentence in front of a yellow traffic light for years. And all
the time the certificate is "onHold" until it expires. Some CA may
change its status from "onHold" to "keyCompromise" after XX days by
policy, but the ultimate revocationDate may still be not available.
Therefore, I dislike the use of "onHold" reason code, provided that is
only uncertain, WHEN the certificate is revoked, besides there is no
doubt, that it HAS TO be revoked.

Nevertheless, both of the mentioned scenarios are compliant to the
current PKIX draft. Hence, certificate path validation depends on
policy. The reason is twofold. Firstly, the current PKIX draft specifies
time intervals.  Secondly, the current PKIX draft remains space for
interpretation of the lower and upper limit of these time intervals.   
-- 

Juergen