Re: Invalidity Dates

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

David, and Mary Ellen,

For what it's worth, the invalidity date David refers to is in my 
opinion one of those feel-good kinds of options that have a 
well-defined syntax, fuzzily defined semantics, and no 
discernible or predictable consequence or justification.

It would be one thing if the date referred to a time certain when 
the binding between the public key and the various attributes 
asserted in the certificate became null and void -- perhaps because
the subject no longer is associated with a particular organization,
someone got married and changed her name (sometimes well after the 
wedding, viz Hillary Rodham Clinton), or some other distinguished 
event occurred.

But to allow the subject/user to even attempt to claim a retroactive 
invalidation of previous signatures seems potentially foolhardy,  
probably ineffective, and generally dangerous:

Foolhardy, because by implication the use of the invalidity date 
indicates the latest date that the key had _not_ been
compromised, so if that date is not known precisely, but merely 
suspected, the user potentially has a greater liability than if she
had said nothing at all other than revoking the certificate.

Ineffective, because the user either did or did not in fact sign 
the document, (although the fact of the signature may be 
more or less difficult to prove) and attempting to retroactively 
cast suspicion on signed documents previously accepted as 
valid turns any notion of nonrepudiation on its head.

Dangerous, because it gives the user a false sense of security 
that he or she can readily undo whatever damage might be 
caused by carelessness, and it may give the relying party the 
sense that unlike the relative permanence of paper, a digitally 
signed document is just written on the wind.

I'm not blaming David -- that would be shooting the messenger.
But it's a Bad Thing, IMHO. :-(

Bob

>>> David Solo <david.solo@citicorp.com> 12/14/98 12:43PM >>>
MEZ,

I think you may be mixing two dates.  There is a revocation date in the
standard CRL entry.  This is the date assigned by the CA as logically
having added the entry and so may not predate the last CRL.  The
invalidity date is a CRL entry extension which is supplied by the user
(probably) and reflects the suspected date of compromise/loss/etc. 
There is no constraint on the invalidity date (it can definitely precede
the last CRL).

Dave

Mary_Ellen_Zurko@iris.com wrote:
> 
> Thanks Steve and Dan. Is anyone willing to speak up on behalf
> of not letting a user indicate an invalidity date previous to the
> current CRL? Because the spec seems to be indicating that
> that should be the disallowed, but I haven't heard any strong
> reason for restricting the user to that. Which makes me worried
> that I'm missing something.
>      Mez