Subject: RE: RFC 2560 - OCSP - Clarification

From: Ambarish Malpani <[email-masked]>
Date: Thu, 31 Aug 2000 07:17:52 -0700

Hi Karl,
     The Archive-Cutoff extension is one that is defined in the
OCSP spec - it would not be a non-standard extension just made up
by you.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Karl Scheibelhofer [mailto:[email-masked]]
> Sent: Thursday, August 31, 2000 6:26 AM
> To: Peter Sylvester; [email-masked]; [email-masked]
> Subject: RE: RFC 2560 - OCSP - Clarification
> 
> 
> 
> 
> > -----Original Message-----
> > From: Peter Sylvester [mailto:[email-masked]]
> > Sent: Thursday, August 31, 2000 2:27 PM
> > To: [email-masked]; [email-masked]; 
> [email-masked]
> > Subject: RE: RFC 2560 - OCSP - Clarification
> >
> >
> > >
> > > the current status of a certificate is very often not so
> > important. when i
> > > verify a signature that was created using a specific
> > certificate, i want to
> > > know, if the certificate was vaild, when the signature 
> was created. to
> > > detemine the time the signature was created, one would ideally use
> > > timestamps. using timestamps, it is possible to determine 
> the signature
> > > creation time to be in an intervall [t1,t2]. here t1 and t2 are
> > the times of
> > > two timestamp (taking time base errors into consideration).
> > > what i would like to see in OCSP is a request with the
> > following meaning:
> > > "what was the state of certificate XYZ in the time 
> interval [t1,t2]?"
> >
> > I do not think that you really want to ask this question, see below.
> 
> i do not simply want, in fact i must(!) have a answer to this 
> question to
> decide whether the signature is valid. for me a certificate 
> status service
> it is the most obvious place to get the answer for this question.
> 
> > > the answers could be:
> > > 1) the state of certificate XYZ was A (e.g. valid, suspended,
> > revoked,...)
> > > throughout the time intervall [t1,t2]
> > > 3) certificate XYZ changed its state from state A (e.g. valid)
> > to state B
> > > (e.g. suspended) at tx, where t1 <= tx <= t2
> > >
> > > if i get the first answer with 'valid', i can definitely say:
> > "the signature
> > > it was used for is valid".
> > > moreover, this request-response supports any history model for
> > certificate.
> > > by now OCSP assumes that a certificate can never become valid
> > again once it
> > > became invalid.
> > Hm,
> >
> > If a certificate was 'invalid' (suspended) and if it becomes
> > valid later, then
> > why would you want to get a 'suspended' status?
> 
> simply to temporarily take away the rigths that a valid 
> certificate brings
> with for a entity. consider a employee gets suspended for any 
> reason, the
> company may not want to revoke the certificate before the 
> reason for this
> suspension have been verified. and if the company finds out 
> that the reason
> is unjustified, it may want to make the certificate valid 
> again. during the
> period the employee is suspended, the company may not want him do any
> business.
> 
> > If it becomes definetely revoked, you get a bad answer,
> > if the the current status is still 'pending', you get that.
> > And for those cases you get a date, so you can compare.
> >
> > It is assumed that either by using a cut-off date or by 
> external knowledge
> > you know that for which time frame you get an answer.
> 
> collecting facts from serveral sources to get an answer is 
> what i want to
> avoid. i would like to have a single point where is get a 
> definitive answer
> to the question stated above. by now i have to do serveral 
> parts of this
> processing at the client side. i think the server side would 
> be the better
> place for this.
> 
> > If you want to have more detailed information about the 
> history, you can
> > also require that the signer, a cosigner, a notary, or 
> whoever you want,
> > produce an OCSP response near the moment of the signature and add
> > this to the document, or you other protocols to enable 
> validity checking
> > of the document.
> 
> if you sign a lot of documents and always attach all 
> necessary verification
> data, you produce a lot of redundant information. this can be 
> avoided and i
> think this should be avoided.
> nevertheless it works.
> 
> > I am not talking about the effects of a CA key compromise 
> that might allow
> > you to create 'good' responses for a non-existing cert, and then
> > you estimate
> > to be able to fake one in the future.
> 
> i also do not consider a CA key compromise here.
> 
> > > of course, implementing this based on CRLs will be hard, but if
> > the server
> > > has access to the history of the certificates, it should not be
> > a big deal.
> > >
> > > what do you and others think of this requirement for future OCSP
> > Some general thoughts:
> >
> > So far, OCSP without extensions has been made in such a way 
> that you can
> > create a conforming implementation if you have a repository of CRLs.
> 
> yes i know about this requirement for supporting CRLs. but this is a
> implementation issue.
> for me as a developer of a signature/verification terminal software my
> stated question is the one that i need an answer for.
> 
> > As far as I remember all requests to give different answers 
> are handled by
> > the magic 'do it by an extension'. OCSP adds an archive-cut 
> off extension
> > for example, this seems to me a simple thing to support, knowing the
> > the history of the CRLs that you have isn't that difficult.
> 
> just getting my idea in there in any non-standard extension 
> is not a very
> disirable solution. because if i am the only one supporting 
> it, it is not
> better than any ad-hoc protocol.
> i posted my idea here to hear the opinion of other people 
> that use OCSP.
> 
> 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: Thu, 31 Aug 2000 16:36:14 +0200

