Re: Invalidity Dates

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

Mary Ellen, Al, Michael, Juergan, et al,

Sometimes the most innocent or seemingly naive questions ("Mommy, why doesn't the Emperor have any clothes on?") reveal a great deal about common misunderstandings.  In this case, I was pointing out that a notion that initially seems somewhat appealing has very negative consequences to the system as a whole.

With all respect to Al, whom I've known and respected a long time, I sincerely believe that analogies to credit card models and behaviors, especially by those (including myself) who are not expects in the credit card/banking business, are potentially very misleading and dangerous.

In particular, at least within the US (the situation in the rest of the world varies very widely, I understand), consumers have the protection of Reg. E and Reg. Z to shield them from more than $50 of loss due to a stolen credit card, EVEN IF THE CARD-HOLD WAS NEGLIGENT.  (These regulations were adopted as a consumer protection mechanism when the credit card industry was sending out cards without either a request or an acknowledgment process, and then billing customers for charges allegedly made to a card which they had never seen.)  So I could probably post a billboard-sized copy of my credit card in Times Square this New Year's Eve, knowing that Dick Clark's cameras would show it to 100 million people, and still not be liable for more than $50.

Michael Smith, who does work for a bank and whose knowledge of such issues I'm sure exceeds mine greatly, pointed out correctly that the absence of very specific "rules of the road" legislation, the more appropriate model is the cash model.  If you leave $3000 at home and you are robbed, the cash is gone, and you have no recourse other than your insurance company.  If you want better protection, you could of course buy traveler's checks, in which case you will normally pay a premium of around 1-1/2% of the dollar amount, and in any case you will pay a premium amounting to the "float" on those checks until you get around to cashing them.

Comments from others would lead me to revise my previous statements -- I can see at least two limited cases in the case of a digital signature where an invalidity date would be useful. The first would be the case when the subscriber reported a possible loss or compromise and requested a certificate-hold until the possible loss could be more carefully evaluated and confirmed, given the inconvenience and disruption that might be cause by revoking a certificate when no loss had really occurred.  In that case, the date and time of the original reporting should be included in the invalidity date when the CRL is issued that converts the certificate hold into a revocation.

Likewise, if for some reason the subscriber reports a loss at a particular date and time and the CA for some reason cannot or does not issue CRLs immediately but waits until the next scheduled update to release them, then I could imagine some utility in an invalidity date that is confirmed by the CA, since if the relying party really cares in that case he is going to have to hold the transaction in suspense until the next scheduled CRL date in any case.  But in that case the invalidity date is the date of notification, not the date of the claimed compromise.

(Michael makes an additional case regarding a compromised key list for encryption keys which I'd like to think about further, but may have some real utility.  In this particular case the invalidity date isn't attempting to revoke a certificate retroactively, but instead is alerting people who may have sent confidential documents to that user that their security may have been compromised.  That adds security, rather than taking it away. Yet another reason why certificates and keys that are used for both encryption and authentication/signatures should be anathema.)

