Subject: RE: OCSP response pre-production

From: "Frank Balluffi" <[email-masked]>
Date: Fri, 3 Oct 2003 09:11:15 -0400

Mike,

My preference would be to define an extension (e.g., via an informational RFC) that can be used with v1 bits on the wire, and then to formally incorporate the extension into v2. Again, if a strong case can be made for v2 to use a different mechanism (than the extension defined above), I am OK with that.

I hope this answers your question.

Frank

                      "Michael Myers"                                                                                                  
                      <[email-masked]        To:       Frank Balluffi/NewYork/DBNA/DeuBa@DBNA, <[email-masked]>                  
                      >                        cc:       "David Engberg" <[email-masked]>, <[email-masked]>                    
                      Sent by:                 Subject:  RE: OCSP response pre-production                                              
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      

                      10/02/2003 06:08                                                                                                 
                      PM                                                                                                               

> -----Original Message-----
> From: Frank Balluffi
>
> . . .
>
> I too like the proposal to use a flag or an
> extension. Perhaps an extension could say the
> equivalent of, "This is a cached response."

Frank,

Would you object the v1/v2 dual paths as means of getting this
into place?

Mike

--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 03 Oct 2003 17:09:16 +0200

Frank Balluffi wrote:
> My preference would be to define an extension (e.g., via an 
> informational RFC) that can be used with v1 bits on the wire, and
> then to formally incorporate the extension into v2. Again, if a
> strong case can be made for v2 to use a different mechanism (than the
> extension defined above), I am OK with that.

I know understand better the case against the round-trip error discovery 
solution without a signed assertion from server.

I think the above solution is something everybody can agree on, and stop 
discussing the point for ever.

So can everybody agree on creating an informationnal RFC about how to 
handle cache response in OCSP v1 that would :

- define an extension that enable a responder to assert the answer is a 
cached answer and not an answer to a nonce-less request

- [MAYBE] define a value for that extension that says this answer does 
not include a nonce, but that the server can provide one if requested

- re-assert that it is not conformant to RFC2560 to send back a response 
without to nonce to a request requiring a nonce (it might change in OCSPv2)

- precise what error amongst the already defined one the OCSP server 
should send back when receiving a nonce if it can not send one back

- describe that a client who wants the best possible answer can :
* Ask for a nonce
* Receive an error
* Ask without nonce
* Receive an answer that includes the extension that the server can not 
able to include nonces in answers.

- describe another possible solution :
* Don't ask for a nonce
* Receive an answer that includes the extension that the server can 
include nonces in answers.
* Ask with a nonce, because I want the very best I can have.

The second solution might be better if the servers that send back cached 
answer have a very heavy load and want to avoid the round-trip, whilst 
the one that are ready to provide nonces are more likely not to have a 
problem with round-trips.

An evolution could then be included in OCSPv2 to avoid the round-trip 
completely.

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 3 Oct 2003 09:16:31 -0700

This works for me, especially the part about getting definitive
on 2560 as it stands.  Ambarish?

Mike

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Jean-Marc Desperrier
> Sent: Friday, October 03, 2003 8:09 AM
> To: [email-masked]
> Subject: Re: OCSP response pre-production
>
>
>
> Frank Balluffi wrote:

---

From: "Ambarish Malpani" <[email-masked]>
Date: Fri, 3 Oct 2003 10:34:40 -0700

Yup, sounds good to me. Is there rough concensus that this is what
folks want? Anybody with a strong opinion to the contrary, please
pipe up now.

Regards,
Ambarish

> [mailto:[email-masked]] On Behalf Of Michael Myers
> Sent: Friday, October 03, 2003 9:17 AM
> To: Jean-Marc Desperrier; [email-masked]
> Subject: RE: OCSP response pre-production
> 
> 
> 
> 
> This works for me, especially the part about getting 
> definitive on 2560 as it stands.  Ambarish?
> 
> Mike
> 
> > [mailto:[email-masked]]On Behalf Of Jean-Marc 
> Desperrier

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 03 Oct 2003 19:52:41 +0200

> on 2560 as it stands.  Ambarish?

I've been thinking about something more, I hope it doesn't reopen the 
whole can of worms.

