Subject: Re: Invalidity Dates

From: [email-masked]
Date: Mon, 14 Dec 1998 16:10:13 -0500

You're right David. I was thrown by the fact that a restriction
on a required field was only discussed in the context of some
other, optional extension with a very similar name. Thanks for
pointing that out.
     Mez

---

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 14 Dec 1998 15:24:22 -0700

>>> <[email-masked]> 12/14/98 02:18PM >>>
Thanks Bob. All good points, which leave me wondering what
to do about that period of time when the key might have been
compromised but was not yet revoked. Do you posit that the
CPS and other contracts cover this? (I'm just asking you instead
of bothering the list, as I imagine this sort of philosophical ground
has been already trod, but feel free to distribute any response
as widely as you like.)
     Mez

Mez,

That's why, in my judgement, we need legislation that lets 
potential relying parties know what the rules of the road are.
Unfortunately, the young turk lawyers that seem to be in control
of the technical legislative agenda in a lot of influential states
are very anti-regulatory, and pro "fight it out in court." that being
their background.

The trouble with putting something in the CPS is that it is highly
questionable just how binding the CPS is on the relying party, 
_unless_ the CA, the subscriber, and the relying party are all part
of a mutual trust association, i.e., a closed user group, which
tends to defeat at least a portion of what a PKI was supposed 
to provide  If on the other hand the relying party is one of the 
proverbial widows and orphans, they are quite likely not to even 
read the CPS, and it is not likely to be binding.

The issue in the case of a contested digital signature is two-fold:

1.  Who has the burden of proof, i.e., to what extent is there or
should there be a rebuttable presumption of the validity of
the signature under certain circumstances (such as licensed CA, 
under Utah law), and if the presumption is rebutted, i.e., challenged,
who has what burden of proof -- does the burden shift to the defendant,
or remain with the plaintiff?

2.  Regardless of who has the burden of proof, who has the risk of 
loss?  (These are two entirely separate issues.)  If it can be 
established as a matter of fact, as well as a matter of law, that the
defendant did not sign the document in question, and hence it must 
have  been signed by person or persons unknown, who is left 
holding the bag:

The poor defendant, who didn't sign it but perhaps should have been
more careful with his keys, if necessary depositing them in Fort Knox
overnight?  

Or the equally hapless relying party, who is clueless about
the defendant's key hygiene?  

Or perhaps the CA, who issued the certificate in exchange for a 
payment of a few tens or hundreds of dollars, and is now potentially 
liable for a transaction greatly in excess of his total cost, much less 
profit, for circumstances they had no control over?

From my perspective, I don't care terribly much one way or the other, 
because I can see pros and cons to each side, and depending 
on the circumstances I might be either a subscriber or a relying party.

What I do insist on is a careful spelling out of the rules of the road.
Given that understanding, I can choose to drive on the right hand 
side, on the left hand side, or stay home in bed, but I will at least know
my risk and potential vulnerabilities.  If you leave it up to a jury, 
I'm at the mercy of which orator has the more golden tongue, how 
the judge is feeling that day, and the economic and technical 
background of the jurors.  None of those give me a warm feeling!

Regards,

Bob

---

From: Mike Smith <[email-masked]>
Date: Wed, 16 Dec 1998 08:04:28 -0700

Part of the confusion, I believe, is that Al and others were lumpng both the functionality of a compromised key list and a CRL into one place.

I agree that "retroactive" revocation should not occur because it weakens the system from a business standpoint, but I also agree that some implementations of identity and privacy systems need to record the actual or closest date of key compromise in case action of the system owners need to occur.  For example, in a government situation with a crypto key reported compormised, then the security administration needs to assess their exposure.

In the private sector model, I used a false will as an example.  If I had strongly suspected that my identitiy was compromised, then I would personally file an affidavid with some notare or state clerk with some proof that I was out of the country to attempt to mitigate my own exposure.  I would not expect the CA or any merchants to relieve me of my responsibility.  In some cases, law protects both the CA and others because the law (like Utah) puts the security of the private key for identity completely with the "subscriber" or certificate user.