Collect me if I'm long, but archive cutoff only indicates whether the
revocation status of a certificate is "garbage collected" after the
expiration of the said certificate (or rather, guarantees that it won't be
until some other point in time). The responder will still only tell you
about the current status of the certificate. I.e. if the certificate was put
on hold and subsequently removed from CRL and is still not expired, you will
not be told.

Karl wants to wind back time and tell the responder: Use only the
information you had at this historical point in time, and answer from that.

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: Ambarish Malpani [mailto:[email-masked]]
> Sent: den 31 augusti 2000 16:18
> To: 'Karl Scheibelhofer'; Peter Sylvester; [email-masked];
> [email-masked]

---

From: Simon Tardell <[email-masked]>
Date: Thu, 31 Aug 2000 16:47:02 +0200

I tend to agree with both of you. That is, both models are fairly valid. It
is my opinion that we should provide standard semantics for supporting both
models. 

The trouble I can see with answering historical questions of the type "what
was the status of this certificate at time t (or in the interval [t1, t2])"
is that there is no corresponding question to put to a CRL. CRLs are
important because (and only because, IMHO) they are the mechanism we have to
resynchronize the state of an OCSP responder with that of the internal state
of a CA at the time of production of the CRL (which has to be done if the
responder does not have access to the internal database of the CA and misses
some CRL issued or so). They are also heavily abused as a certificate
validation mechanism -- but this is a akin to having a POS terminal
downloading the banks account database to be able to validate a credit card
purchase.

Now, to support the historical question the OCSP responder has to be able to
retrieve the state of certificates issued by the CA during the CAs entire
history (modulo some cutoff). This means that it will have to have all CRLs
that the CA has issued (after that cutoff). That will be a lot of redundant
information, and also a lot of processing to get started. A better way would
be to have a way to serialize the entire revocation history of certificates
from a CA. We could use the CRL form and allow a certificate to appear
multiple times (is this actually disallowed?...), e.g. to have entries with
revocation reason certificateHold followed by an entry with removeFromCrl
_in the same CRL_ if the certificate was later unsuspended (obviously the
history could be arbitrarily complicated: suspend, unsuspend, suspend,
unsuspend, suspend, permanent). Apparently, used this way "removeFromCrl"
becomes a misnomer and should perhaps be called something else. A CRL with
these semantics should be marked with a critical extension to avoid
confusion.

Bottom line: I am in favour of Karl's extension, and I also argue for a
similar extension to CRLs to support OCSP responders that are separate from
the CA.

Simon.

> Sent: den 31 augusti 2000 15:26

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 31 Aug 2000 16:53:07 +0200 (MET DST)

> i do not simply want, in fact i must(!) have a answer to this question to
> decide whether the signature is valid. for me a certificate status service

The intial question is: "Is this document/contract/etc a valid one in my
context of application etc?" 
 
A verifier can also simply ask some server (of the other company or a 
local company centralized server) 

"Is this signed document a valid one in this particular application context?"

Depending on the answer, continue with the workflow this way or the other
*AND* you might want to add the answer as a verifiable element to the 'dossier'.  

