Cash or charge? (Was: Re: Invalidity Dates)

[Al Arsenault <aarsenault@xxxxxxxxxx>]

At 02:13 PM 12/16/98 -0500, Paul Koning wrote:
>>>>>> "Bob" == Bob Jueneman <BJUENEMAN@novell.com> writes:
>
> Bob> ...Michael Smith, who does work for a bank and whose knowledge of
> Bob> such issues I'm sure exceeds mine greatly, pointed out correctly
> Bob> that the absence of very specific "rules of the road"
> Bob> legislation, the more appropriate model is the cash model.  If
> Bob> you leave $3000 at home and you are robbed, the cash is gone,
> Bob> and you have no recourse other than your insurance company. 
>
>The one issue I can see with this is that a certificate, unlike a
>bundle of dollar bills, has no well-defined or even bounded value.  If 
>I don't adequately protect my certificate, my exposure is not limited
>in any way I can see.  With cash, the amount of exposure is exactly
>equal to the amount I left lying around, and with credit cards, if the 
>regulations limiting it to $50 didn't exist, would still be limited to 
>the credit limit.
>
>	paul

The other problem with this "cash model" is the ways in which I can lose
it.  With cash, as far as I know, I can:  lose it, due to my own
negligence; have it destroyed (burned up in a fire, for example); or have
it stolen.  That's about it.  (Oh, there could always be some event leading
to hyper-inflation which causes it to lose all of its value, but that's not
the same as having the pieces of paper/small pieces of metal disappear.)

With a certificate/key,  I can lose it through:  loss of my smart card/PC
card/other token; have it stolen in a breakin of my computer; ..., or

.. lose it all because, for example, some young genius math professor back
in dear old West Lafayette figures out a neat way to factor large integers
really fast.

This last condition is fundamentally different, to my way of thinking. It's
a neat trick on the part of many CA vendors - "if somebody breaks our
system, it's your fault - we can't be held liable for that."

Regardless of my personal opinions about the "right" model, I don't
disagree that various providers can put up PKIs that they insist will work
on the cash model, and other providers can put of PKIs that will work on
the credit card model.  Customers can take their pick of which provider to
use.  Based on the service model chosen, the liability apportionment, the
provision or not of reliable timestamping systems, and a bunch of other
factors, invalidity dates may or may not be useful in any given service.  

That's one of the reasons they're optional in PKIX (it's a SHOULD, not a
MUST); and even when the extension is present, it's non-critical.  If
you're operating in a "cash model" PKI, and don't allow after-the-fact
repudiation of costs, you just ignore the invalidity date (if present) and
go about processing.  If you're operating in a model (such as charge cards,
or, if the URL provided by Bobby Miller is correct, ATM cards) in which
after-the-fact repudiation is permitted, then you pay attention to the field.

The point is that there are two dates that can appear in a CRL entry:  

	- the revocation date, which is the date that the CA (or other authority)
processes the notice and declares the certificate to have been revoked; and
	- the invalidity date, which is the date asserted by somebody that control
of the key or certificate was lost.

It seems to me that the first of these is always useful.  The second is
useful in some (many? most?  darned if I know) situations.  Thus, the
current PKIX profile has it right, I think.

				Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.