Subject: [pkix] 2560bis

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Aug 2012 12:55:59 -0400

The results of the straw poll (which closed on Sunday are below.

recall that the options were:

     A - continue to work with the -05 version as the basis for an RFC
     B - revert to the -04 version as the basis for an RFC
     C - don't publish a clarifications document for OCSP
     D - the respondent volunteers to work on a new version of 2560bis

Name 	A 	B 	C 	D
Mike Myers 	1 	

Russ Housley 	1 	

Santosh 	
	1 	
	
Stephen Farrell 	1 	

Stefan 	1 	

David Cooper 	
	1 	
	
Martin Rex 	1 	

Tim Polk 	
	1 	
	
Peter Yee 	1 	

Simon Josephson 	1 	

Denis Pinkas 	

	1
Steve Kent 	1 	

	

TOTAL 	8 	3 	0 	1

So, we will proceed with the -05 version of the I-D.

Steve

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 14 Aug 2012 14:15:22 -0700

On Aug 14, 2012, at 9:55 AM, Stephen Kent wrote:

> Santosh	                1	
> David Cooper            1
> Tim Polk                1
> Denis Pinkas                             1

Not to cause trouble, and meaning no slight to Stefan: I note that there was no way to vote for Denis as opposed to oneself to create a new, alternate version.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Aug 2012 17:40:50 -0400

Henry,

Your observation is accurate, but no one objected to the options when I 
posted
them. Also, during the course of the poll, there were several "essay" 
responses,
none of which suggested that course of action.

So, I don't see a need to revisit this topic at this point.

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 15 Aug 2012 07:45:39 +0200

Note: This question is not about chaining OCSP. It is about what would be
compliant with the current spec.

I'm having some exchange with members of CAB forum regarding their use of
OCSP.

They want to require OCSP responders belonging to compliant CAs to NOT
return a "good" response unless they have a record of the certificate
being asked about.

It seems to me that it would be perfectly in line with current OCSP spec
to return "unknown" in case the CA has no record of the certificate being
asked about.

Current text from RFC 2560:
  The "unknown" state indicates that the responder doesn't know about
  the certificate being requested.

Does anyone have a different opinion?

/Stefan

---

From: [email-masked]
Date: Wed, 15 Aug 2012 09:17:16 +0200

For of all, thank you Henry for your posting.

Steve, do you mean that it is possible to object when the chairs are 
proposing a straw poll ?
I was not thinking it was ever possible, so I did not objected.

Steve, you said: 

"Also, during the course of the poll, there were several "essay" 
responses, none of which suggested that course of action".

This is not quite true. On August 6, I wrote to the list:

        "I hope to be able to deliver such a new version within two weeks 
from now.

        I plan to add explanations:
 
                - for OCSP clients when they build a request,
                - for OCSP clients when they verify a response.
        (...)

        I plan to work from version -05 which is not "good enough", but 
        much better than version -04 with all its annexes."

Two weeks from August 6 means August 20.

I have already spent about 20 hours to prepare this document starting from 
version -05.
.i.e. one of the two proposed versions of the strawpol (and the one which 
won the strawpol).

In fact, I did a lot more than the announced explanations, including 
additional text in 
the security considerations section. The changes, mostly additional text, 
will be indicated 
at the beginning of the document.

The draft document is currently still being reviewed by a few people 
within my company.

I still hope to be able to post it close to August 20.

On August 10, the co-chairs privately received an intermediate copy of the 
draft, so they could start 
to build their own opinion about the improvements made, but I have 
received no private response from 
the co-chairs yet at this time.

The question for me, at the time being, is whether I can post the drat as 
:

      draft-ietf-pkix-rfc2560bis-06

or whether I should post it as :

      draft-ietf-pinkas-rfc2560bis-00

Steve, would you please provide an answer to that question ?

Denis 

De :    Stephen Kent <[email-masked]>
A :     "Henry B. Hotz" <[email-masked]>
Cc :    pkix <[email-masked]>
Date :  14/08/2012 23:40
Objet : Re: [pkix] 2560bis
Envoyé par :    [email-masked]

Henry,

Steve

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Simon Tardell <[email-masked]>
Date: Wed, 15 Aug 2012 10:14:35 +0200

Skickat från min iPad

> Does anyone have a different opinion?

:)

Yes. This is the perennial debate, since the early days of OCSP.

There are actually two discussions. 1/ should we at all allow the issuance
question to be answered in the protocol 2/ if we do, how should it be
expressed? There are good arguments both ways regarding 1, but I feel we
should, and doing that answer 2 just to put this dead horse to rest once
and for all.

In my mind the three possible responses are "good", "bad" and "don't know,
ask someone else if you really want to know". Granted, the wording of the
"unknown" definition is a bit vague, but it cannot be read as an
affirmative response about the non-existence of a certificate. The real
problem is that "bad" is labeled "revoked" in the document and defined only
as such. The "good" definition on the other hand foresees the issuance
question:

   The "good" state indicates a positive response to the status inquiry.
>    At a minimum, this positive response indicates that the certificate
>    is not revoked, but does not necessarily mean that the certificate
>    was ever issued or that the time at which the response was produced
>    is within the certificate's validity interval. Response extensions
>    may be used to convey additional information on assertions made by
>    the responder regarding the status of the certificate such as
>    positive statement about issuance, validity, etc.

My position is that reading "unknown" as an assertion of non-issuance is
contrived. It is more reasonable to read it as "...the responder doesn't
know about [the status of] the certificate requested" (as in I can't map
the CertID to any CA, or I am temporarily offline with regards to that CA).
Looks very much more like an editing error than anything else.

The client can only do three thing as a result of an OCSP response: accept
the certificate, reject it, or try to get better information later or at
some other place. There is little point in having two "reject" responses,
especially if it comes at the expense of the
"try-somewhere-else-or-come-back-later-if-you-have-time" response.

I propose that we resolve this by defining the extension that the "good"
definition talks about, and changing the label of "revoked" to be "bad". I
suggest that if you want the responder to answer the question about
issuance, you use a single request extension to signal that. And if you
want to answer the question, you answer good if it is issued and not
revoked or bad/revoked if it is non-issued with reason code certificate
hold and an invalidity date at the beginning of time; adding a single
response extension in both cases to show that you have considered the
issuance question. The exact syntax of the single request/response
extension can be discussed, but it potentially could include a hash of the
certificate at hand.

This would leave us with three orthogonal response states:
"good"/"bad"/"don't-know" and clear out a lot of confusion.

/Simon

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 15 Aug 2012 10:36:03 +0200

> Does anyone have a different opinion?

I agree with you. For a responder this is definitely in line with the spec.

Regards,
Tomas

---

From: Rob Stradling <[email-masked]>
Date: Wed, 15 Aug 2012 09:40:12 +0100

On 15/08/12 09:14, Simon Tardell wrote:
<snip>
> definition talks about

http://tools.ietf.org/html/draft-hallambaker-ocspdigest

> , and changing the label of "revoked" to be "bad".

If a label change is permitted (in 2560bis), I'd prefer to see "good" 
changed to "not revoked".

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 15 Aug 2012 11:14:09 +0200

Hi Simon,

Your read more into my question than I asked (or proposed).

I never asked/suggested that the unknown response should be interpreted as a
confirmation that the certificate was never issued.
The question was whether it would be conformant to send the "unknown"
response if the cert has never been issued.

Do you see the difference?

In the context of my question, the client would not know that the
certificate was never issued. It would simply know that the responder don't
know about the cert for any given reason you mention.

Yes I agree we would need an extension to signal (if at all) an explicit
confirmation that the certificate was never issued. The question is still
what response that could be returned if that extension states that the
certificate was never issued.

There are only three to choose from good, revoked and unknown. It seems to
me that "unknown" is the only reasonable alternative as both "good" and
"revoked" are clearly wrong.

/Stefan

From:  Simon Tardell <[email-masked]>
Date:  Wednesday, 15 August, 2012 10:14 AM
To:  Stefan Santesson <[email-masked]>
Cc:  pkix <[email-masked]>
Subject:  Re: [pkix] Use of the OSCP unknown response

> should, and doing that answer 2 just to put this dead horse to rest once and
> for all.
> 
> In my mind the three possible responses are "good", "bad" and "don't know, ask
> someone else if you really want to know". Granted, the wording of the
> "unknown" definition is a bit vague, but it cannot be read as an affirmative
> response about the non-existence of a certificate. The real problem is that
> "bad" is labeled "revoked" in the document and defined only as such. The
> "good" definition on the other hand foresees the issuance question:
> 
> contrived. It is more reasonable to read it as "...the responder doesn't know
> about [the status of] the certificate requested" (as in I can't map the CertID
> to any CA, or I am temporarily offline with regards to that CA). Looks very
> much more like an editing error than anything else.
> 
> The client can only do three thing as a result of an OCSP response: accept the
> certificate, reject it, or try to get better information later or at some
> other place. There is little point in having two "reject" responses,
> suggest that if you want the responder to answer the question about issuance,
> you use a single request extension to signal that. And if you want to answer
> the question, you answer good if it is issued and not revoked or bad/revoked
> if it is non-issued with reason code certificate hold and an invalidity date
> at the beginning of time; adding a single response extension in both cases to
> show that you have considered the issuance question. The exact syntax of the
> single request/response extension can be discussed, but it potentially could
> include a hash of the certificate at hand.
>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 15 Aug 2012 11:20:34 +0200