You have reduced the problem space to something that seems to be close to
what OCSP could respond.

> simply to temporarily take away the rigths that a valid certificate brings
> with for a entity. consider a employee gets suspended for any reason, the
> company may not want to revoke the certificate before the reason for this
> suspension have been verified. and if the company finds out that the reason
> is unjustified, it may want to make the certificate valid again. during the

The person cannot do any business during that time, since any verifier would
fall on the suspended status DURING that time, and if something gets rectified
later, where is the harm of having prepared a contract in advance? 

> > It is assumed that either by using a cut-off date or by external knowledge
> collecting facts from serveral sources to get an answer is what i want to
> avoid. i would like to have a single point where is get a definitive answer
> to the question stated above. by now i have to do serveral parts of this
> processing at the client side. i think the server side would be the better
> place for this.

You don't collect answers from several sources, you determine the validity 
of the document by using some information that you get from one server. 

You already do local processing by validating the signatures, etc.

Why do you start with the second step of validating the cert? you can also ask
some server to validate the whole document. 

> 
> > If you want to have more detailed information about the history, you can
> > also require that the signer, a cosigner, a notary, or whoever you want,
> > this to the document, or you other protocols to enable validity checking
> > of the document.
> 
> if you sign a lot of documents and always attach all necessary verification
> data, you produce a lot of redundant information. this can be avoided and i
In real life contracts in an enterprise you also add several signatures
and other info, like for example you use the officiel forms for contracts
of the company (a verifier knows that only authorised persons have access to that), 
or you add a date stamp of the company and verifiers know that this stamp can
only be made if the contract had been reviewed, copied, archived, etc.
And you sometimes need a second signature from a financial controller.

> nevertheless it works.
Where do you see the redundancy: Either the signer or the verifier
have to determine 'current' status info, and carrying around a response
during the workflow doesn't look a redundant to me. You
could also argue that the document itself is redundant because 
a verifier could be asked to ask a server of potential document producer
to deliver all contracts on line when you are ready.
 
> 
> > I am not talking about the effects of a CA key compromise that might allow
But this could break the whole model?

> >
> > So far, OCSP without extensions has been made in such a way that you can
This is a design decision of OCSP, the protocol is specified in such a way
that support via CRL repositories are possible.  

> stated question is the one that i need an answer for.

You don't have a signature/verification terminal. 
You are assuming a particular application context with a particular
validity model of signatures/signed documents. Adding a little bit
of 'feature' like "you may not sign during suspension" reminds me to
many discussion at least 15 years ago of the kind 'if we just add 
a trustworthy message-id to mail, then ....'. (Sorry for the flame).

But wouldn't the next question be for example: Well, in order to determine
the validity of the signature, I have to know whether the signer has already
used his quota of money for that certificate, or else ?

How do you determine the time of the contract? Probably the signer had to
add a time stamps? Why would you allow him to make time stamps during the
time his signing cert is suspended?

> 
> > As far as I remember all requests to give different answers are handled by
> > the magic 'do it by an extension'. OCSP adds an archive-cut off extension
> just getting my idea in there in any non-standard extension is not a very
> disirable solution. because if i am the only one supporting it, it is not
Indeed. 

> i posted my idea here to hear the opinion of other people that use OCSP.
You have at some opinion of someone who doesn't (any more). 

And I share your desire. 

Maybe you could simply rephrase your question by asking to what extent OCSP
support path validation as in :

   To meet this goal, the path validation process verifies, among other
   things, that a prospective certification path (a sequence of n certi-
   ficates) satisfies the following conditions:
      (i) for all x in {1, ..., n-1}, the subject of certificate x is
      the issuer of certificate x+1;
      (ii) certificate 1 is issued by the trust anchor;
      (iii) certificate n is the end entity certificate; and
      (iv) for all x in {1, ..., n}, the certificate was valid at the
                                     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
      time in question.
      XXXXXXXXXXXXXXXXX

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 31 Aug 2000 17:01:54 +0200 (MET DST)

> on hold and subsequently removed from CRL and is still not expired, you will
This seems right.

> information you had at this historical point in time, and answer from that.
This means to have a protocol that can support 'by the letter' the following
spec:

