Subject: RE: RFC 2560 - OCSP - Clarification

From: "Karl Scheibelhofer" <[email-masked]>
Date: Fri, 1 Sep 2000 08:38:52 +0200

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Thursday, August 31, 2000 4:53 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: RFC 2560 - OCSP - Clarification
>
>
> >
> > >
> > > 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 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?"

sorry, but i don't want to send my documents for verification to other
companies. and i think most managers won't allow that. moreover, you have
the to anser the same question at this server.
no matter where you process it, for a serious validation you need to answer
this question.

> 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.
>
>
> > > 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.
>
> 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?

you may not be allowed to sign anything because of legal issues.

>
> >
> > > 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.
>
> 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.

yes, implementing a server for document validation makes sense. but this
server also needs an answer for this question.

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: Fri, 1 Sep 2000 08:48:22 +0200

> From: Mathew Butler [mailto:[email-masked]]
> Sent: Thursday, August 31, 2000 10:03 PM
> To: 'Peter Sylvester'; [email-masked]; [email-masked];
> 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.

it is the goal of our current project to create/verify legally valid
signatures (following the european signature directive).

regards

  Karl Scheibelhofer

--

---

From: Bruno Salgueiro <[email-masked]>
Date: Fri, 01 Sep 2000 12:25:34 +0100

Hi Khaja. Just few comments.

The Bloomingdale's example would use the OCSP request at the time where
Lee's Shirts receive the signed order. As this is a contract that ends
when the goods are delivered, i.e., it isn't lenghty over time, it is
not
required to ask for the validity for a time interval.

Assuming that the answer for the OCSP protocol could be semantically
accurate,
and your examples demonstrate that probably the request would need an
extra
information to desambiguate the answer, my opinion is that with DVCS
draft
we may be solving the issue of knowing if at a particular time the
certi-
ficate's state and more (assuming that DVCS also verifies signatures,
certificate's validity and after that signs the OK/not OK answer), which
is
far more useful.

Finally, answering whether a certificate was valid at interval [t1, t2]
may
disclose some information that relying parties don't really need and/or
end
users don't want CAs to disclose... I guess that these problems should
be
tackled by DVCS but the authors can surely give their opinion about
this.

Regards,

> Khaja Ahmed wrote:
> 
> 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
> 
> From: Covey Carlin-P21262 [mailto:[email-masked]]
> Sent: Thursday, August 31, 2000 5:14 PM
> To: 'Khaja Ahmed'; 'Karl Scheibelhofer'; Peter Sylvester;
> [email-masked]; [email-masked]
> 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.
> 
> From: Khaja Ahmed [mailto:[email-masked]]
> Sent: Thursday, August 31, 2000 4:27 PM
> To: 'Karl Scheibelhofer'; Peter Sylvester; [email-masked];
> [email-masked]
> 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
> 
> From: Karl Scheibelhofer [ mailto:[email-masked]
> <mailto:[email-masked]> ]
> Sent: Thursday, August 31, 2000 6:26 AM
> To: Peter Sylvester; [email-masked]; [email-masked]
> > From: Peter Sylvester [ mailto:[email-masked]
> <mailto:[email-masked]> ]
> > Sent: Thursday, August 31, 2000 2:27 PM
> > To: [email-masked]; [email-masked];
> > > 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 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 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,
> >
> 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
> > 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
> 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]
> <mailto:[email-masked]> >
> <http://www.iaik.at>

-- 
=======================================================
Bruno Salgueiro       (mailto:[email-masked])
                   
Grupo de Trabalho de Certificação Digital
SIBS - Sociedade Interbancária de Serviços
Rua Soeiro Pereira Gomes, Lote 1, 1600 Lisboa, Portugal

Tel: + 351 21 791 88 33
Fax: + 351 21 794 24 40
http://www.sibs.pt

This message was digitally signed with a MULTICERT cer-
tificate to give an identity assurance. In order to
download the root MULTICERT certificate please go to :
             http://www.multicert.com

"Computers are useless. They can only give you answers."
                                        --Pablo Picasso
=======================================================

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 1 Sep 2000 14:35:15 +0200 (MET DST)

> the to anser the same question at this server.
A slight misunderstanding: 

The verifier sends the document to the originating company or a notary. 