I'm reluctant to rename these labels of OCSP.

These labels are not UI components, they are simply labels used in the
protocol.
Changing labels in ASN.1 is problematic as ASN.1 often is compiled into
code where the labels form variable names.

Changing label names thus creates unnecessary problems for implementers.

It is better then to clarify the labels if necessary.

/Stefan

---

From: Rob Stradling <[email-masked]>
Date: Wed, 15 Aug 2012 10:44:14 +0100

On 15/08/12 10:14, Stefan Santesson wrote:
> I never asked/suggested that the unknown response should be interpreted
> as a confirmation that the certificate was never issued.
> certificate was never issued. It would simply know that the responder
> don't know about the cert for any given reason you mention.
>
> confirmation that the certificate was never issued. The question is
> still what response that could be returned if that extension states that
> the certificate was never issued.
>
> There are only three to choose from good, revoked and unknown. It seems
> to me that "unknown" is the only reasonable alternative

RFC2560 says:

How could "unknown" possibly be the correct response if the responder 
_does know_ for certain that the "certificate being requested" was never 
issued?

 > as both "good" and "revoked" are clearly wrong.

I agree that "revoked" is clearly wrong, since a certificate must first 
have been issued before it can be revoked.

So IMHO, the "good" state would have to be used because "good...does not 
necessarily mean that the certificate was ever issued".

(But since the CABForum have decided to disallow "good" for non-issued 
certs, I conclude that CABForum-compliant CAs simply cannot use a signed 
OCSP Response at all for non-issued certs.  They'll have to use the 
unsigned "unauthorized" Response instead, as per the (extended) 
definition in RFC5019 Section 2.2.3).

> /Stefan
>
>
> From: Simon Tardell <[email-masked] <mailto:[email-masked]>>
> To: Stefan Santesson <[email-masked] <mailto:[email-masked]>>
> Cc: pkix <[email-masked] <mailto:[email-masked]>>
>     15 aug 2012 kl. 07:45 skrev Stefan Santesson <[email-masked]
>     <mailto:[email-masked]>>:
>
>     There are actually two discussions. 1/ should we at all allow the
>     issuance question to be answered in the protocol 2/ if we do, how
>     should it be expressed? There are good arguments both ways regarding
>     1, but I feel we should, and doing that answer 2 just to put this
>     dead horse to rest once and for all.
>
>     In my mind the three possible responses are "good", "bad" and "don't
>     know, ask someone else if you really want to know". Granted, the
>     wording of the "unknown" definition is a bit vague, but it cannot be
>     read as an affirmative response about the non-existence of a
>     certificate. The real problem is that "bad" is labeled "revoked" in
>     the document and defined only as such. The "good" definition on the
>     other hand foresees the issuance question:
>
>     My position is that reading "unknown" as an assertion of
>     non-issuance is contrived. It is more reasonable to read it as
>     "...the responder doesn't know about [the status of] the certificate
>     requested" (as in I can't map the CertID to any CA, or I am
>     temporarily offline with regards to that CA). Looks very much more
>     like an editing error than anything else.
>
>     The client can only do three thing as a result of an OCSP response:
>     accept the certificate, reject it, or try to get better information
>     later or at some other place. There is little point in having two
>     "reject" responses, especially if it comes at the expense of the
>     I propose that we resolve this by defining the extension that the
>     "good" definition talks about, and changing the label of "revoked"
>     to be "bad". I suggest that if you want the responder to answer the
>     question about issuance, you use a single request extension to
>     signal that. And if you want to answer the question, you answer good
>     if it is issued and not revoked or bad/revoked if it is non-issued
>     with reason code certificate hold and an invalidity date at the
>     beginning of time; adding a single response extension in both cases
>     to show that you have considered the issuance question. The exact
>     syntax of the single request/response extension can be discussed,
>     but it potentially could include a hash of the certificate at hand.
>
>     >[email-masked] <mailto:[email-masked]>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Simon Tardell <[email-masked]>
Date: Wed, 15 Aug 2012 11:55:38 +0200

On Wed, Aug 15, 2012 at 11:14 AM, Stefan Santesson <[email-masked]>wrote:

> I never asked/suggested that the unknown response should be interpreted as
> a confirmation that the certificate was never issued.

Yes, but what do you want to achieve, as a responder? If you want to make
the client reject the certificate you really have to answer "revoked". If
you answer "unknown", a lot of clients will have the option to fall back to
some other source of revocation information, be it CRLs or another OCSP
responder. And then you have a security problem. Better to answer something
safe from the responder.

Also, I think it wouldn't be compliant to answer "unknown". If you know the
certificate hasn't been issued, you know about the certificate (viz. the
property that it wasn't issued), which clearly contradicts the wording in
the RFC.

> "revoked" are clearly wrong.

I don't agree that using revoked would be clearly wrong. What is wrong is
the current wording of "revoked", which is not aligned with the wording of
"good". If you clarify/correct the wording of the "revoked" definition
according to my suggestion you would not change anything for clients who
don't understand the extension, and you would also preserve the possibility
of redundancy at the protocol level for PKIs that need it (and while it
might be use case of limited application there definitely are those out
there that require it).

The extension would of course only be needed if the client cared about why
he shouldn't accept the certificate.

Also, I think the use of certificate-hold to signal not-issued aligns quite
well. Both are conditions that can change in the future so that the
certificate becomes valid for use. So while it could seem odd that a
certificate that hasn't been issued is already a kind of revoked I think
that is only about labels not about actual semantics.

I think we should write in the RFC what the client is expected to do in
each case:
"good" it MAY accept the certificate
"revoked" it SHOULD reject the certificate
"unknown" it may try some  other revocation source (as defined by whatever
policy you have), or try again later if it has the possibility, failing
that it SHOULD reject the certificate

/Simon

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 15 Aug 2012 12:03:33 +0200

>From an OCSP responder's perspective this sounds quite logical to me.
If the OCSP responder has been handed a positive list, and the requested
cert is not on that lists, then the OCSP responder simply "does not know"
about that certificate.

In theory, that certificate may have been issued but has not yet made it
to the positive list. Perhaps that certificate has been issued ahead of
it's validity period and will not make it to the positive list until it
does.

An interesting question is what would happen if an "unknown" response was
sent.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 15 Aug 2012 12:06:51 +0200

Simon,

I thin you have a point here.
I could definitely see the security advantage of declaring the case when the
CA knows the certificate to never have been issued to reply "revoked".

I guess this could be clarified in the text of 2560bis.

Even though I still see some cases where "unknown" could be valid (see
previous mail), I do think you are right in the case when the cert is known
to never have been issued.

/Stefan

From:  Simon Tardell <[email-masked]>
Date:  Wednesday, 15 August, 2012 11:55 AM
To:  Stefan Santesson <[email-masked]>
Cc:  pkix <[email-masked]>
Subject:  Re: [pkix] Use of the OSCP unknown response

> 
> 
> On Wed, Aug 15, 2012 at 11:14 AM, Stefan Santesson <[email-masked]> wrote:
>> Hi Simon,
>> 
>> In the context of my question, the client would not know that the certificate
>> was never issued. It would simply know that the responder don't know about
>> the cert for any given reason you mention.
> 
> Yes, but what do you want to achieve, as a responder? If you want to make the
> client reject the certificate you really have to answer "revoked". If you
> answer "unknown", a lot of clients will have the option to fall back to some
> other source of revocation information, be it CRLs or another OCSP responder.
> And then you have a security problem. Better to answer something safe from the
> responder. 
> 
> property that it wasn't issued), which clearly contradicts the wording in the
> RFC.
>  
>> There are only three to choose from good, revoked and unknown. It seems to me
>> that "unknown" is the only reasonable alternative as both "good" and
> I don't agree that using revoked would be clearly wrong. What is wrong is the
> current wording of "revoked", which is not aligned with the wording of "good".
> If you clarify/correct the wording of the "revoked" definition according to my
> suggestion you would not change anything for clients who don't understand the
> extension, and you would also preserve the possibility of redundancy at the
> protocol level for PKIs that need it (and while it might be use case of
> limited application there definitely are those out there that require it).
> 
> The extension would of course only be needed if the client cared about why he
> shouldn't accept the certificate.
> 
> certificate that hasn't been issued is already a kind of revoked I think that
> is only about labels not about actual semantics.
> 
> I think we should write in the RFC what the client is expected to do in each
> case:
> policy you have), or try again later if it has the possibility, failing that
> it SHOULD reject the certificate
> 
> /Simon
>  
>> 
>> /Stefan
>> 
>> 
>>> know about [the status of] the certificate requested" (as in I can't map the
>>> CertID to any CA, or I am temporarily offline with regards to that CA).
>>> issuance, you use a single request extension to signal that. And if you want
>>> to answer the question, you answer good if it is issued and not revoked or
>>> bad/revoked if it is non-issued with reason code certificate hold and an
>>> invalidity date at the beginning of time; adding a single response extension
>>> in both cases to show that you have considered the issuance question. The
>>> exact syntax of the single request/response extension can be discussed, but
>>> it potentially could include a hash of the certificate at hand.
>>>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 15 Aug 2012 10:16:37 -0400

