Re: Invalidity Dates

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

Juergan,

We may be getting somewhere.

I believe that your "T2" date (the date which you last claim and/or admit to having validly used your key is rather similar to the (unfortunately deprecated) private key validity period.

As is the case with the private key validity period, after which the user is supposed to have zeroized his private key but might not have, if the user reports a T2 date she is effectively saying: 

"(1) If you haven't already done so, please don't accept any signatures as being mine after date T2. 

(2)  If you have already done so, my apologies, but I am hereby repudiating any signature made after T2 and am prepared to re-sign any valid transactions which you may have received.  

(3)  For transactions signed after T2 which I repudiate and refuse to re-sign, we may have to fight it out in court unless we can come to some agreement, so you'd better not destroy any evidence you may possess that would point to who really signed the transactions. 

(4) For transactions signed after the date (T1) which I reported my key as having been compromised, you'd better have awfully convincing evidence if you hope to make your allegations stick, as I will claim that your reliance on my signature was completely unreasonable."

Bob


>>> Juergen Walter <walter@deh.de> 12/21/98 05:24AM >>>
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