or whether the specification is an overkill and there should be added
the two words 'or later' at the end ?

---

From: Ambarish Malpani <[email-masked]>
Date: Thu, 31 Aug 2000 08:01:22 -0700

Sorry, I misread Karl's message.

Regards,
Ambarish

> From: Simon Tardell [mailto:[email-masked]]
> Sent: Thursday, August 31, 2000 7:36 AM
> To: 'Ambarish Malpani'
> Cc: 'Karl Scheibelhofer'; Peter Sylvester; [email-masked];
> [email-masked]
> > Architect                                                
> 650.567.5457

---

From: Mathew Butler <[email-masked]>
Date: Thu, 31 Aug 2000 13:02:42 -0700

Preparing a contract in advance, and committing to it in advance, are two
separate problem domains.  One is a necessary part of business; the other is
fraught with legal problems.  Better to not 'enforce' a particular 'legal
worldview' on what is eventually going to be a globally-used protocol.
(Attempting to exceed your authority to bind a corporation that you're
suspended from is 'fraud' in the US, and probably other countries.  The way
it's usually handled, to rectify the situation if it got screwed up on
paper, is to re-sign the document with the current date -- there's no reason
why the same requirement not be extended to the digital world, possibly with
a statement included with the new signature noting the reason for the
re-signing, and a commitment to honor the agreement from the original
signature date even though the original signature wasn't technically valid.)

Regarding the "why allow a suspended certificate to make timestamps": How
easy is it going to be to ensure that the timestamping software checks for
certificate suspension via OCSP?  [Yes, this is a security consideration.]
Also, in the event a third-party timestamping service is used -- how is it
going to be possible to ensure that the third-party timestamping service
checks all arbitrary CA's and their OCSP responders for current validity of
a certificate?

Granted, I agree that this is "pandering to the lawyers"... but if we don't
do this right, this protocol is eventually going to be challenged as a way
to legally validate signatures.

-Mat Butler

--- Original Message ---

"Is this signed document a valid one in this particular application
context?"

Depending on the answer, continue with the workflow this way or the other
*AND* you might want to add the answer as a verifiable element to the
'dossier'.  

--- Original Message ---

The person cannot do any business during that time, since any verifier would
fall on the suspended status DURING that time, and if something gets
rectified
later, where is the harm of having prepared a contract in advance?

---

From: Mathew Butler <[email-masked]>
Date: Thu, 31 Aug 2000 13:03:49 -0700

I don't think "or later" should be appended.  (My reasoning shows up in
another message, sent 5 minutes or less before this one.)

-Mat Butler

-----Original Message-----
From: Peter Sylvester [mailto:[email-masked]]
Sent: Thursday, August 31, 2000 8:02 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: RFC 2560 - OCSP - Clarification

This seems right.

---

From: Khaja Ahmed <[email-masked]>
Date: Thu, 31 Aug 2000 19:27:23 -0400

Under some circumstances or for some communities it may be possible for the
sender of the signed data to send along with the signed data proof that at
the time of signing (+/- some tolerance limit) the certificate was not
revoked. In other words, the sender could get an ocsp response from a common
trusted responder and include this with the transmission of the signed data.
This approach offers the advantage that the response can be archived /
stored along with the signature.  At a later date when the archived / stored
signed data and signature is retrieved it can be readily verified as having
been valid at creation time (+/- tolerance limit).  

Is this not an ability that we should formalize and add to appropriate
protocols like OCSP?

Khaja

-----Original Message-----
From: Karl Scheibelhofer [mailto:[email-masked]]
Sent: Thursday, August 31, 2000 6:26 AM
To: Peter Sylvester; [email-masked]; [email-masked]
Subject: RE: RFC 2560 - OCSP - Clarification

> To: [email-masked]; [email-masked]; [email-masked]
> > know, if the certificate was vaild, when the signature was created. to
> > timestamps. using timestamps, it is possible to determine the signature
> > "what was the state of certificate XYZ in the time interval [t1,t2]?"
>

regards

  Karl Scheibelhofer

--

---

From: Covey Carlin-P21262 <[email-masked]>
Date: Thu, 31 Aug 2000 17:13:51 -0700