> I was not thinking it was ever possible, so I did not objected.
you could object, but the straw poll would take place anyway.
>         "I hope to be able to deliver such a new version within two 
> weeks from now.
>
My comment was in tended to say that none of the essay responses said that
someone wanted to join you in preparing a different submission, which is my
interpretation of the essence of Henry's question,
> On August 10, the co-chairs privately received an intermediate copy of 
> the draft, so they could start
I did not reply since:
     - I don't work on Fridays and thus did not see your message until 
Monday.
     - I tallied the straw poll responses and it was clear
       that option A was the winner, by a large margin.
> The question for me, at the time being, is whether I can post the drat 
> as :
>
no, you cannot post this as -06.
>       draft-ietf-pinkas-rfc2560bis-00
you can post an individual submission.

Steve

---

From: "Ben Wilson" <[email-masked]>
Date: Wed, 15 Aug 2012 09:26:10 -0600

I agree with Rob with regard to an unsigned  "unauthorized" response.   If
certificate status is indeed unknown, then a signed "unknown" seems
appropriate (but illogical where a CA should know whether the certificate
was issued -- it should not say "unknown" if it knows the certificate was
not issued).  A delegated OCSP responder could respond "unknown".
Otherwise, saying "unknown" would be a lie.  I am very opposed to responding
"good" if there is no record of issuance, that is a lie, too.  There are
legal liability issues with misrepresenting the truth -- fraud, negligent
misrepresentation, etc.  The fact that it is a technical standard should not
be used as an excuse when the response has legal implications - (ala
Lessig's book "Code").   If extensions in this area are needed, then they
should be for the "unknown" and "unauthorized" responses.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rob
Stradling
Sent: Wednesday, August 15, 2012 3:44 AM
To: Stefan Santesson
Cc: pkix
Subject: Re: [pkix] Use of the OSCP unknown response

On 15/08/12 10:14, Stefan Santesson wrote:
> I never asked/suggested that the unknown response should be 
> interpreted as a confirmation that the certificate was never issued.
> Yes I agree we would need an extension to signal (if at all) an 
> explicit confirmation that the certificate was never issued. The 
> question is still what response that could be returned if that 
> extension states that the certificate was never issued.
>
> There are only three to choose from good, revoked and unknown. It 
> seems to me that "unknown" is the only reasonable alternative

RFC2560 says:

How could "unknown" possibly be the correct response if the responder _does
know_ for certain that the "certificate being requested" was never issued?

 > as both "good" and "revoked" are clearly wrong.

I agree that "revoked" is clearly wrong, since a certificate must first have
been issued before it can be revoked.

(But since the CABForum have decided to disallow "good" for non-issued
certs, I conclude that CABForum-compliant CAs simply cannot use a signed
OCSP Response at all for non-issued certs.  They'll have to use the unsigned
"unauthorized" Response instead, as per the (extended) definition in RFC5019
Section 2.2.3).

COMODO CA Limited, Registered in England No. 04058690 Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by
replying to the e-mail containing this attachment. Replies to this email may
be monitored by COMODO for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no
liability can be accepted and the recipient is requested to use their own
virus checking software.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Rob Stradling <[email-masked]>
Date: Wed, 15 Aug 2012 16:37:32 +0100

On 15/08/12 16:26, Ben Wilson wrote:
<snip>
> I am very opposed to responding "good" if there is no record of issuance,
 > that is a lie, too.  There are legal liability issues with
 > misrepresenting the truth

In RFC2560, "good" is just a label, and the definition of the label 
clearly says...

    was ever issued...

Maybe it was a bad choice of label name.  Maybe it was a bad design 
decision to omit proof of (non-)issuance from the core protocol.

But I fail to see how RFC2560's definition of the "good" label 
misrepresents the truth.

<snip>

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 15 Aug 2012 19:11:20 +0200

> But I fail to see how RFC2560's definition of the "good" label

I agree -- I don't think we should redefine OCSP semantics now.  I
believe we should only do editorial fixes to resolve ambiguities and
bugs.  Stefan's initial proposed text does, I believe, redefine
semantics, so I would be against it.  Members of CAB forum can address
their concern by publishing a OCSP profile that they promise to follow.

/Simon

---

From: [email-masked]
Date: Wed, 15 Aug 2012 20:08:32 +0200

Rob,

The citation you provided has been  truncated. What is important is the 
end of the text.
Hereafter is the full text:

If the certificate was never issued and if the OCSP responder is using 
only CRLs, it will return good.

If the certificate was never issued and if  the OCSP responder knows that 
the certificate was never issued, 
it will also return "good", but MAY use a single response extension to 
convey additional information such as 
a positive statement about issuance.

So, the status should be "good" (and not revoked, nor unknown).

The question is whether we should take the opportunity of the revision of 
RFC 2560 to define 
such a single extension, or leave the definition of such an extension to 
the CAB forum ?
.
Denis

De :    Rob Stradling <[email-masked]>
A :     [email-masked]
Cc :    'Stefan Santesson' <[email-masked]>, 'pkix' <[email-masked]>
Date :  15/08/2012 17:39
Objet : Re: [pkix] Use of the OSCP unknown response
Envoyé par :    [email-masked]

<snip>

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 15 Aug 2012 11:40:16 -0700

+1

On Aug 15, 2012, at 2:55 AM, Simon Tardell wrote:

> I think we should write in the RFC what the client is expected to do in each case:
> "unknown" it may try some  other revocation source (as defined by whatever policy you have), or try again later if it has the possibility, failing that it SHOULD reject the certificate

-------

As a separate issue I wish we would include some of T. Miller's discussion of what an OCSP responder is actually capable of saying.  

I'm oversimplifying, but basically there are only ever two responses that a responder can give:  if it has a CRL it can say "revoked" or "unknown" (IMO it would be bad practice to say "good", though the current spec implies you should say "good" instead of "unknown").  If it has a white-list, it can say "good" or "unknown".  (While the spec might allow it, I think it would be silly to respond "good" for a cert not on the white list. ;-)  

The only way I see to justify three responses is if the responder has both a black and a white list.  The only way I see for an OCSP responder to provide useful actionable information is if we change something so a client can consistently interpret and act on the responses, regardless of what kind of information the OCSP responder is using.

If we don't want to change the base definition of "good" so it actually means on-the-white-list, OK.  We can define a "really good" extension, like Denis says.  In that case I don't see any useful distinction between "good" (but not "really good") and "unknown".

---

From: [email-masked]
Date: Wed, 15 Aug 2012 20:50:17 +0200

Errata. Replace: 

with

it will also return "good", but SHALL use a single response extension to 
convey additional information: 
a negative statement about issuance. 

Denis

De :    [email-masked]
A :     Rob Stradling <[email-masked]>
Cc :    'pkix' <[email-masked]>, 'Stefan Santesson' <[email-masked]>
Date :  15/08/2012 20:09
Objet : Re: [pkix] Use of the OSCP unknown response
Envoyé par :    [email-masked]

Rob, 

De :        Rob Stradling <[email-masked]> 
A :        [email-masked] 
Cc :        'Stefan Santesson' <[email-masked]>, 'pkix' 
<[email-masked]> 
Date :        15/08/2012 17:39 
Objet :        Re: [pkix] Use of the OSCP unknown response 
Envoyé par :        [email-masked] 

<snip>

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 15 Aug 2012 16:03:02 -0400

> I'm oversimplifying, but basically there are only ever two responses that a responder can give:  if it has a CRL it can say "revoked" or "unknown" (IMO it would be bad practice to say "good", thoug…

By this logic, the only response a responder can give is "unknown," 
unless the request includes a (yet to be defined) extension that 
includes a copy of the certificate or a hash of the certificate. Since 
the request only includes hashes of the issuer's name and public key and 
the serial number of the certificate, even if the responder has a white 
list, the responder cannot know whether the requester is referring to 
the certificate on the white list or to a different certificate that 
just happens to have the same issuer name and serial number, and that 
has been signed by the same key (or that at least appears to have been 
signed by the same key).  So, I guess that until a new request extension 
has been defined it would be "silly" for a responder to ever give a 
response other than "unknown."

> The only way I see to justify three responses is if the responder has both a black and a white list.

It is very easy to justify three responses as long as you accept that 
OCSP is a certificate status responder and not a validation server.  A 
response from an OCSP responder, by itself, it useless. The OCSP 
response only serves to help perform Step (a)(3) in Section 6.1.3 of the 
path validation algorithm in RFC 5280 (i.e., verify that the certificate 
is not revoked).

Since the labels that are assigned to the three possible responses from 
the OCSP responder seem to object to the use of one particular response 
in the case of a certificate that has not been revoked, but for which 
the responder does not have sufficient information to ensure was issued, 
let's refer to the responses as (A), (B), and (C).

1.  A response of (A) indicates that the responder knows that the 
specified certificate has not been revoked (whether it was ever issued 
or not).  This means that the certificate satisfies the condition 
specified in Step (a)(3) in Section 6.1.3 of the path validation 
algorithm (i.e., it is not revoked).

2. A response of (B) indicates that the responder knows that the 
specified certificate has been revoked.  This means that the certificate 
does not satisfy the condition specified in Step (a)(3) in Section 6.1.3 
of the path validation algorithm, which triggers the following:

    If any of steps (a), (b), (c), or (f) fails, the procedure
    terminates, returning a failure indication and an appropriate reason.

3. A response of (C) indicates that the responder does not know the 
status of the certificate.  In this case the client may try another way 
to verify that the certificate has not been revoked (e.g., ask a 
different responder or obtain a CRL).  [If the client is unable to 
verify the certificate's revocation status by another means, then it 
will either have to reject the certificate or make a risk-based decision 
to accept the certificate despite being unable to verify that it is not 
revoked.]

I would guess that a response of (C) is most likely to occur in the case 
of a locally trusted OCSP responder.  My client may be configured to ask 
the locally configured OCSP responder first, and then if the response is 
(C) attempt to determine the certificate's status by using an OCSP 
responder referenced in the AIA extension in the certificate or by using 
a CRL obtained via the CDP extension in the certificate.

> The only way I see for an OCSP responder to provide useful actionable information is if we change something so a client can consistently interpret and act on the responses, regardless of what kind of information the OCSP responder is using.

As noted above, the current protocol already allows an OCSP responder to 
provide "useful actionable information."   Of course, clients won't be 
able to consistently interpret and act on responses if responders apply 
their own (personal) interpretations to the three possible status 
responses.  If some developers decide that it is "silly" for a responder 
to provide a response of (A) unless working from a white list and so 
have their responders provide a response of (C) for any certificate 
isn't known to be revoked, then clients will no longer have "useful 
actionable information."  This may not matter for some clients if they 
are configured to ask the OCSP responder about the certificate, but then 
continue on with validation unless a response of (B) is received (i.e., 
if all other aspects of path validation are successful, then accept the 
certificate even if no response is received from the OCSP responder or 
if a response of (A), (C), or even a error response is received).  
However, it will make a big difference to any client configured to fail 
safe by failing path validation unless it can actually verify that the 
certificate is not revoked.

---

From: "Ben Wilson" <[email-masked]>
Date: Wed, 15 Aug 2012 14:29:30 -0600

David Cooper wrote:  

>
>unless the request includes a (yet to be defined) extension that includes a
copy of the certificate or a hash of the certificate. 

What would it take to get clients to hash the certificate, send the hash as
part of the OCSP request, and get responders to respond accordingly?

---

From: "Rich Smith" <[email-masked]>
Date: Wed, 15 Aug 2012 17:28:47 -0400

Whether you call the responses Good, Revoked and Unknown, OR; A, B and C,
OR; Alice, Bob and Charlie, the RFC is logically flawed in that Good, by
containing, "...but does not necessarily mean that the certificate was ever
issued..." overlaps status Unknown.  As long as that is the case
implementations will be flawed and confused.

And since the response is in fact called 'Good' and not 'A', and not
'Alice', a response of 'Good' for an unissued certificate may not, as Rob
has pointed out, misrepresent the truth as per the definition provided in
the RFC, but it most certainly does misrepresent the truth in terms of what
most people understand the word and concept of 'Good' to mean.

-- 
Regards,
Rich Smith
Validation Manager
Comodo
http://www.comodo.com

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David A. Cooper
> Sent: Wednesday, August 15, 2012 4:03 PM
> To: pkix
> > I'm oversimplifying, but basically there are only ever two responses
> > that a responder can give:  if it has a CRL it can say "revoked" or
> > "unknown" (IMO it would be bad practice to say "good", though the
> > current spec implies you should say "good" instead of "unknown").  If
> > it has a white-list, it can say "good" or "unknown".  (While the spec
> > might allow it, I think it would be silly to respond "good" for a
> cert
> > not on the white list. ;-)
> 
> the request only includes hashes of the issuer's name and public key
> and the serial number of the certificate, even if the responder has a
> white list, the responder cannot know whether the requester is
> referring to the certificate on the white list or to a different
> certificate that just happens to have the same issuer name and serial
> number, and that has been signed by the same key (or that at least
> appears to have been signed by the same key).  So, I guess that until a
> new request extension has been defined it would be "silly" for a
> responder to ever give a response other than "unknown."
> 
> response only serves to help perform Step (a)(3) in Section 6.1.3 of
> the path validation algorithm in RFC 5280 (i.e., verify that the
> certificate is not revoked).
> 
> the responder does not have sufficient information to ensure was
> issued, let's refer to the responses as (A), (B), and (C).
> 
> specified certificate has been revoked.  This means that the
> certificate does not satisfy the condition specified in Step (a)(3) in
> Section 6.1.3 of the path validation algorithm, which triggers the
> following:
> 
> will either have to reject the certificate or make a risk-based
> decision to accept the certificate despite being unable to verify that
> it is not revoked.]
> 
> I would guess that a response of (C) is most likely to occur in the
> case of a locally trusted OCSP responder.  My client may be configured
> to ask the locally configured OCSP responder first, and then if the
> response is
> responder referenced in the AIA extension in the certificate or by
> using a CRL obtained via the CDP extension in the certificate.
> 
> > The only way I see for an OCSP responder to provide useful actionable
> information is if we change something so a client can consistently
> interpret and act on the responses, regardless of what kind of
> information the OCSP responder is using.
> 
> responses.  If some developers decide that it is "silly" for a
> responder to provide a response of (A) unless working from a white list
> and so have their responders provide a response of (C) for any
> certificate isn't known to be revoked, then clients will no longer have
> "useful actionable information."  This may not matter for some clients
> if they are configured to ask the OCSP responder about the certificate,
> but then continue on with validation unless a response of (B) is
> received (i.e., if all other aspects of path validation are successful,
> then accept the certificate even if no response is received from the
> OCSP responder or if a response of (A), (C), or even a error response
> is received).

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 15 Aug 2012 15:07:48 -0700

