RE: RFC 2560 - OCSP - Clarification

RE: RFC 2560 - OCSP - Clarification

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:Khaja.Ahmed <at> identrus.com]
Sent: Thursday, August 31, 2000 4:27 PM
To: 'Karl Scheibelhofer'; Peter Sylvester; MMyers <at> verisign.com;
ietf-pkix <at> imc.org
Subject: RE: RFC 2560 - OCSP - Clarification

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:Karl.Scheibelhofer <at> iaik.at
<mailto:Karl.Scheibelhofer <at> iaik.at> ] 
Sent: Thursday, August 31, 2000 6:26 AM 
To: Peter Sylvester; MMyers <at> verisign.com; ietf-pkix <at> imc.org 
Subject: RE: RFC 2560 - OCSP - Clarification 

> -----Original Message----- 
> From: Peter Sylvester [ mailto:Peter.Sylvester <at> EdelWeb.fr
<mailto:Peter.Sylvester <at> EdelWeb.fr> ] 
> Sent: Thursday, August 31, 2000 2:27 PM 
> To: MMyers <at> verisign.com; ietf-pkix <at> imc.org; Karl.Scheibelhofer <at> iaik.at 
> 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:Karl.Scheibelhofer <at> iaik.at
<mailto:Karl.Scheibelhofer <at> iaik.at> > 
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 

RE: RFC 2560 - OCSP - Clarification

RE: RFC 2560 - OCSP - Clarification

> -----Original Message-----
> From: Peter Sylvester [mailto:Peter.Sylvester <at> EdelWeb.fr]
> Sent: Thursday, August 31, 2000 4:53 PM
> To: Peter.Sylvester <at> EdelWeb.fr; RMMyers <at> verisign.com; ietf-pkix <at> imc.org;
> Karl.Scheibelhofer <at> iaik.at
> 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:Karl.Scheibelhofer <at> iaik.at>
Institute for Applied Information Processing and Communications (IAIK)
at Technical University of Graz, Austria, http://www.iaik.at
Phone: (+43) (316) 873-5540

RE: OCSP support for historical reference to certificate suspension

> -----Original Message-----
> From: Michael Myers [mailto:MMyers <at> verisign.com]
> Sent: Thursday, August 31, 2000 8:34 PM
> To: ietf-pkix <at> imc.org
> Subject: OCSP support for historical reference to certificate suspension
>
>
> All,
>
> This is the same dialog I had Denis on the list regarding a
> requirement for
> historical references.  That ultimately led to the Archive Cutoff
> definition
> that appears in RFC 2560.
>
> The text reads:
>
>    "An OCSP responder MAY choose to retain revocation information beyond
>    a certificate's expiration. The date obtained by subtracting this
>    retention interval value from the producedAt time in a response is
>    defined as the certificate's "archive cutoff" date.
>
>    OCSP-enabled applications would use an OCSP archive cutoff date to
>    contribute to a proof that a digital signature was (or was not)
>    reliable on the date it was produced even if the certificate needed
>    to validate the signature has long since expired.
>
>    . . .
>
>    To illustrate, if a server is operated with a 7-year retention
>    interval policy and status was produced at time t1 then the value for
>    ArchiveCutoff in the response would be (t1 - 7 years)."
>
> That is, the historical accuracy of a validation of an expired certificate
> related to given digital signature is only reliable up to the
> archive cutoff
> date.  This date is arbitrary.  It could be seven years, thirty years or
> whatever local digital signature rules require.
>
> What is needed, and what Denis originally advocated for, was syntax in the
> request that enabled specification of a date field whose
> semantics were "was
> the cert valid at this date?"  However, it is unwise to predicate OCSP
> historical references on the presumption of CRL-based suspension
> mechanisms
> given the lack of Internet-scale support of this mechanism.  A
> database-centric approach is much more practical.
>
> Given the current work underway regarding 2560bis, I propose to include in
> the 2560bis work effort an optional "ValidAt" (or some such) field in the
> request syntax to accomodate this requirement.

normally, it will not be possible to determine the signature creation time
exactly. the best i can reliable determine is, that the signature was
created in a time intervall (between two time stamps). so if you plan to
include a time field, i think it would be nice to consider taking an
interval. you can make the second value optional.

regards

  Karl Scheibelhofer

--

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

RE: RFC 2560 - OCSP - Clarification

> -----Original Message-----
> From: Mathew Butler [mailto:mbutler <at> tonbu.com]
> Sent: Thursday, August 31, 2000 10:03 PM
> To: 'Peter Sylvester'; RMMyers <at> verisign.com; ietf-pkix <at> imc.org;
> Karl.Scheibelhofer <at> iaik.at
> Subject: RE: RFC 2560 - OCSP - Clarification
>
>
> 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

--

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

Re: RFC 2560 - OCSP - Clarification

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
> 
> -----Original Message-----
> From: Covey Carlin-P21262 [mailto:Carlin.Covey <at> motorola.com]
> Sent: Thursday, August 31, 2000 5:14 PM
> To: 'Khaja Ahmed'; 'Karl Scheibelhofer'; Peter Sylvester;
> MMyers <at> verisign.com; ietf-pkix <at> imc.org
> Subject: RE: RFC 2560 - OCSP - Clarification
> 
> 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:Khaja.Ahmed <at> identrus.com]
> Sent: Thursday, August 31, 2000 4:27 PM
> To: 'Karl Scheibelhofer'; Peter Sylvester; MMyers <at> verisign.com;
> ietf-pkix <at> imc.org
> Subject: RE: RFC 2560 - OCSP - Clarification
> 
> 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:Karl.Scheibelhofer <at> iaik.at
> <mailto:Karl.Scheibelhofer <at> iaik.at> ]
> Sent: Thursday, August 31, 2000 6:26 AM
> To: Peter Sylvester; MMyers <at> verisign.com; ietf-pkix <at> imc.org
> Subject: RE: RFC 2560 - OCSP - Clarification
> 
> > -----Original Message-----
> > From: Peter Sylvester [ mailto:Peter.Sylvester <at> EdelWeb.fr
> <mailto:Peter.Sylvester <at> EdelWeb.fr> ]
> > Sent: Thursday, August 31, 2000 2:27 PM
> > To: MMyers <at> verisign.com; ietf-pkix <at> imc.org;
> Karl.Scheibelhofer <at> iaik.at
> > 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:Karl.Scheibelhofer <at> iaik.at
> <mailto:Karl.Scheibelhofer <at> iaik.at> >
> 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

-- 
=======================================================
Bruno Salgueiro       (mailto:bs <at> sibs.pt)

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

RE: RFC 2560 - OCSP - Clarification

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

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? 

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

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. 

RE: RFC 2560 - OCSP - Clarification

> 
> it is the goal of our current project to create/verify legally valid
> 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'. 

RE: RFC 2560 - OCSP - Clarification

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

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?