I agree that some communities may want to know that the signature
certificate was valid at the
time that data was signed.  However, many communities might also want to
know that no event 
has occurred later that would cast doubt on the validity of the signature.
For instance, the subject
of the signature certificate might have belatedly discovered that his
private key had been compromised.
It seems inconvenient to send two OSCP requests, one asking "was this
certificate good in this interval?"
and a second asking "is this certificate good (but perhaps now expired) at
the current time?"  It seems 
like an mechanism that purports to answer the first question is obligated to
implicitly answer the second.

-----Original Message-----
From: Khaja Ahmed [mailto:[email-masked]]
Sent: Thursday, August 31, 2000 4:27 PM
To: 'Karl Scheibelhofer'; Peter Sylvester; [email-masked];
[email-masked]

Khaja 

-----Original Message----- 
From: Karl Scheibelhofer [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, August 31, 2000 6:26 AM 
To: Peter Sylvester; [email-masked]; [email-masked] 
Subject: RE: RFC 2560 - OCSP - Clarification 

> From: Peter Sylvester [ mailto:[email-masked]
<mailto:[email-masked]> ] 

regards 

  Karl Scheibelhofer 

-- 

Karl Scheibelhofer, < mailto:[email-masked]
<mailto:[email-masked]> > 
Institute for Applied Information Processing and Communications (IAIK) 
at Technical University of Graz, Austria, http://www.iaik.at
<http://www.iaik.at>  
Phone: (+43) (316) 873-5540

---

From: Khaja Ahmed <[email-masked]>
Date: Thu, 31 Aug 2000 22:15:38 -0400

It is certainly conceivable that validity through a period could be
important to know in some circumstances.  I wonder, however, if the
complexity of such a dialogue requires more effort than is justified by the
reward.  

Let us consider how this might be handled in the world of manual signatures.
When a purchase officer at Bloomingdale's sends a manually signed P.O. to
Lee's Shirts let us assume that an acknowledgement is immediately sent out.
After a lapse of time (to build to order) the 5,000 pink shirts that were
ordered are ready to be shipped.  The PO is being referenced to make sure
that the goods being dispatched are consistent with the PO.  Would Lee's
shirts want to confirm that the purchase officer is still at Bloomingdale's
and that signature is still valid?  I suspect not.  But then for whatever
application you are considering it may be necessary.  If so...

How does one automate the decision of a relying party when it gets the
answer to the question, "was this certificate good in this interval?" It is
a potentially burdensome to process the answer in an automated fashion.  The
answer could be:

a.) that the certificate was suspended from time tx to ty, where t1 <= tx <=
ty <= t2, or 
b.) that the certificate was revoked at tx, where t1 <= tx <= t2, or 
c.) that the certificate expired at tx, where t1 <= tx <= t2 

If (a), is it important to know why the certificate was suspended?  Does it
matter if ty is in fact equal to t2 or equal to the expiry date of the
certificate.  It could be that the person was on administrative leave until
the certificate expired after which he/she was fired. 

If (b) or (c), what would the relying party do?  

Furthermore, this requires that the CA maintain in an online database every
state transition and that the OCSP responder process this information before
responding.  This also makes it challenging to now have a set of distributed
OCSP responders because you have to distribute/replicate the database.

The biggest obstacle, I think, is that the logic to process such responses
at a relying party is likely to require much more decision making logic and
other input than is realistically going to be provided to most applications.

None of the foregoing is to say that the requirement is not legitimate or
such capability is not needed or even important.  I am just wondering if
current realities warrant that we settle for something more modest.  i.e.
the ability have a dialogue like

Questions.) "Is the certificate good now?" or, "Was the certificate good at
time t?"

Answers.) "Yes" or "No" or "Don't know."

This would still require maintenance of detailed state transition
information at the CA/VA end but at least the relying party doesn't have
very complex decision making logic to go through.

Khaja

-----Original Message-----
From: Khaja Ahmed [mailto:[email-masked]]
Sent: Thursday, August 31, 2000 4:27 PM
To: 'Karl Scheibelhofer'; Peter Sylvester; [email-masked];
[email-masked]

Khaja 

-----Original Message----- 

regards 

  Karl Scheibelhofer 

--