On Aug 15, 2012, at 1:03 PM, David A. Cooper wrote:

> By this logic, the only response a responder can give is "unknown," unless the request includes a (yet to be defined) extension that includes a copy of the certificate or a hash of the certificate.

Perhaps you're trying to tweak me, but I think I agree with you.  ;-)

---

From: [email-masked] (Martin Rex)
Date: Thu, 16 Aug 2012 01:12:28 +0200 (CEST)

> most people understand the word and concept of 'Good' to mean.

RFC2560 defined only 3 response types:  "good", "revoked", "unknown",
where what is currently described covers only a fraction of what is
actually possible.

One of the purposes of OCSP, as defined by rfc2560, is a protocol to
outsource CRL checking.  The elaborate explanation for "good" is only
proof of how lousy CRLs are in the first place, because you really
don't know much at all.

It seems to have never occured to the architects of X.509 that fraudulent
cert issuance could happen, and consumer might appreciate when revocation
checking did at least offer some amount of risk management for certain
aspects of fraudulently issued certs that subvert the design of
CRL-based revocation checking (such as multiple certs from the same CA with
the same serial number or certs for which records of issuance were destroyed,
so that the CA is not (no longer) aware these certs have been issued).

For the way forward, the original description is much less important
than the behaviour of the installed base to each of the three responses,
and the intention of the CA, which RP behaviour does it want to induce.

If a CA runs an OCSP server with access to the cert issue records or the
certs database, then this CA might want to send OCSP responses
"revoked (on hold)" for all requests about certs that it can not positively
identify to have issued.

This is not possible for running an OCSP server with a newly invented,
periodically issued whitelist of existing certs, unless you're OK with
declaring all newly issued certs "revoked (on hold)" as well, until the
whitelist update covering the newly issued cert is complete.

The "unknown" status looks pretty useless to me for the purpose of
conveying "does not exist" status, because it will probably
cause RPs in the installed base to perform CRL checking (which is also pure
blacklisting), so that extra overhead is likely not going to lead to a better
result, but will typically cause additional network round trips and
repeat of processing that the OCSP server already did
(but could not convey with the 3-state response "good", "revoked", "unknown").

-Martin

---

From: [email-masked]
Date: Thu, 16 Aug 2012 15:39:17 +0200

Rich,

There is indeed a solution which uses the current text of RFC 2560, 
without the need to tweak any current meaning 
of "good", "revoked" or "unknown".

The solution allows all current OCSP clients (if they comply with RFC 
2560) to reject the target certificate.

The solution allows "new" OCSP clients, compliant of the solution, to know 
that a white list of certificates 
has been used by the OCSP server and that the target serial number is 
unknown in that list.

In order to provide everybody with the opportunity to find the solution by 
himself, I will post additional  information 
a little bit later in another post, as a reply to Henry B. Hotz.

:-)

Denis

De :    "Rich Smith" <[email-masked]>
A :     "'David A. Cooper'" <[email-masked]>, "'pkix'" 
<[email-masked]>
Date :  15/08/2012 23:29
Objet : Re: [pkix] Use of the OSCP unknown response
Envoyé par :    [email-masked]

containing, "...but does not necessarily mean that the certificate was 
ever

the RFC, but it most certainly does misrepresent the truth in terms of 
what

-- 
Regards,
Rich Smith
Validation Manager
Comodo
http://www.comodo.com