In some circumstances you are even required to send a signed document
to a third party, otherwise the business cannot be done, try to buy a house
without a notary. 

> no matter where you process it, for a serious validation you need to answer

But it doesn't mean that one could not require that if an answer must be producable
at any time in the future the creator should make some additional effort to
make this possible.  

> you may not be allowed to sign anything because of legal issues.
Who do you want to protect and when? The signer or the verifier? 

> server also needs an answer for this question.

Such a server is not necessarily in the same situation as a CA or OCSP responder.
A server could for example base its decision on the existance of the document
in an archive of all validly signed documents, the procedure could require that all
documents that leave a company must be archived, similar to the 'company stamp'
a document would only be considered valid if the archive server has added a 'stamp'
on the document saying 'valid for this purpose, correctly signed by, and archived'.

Or if the server validates certificates as part of that process, this is the
only place where historic CA information may be required.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 1 Sep 2000 16:36:28 +0200 (MET DST)

> signatures (following the european signature directive).

You proably mean that you want to follow one the laws of the
member countries that are supposed to be conformant with
the directive.  

The only thing that the directive requires is that
a provider has to offer an efficient revocation service
without saying what that would mean in detail. 

The laws may still say many things about the issue, they need
to be accompagnied by decrets that explain the current
state of art technical requirements for certification
authorities. 

Do these rules require that you have more than two states
(good and revoked), and can there be more than at most
one change from good to bad? The fact of using X.509 and its
revocation, doesn't mean that you implement all possible
theoretical values.

Also, the directive handle at all the situations
of complex b2b relationships because this are closed groups,
the directive handles 'individuals'.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 1 Sep 2000 17:46:41 +0200 (MET DST)

> 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.
> and a second asking "is this certificate good (but perhaps now expired) at
> like an mechanism that purports to answer the first question is obligated to

Unless one assumes that it should be possible to detect 
a suspended and later become valid certificate, and that this situation
should lead to a rejection of the signature, the current OCSP question
seems sufficient to give the anwser to both questions. 

Who would suspend a certificate? The owner? Someone else? If so, 
what stops you of suspending it, and NEVER remake it valid but just
issue a new certificate.  Also, the information about the transition
from suspended to good has a propagation delay, 

What if a signer falls on a slow verifier who has not received the
latest update of CRLs or else, can this verifier immediately execute
a death penalty? :-)

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 1 Sep 2000 18:15:11 +0200 (MET DST)

> Hmmmmm.
Ohhhh :-)

> I don't like the word Document for this process. I will talk more about that
> below.
> Would this mandate that the "user" of this trust process would be
> responsible to tell the RA or issuing CA service that the "trust Instrument"
> in question had been used?
> 
> if so this might be a workable method of answering the "Which One" issue in
> a digital context.
I am not sure that we are in phase here? A CA/RA is not a 'notary' ?

> > "Is this signed document a valid one in this particular application
> context?"
> 
> As I said above - I don't like the term DOCUMENT here. There is too much
> confusion as to what a document contains and is to be used for. Lets call
> these trust process element's "Instruments" just like in the Financial
> World.
what about XYZZY or Y2 ? :-)

> > *AND* you might want to add the answer as a verifiable element to the
> 'dossier'.
> 
> OK so the "instrument" is validated for its current viability (meets all the
> app's standards for validity, applicability, and potentially capability as
> well), what next? how do you create a process for terminating the usability
> of any of the potentially remaining digital copies of this that are still in
> circulation? and what is the overhead of that process - these are the next
> germain questions I think.

Hold on, that was not the question at all, we are not talking about copies of
money, or whatever, it is certainly not my problem if you pay me twice,
I may have a slight problem of space, if you send me 100 copies of a motocycle, 
I would certainly not ack the receipt of your delivery or invoice. 
If I send you twice exactly the same order (signed the same date, etc) to me,
I would treat this as a duplicate (within some limits).  

> Exactly - And if OCSP can be used to tell the App that all is well then it
> can also be used to tell the OCSP Source or RA that this instrument has been
> used.
I am lost, what instrument? The certificate, or the signed data? 

I should have said: Since in the space full of fog of possible solutions OCSP
seems to be the closest real one, you try to shake and stretch it so it
might get broken. With a little bit of imaginary one might be able to
solve the complex problem much easier ;-)