Some private models, like credit card holders may wish to use password or biometric controlled certificates as enhanced identity authentication and retain theor current licability models or even offer higher protection for people with this system, but I doubt that they will assume any liability for time periods before they new about the compromise.

Hope this helps,

michael

>>> Juergen Walter <[email-masked]> 12/16/98 03:37AM >>>
******************  InterScan Message (on zbc2)

noname is scanned and no virus found
*********************************************************
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !

---

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 17 Dec 1998 09:17:01 -0700

David,

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

>>> David Solo <[email-masked]> 12/17/98 08:18AM >>>
Bob,

DS>A further comment (and clarification).  With respect to hold status, in 
all the discussions I can recall, the firm agreement has been that if a
hold is converted to a "full" revocation, the revocation date
(regardless of what happens with the invalidity date) becomes the date
of the hold (i.e. for all intents and purposes, it is as if the
certificate was revoked, rather than held, at the time of the original
hold).  I'm not sure if you were suggesting something different.

No, I agree with you.  I just have been so busy with encryption and 
other issues that I haven't had the time I'd like to keep up with the latest
revisions, and haven't even downloaded the latest text to check exactly 
what is said on this point. Does the current text make this clear?  In
particular, I didn't want the date of the CRL to be the date of the 
revocation in this case.

DS>With respect to the general discussion, I still believe the invalidity
date makes sense in some environments.  I would expect some CAs (as part
of their operating rules/practices) to preclude its use, others to
perform some degree of diligence on the requested value, and others to
allow end entities to request whatever they like.  This is then
supplemental information which an RP may or may not elect to make use
of.  In any case, disputes would either be subject to operating rules
for a given environment or to more general contract principles.

Hmm.  Every time we get into these kinds of philosophical discussions,
I am torn between wanting to be flexible enough to satisfy the primary 
business needs, vs. being so flexible that no one knows what a given 
field represents in a specific case.  I am particularly reluctant to allow
the mass of individual CAs to make up their own mind about these
things and to include them in their (normally unread) CA Policy
documents.  (I am not necessarily talking about the major public CAs,
nor the more or less private, closed CAs such as are used for 
industry associations, etc.)

At present, I understand the field is defined with a SHOULD, rather 
than a MUST. That's certainly going in the right direction, but my preference
would be for PROBABLY OUGHT NOT TO (mildly deprecated).

Bob

---

From: David Solo <[email-masked]>
Date: Thu, 17 Dec 1998 10:18:21 -0500

Bob,

A further comment (and clarification).  With respect to hold status, in 

With respect to the general discussion, I still believe the invalidity

Dave

Bob Jueneman wrote:
> 
> Andreas, I certainly agree that we need to clarify the
> semantics of an entry in a CRL.  For reasons I've described
> in my previous response to Al, there may be some merit in
> interpreting the invalidity date as the reporting date and time
> of the compromise, for a certificate that is issued later, but
>  NOT the date at which it was suspected (or fervently
> hoped) that the compromise took place.
> 
> Likewise, if a certificate transitions from "hold" status to revoked,
> the invalidity date should be the date when the suspension was
> requested.
> 
> I am just very, very unwilling to allow a subscriber to write checks
> in disappearing ink by claiming well after the fact that his keys were
> compromised.  The fact that the subscriber is careless or imprudent
> should not disadvantage an innocent relying party, much less the
> CA.
> 
> If the subscriber can't afford or control the risk, either by being
> more careful or by buying insurance, they shouldn't accept the
> certificate in the first place, and that is their right.
> 
> Bob
> 
> >>> Andreas Berger <[email-masked]> 12/16/98 06:14AM >>>
> Al Arsenault wrote:
> >
> > Bob,
> >         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
> 
> 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: "Bob Jueneman" <[email-masked]>
Date: Mon, 21 Dec 1998 11:30:58 -0700

Juergan,

We may be getting somewhere.