> certificate is not revoked.
[pièce jointe "smime.p7s" supprimée par Denis PINKAS/FR/BULL] 
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: [email-masked]
Date: Fri, 17 Aug 2012 09:57:33 +0200

Follow up of the previous mail on the same topic.

There is a solution which does not use any extension in the request.

This solution uses a new singleResponse extension, which indicates that 
the serial number of the certificate is not present 
in the list of the certificates issued by the CA to which the OCSP 
responder has access.

When this extension contains that indication, the critical flag SHALL be 
set.

OCSP clients unable to process this singleResponse extension SHALL 
consider that the content of the single response 
cannot be interpreted (this is the usual way to process an extension that 
is marked critical) and this leads to an error 
case (e.g. single response content invalid).

Clients able to process this singleResponse extension will know that the 
serial number of the certificate is not present 
in the list of the certificates issued by the CA to which the OCSP 
responder has access.

Denis 

De :    "Henry B. Hotz" <[email-masked]>
A :     "David A. Cooper" <[email-masked]>
Cc :    pkix <[email-masked]>
Date :  16/08/2012 00:20
Objet : Re: [pkix] Use of the OSCP unknown response
Envoyé par :    [email-masked]

> By this logic, the only response a responder can give is "unknown," 
unless the request includes a (yet to be defined) extension that includes 
a copy of the certificate or a hash of the certificate.

---

From: [email-masked] (Martin Rex)
Date: Sat, 18 Aug 2012 02:25:02 +0200 (CEST)

> There is a solution which does not use any extension in the request.

Uh-oh!

If the OCSP requestor does not indicate that it supports new response
semantics, then the OCSP responder can not distinguish rfc2560 clients
from updated clients!

The prerequisite for any negotiation of new features is that
the requst contains an indication about the clients additional
capabilities.  Without it, the server should not be _extremely_
conservative about changes in the response.

> When this extension contains that indication, the critical flag SHALL be 

Now that looks quite dangerous to me.  A client that did not indicate
to understand the extension is indistinguishable from an simple
rfc2560 client.  And the simple rfc2560 should drop the OCSP response
with an unrecognized critical extension.  Which will either result
in the client to skip OCSP checking (bad) or to try other responders
or CRLs (also bad).

What the (CAs) OCSP responder should answer depends on what the OCSP
responder wants the client/RP to do.  If the OCSP responder wants
the client/RP to *NOT* trust that cert, then "revoked (on hold)" is
the only sensible response.

If the OCSP responder wants to include this information only for those
(new/updated) clients/RP that care about this info, then "good" with
a non-critical extension would be OK.

"unknown" implies that the client/RP should ask someone else,
and a non-marginal number of client/RPs might skip the revocation
check when receiving an unknown response (treating it similar
to a network connection failure to the OCSP responder).

> case (e.g. single response content invalid).

This leads to the client/RP either skipping revocation or
falling back to CRL checking--where the "not issued" state can
not be conveyed at all.  I consider this behaviour non-sensical
with respect to the installed base.

> in the list of the certificates issued by the CA to which the OCSP 

Client/RPs do not want to know that.  They instead want to know
"can I trust this cert"?  An OCSP server that says "This cert may have
not been issued" rather than "Do NOT trust this cert" is chickening out.

In order to make a whitelist check reasonably foolproof, the client/RP
should send either the whole cert or at least the certificate(!) hash
and the validity of the certificate in the OCSP request.

The whitelist lookup should be performed with the certificate hash,
and the validity enables an OCSP responder to determine whether the
whitelist records it has access to are sufficiently "fresh" to
determine whether the cert in question has been issued.

-Martin

---

From: Tom Ritter <[email-masked]>
Date: Sun, 19 Aug 2012 11:58:28 -0400

> determine whether the cert in question has been issued.

I agree with this completely, including hash lookups.

Trying to map blacklist and whitelist information is not what the client is
interested in.  It's very rare that a responder should say "I can't
assertively speak for this certificate, go elsewhere." The responder should
be giving "trust this" or "don't trust this".

---

From: [email-masked]
Date: Mon, 20 Aug 2012 09:29:26 +0200

Martin, 

See my responses in the text below:

De :    [email-masked] (Martin Rex)
A :     [email-masked]
Cc :    "Henry B. Hotz" <[email-masked]>, pkix <[email-masked]>
Date :  18/08/2012 02:25
Objet : Re: [pkix] Use of the OSCP unknown response

Uh-oh!

The prerequisite for any negotiation of new features is that
the request contains an indication about the clients additional
capabilities.  Without it, the server should not be _extremely_
conservative about changes in the response.

[Denis: No. The solution does not need any change in the request]

[Denis: An OCSP client which does not recognize a critical extension 
within singleExtensions SHALL drop the individual response where that 
critical extension is present but may accept other responses within 
the field responses"]

[Denis: Again, if a critical extension is present within singleExtensions 
in an individual response then the client SHALL drop the individual 
response 
whatever the value of CertStatus may be. So it is irrelevant to argue 
about the value of the CertStatus] 

[Denis: No. See above]

[Denis: No. See above]

[Denis: Compliant clients shall not skip revocation as you say. 
However, your second argument is a valid consideration. I am preparing 
a draft for the definition of a new extension within singleExtensions 
and I have added the following note:

   NOTE: OCSP clients should not use a fallback mechanism based on CRLs 
         when they encounter within singleExtensions an extension which 
         is not understood and which is marked critical.]

[Denis: In the draft I am preparing, the server may return the hash. 
So you get the same property, but without the need to change the syntax 
of the request. Note: the client may not know in advance whether the 
server 
is using or not white lists]

[Denis: returning the hash provides the same benefit. The comparison 
will be done by the client rather than by the server].

-Martin

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 20 Aug 2012 10:04:48 +0200

Of course some organizations have already started using extensions like 
some things discussed here.

I'm pretty sure some of you are familiar with the german Common PKI. 
They have an OCSP extension (non critical):

-----
Common PKI Profile: This Common PKI-specification defines the private 
single response extension CertHash that may deliver a positive statement 
about the availability
of a certificate.

(oid 1.3.36.8.3.13)

SingleResponse extension: the responder may include this --
extension in a response to send the hash of the requested
certificate to the requestor. This hash serves as evidence that
the certificate is known to the responder (i.e. it is available in
the queried directory) and will be used as means to provide a
positive statement of availability.
-----

While I am usually fiercly against extending standard protocols, this 
seems like one of the simplest ways to inform the client with extra 
information about what exactly is included in the "good" response.

CAB Forum could use this possible information in a number of ways, 
including requiring that EV CAs include this or the cert will be rejected.

The client is the end point enforcing a specific policy, and it seems to 
me that most OCSP consuming systems do not have a lot of random clients 
that interpret the responders responses in very different ways.
For the browser world CAB Forum should be able to profile OCSP as to not 
require large changes to the spec.

Cheers,
Tomas

On 08/20/2012 09:29 AM, [email-masked] wrote:
> ------------------------------------------------------------------------
>
>
> *[Denis: No. The solution does not need any change in the request]*
>
> *[Denis: An OCSP client which does not recognize a critical extension *
> *within singleExtensions SHALL drop the individual response where that
> the field responses"]*
> *[Denis: Again, if a critical extension is present **within
> singleExtensions
> response *
> *whatever the value of CertStatus may be. So it is irrelevant to argue *
> *about the value of the CertStatus] *
>
> *[Denis: No. See above]*
> *[Denis: No. See above]*
> *[Denis: Compliant clients shall not skip revocation as you say. *
> *However, your second argument is a valid consideration. I am preparing *
> *a draft for the definition of a new extension within singleExtensions *
> *and I have added the following note:*
>
> *   NOTE: OCSP clients should not use a fallback mechanism based on CRLs *
> *         when they encounter within singleExtensions an extension which *
> *         is not understood and which is marked critical.**]*
>
> *[Denis: In the draft I am preparing, the server may return the hash. *
> *So you get the same property, but without the need to change the syntax *
> *of the request. Note: the client may not know in advance whether the
> server *
> *is using or not white lists]*
>
> *[Denis: returning the hash provides the same benefit. The comparison *
> *will be done by the client rather than by the server].*
>
> -Martin
>
>

---

From: [email-masked]
Date: Mon, 20 Aug 2012 10:27:23 +0200

Tomas,

Thank you for the information,

However, this extension does not help if the OCSP client does not 
understand it, 
since it is a non critical extension.

I am preparing a draft for an extension which provides benefits in both 
situations, 
i.e. whether the OCSP client understands it or whether it does not. 
Of course, the benefits are exactly not the same.

Denis

De :    Tomas Gustavsson <[email-masked]>
A :     [email-masked]
Date :  20/08/2012 10:04
Objet : Re: [pkix] Use of the OSCP unknown response,    german CertHash 
extension?
Envoyé par :    [email-masked]

-----

(oid 1.3.36.8.3.13)

Cheers,
Tomas

---

From: [email-masked] (Martin Rex)
Date: Mon, 20 Aug 2012 13:45:52 +0200 (CEST)

> [Denis: No. The solution does not need any change in the request]

Oh yes, you do.  That requirement is described in rfc2560 section 4.4.3.

  http://tools.ietf.org/html/rfc2560#section-4.4.3

An OCSP server is not allowed to return something other than a
basic ocsp response unless the client has included a requestExtension
that indicates that the client recognizes other than id-pkix-ocsp-basic.

> critical extension is present but may accept other responses within 

I would not be surprised if a client that obtains a response for
an request about a singular cert would drop the entire response if
it contained an unexpected (=non-negotiated) critical responseExtension
in the first single response.

I would consider it strange if an OCSP response about a singular
cert contains multiple single repsonses about the exact same cert
with different properties (one with a critical extension, and one
without a critical extension).  Since there is no specific ordering
defined for processing multiple single responses for one singular cert
in rfc2560, a response with multiple responses for a singular cert
would be a clear violation of the protocol defined rfc2560.

> > cannot be interpreted (this is the usual way to process an extension 
> > that is marked critical) and this leads to an error 

You can not change behaviour of the installed base by adding a note
to a protocol update.  The only thing you can reliably affect is
the behaviour of *NEW* implementations, and a hard-to-predict
subset of the installed base when it is patched.

> will be done by the client rather than by the server].

As someone regular doing customer support, I strongly dislike the reverse
approach.

This is an issue where it would be quite sensible to require the client
to send the certificate hash, so that the CA can detect when there is
a problem, and CA helpdesk has access to that information when the
cert hash mismatch leads to clients/RPs failing authentication--rather
than having to jump hoops in order to trace arbitrary third-party software
for reasons why it keeps failing cert revocation checks.

The client can use the best/strongest hash available, whereas the
server would have to use the weakest (when the client did not convey
anything through extensions about its capabilities.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Aug 2012 12:24:43 -0400

I don't think what we actually do here matters at all provided that
(1) we all interpret the same signals to mean the same thing and (2)
we can actually distinguish between the status situations that require
it.

The fact that OCSP does not distinguish 'good' from 'utterly bad' has
turned out to be a very bad thing in practice.

One problem here is that OCSP was saddled with being both an
authoritative status protocol and a non-authoritative one without the
use cases for either being adequately considered let alone separated.

What is in the specification does not really worry me a whole lot at
this point. What I personally care about is what the code that is out
there in the wild does.

It seems to me to be completely sensible for an authoritative  OCSP
responder to report status as follows:

Good: I know that this is good
Revoked: This was once good but now is bad
Unknown: This is so bad I ain't ever heard of it.

Likewise it seems completely sensible for a non-authoritative OCSP
responder to report status as

Good: I have CRLs for that issuer and it is not on it
Revoked: It is on the CRL for that issuer I have
Unknown: I do not have a CRL for that issuer.

These seem to be completely separate semantics that have been
unfortunately merged into one spec in a bad fashion.

How does the client know that the responder is authoritative or not?
Well how did it decide to send the query there in the first place? If
the responder was found by following a URL in the cert then it is
authoritative. Otherwise the responder must have been configured out
of band and that configuration should have the necessary information.
An authoritative response should hopefully have some common connection
to the trust anchor for the cert,

The question is how we get from where we are now to where we want to
be given the deployed infrastructure. If the criticality flag hack
proposed by Denis turns out to be more backwards compatible then we
should probably do that, if it turns out that real deployed clients
treat an OCSP token with a criticality flag as 'accept the cert' then
we should not.

In any case I think we really do need to have a set of extensions to
OCSP that allow a CA to state with clarity:

1) This OCSP response purports to be from the authoritative provider
of status for that cert
2) Which specific certificate the response refers to
3) Whether the certificate was issued and if issued what its status is

