RE: OCSP response pre-production

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

Mike,

As there has been some suggested changes to the text, can you post the most
recent wording to get everyone back on the same page?

Thanks
Alex


> -----Original Message-----
> From: Michael Myers [mailto:mmyers@xxxxxxxxx]
> Sent: Friday, September 26, 2003 2:35 PM
> To: Deacon, Alex; ietf-pkix@xxxxxxx
> Subject: RE: OCSP response pre-production
> 
> 
> Alex,
> 
> I'm willing to discuss client-side "nonce capability discovery"
> via this mechanism but it's clearly a v2 proposition.
> Meanwhile, we're working to clarify what we meant in v1 when we
> defined nonces in the first place.  The poll clearly establishes
> a nearly unanimous consensus that the common understanding in
> place at the time found its way into running code in all but, to
> date, one case.  I propose we proceed on this basis.
> 
> Mike
> 
> 
> 
> 
> > -----Original Message-----
> > From: Deacon, Alex [mailto:alex@xxxxxxxxxxxx]
> > Sent: Friday, September 26, 2003 2:09 PM
> > To: 'Ryan M. Hurst'; Paul Hoffman / IMC; Michael
> > Myers; David Engberg;
> > oelmaier@xxxxxxxxxxx; Ambarish Malpani; ietf-pkix@xxxxxxx
> > Cc: Russ Housley; Stephen Kent; Tim Polk
> > Subject: RE: OCSP response pre-production
> >
> >
> >
> > This summary assumes that the OCSP responder has
> > control of the OCSP clients.  This may not be the
> > case, especially when responding to OCSP requests
> > for certs issued from SSL CA's (i.e. every flavor
> > of browser/ocsp client on earth).  As I stated in
> > my response to Russ, the responder could reject a
> > request with a nonce, but why not reply with a
> > request without a nonce, and let the client decided
> > if it wants to accept or reject it.  If a client
> > requires that the nonce in the result, the result
> > is the same, the response is rejected.
> >
> > Alex
> 
>