PS

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 1 Sep 2000 19:00:10 +0200 (MET DST)

> 
> 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
> 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.
> 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

You can also add at any time a CRL in S/MIME for example.  

At least the time stamping protocol and dvcs provide for adding the
results in a PKCS9 attribute. And also the draft for electronic signature formats
to include OCSP responses.

But the question was whether OCSP (and/or other bricks handled by pkix) need
enhancements so that applications can benefit from that without creating
an unimplementable protocol.  

You don't add the actual usage rules to ocsp. The 'electronic signature
format' text is an example containing some explicit rules for verification
of documents. This is above certificate, and S/MIME.

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 1 Sep 2000 14:09:09 -0400 (EDT)

Mike,

There is no need to justify the existence of OCSP with false statements
concerning CRLs - OCSP will stand on its own merits in some locations,
and CRLs will excel in others.

"Immediate timeliness" is not "inherently" beyond the scope of CRLs
(which can be issued immediately upon every revocation event), and not
beyond the scope of periodically-produced CRLs, which can be produced
as frequently as anyone's definition of "immediate" requires.  Is 60
seconds "immediate"?  Is one second?  If 10 million RPs absolutely need
revocation information three seconds after it is entered into a CA
database, then have the CA generate a delta CRL every second and stick
it on a web page or broadcast it as TV vertical interval data or FM
subcarrier data.

OCSP doesn't work in multicast/broadcast (IP or broadband) environments,
and web caches can be considered a broadcast medium if you demand the
absolute minimum delay between the CA's knowledge and a number of
clients' knowledge of revocation events.

I would say that OCSP is not primarily suited to address immediate
timeliness, but is instead primarily suited to minimize the complexity
of clients by pushing CRL processing logic and memory requirements onto
distributed (LAN-based) servers.  And I would challenge any claim that
OCSP from the RP to the CA is more timely than using local CRL-fed OCSP
servers, for any configuration of client population, CA processing
capacity, CA bandwidth, OCSP server capacity, and OCSP server
bandwidth.

Regards,
Dave

> From: Michael Myers <[email-masked]>
> To: Liaquat Khan <[email-masked]>, [email-masked]
>
> But OCSP is and was primarly intended to address immediate timeliness, a
> feature that is inherently beyond the scope of periodically produced CRLs.
> 
> 2560bis will clarify this intent.
> 
> Mike

---

From: Peter Williams <[email-masked]>
Date: Fri, 01 Sep 2000 11:58:40 -0700

David,

In our "Digital Certificates"
book, we reported on a simple java experiment using 
simple multicast to distribute CRL information 
on a schedule. One can easily use the same
multicast transport to handle request/responses
for OCSP messages. The multicast security
architecture can control who relies on
an OCSP response, even when that response
is intended for a particular recipient.

The component is invoked using a (secure) DCOM/RPC request.
(Java RMI could presumably do the same, once one
adds the java wrapper to COM). It went to the Microsoft CA's  
database, and sent the CRL  value over a (secure) multicast 
channel. The security I  envisaged (not discussed in the book)  
was based on the IETF and DARPA's secure multicast work, which 
leveraged secure DNS, IPSEC AH, and IGMP to enforce access control,
distribution of, and reliance on the value to authorized 
relying parties.
  
(The source code is included on the disk if you want
to play with it on NT's java.)

Security and Use of multicast in secure reliance protocols is 
orthogonal to the syntax and access protocol design of CRLs and 
OCSP, in my view.

Peter.

-----Original Message-----
From: David P. Kemp [mailto:[email-masked]]
Sent: Friday, September 01, 2000 11:09 AM
To: [email-masked]
Subject: RE: RFC 2560 - OCSP - Clarification

Mike,

Regards,
Dave

---

From: Michael Myers <[email-masked]>
Date: Wed, 6 Sep 2000 08:52:33 -0700

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Saturday, September 02, 2000 9:35 AM
> To: Michael Myers
> Cc: Liaquat Khan; [email-masked]
> Subject: Re: RFC 2560 - OCSP - Clarification

. . .

> *In
> addition* to 2560bis, when are you expecting to provide a draft for
> OSCP extensions (i.e. OCSP-X) able to cover additional functionality
> ? 

Denis,

We intend to get out by Sept. 15 the various drafts I proposed in Pittsburg.

Mike