The fact that we appear to be having difficulty with all three points
here does not lead me to conclude 'do what the spec says regardless of
whether it makes sense'.

---

From: [email-masked] (Martin Rex)
Date: Mon, 20 Aug 2012 20:52:22 +0200 (CEST)

> turned out to be a very bad thing in practice.

The originial protocol failed to recognized (from the discussion of
"good" in rfc2560 section 2.2) that there is a need for bad status
codes besides revoked.  But by lacking to define other states from the
start, the only reasonable way forward is to use "revoked" to convey
all variations of known "bad", and to sort out the details through extensions.

It seems silly to have an OCSP responder label a known "bad" certificate
"good" or likewise to chicken out with an "unknown" reply, which will cause
RPs to ignore the result or fallback to CRL checking (and the latter
will result in a "good" classification of "bad" states that a CRL can
not represent).

A "fallback to other OCSP server" would be even more silly, because
if the other OCSP server would return "good" or "bad", then the first
OCSP server should have provided this answer in the first place.
And if the other OCSP server also provides "unknown", then it is
an obvious waste of resources, ultimately ending in the RP attempting
CRL-checking (with a result of "good"), or skipping revocation checking
entirely.

Adding situations where OCSP-based revocation will fail to provide an
answer (i.e. "unknown" rather than "good" or "bad/revoked") will make
hard fail clients/RP further unlikely.

> How does the client know that the responder is authoritative or not?

Authoritative is exclusively indicated by rfc2560 section 4.2.2.2
items (2) and (3).

  http://tools.ietf.org/html/rfc2560#section-4.2.2.2

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

> to the trust anchor for the cert,

Ouch.  The "common trust anchor" is a security vulerability in the
definition of authorized CRL signers!  rfc2560 originally does not
have this vulnerability, and I strongly opposed to drilling the CRL
security hole into the OCSP spec.

> authoritative. Otherwise the responder must have been configured out

Strong disagree.  It is *completely* irrelevant how the OCSP response was
actually obtained (from cache, stapled in a TLS extension, out-of-band,
proxied by a local OCSP responder, etc.).

> this point. What I personally care about is what the code that is out

But looking only at the behaviour of the well-known browser vendors
would be short-sighted.  The question is: which of the well-defined
behaviour (per rfc2560) works in a predictable fashion in the installed
base. 

The behaviour resulting from an "unknown" response of the OCSP responder
is de-facto undefined.

> Unknown: This is so bad I ain't ever heard of it.

That latter unkown state does not exist in rfc2560.

The end of rfc2560, section 2.2 Response says exactly this:

Which means that the "unknown" response clearly means that the OCSP
server does either not know about the status or does not want to
answer, with the effective meaning of "Don't ask ME, ask someone else."

It certainly does NOT say "worse than revoked".

> Unknown: I do not have a CRL for that issuer.

Where does rfc2560 _limit_ the information source for the answers of
non-authoritative OCSP responders to CRLs?  The description for the
"good" state is very explicit that OCSP responders may work on other
information resources besides CRLs.  (there would not be much of an
extensibility, if it didn't).

-Martin

---

From: [email-masked]
Date: Tue, 21 Aug 2012 17:29:44 +0200

Martin,

Responses are indicated with brackets [Denis: ...]

 

 
> that indicates that the client recognizes other than id-pkix-ocsp-basic.

[Denis: No. The proposal is fully compliant with id-pkix-ocsp-basic. 
It uses a field defined in id-pkix-ocsp-basic] 

 
> > in the client to skip OCSP checking (bad) or to try other responders

[Denis: No. You misread RFC 2560. A client which does not understand 
responseExtensions 
within ResponseData shall drop the whole response, but a client which does 
not understand 
singleExtensions with SingleResponse shall only drop the single response. 
I am proposing to use singleExtensions with SingleResponse]. 

> in the first single response.

[Denis: Thus, this would be a client that is not compliant. However, I 
recognize that RFC 2560 
does not explain how to process singleExtensions with SingleResponse. In 
the draft I have 
prepared (and posted yesterday to the rfc editor), I am providing full 
details about:

     - the building of a request by an OCSP client,
     - the processing of a received request by an OCSP server, 
     - the building of a response by an OCSP server, and 
     - the processing of a response by an OCSP client].

> would be a clear violation of the protocol defined rfc2560.

[Denis: RFC 5280 states:

   A certificate-using system MUST reject the certificate if it encounters
   a critical extension it does not recognize or a critical extension
   that contains information that it cannot process.  A non-critical
   extension MAY be ignored if it is not recognized, but MUST be processed 

   if it is recognized.

The extension I have drafted is compliant with this text (which was 
dedicated 
to PKCs). Depending upon its content, the extension will be marked 
critical or 
non critical by the server. A single OID is thus needed to define that 
extension. 
What is important is the way the client shall process it. I will re-use 
the text 
from RFC 5280 in the right order: 

   1) an extension that is recognized MUST be processed.
   2) a critical extension that is not recognized must invalidate 
      the SEQUENCE structure where it is present.
   3) a non-critical extension that is not recognized may be ignored].

 

 
 
> subset of the installed base when it is patched.

[Denis: A fallback mechanism cannot provide the same level of security as 
on line service. Anyway, The following question should be answered:
 - How many OCSP implementations are currently using a singleExtension 
which is marked critical ?
 - How many OCSP clients are currently using these OCSP implementations 
and are unable to 
   understand these singleExtensions which is marked critical ?
 - How many of these OCSP clients are currently using a CRL fallback 
mechanism when they encounter 
   a singleExtension which is marked critical ?

I believe that the answer to the last question is none. 
So the point you raised is not an issue]

 
 
> for reasons why it keeps failing cert revocation check> 

[Denis: Doing this, is opening the door to false detections. Let me 
explain: 
as a client I will send purposely wrong hashes. Using your wording "the CA 
can detect 
when there is a problem, and CA helpdesk has access to that information 
...". 
I can keep busy the CA helpdesk nights and days, since most OCSP clients 
do not 
authenticate to the OCSP server].

