RE: OCSP response pre-production

["Michael Myers" <mmyers@xxxxxxxxx>]

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

Mike

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of
> Jean-Marc Desperrier
> Sent: Friday, October 03, 2003 8:09 AM
> To: ietf-pkix@xxxxxxx
> Subject: Re: OCSP response pre-production
>
>
>
> 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.
>
>