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

From: Michael Myers <[email-masked]>
Date: Tue, 5 Sep 2000 15:02:15 -0700

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

> -----Original Message-----
> 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
> 
> 
> > 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.
> 
> 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: "Karl Scheibelhofer" <[email-masked]>
Date: Wed, 6 Sep 2000 14:34:24 +0200

Michael,

> is reliable (or at the least, not revoked).

that is not what i actually meant with my example, but this can be a
problem. i am not sure, if you can solve the problem you sketched by
technical means. i also agree that this problem is related to the one i
explained.
if i get a qualified response that a certificate was valid at some time, it
must not be possible to get a  qualified response that contradicts the
previous one.

i meant the case where i as the signer (or verifier) want to proove later on
that i signed a document at some time (or in an interval). i think it is
important for the requirement of non-repudiation to have a chance to proove
that the certificate was valid at the signature creation time. but this can
be achieved, if it is not allowed to make any retroactive status changes. if
there is no suspended status allowed that means that the certificate is not
valid, OCSP as it is now is enough. but there are different interpretations
of the suspended status. in the "ILLINOIS ELECTRONIC COMMERCE SECURITY ACT"
(http://www.mbc.com/ecommerce/legis/ill-esca.html) one can read:
> If a certificate is suspended rather than revoked, the operational period
is considered to be terminated
> for the duration of the period of suspension, and digital signatures
created during the period of
> suspension will not qualify as secure electronic signatures under Section
15-105.
in the austrian signature law, a signature created while the certificate is
suspended is valid, if the certificate is not revoked after suspension.

in my first suggestion, i also missed that the status can change several
times in an interval. so it should sound like this:
"what was the state of certificate XYZ in the time interval [t1,t2]?" (where
t1 <= t2)

the answers could be:
1) the state of certificate XYZ was A (e.g. valid, suspended, revoked,...)
throughout the time intervall [t1,t2]
2) certificate XYZ changed its state from state A (e.g. valid) to state B
(e.g. suspended) at t(AB), from state B to state C at t(BC), from state C to
state D at t(CD),... ,where t1 <= t(AB) < t(BC) < t(CD) < ... <= t2

this would also have the advantage that one could get the history of a
certificate by requesting the state in the intervall [t(valid not before),
t(now)]. so if i have a OCSP server at my company, that get's a request for
the state of certificate XYZ it could contact the certificate issuer for its
state in the intervall [t(valid not before), t(now)] and cache this
response. by using this response my server could respond to all subsequent
requests for this certificate referring to any interval included in [t(valid
not before), t(now)]. if the certificate expired one can archive [t(valid
not before), t(valid not after)] as the complete history.
i would like to hear a comment from a CA provider, if this information is
easily available at a CA. i would really be surprised, if they would not
have the whole history of a certificate available in a database.

i hope that i am not the only one who finds this idea worth to consider.

regards

  Karl