RE: OCSP response pre-production

["Ambarish Malpani" <ambarish@xxxxxxxxxxx>]

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

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