What would you think if it'd also define an extension that the client 
can use in a request including a nonce, in order to indicate it will 
accept an answer without a nonce if it includes the pre-produced extension.

The server would be breaking RFC 2560 by sending back the pre-produced 
answer, but only with a client that has explicitly indicated it is 
expecting this behaviour.

This, if acceptable, would enable to fully avoid the round-trip with 
compatible servers.
Legacy servers would send back an error to this kind of request if they 
can not supply a nonce, which does not break the expected behaviour.

>> cached answer and not an answer to a nonce-less request

I'll correct myself : "is a pre-produced answer and this server can not 
successfully answer requests requiring a nonce."

---

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 3 Oct 2003 20:35:41 +0200

> without to nonce to a request requiring a nonce (it might 

The RfC states: "[A request includes] [...] optional extensions which
MAY be processed by the OCSP Responder". With the clear definition of
MAY according to RfC 2119:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

When writing such an informational RfC we also have to clarify that
extension processing is not optional anymore with this change (as every
responder MUST detect a nonce).

-- 
Florian Oelmaier
SyTrust

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 03 Oct 2003 21:59:54 +0200

Florian Oelmaier wrote:
> MAY be processed by the OCSP Responder". 

I don't know.
This is not in line with RFC3280 definition of extensions, in which if 
you *do* recognize an extension, you have to treat it correctly and not 
simply ignore it.
With that definition if you implement RFC2560, you can say I don't know 
what id-pkix-ocsp-nonce means so I don't care about it, because it's 
defined in the standard.

---

From: "Florian Oelmaier" <[email-masked]>
Date: Fri, 3 Oct 2003 23:23:00 +0200

> accept an answer without a nonce if it includes the 

If we do that, I agree with your course, Jean-Marc. Otherwise I would
feel strongly against it. In any case I would vote to go with Davids
proposal - it seems more simple to me while accomplishing the same task
with additional security.

> expecting this behaviour.

Once again: RfC2560 allows sending of nonceless responses to nonced
requests. It clearly states that processing of every extension (and
"nonce" is an extension) is optional for both responder and client. And
OPTIONAL is clearly defined. So if we define that request-extension, the
responder would be fully on the ground of RfC2560. 

In fact I would bet that currently nearly all caching servers send back
nonceless responses to nonced requests - as this is what the RfC seems
to suggest in ist current wording. At least this is what our responder
does when configured for caching.

-- 
Florian Oelmaier
SyTrust

---

From: "Florian Oelmaier" <[email-masked]>
Date: Sat, 4 Oct 2003 04:05:33 +0200

> what id-pkix-ocsp-nonce means so I don't care about it, because it's 

You are partly right for RfC3280 - while it in fact lists some
extensions that SHALL be recognized by CAs/applications, in general
extension are optional. The exact wording of RfC3280 is:

"A certificate using system MUST reject the certificate if it encounters
a critical extension it does not recognize; however, a non-critical
extension MAY be ignored if it is not recognized. [...] [List of
extensions CAs and Applications SHOULD recognize] Support for the
remaining extensions is OPTIONAL." [nearly same wording for CRLs]

Nevertheless the wording of RfC3280 and RfC2560 is very different. If we
apply the rationale behind RfC3280 to RfC2560, we should allow a client
to mark his nonce-extension critical, thus indicating that it does not
wish that any responder ignores the nonce. But currently RfC2560 states
clearly: 

"Support for any specific extension is OPTIONAL. The critical flag
SHOULD NOT be set for any of them."

Allowing an extension (e.g. the nonce-extension) to be critical would be
a change to RfC2560. I would really like such a change, but as Ambarish
already pointed out, this may put an unwanted semantic into the requests
of some existing clients out there. As these clients adhere to RfC2560,
the nonce is not critical - thus they would indicate that a nonceless
response is ok for them.

Remark: With this whole system, we have not yet solved the problem
adressed by David's proposal: A client wants to know securely if a
response without nonce was generated by an OCSP-responder not supporting
nonces or by an OCSP-responder normally being able to generate nonces. 

-- 
Florian Oelmaier
SyTrust