RE: POLL: Nonce-specific error code for OCSP

["Joseph A. Doekbrijder" <joseph.doekbrijder@xxxxxxxxxxxxx>]

No.

Joseph A. Doekbrijder
--------------------------------------------------
SwissSign AG
Löwenstrasse 1, CH-8001 Zürich
Tel: +41 433 44 88 11
Mobile: +41 79 211 24 46
www.swisssign.com
--------------------------------------------------

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx 
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Michael Myers
> Sent: Thursday, October 16, 2003 18:05
> To: ietf-pkix@xxxxxxx
> Subject: RE: POLL: Nonce-specific error code for OCSP
> 
> 
> 
> > -----Original Message-----
> > From: owner-ietf-pkix@xxxxxxxxxxxx 
> > [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Denis Pinkas
> > Sent: Thursday, October 16, 2003 12:34 AM
> > To: Michael Myers
> > Cc: ietf-pkix@xxxxxxx
> > Subject: Re: POLL: Nonce-specific error code for OCSP
> >
> >
> >
> > Mike,
> >
> > > All,
> >
> > > I recently received permission from the chairs to
> > poll the WG
> > > against the following question.
> >
> > > Should we standardize an OCSP *V1* error code that enables a 
> > > responder to indicate its inability to respond to nonced requests?
> >
> > > Please respond with either YES or NO.
> >
> > I would suggest to you provide a resumé of the
> > advantages of this new error
> > code (and disadvantages if not supported), so that
> > people do not have to
> > look back at that long thread on that topic to make
> > up their opinion.
> >
> > Denis
> >
> > > Mike
> 
> 
> 
> A reasonable request.
> 
> In summary, we need to standardize the treatment of nonces 
> when nonces aren't supported.  RFC2560 is regrettably silent 
> on the point.  The need to do so is particularly acute in the 
> context of heterogeneous populations of clients and servers 
> (i.e. not operating under a single administrative authority). 
>  Some may be set up to use or support nonces and some may 
> not.  The question is of course moot for requests that don't 
> contain nonces.
> 
> The issue is further complicated by the use of pre-produced 
> responses to achieve scalability through caching (i.e.
> non-signing) servers.  A relay back to a master signing 
> server could work, but that doesn't seem to be a popular 
> option.  So that leaves us with two server-side options.  
> Either: 1) send back a non-nonced response anyway with 
> technical extensions; or
> 2) send back an error code.
> 
> Variations on option 1 have been discussed, with the 
> likelihood that an extended response syntax or equivalent 
> technical mechanisms will force a v2 and all that entails 
> with regard to IETF process.
> 
> Yet we also need to do something sooner about v1.  In this 
> case, an existing error could be designated or we could 
> define a new one that servers can send back in the event they 
> don't support nonces.  Absent a designated error code, it is 
> predictable that ad-hoc selections will be made to to address 
> the issue with a consequent reduction in Internet-wide OCSP 
> interoperability and security.
> 
> This poll is focussed on the narrower v1 issue ONLY. Should 
> we or should we not standardize a v1 error code? If this poll 
> is inconclusive, then I suppose we'll get into the heart of 
> the matter, which is whether it is acceptable in v1 to 
> disregard a client's nonce.  But let's leave those 
> discussions to another thread and first get a vote tally.
> 
> Mike
> 
> 
>