> anything through extensions about its capabilities.

[Denis: the server shall use a hash algorithm that is as good (or as bad) 
as the one 
used by the client in its OCSP request. At least, the server is sure that 
the client 
will be able to use the same hash function, so interoperability is 
guaranteed].

---

From: [email-masked] (Martin Rex)
Date: Tue, 21 Aug 2012 18:49:48 +0200 (CEST)

> It uses a field defined in id-pkix-ocsp-basic] 
 
You're correct.  I'm sorry, I misinterpreted the
the ASN.1 structures in rfc2560.

> responseExtensions within ResponseData shall drop the whole response,
> but a client which does not understand singleExtensions with
> SingleResponse shall only drop the single response. 

That is actually not what rfc2560:

   Support for any specific extension is OPTIONAL. The critical flag
   SHOULD NOT be set for any of them.  Section 4.4 suggests several
   useful extensions.  Additional extensions MAY be defined in
   additional RFCs. Unrecognized extensions MUST be ignored (unless they
   have the critical flag set and are not understood).

according to rfc2560, OCSP extensions that are critical may be ignored.
The logical negation of MUST is "everything but MUST", which amounts to MAY,
this is in particular encouraged by the "The critical flag SHOUD NOT be
set for any of them.".

> recognize that RFC 2560 does not explain how to process singleExtensions
> with SingleResponse. In the draft I have prepared (and posted yesterday
> to the rfc editor), I am providing full details about:
> 

The problem goes *much* deeper.  rfc2560 does not define that there could
be multiple singleResponses with different content contained in a reply,
and the strategy how to evaluate them if there are.

So is PERFECTLY compliant for an rfc2560 client to search the singleResponse
for a match to the cert in question, look at the first match that is
encountered, and not look at any other singleResponses AT ALL.

Whether the rfc2560 processes the singleResponse sequence from top to
bottom or from bottom to top, or in any other order, is UNDEFINED in
rfc2560, which means, that there MUST only be one singleResponse for
any particular cert, so that the result from processing the rfc2560
will be independent from the ordering in which the rfc2560 client/RP
processes the singleResponse entries.

>    extension MAY be ignored if it is not recognized, but MUST be processed 

This text of rfc5280 applies exclusively to a certificate that contains
critical certificate extensions.  There is seperate text in rfc5280 that
applies exclusively to critical CRL extensions any yet another seperate
text in rfc5280 that applies exclusively to critical CRLEntryExtensions.

None of the text in rfc5280 applies to rfc2560/OCSP extensions.

>    3) a non-critical extension that is not recognized may be ignored].

But you must realize that this is a change of the OCSP protocol, and
a requirement that does not apply to the installed base of rfc2560.

What this would still be lacking is the definition of either
a well-defined order of processing of singleResponses, or a well-defined
behaviour for the presence of multiple (potentially conflicting)
singleResponses for a single certificate.  Sorting this out will
also be something that does not apply to the installed base of rfc2560.

At which point we're pretty much defining OCSP 2.0, even if it does not
show on the version number of the wire protocol.

An unsolicited, backwards-incompatible critical singleResponse extension
in combination with two conflicting singleResponses for the exact same
cert in a single OCSP response is a complete NO GO.  It would have
pretty much nothing in common with the original rfc2560 protocol.

>    which is marked critical ?

It is impossible to come up with any meaningful figures about the
installed base of a 12-year old protocol.  Doing backwards-incompatible
in a NON-negotiating fashion (i.e. interoperability impairing) is
incompatible with the spirit of the IETF and IETF protocols.

> > As someone regular doing customer support, I strongly dislike the 
> > reverse approach.
>  
> > than having to jump hoops in order to trace arbitrary third-party 
> > software for reasons why it keeps failing cert revocation check
> 
> as a client I will send purposely wrong hashes. Using your wording
> "the CA can detect when there is a problem, and CA helpdesk has access
> to that information ...". 
> I can keep busy the CA helpdesk nights and days,
> since most OCSP clients do not authenticate to the OCSP server].

Which part of "the CA helpdesk has access to that information" don't
you understand?  There will always be numerous ways to tick off "alarms"
in IDSses/Monitoring and to keep Helpdesks busy, so there is no
additional risk involved by being able to provide CA helpdesks with
additional information to resolve customer support calls.

> as the one used by the client in its OCSP request. At least, the server
> is sure that the client will be able to use the same hash function,
> so interoperability is guaranteed]. 

I actually prefer protocols that have a facility to negotiate to actively
use that facility.  the CertID in the request can only accomodate a
single AlgorithmIdentifier, in which case the client would typically
make a conservative assumption (SHA1), whereas the the additional
singleRequestExtension could use SHA256 in addition, which means that
the client will get some level of algorithm agility for free, without
having to submit two independent requests.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Aug 2012 16:04:03 -0400

+1

+1

If unknown with a marked critical extension has the desired effect, I
would be ok with it. But I agree it is not a nice solution.

I don't see what is bad about defining the ASN1 'revoked' status to
mean 'not valid' and adding in an extension to allow the server to
report additional status info

> CRL-checking (with a result of "good"), or skipping revocation checking

Agreed, we have to stop the OCSP chasing chain there. The object is to
have the responder give a report that as a minimum causes the cert to
be rejected and preferably causes a loud complaint somewhere.

> hard fail clients/RP further unlikely.

What is proposed is not an 'unknown' response so much as redefining
the semantics of unknown for the case of an authoritative server.

> security hole into the OCSP spec.

What happened in practice is pretty ugly. See all the questions about
what extensions the cert should have....

> proxied by a local OCSP responder, etc.).

Good point, I had forgotten about stapling.

-- 
Website: http://hallambaker.com/

---

From: [email-masked]
Date: Wed, 22 Aug 2012 14:07:17 +0200

> this is in particular encouraged by the "The critical flag SHOUD NOT be

