I am also in favor of consistently using OperationError rather than distinguishing some as DataError. Chromium has also been treating some of these as OperationError (RSA-OAEP padding errors for instance are not DataError as specced: https://code.google.com/p/chromium/issues/detail?id=388352). On Thu, Oct 9, 2014 at 3:59 PM, Richard Barnes <rlb@ipv.sx> wrote: > That makes sense to me. It's basically the path we've been following in > Firefox. > > On Mon, Sep 29, 2014 at 6:17 PM, Mark Watson <watsonm@netflix.com> wrote: > >> All, >> >> As discussed on the call, we have a number of bugs which deal with >> parameter validation, specifically 25741, 25815, 25557 and 26741. >> >> The common theme is that we do not know (and likely cannot assume) that >> cryptographic libraries expose a distinction between parameter validation >> errors and other forms of failure. If we require in our specification that >> a distinction be exposed, this may require that UAs implement checks >> themselves. These checks could be cryptographically sensitive (leak timing >> information etc.). >> >> My proposal is that whenever there is doubt, we should simply return >> OperationError. This leaves implementations the flexibility to delegate >> such checks to crypto libraries independent of the level of error >> information exposed by the crypto library. >> >> Comments ? >> >> ...Mark >> > >
Received on Friday, 10 October 2014 22:31:40 UTC