Subject: Re: Invalidity Dates

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 16 Dec 1998 10:27:46 -0700

Andreas, I certainly agree that we need to clarify the 
semantics of an entry in a CRL.  For reasons I've described
in my previous response to Al, there may be some merit in 
interpreting the invalidity date as the reporting date and time
of the compromise, for a certificate that is issued later, but
 NOT the date at which it was suspected (or fervently 
hoped) that the compromise took place.

Likewise, if a certificate transitions from "hold" status to revoked, 
the invalidity date should be the date when the suspension was 
requested.

I am just very, very unwilling to allow a subscriber to write checks 
in disappearing ink by claiming well after the fact that his keys were
compromised.  The fact that the subscriber is careless or imprudent
should not disadvantage an innocent relying party, much less the 
CA.

If the subscriber can't afford or control the risk, either by being 
more careful or by buying insurance, they shouldn't accept the 
certificate in the first place, and that is their right.

Bob

>>> Andreas Berger <[email-masked]> 12/16/98 06:14AM >>>
Al Arsenault wrote:
> 
> Bob,
>         The main scenario in which it's useful is when the private key has been
> compromised, particularly when the key is contained on a token such as a
> smart card or a PC card.  Suppose that I go away for a week on vacation.  I
> know that I had my token the day before I left, because I have a signed
> message (that I'm willing to admit to signing) that I sent that particular
> day. When I come back from vacation, I find that token has been stolen in a
> burglary of my home or office. I may or may not be able to pinpoint the
> date/time of the burglary.  (If my alarm monitoring system is sufficiently
> good, I may be able to pinpoint the minute of break-in.  If I have no
> alarm, I probably won't know any more than "sometime between Saturday, 21
> November at 0600 at Sunday, 29 November, at 1930".)  Regardless, since I'm

I think Al makes a good point here. We should try to clarify the
semantics of an entry in a CRL.

Personally, I think that the CRL should contain the time when the
revocation was reported to the CA. Up to this point in time the
infrastructure reports the certificate as valid. The we may add some
uncertainty period, similar to the "week of vacation" described in the
scenario above. During verification, the system can say that the
validity is "questionable" due to the reason given in the CRL along with
the revocation entry.

A similar situation exists with  a certificate on hold. For clarity
resons, if a certificate was ever set on-hold and the moved from
"on-hold" to valid again (the hold has found the card after losing it
for some days), this period should be reflected in the CRL even though
the certificate is not revoked.

What we need is that information about probable compromises is not lost
and is available identically to every user of the overall system.

Andreas
-- 
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 16 Dec 1998 19:07:48 -0800

Bob,

It has been a long time since you jumped in a discussion.

> hoped) that the compromise took place.

I have a different opinion. :-)

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

---

From: Juergen Walter <[email-masked]>
Date: Fri, 18 Dec 1998 16:26:07 +0100

[snip]
> So the question is how should we advertise both dates ?

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

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

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 18 Dec 1998 17:14:14 -0800

Juergen,

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

> 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

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

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 18 Dec 1998 17:14:14 -0800

Juergen,

Regards,

Denis

---

From: Juergen Walter <[email-masked]>
Date: Mon, 21 Dec 1998 13:24:39 +0100

Denis,

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

> 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