Subject: RE: OCSP support for historical reference to certificate suspensi on

From: Michael Myers <[email-masked]>
Date: Tue, 5 Sep 2000 07:45:09 -0700

Pat,

Am I correct in concluding that a single "validAt" date would address your
needs?

Mike

> -----Original Message-----
> From: Patrick G. Moore [mailto:[email-masked]]
> Sent: Friday, September 01, 2000 2:47 PM
> To: [email-masked]; [email-masked]
> Subject: Re: OCSP support for historical reference to certificate
> suspension
> 
> 
> Hi,
> 
> In my case, the signing time is part of the signed data.  We may
> like to re-verify old data from our archives at any time.  Thus,
> we would also like a "VALID AT" type of option.  I agree that 
> an interval
> could be problematic, if a cert was suspended for a period between
> the endpoints, how would you discover that.  Just checking 
> the endpoints
> would not reveal the suspension.  I would say, if the app is uncertain
> of the signing time, let it make as many "VALID AT" queries 
> as it likes
> to make it happy.
> 
> Pat
> 
> Michael Myers wrote:
> > 
> > This is first I've heard of this specific requirement but 
> it seems quite
> > natural once the need is exposed.  We'll take this into 
> account in the
> > 2560bis work.  Thanks also for the OPTIONAL.  That'll make 
> things a little
> > bit easier.
> > 
> > But for discussion purposes, I've been architecting under 
> the presumption
> > that in the instance when signing time was important, the 
> time when the
> > digital signature was created would be integrated somehow 
> into the subject
> > electronic document and thus there exist a well-defined time.
> > 
> > I believe you're implying that it may not be the case that 
> signing time is
> > integrated into a subject document, and so one is led to 
> bracket the signing
> > time.  Could confirm please, or otherwise clarify?  Thanks.
> > 
> > Mike

---

From: Simon Tardell <[email-masked]>
Date: Tue, 5 Sep 2000 17:49:07 +0200

> The question is when and why do you want to discover whether a cert

No, that was not the actual question. Karl believes he has a valid case for
asking the question "was this cert valid at t1 or between t1 and t2" and he
wanted to have a standard way of expressing the query and the answer. I
think we should separate the question of whether there are valid cases for
asking such questions (and not whether there are cases where its not an
interesting question to ask...) and how to best express the question.
 
> Which date are you asking for, remember, the 'now' date is the one of
> the OCSP server, and the answer of 'now' does not say whether
> the cert is valid/invalid at 'now', but only that in case of 'good',
> the server doesn't know anything negative at that moment. It
> may happen that it receives a CRL a minute later, that has a
> revoked cert with a revocation date 2 minutes ago, a new request
> would now tell that. Since the two OCSP requests should inconsistent
> information which of the two answer would you see for a validAt
> send at the 'now' of the first response.     

Correct. For this to work revocation backwards in time can not be allowed
(German SigG has this restriction, I don't know about Austrian). The
response must contain the same "evaluateAt" (validAt, whatever) extension as
the response, of course. The evaluateAt has to be less than the thisUpdate
of the response. 

Simon.

Simon Tardell, Software Architect, iD2 Technologies
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
[email-masked], http://www.iD2tech.com
Securing the Internet economy

---

From: Simon Tardell <[email-masked]>
Date: Tue, 5 Sep 2000 18:03:56 +0200

> we would also like a "VALID AT" type of option.  I agree that an interval
> the endpoints, how would you discover that.  Just checking the endpoints
> as it likes to make it happy.

I am not sure I follow. For the responder an interval is not problematic. If
it uses CRLs as the base of its answers it is only a problem if it misses a
CRL (in the interval), and then it has to return "unknown". For a client
there is no good way to know how many question it must ask in order to be
sure that it doesn't miss a quick suspension. Also, asking multiple
questions is not bandwidth conservative.

Simon.

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 5 Sep 2000 19:02:16 +0200 (MET DST)

> interesting question to ask...) and how to best express the question.