What I was really strongly opposed to was the notion of a self-serving claim by the subscriber that the key was compromised being deliberately intended to retroactively cast doubt on a previously confirmed transaction.  Instead of providing any particular benefit for the careless subscriber, who would almost certainly continue to bear the burden of proof in that case (so the claim accomplished very little other than advertising the subscriber's carelessness), countenancing any kind of retroactive invalidation is like allowing checks to be written in pencil, rather than ink -- it would seriously weaken the system for everyone, since no one would be able to trust a signature at all.

Thinking about this a little more, I guess I was primarily concerned about the "short-term" use of a signature to validate a transaction that cannot easily be undone or backed out.  If a merchant accepts my signature and ships the goods, only to find out that the subscriber claims that he didn't sign the transaction and the goods have disappeared, in the absence of some kind of a transaction insurance model fundamental fairness dictates that the subscriber, rather than the merchant, bear both the burden of proof and the risk of loss.

In the case of a long-term, non-repudiation type of transaction, the invalidity date notion COULD work, but only if the very last CRL issued (just prior to or just after the certificate expiration date) is checked.  In that case the invalidity date would put the relying party on notice that something might very well be fishy.

Unfortunately, that would make the normal notion of nonrepudiation exceptionally difficult to implement, and I therefore believe that this approach should be explicitly rejected.  Normally, if I want to be able to establish the fact that someone signed a document, I take pains to archive the document along with the entire certificate chain that existed as of that moment, together with the appropriate time stamps, or perhaps I wait to collect the CRLs at a time following the next update cycle, to be sure that I got the most current one.  But it would be a severe imposition on me to have to keep going back to the CA for the entire life of the certificate in order to recheck that a new CRL hadn't been issued with a retroactive invalidity date.  And what if the user were to claim a "recently discovered compromise"  after the certificate had expired that allegedly occurred during the time the certificate was valid?  This concept would simply demolish the entire notion of nonrepudiation, and hence I believe must be rejected.

(BTW, I want to point out that Juergan's summary of when a signature is valid applies to the technical validity and technical nonrepudiation, i.e., conformance to a certain set of technologist-specified rules.  It does NOT mean that the signature is not necessarily legally binding, regardless of whether the signature occurred before, during, or after the validity period.  All that the validity period establishes, and then only under specific legislation (or perhaps some contracts), is that a certain rebuttable presumption may apply.  The fact that the cop says that the radar gun said that you were doing 75 mph doesn't necessarily make it so, but it may very well shift the burden of proof to the you, the defendant, to prove otherwise.  So the fact that the certificate has either expired or been revoked doesn't mean that the signature is ipso facto invalid, it just makes it harder to prove that the signature was legally binding.)

Finally , Al questioned why I claimed that my posting a note claiming a certain invalidity date might actually increase, rather than decrease, my potential liability.  The reason is that if I say nothing about the date of the supposed compromise, but merely revoke the certificate, the burden of proof presumably transfers to the relying party for signatures accepted after the date of the CRL, but remains with me for all times prior to that time, regardless of when the compromise occurred.

However, if I believe (but cannot be absolutely certain) that the loss occurred on November 30th and report that on December 8th, I am by implication saying that I acknowledge as valid all signatures created before November 30th, then I am tightening the noose around my own neck if in fact the covert compromise occurred before that date.  Having reported the loss once, it is going to be quite a bit more difficult to seem credible if and when another embarrassing document comes to light to get the jury to accept an even earlier invalidity date. But if I revoke the certificate and indicate as a reason code a suspected compromise, then all prior signatures may be viewed with a certain amount of suspicion, even though I still have the burden of proof.

Bob


>>> Al Arsenault <aarsenault@spyrus.com> 12/16/98 07:37AM >>>
Bob,

	I have to "sort-of" disagree with your characterization of the invalidity
date extension.

	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
away, I can't know what has been taken, and I probably won't report the
compromise of the key until I return.  It's important to let people know
(after the fact though it may be) that the key was out of my possession
prior to the time I report the crime, since the key could have been used
before I knew it was gone.  This is not, as you claim, "potentially
foolhardy, probably ineffective, and generally dangerous".  Instead, it is
simply an acknowledgement that the world in which we live, and in which our
systems operate, is not perfect, and we'd better be prepared to deal with
the anomalies.

	Now, this certainly introduces some doubt onto the whole notion of
non-repudiation.  I can report on 30 November that my key was compromised
on 22 November, and lo and behold it was used to purchase $3,000 worth of
books and software from on-line services on the 25th.  The merchants
approved those purchases based on the fact that the certificate was not
revoked.  Now, maybe I really made the purchases and now wish to repudiate
them, to try to get the merchandise 'for free'.  Or, maybe the key really
was stolen, and the purchases were made by the person or persons who stole
it, rather than me.  The merchants (and the CA who issued the certificate)
don't know.  Depending on the value of goods in question, and on other
available evidence, they may do one of several things:
	
	- they may waive the charges and absorb the loss, since some level of
fraud is part of the cost of doing business;
	- they may try to take me to court to force me to pay the costs, and let
the problem of identifying the criminal and identifying the items be my
problem;
	- they may suspend the charges until an investigation of where the goods
were shipped, who accepted them, etc. is completed, and then decide
	- some other strategy

	While this does introduce some uncertainty into the system, it is no
different from what happens today in the physical world of credit cards and
similar instruments.  I may lose my credit card, or have it (or the number)
stolen.  I may not know this for some period of time after the event - for
example, the item stolen in the burglary could have been the credit card
left behind, rather than my private key.  I can certainly dispute any item
that shows up on my credit card bill.  I can claim that the physical
signature on the piece of paper in the merchant's possession is not my
signature; the merchant asked for no ID and did a bad job of comparing the
signature on paper to the signature on the back of the card (or the
criminal was a sufficiently-skilled forger to pass the clerk's inspection).
 Based on a number of factors, the credit card issuer may choose to simply
waive a charge and eat the loss; or may issue a charge-back to the merchant
and make the merchant collect or recover; or may reject my claim and try to
make me pay the amount in question.  The fact that a credit card
transaction can be nullified after the fact certainly introduces some risk
into that system, but it is accepted as a necessary part of the system.
Yes, it leads to fraud. (I'm not proud of the fact that I personally know
people who try to repudiate some of their legitimate charges, as a way of
getting themselves a "bargain".  If they do it infrequently enough, and the
amounts in question are small, it often works.)  But the risks are
understood.  The difference with certificates and keys is that the risks
are NOT understood, and there is no generally agreed to partitioning of
risk and liability.  Other than that, it's the same.

	A couple of specific comments:


At 02:03 PM 12/14/98 -0700, Bob Jueneman wrote:
>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.

AWA:  I don't understand this.  As above, I discover on 29 November that
the token containing my private key (which had the PIN/password written on
it) has been stolen.  Why is my liability WORSE if I report it "stolen;
last known good 20 November; anything since then suspect" than if I report
"stolen, effective today, 30 November"?  It may be the same - I may be
liable for actions that occurred using my key, due to my negligence in
protecting my private key, but I don't understand how it can be worse.

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

AWA:  as noted above, I agree with this point, but I think it's a reality
of any system we try to design.  If you don't let the user indicate when
the key was compromised, if it was known or suspected to be prior to the
date of notification, then non-repudiation doesn't mean anything useful.
In fact, it means that you're forcing a user to "admit" to something that
in fact didn't happen, which is in many cases as bad as the opposite.

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

AWA:  again, true, but how is this different from the physical system?  The
"relative permanence of paper" is not so permanent; there are plenty of
opportunities to challenge its validity.  As noted above, I can claim that
the physical signature on the piece of paper is not mine, but a forgery,
and now somebody has to prove that it is or isn't mine.


				Al Arsenault