Re: Invalidity Dates

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Bob,

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

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

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


> 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