Subject: Re: Invalidity Dates

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 14 Dec 1998 14:03:52 -0700

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 <[email-masked]> 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

[email-masked] 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

---

From: Al Arsenault <[email-masked]>
Date: Wed, 16 Dec 1998 09:37:56 -0500

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:

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

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

>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

---

From: bgmiller <[email-masked]>
Date: Tue, 15 Dec 1998 10:35:51 -0500

The Electronic Funds Transfer Act (described in layman's terms at
http://www.fdic.gov/consumer/consnews/spr98/crook.html) would appear to apply to this
situation.  Depending on the type of card involved (debit, credit, ATM), liability is
limited based on when the theft is reported.  I think it could be successfully argued
that stealing the key is equivalent to stealing the card.  The important dates for
purposes of liability are when it was reported relative to when it was stolen.

It would appear to be in the consumer's best interest to not rely on the CRL as the
mechanism for reporting, since the delay introduced by the CRL issuance (versus a
phone call to the credit card company) potentially increases the liability.

Bobby Miller

Al Arsenault wrote:

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

---

From: Andreas Berger <[email-masked]>
Date: Wed, 16 Dec 1998 14:14:49 +0100

> 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

---

From: Juergen Walter <[email-masked]>
Date: Wed, 16 Dec 1998 17:58:21 +0100

Andreas,

[snip]
> validity is "questionable" due to the reason given in the CRL along with

Do you denote "questionable" in accordance to the granularity of CRLs?
The certificate holder signs a message and forward it to a relying
party. Then the relying party validates immediately the signature.
Unfortunately, there isn`t the next updated CRL available. Hence, the
relying party gets the answer "questionable - please wait until
_nextUpdate_ + X".

Whereas, if there is any time interval between the date when the
revocation was reported to the CA and the date  that the holder was
refered to invalidity date, then the answer is not "questionable". The
answer is twofold: "The revocation was reported _revocationDate_, and
the holder repudiates all signatures after invalidity date."

> the certificate is not revoked.

I agree. The CRL issued next to the date, when the certificate status
has changed from "hold" to "valid", should contain the _removedFromCRL_
_reasonCode_ provided that the CA is publishing delta-CRLs. If the CA
isn`t publishing delta-CRLs, then the entry has disappeared. The relying
party must start his "hunting" through all those CRLs covering the whole
validity period of the certificate.
> and is available identically to every user of the overall system.

The information is not lost, provided that all CRLs are still available.
Would you like to review the definition of CRL entries?

-- 

Juergen