[Denis: ... but the text states "Unrecognized extensions MUST be ignored 
           (unless they have the critical flag set and are not 
understood).

> and the strategy how to evaluate them if there are.

[Denis: this is not fully correct. RFC 2560 does define that there may be 
multiple singleResponses in a reply. However it is true that there is no 
algorithm for their individual evaluation]. 

> processes the singleResponse entries.

[Denis: this is not an issue since a singleExtension only applies to a 
single response]
 
> a requirement that does not apply to the installed base of rfc2560.

[Denis: ...RFC 2560 states: "Unrecognized extensions MUST be ignored 
           (unless they have the critical flag set and are not 
understood).
           The single change would be to remove the sentence : 
           "The critical flag SHOULD NOT be set for any of them".

> also be something that does not apply to the installed base of rfc2560.

[Denis: I am only thinking of a single extension. So there is not yet any 
conflict possible.
If the PKIX WG defines critical extensions that may conflict, then the 
rule will be indicated 
at that time].

> show on the version number of the wire protocol.

[Denis:  No. I don't think so]

> additional information to resolve customer support calls.

[Denis: You missed the point. The helpdesk will be triggered by the CA 
(rather than customer support calls) for problems which do not exist.

> having to submit two independent requests.

[Denis: It looks like applying the following sentence: 
Why make it simple when we can make it complex ? :-)
I believe it is better to have a solution which avoids 
the use any kind of singleRequestExtension]

---

From: [email-masked]
Date: Wed, 22 Aug 2012 16:00:07 +0200

Martin,

I answered too quickly to your last email.

The text you mentioned ("The critical flag SHOULD NOT be set for any of 
them") 
is in section 4.1.2, i.e. Notes on the Request Syntax.

So it only applies to the request, not to the response.

There is no text in RFC 2560 which forbids (or even does not recommend) to 
use critical single extensions 
within a response.

Denis

========================================================================

understood). 

> > >    extension MAY be ignored if it is not recognized, but MUST 
beprocessed 
understood). 
> [Denis: I am only thinking of a single extension. So there is not 
> yet any conflict possible. 
> If the PKIX WG defines critical extensions that may conflict, then 
> the rule will be indicated 
> at that time]. 
> 
> 
> > -Martin_______________________________________________
> pkix mailing list
> [email-masked]

---

From: [email-masked] (Martin Rex)
Date: Wed, 22 Aug 2012 16:42:31 +0200 (CEST)

[email-masked] wrote:
> The text you mentioned
> ("The critical flag SHOULD NOT be set for any of them") 
> There is no text in RFC 2560 which forbids (or even does not recommend)
> to use critical single extensions within a response.

It could be that I still do not understand what you're really
trying to accomplish and how.

I do not have a problem with critical extensions (in both request and
response) in principle,  I just wanted to point out that the presence
of (and dealing with) a an extension that is marked critical is
not specified in rfc2560, which means that ANY behaviour is conforming,
although there is some likelyhood that the presence of an unrecognized
extension that is marked critical will result in the complete response
to be dropped/ignored.

Therefore sending a critical extension in an OCSP request would probably
be a bad idea, because a server that does not recognize it may return
an error (and it would require a second request or out-of-band meta-knowledge
to know whether a server supports the extension).

The OCSP server returning an OCSP resonse with a critical singleResponse
extension, which has *NOT* been offered in the OCSP request through
a non-critical singleRequest extensions is a BAD idea.  Nothing
in rfc2560 descibed the exact semantics of critical singleResponseExtensions,
so for rfc2560 they're simply prohibited--that is an implicit consistency
requirement.

That an unrecognized critical singleResponse extension applies should
not cause the rejection of the whole response is not backed by any
existing specifications.  rfc2560 certainly does not specify it.
So the behaviour is undefined.

For those who believe that rfc5280 should provide fallback guidance,
look at what semantics rfc5280 specifies for critical crlEntryExtensions:

  http://tools.ietf.org/html/rfc5280#section-5.3

                                                         If a CRL
   contains a critical CRL entry extension that the application cannot
   process, then the application MUST NOT use that CRL to determine the
   status of any certificates.  However, applications may ignore
   unrecognized non-critical CRL entry extensions.

rfc5280 specifies that a single unrecognized critical crlEntryExtension
anywhere in the CRL should cause the RP to completely ignore/drop the
entire signed object (the complete CRL).

The semantics that you are asking--the criticality of a
singleResponseExtensions applies only to that particular singleResponse
and should be ignored with respect to all other information in the 
signed object (the OCSP response) is not specified in rfc2560,
and is the exact opposite of the sematics specified in a vaguely
similar situation in section 5.3 of PKIX/rfc5280 for the criticality of
CRLEntryExtensions.

I'm OK with extending OCSP to support such semantics, provided that
these semantics are properly negotiated(!) between OCSP requestor and OCSP
responder, which means that the OCSP request MUST contain a request
extension indicating support for these semantics.

However, since there are scenarios where OCSP responses are forwarded
_without_ an original OCSP request from the client that is supposed
to process them (e.g. in the TLS extensions for OCSP response stapling),
use of critical OCSP response extensions ought to be limited to
very exceptional situations that will not occur in regular usage
scenarios where e.g. OCSP response stapling is desirable.

-Martin

---

From: [email-masked]
Date: Wed, 22 Aug 2012 18:57:09 +0200

Martin,

> extension that is marked critical will result in the complete response

A singleExtensions that is critical and not recognized will result in the 
single response to be dropped/ignored.

> to know whether a server supports the extension).

I am not discussing such a case.

> so for rfc2560 they're simply prohibited--that is an implicit 
consistency

This is one of the many topics on which RFC 2560 is obscure; hence why we 
are working on 2560bis.

> So the behaviour is undefined.

This is one of the many topics on which RFC 2560 is obscure; hence why we 
are working on 2560bis.

> entire signed object (the complete CRL).

This is an interesting point which deserves a separate thread.
I believe this is an error and that we should discuss it as an errata to 
RFC 5280.

> extension indicating support for these semantics.

I now understand your point, but I do not think that the reject of a whole 
response is logical 
if there is a critical unrecognized extension within a single response.

---

From: [email-masked] (Martin Rex)
Date: Thu, 23 Aug 2012 05:38:11 +0200 (CEST)

[email-masked] wrote:
> 
> [Denis: returning the hash provides the same benefit. The 
> comparison will be done by the client rather than by the server].

Denis, you're (mostly) correct on "returning the hash".

The presence of the certificate hash in the OCSP response in a
non-critical(!) singleResponseExtension is vital for all scenarios
where OCSP responses are processed without a prior OCSP request,
i.e. all caching and all stapling and proxy scenarios.

But I still believe that adding the hash into the request provides
additional benefits, so I'd like to see both possibilities.
Probably something like

CertificateImprint ::= SEQUENCE   {
    hashAlgorithm              AlgorithmIdentifier,
    certificateHash            OCTET STRING }

plus an ASN.1 OID for wrapping it into an Extension...

-Martin

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 23 Aug 2012 15:54:07 -0700

I hope I can interpret this exchange as converging toward consensus that clarification and consensus is needed.  ;-)

On Aug 22, 2012, at 9:57 AM, <[email-masked]> <[email-masked]> wrote:

> A singleExtensions that is critical and not recognized will result in the single response to be dropped/ignored. 

It seems to me that a critical extension in a response ought to cause the response to be rejected.  If that constitutes an incompatible upgrade to the protocol, so be it, but it sounds more like a clarification to me.  I hope the installed base agrees with me.

> This is one of the many topics on which RFC 2560 is obscure; hence why we are working on 2560bis. 
> 
> This is one of the many topics on which RFC 2560 is obscure; hence why we are working on 2560bis. 
>  
> I believe this is an error and that we should discuss it as an errata to RFC 5280. 

Within the context of OCSP the "object" to be dropped would be an entire response, because it's only requested for a single cert?  I have a hard time interpreting the meaning of any finer granularity than that.  Or at least a hard time finding a good use case for it.

> I now understand your point, but I do not think that the reject of a whole response is logical

---

From: [email-masked] (Martin Rex)
Date: Fri, 24 Aug 2012 03:30:04 +0200 (CEST)

Denis,

I believe that the semantics of OCSP responses with unrecognized critical
extensions are effectively undefined in rfc2560 so that their use ought
to be avoided.

I believe that for the purpose of conveying information about cert
existence/non-existence in an OCSP response, non-critical
(entry)extensions will be perfectly sufficient.

It may be easier to discuss the issues by drilling down into
the details.

What needs to be accounted for is (a) what answer is best suited
for the OCSP requestor, and (b) can the OCSP response confuse
other RPs who obtain that response from caching, stapling, proxying,
or from a malicious attacker?

Traditional OCSP:
                                           rfc2560 response:
   issuer+serial refer to 
     (1)  real cert that is valid                 good
     (2)  real cert that is revoked             revoked
     (3)  non-existent cert                       good

Having the OCSP responder add the certificate hash of
the REAL cert into a non-critical singleResponse extension
for (1) and (2) should be safe according to rfc2560, _independent_
of which RP is going to process the repsonse.

The whitelisting check that were discussing (comparing the
hash of the cert that an RP is checking for revocation against
the records of issued certs applies in theory to all three
scenarios above.  However, we ought to leave the ocsp responses
semantics of (1) and (2) alone, and only modify the response (3).

It would be dangerous to have an OCSP responder create a
response with an rfc2560 CertID refering to a valid,
unrevoked issued cert, accompanied by an incorrect cert
hash in a singleResponse extensions and a revoked status,
because the installed base does not understand the semantics
of such a beast and it has a potential to be misunderstood.

For (1) and (2), I (finally) agree with you Denis, for
rfc2560 CertIDs refering to real issued certs, the OCSP response
ought to convey the true status (good/revoked) and a whitelist-enabled
OCSP responser should include the true hash of the issued cert in
a non-critical OCSP singleResponseExtension, and the RP must be
burdened with comparing the hash of the real cert with the hash
of the cert the RP is verifying. 

What about situation (3).  I do not see a problem with an OCSP
responder who has access to a white list or issue records to
return "revoked (on hold)" to discourage the RP from trusting
this cert.  But the validity of such a "denial-of-existance"
OCSP response should be extremely short (to minimize interference
with real certs that get issued shortly after such an OCSP response
is created) similar how negative DNS responses ought to be short-lived.
And such a "negative" OCSP response ought NOT to contain any cert hash
in a singleResponse extension--the presence of a cert hash in the
response should be limited to correct hashes of isssued certs.

It's true that there is no need for the OCSP resquest to convey
a cert hash to make the above happen.  The purpose of a cert hash
in the requst is really more about allowing an OCSP responder
to detect when there are potentially fraudulently issued certs
being used that the CA does not know about.  I agree that it will be
easy to create the impression of fraudulent cert usage by submitting
OCSP requests for real certs accompanied by random hash values,
so OCSP operators need to be careful about interpreting the
collected data.  But I do not see this as a problem.

-Martin

---

From: "Peter Rybar" <[email-masked]>
Date: Fri, 24 Aug 2012 10:57:42 +0200

Martin,

> But the validity of such a "denial-of-existance"
OCSP response should be extremely short (to minimize interference
with real certs that get issued shortly after such an OCSP response
is created) similar how negative DNS responses...

It looks like that thisUpdate time value is in online usage of OCPS response ignored. Because thisUpdate time value indicates that situations which happened after thisUpdate time was not covered in OCSP response status.

Online systems are based on probability where when something was true recently it is expected that it is true also now when the online service is used and for that reason thisUpdate of OCSP response is ignored. For that reason OCSP response containing hash of certificate must be processed together with the value included in thisUpdate to prevent it from situations which you have described.

For the long term validation thisUpdate time value of OCSP response (or CRL) must be always before the time in the past to which the validation is realized e.g. signature validation or other investigation of X.509 PKI usage in the past.

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Friday, August 24, 2012 3:30 AM
To: [email-masked]
Cc: pkix
Subject: Re: [pkix] Use of the OSCP unknown response

Denis,

Traditional OCSP:
                                           rfc2560 response:
   issuer+serial refer to 

-Martin

---

From: Peter Rybar <[email-masked]>
Date: Fri, 24 Aug 2012 15:19:33 +0200

Ups
replace "always before the time in " with "always after the time in "

Time-line:
 time in the past when something was done and is checked with
certificate < thisUpdate of (OCSP response with cert-hash value) < now

Peter