Re: Invalidity Dates

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

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 <aberger@darmstadt.gmd.de> 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