RE: OCSP response pre-production

["Deacon, Alex" <alex@xxxxxxxxxxxx>]

Yes, I have an issue with "re-assert[ing] that it is not conformant to
RFC2560 to send back a response without to nonce to a request requiring a
nonce"

You can't re-assert something that was never asserted in the first place.
The current spec does not mandate that servers support extensions in OCSP
requests. (as Florian pointed out in a recent email)  Mandating that servers
MUST respond to a nonce extension would make currently compliant responders
non-compliant.   Not good...

Alex


> -----Original Message-----
> From: Ambarish Malpani [mailto:ambarish@xxxxxxxxxxx]
> Sent: Friday, October 03, 2003 10:35 AM
> To: 'Michael Myers'; 'Jean-Marc Desperrier'; ietf-pkix@xxxxxxx
> Subject: RE: OCSP response pre-production
> 
> 
> 
> 
> 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.
> > >
> > >
> > 
> > 
>