My response was to Pat's remark.
To an extreme, without qualifying Karl's or Pat's question,
this approach seems equivalent to allowing to believe any kind of
non-sense, and force to treat how to express this non-sense in the best way. 

But let's assume that we want an online service that can detect this.

> the response, of course. The evaluateAt has to be less than the thisUpdate

For what to work? I haven't said that something can work? 

If you allow backward revocation, the NO protocol to determine the actual
or past status can work in an absolute way. 

You still can spread the risk, as usual. Or, if the verifier
knows the probability curve of to how far a backwards revocation can occur,
it can wait until the risk becomes acceptable.  

The SigG does not say anywhere whether you can suspend and resume a cert.

I am not sure whether I understand the order of thisUpdate or evaluateAt: 

The OCSP responder has a the latest copy of a CRL of t1, it gets a request
asking for a status with an evaluation date of t2>t1. (t2 maybe less or
larger than the 'now' date of the server). 
what should the server respond?

---

From: Mathew Butler <[email-masked]>
Date: Tue, 5 Sep 2000 15:06:51 -0700

In other words, you want to provide for the possibility of repudiation of a
signature that appears valid, but for reasons outside the scope of the
specification really is not.

-Mat Butler

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Tuesday, September 05, 2000 3:02 PM
To: Karl Scheibelhofer; [email-masked]
Subject: RE: OCSP support for historical reference to certificate
suspensi on

Karl,

Very good catch!  At least, some very good inspiration.  We'll see . . . .

May I transform your cited case into more generalized trusted transaction
management practices for your confirmation and my own clarification.  

Assume there exists a relationship between a wireless client (WC) and a
wireless transaction facilitator (WTF) that enables mobile e-commerce, the
secure interaction of which is assured via PKI.  Further assume that a
wireless client's digital signature private key is compromised.  Then:

1. Between the (apparent) WC's commit to a wireless transaction (1st
timestamp, produced by attacker) and WTF's execution of that transaction
(2nd timestamp) there exists a non-zero probability that the client's report
of that compromise would not reach the facilitator.

2. If the client's certificate issuer confirms "good" via OCSP between these
two endpoints, then to the actual knowledge of the issuer, the certificate
is reliable (or at the least, not revoked).

Is this a reasonable generalization?

Mike

> From: Karl Scheibelhofer [mailto:[email-masked]]
> Sent: Sunday, September 03, 2000 11:55 PM
> To: Michael Myers; [email-masked]
> Subject: RE: OCSP support for historical reference to certificate
> suspension
> 
> 
> > integrated into a subject document, and so one is led to bracket
> > the signing
> of course, it is desirable that the document is timestamped 
> before it gets
> signed. and to fulfill the requirement for non-repudiation, 
> it is necessary
> to timestamp the signed document afterwards. but there are 
> cases thinkable,
> where there is a longer time between these two timestamps; 
> e.g. if you are
> signing on a mobile device, that does not have permanent access to a
> timestamping sever. very often, the first time stamp will be 
> replaced by
> just a time value that is added before the document gets 
> signed. but if it
> is just a value, i can insert any value i like; it is not detectable
> afterwards. so you cannot proof that you signed the document 
> not before a
> specific time.
> only if you are using two timestamps, you can proof later on that the
> signature was created between these two timestamps. in case 
> of a dispute, i
> think this is very helpful.
> 
> regards
> 
>   Karl Scheibelhofer
> 
> --
> 
> Karl Scheibelhofer, <mailto:[email-masked]>
> Institute for Applied Information Processing and Communications (IAIK)
> at Technical University of Graz, Austria, http://www.iaik.at
> Phone: (+43) (316) 873-5540
>

---

From: Simon Tardell <[email-masked]>
Date: Wed, 6 Sep 2000 11:29:58 +0200

Peter,

> what should the server respond?

If you ask for an evaluation date which is later than the latest CRL that
the responder has access to, the response must be "unknown". If you don't
give an evaluation date, then, effectively, the query will be evaluated at
the latest time for which there is information (i.e. the thisUpdate of the
latest CRL) and that will be documented in the thisUpdate of the response.

Simon