Re: Invalidity Dates

[Mike Smith <mfsmith@xxxxxxxxxxxxx>]

Protection of the private key is the responsibility of the key owner.  If we build systems that shift that responsibility to someone else, then the value of the system is weakened.

If, as in this "real world" example, we use the credit card model of repudiation and indemnity (the credit card company takes the loss), then the value of PKI to ascertain identity is gone.  If we use a "cash" model instead (i.e., a thief stole $3,000 from your home while on vacation) then ther risks are known and the value of storing cash is accepted.

Retroactive revocation has its place in cryptography, especially with encryption and national security.  Retroactive revocation of identity certs is a bad business model.

When you shift the responsibility for the $3,000 in purchases, to whom do you suggest the responsibility be shifted?  The vendor?  The CA?  In your model, it seems to be the vendor.  The card issuer backs the vendor with a loss reserve and insurance.  The equivalent in your credit card model is again the CA.

So, in systems that allow retroactive revocation of identity certificates should we also then require some sort of aggregate or per item assurance value?  There would be a revenue stream here, so this is not our of line.  Several years ago we were wrestling with the meaning and infrastructure to support these "reliance limits" without the industry finding a place for them.

This is business, so, eventually, all of these repudiable losses are passed back to the customer.  How much should a certificate owner then, be expected to pay for a certificate that includes the cost of these potential losses?

Going back to the example of credit cards, the use of the card has annual charges, per transaction costs, and ongoing revenue (interest accruals and minimums).  these costs reflect the loss reserves, operating costs, etc.

if the certifcate is on a smart card that is issued by a credit card vendor, then I could see the repudiability model that you have used actually working, since the authentication methods would be better than what they already do.

This credit model is vastly different than one in which a family member uses the parents' identity card to create a new will to bring forward many years later when the original card holder is not around to repudiate it, but that is yet another business situation.  In this case, a retroactive revocation (didn't this use to be called a "compromised key list"?) may be of value.

So, there are cases where it does make sense from a busines perspective to allow retroactive revocations and some where the business infrastructure would need to be created to support retroactive revocation.

michael

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