I believe that your "T2" date (the date which you last claim and/or admit to having validly used your key is rather similar to the (unfortunately deprecated) private key validity period.

As is the case with the private key validity period, after which the user is supposed to have zeroized his private key but might not have, if the user reports a T2 date she is effectively saying: 

"(1) If you haven't already done so, please don't accept any signatures as being mine after date T2. 

(2)  If you have already done so, my apologies, but I am hereby repudiating any signature made after T2 and am prepared to re-sign any valid transactions which you may have received.  

(3)  For transactions signed after T2 which I repudiate and refuse to re-sign, we may have to fight it out in court unless we can come to some agreement, so you'd better not destroy any evidence you may possess that would point to who really signed the transactions. 

(4) For transactions signed after the date (T1) which I reported my key as having been compromised, you'd better have awfully convincing evidence if you hope to make your allegations stick, as I will claim that your reliance on my signature was completely unreasonable."

Bob

>>> Juergen Walter <[email-masked]> 12/21/98 05:24AM >>>
Denis,

> 
> In practice the user (system) can "remember" when the key was used safely by himself for
> the last time, the invalidity date should be set shortly past that time.

This is the lower limit. The upper limit is the date, when the
revocation request was reported to the CA, in my opinion, but I am aware
that the generally recognized upper limit is the _revocationDate_.

> > So, the problem we have is that the certificate path validation software
> > relies on it. The answer "valid" or "invalid" is not enough. Otherwise,
> > the answer "maybe" is not quite useful, especially in the case that the
> > verifier is not human (e. g. server)(please see Russ` mail). In
> > contrast, I don`t see any reason that CAs doesn`t share additional
> > informations like the following with human verifiers.
> >
> > "certificate is valid -  the certificate holder repudiates all
> > signatures after _invalidityDate_"
> 
> I am not sure I understand correctly. In practice you test the validity of a certificate
> *for the signing time* against a security policy. The answer is either "Valid", "Invalid"
> or "Don't know yet" (i.e. come back later on - this is the "hold on" situation"). The
> "don't know yet" situation should be interpreted in the following way: if the requester
> cannot afford to come back later on, then the answer is "Invalid".

I agree with you, that "Don`t know yet" is quite easier to understand.
Like a yellow traffic light (see Bob`s mail).

I apologize I was not clear. The following example may help. The
certificate holder sends a revocation request at T1 to the CA and
reports  I have lost my smart card and used it last at T2.  Plainly,
T2<T1. The CA issues a CRL at _ThisUpdate_ > T1 with following setting:
1. revocationDate = T1 (or, close to)
2. invalidityDate = T2
3. reasonCode = keyCompromise.
(Besides, there arises additional problems, if T1 is not close to the
revocationDate, when the CRL entry was processed.)

The well-recognized (?)  handling is different:
After the revocation request the CA issues CRL 1 with reasonCode =
onHold. After dispute solution the CA issues CRL 2, say with reasonCode
= keyCompromise and an invalidityDate which the CA warrants for. I think
that dispute solution may take time. A court may be involved. As I know
German courts, their flow-rate is few. So, the relying party may wait
for the sentence in front of a yellow traffic light for years. And all
the time the certificate is "onHold" until it expires. Some CA may
change its status from "onHold" to "keyCompromise" after XX days by
policy, but the ultimate revocationDate may still be not available.
Therefore, I dislike the use of "onHold" reason code, provided that is
only uncertain, WHEN the certificate is revoked, besides there is no
doubt, that it HAS TO be revoked.

Nevertheless, both of the mentioned scenarios are compliant to the
current PKIX draft. Hence, certificate path validation depends on
policy. The reason is twofold. Firstly, the current PKIX draft specifies
time intervals.  Secondly, the current PKIX draft remains space for
interpretation of the lower and upper limit of these time intervals.   
-- 

Juergen

---

From: Juergen Walter <[email-masked]>
Date: Tue, 22 Dec 1998 10:50:27 +0100

Bob, 
> (4) For transactions signed after the date (T1) which I reported my key as having been compromised, you'd better have awfully convincing evidence if you hope to make your allegations stick, as I wi…

That`s precisely what I wanted to say. May be, I´ve overseen the
evident, but I don´t see the reason why this handling is unwillingly
applied for private key compromise case; unless we consider the case,
where the CA warrants for invalidity dates.

Thanks for all hints, remarks, objections, contributions,...

I wish you a merry christmas and a happy new year.

Juergen