On Tue, Nov 27, 2012 at 10:55 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:
> Just not sure I follow the logic from this thread, we are propose other
> function that is needed for various crypto functions, why not the bigint?
Because we're specifically not proposing something that low-level. The
only reason you need bigint is to polyfill something. The whole point
of this API is so that you don't have to polyfill something.
> When it comes to blind signatures there are several ways to do that, we have
> the requirement to be able to use blind signatures (not Chaumâ€™s RSA) within
> the browser, we also need bigint. So we are in favor of this proposal.
There has not been a proposal. This is a question about something
outside of our charter. The question at hand is whether or not to
recharter to embrace this feature.
I strongly oppose rechartering, since this is clearly an issue of the
language, and not of user agents. If Javascript wishes to support
arbitrary precision integers, as opposed to the current types today,
then it should be done in TC39. Given that TC39 has discussed this in
the past, I see no value in us taking up that mantle.
This is especially true because, within this group, the only reason to
talk bigints is to talk about polyfilling (whether ZRTP, arbitrary
KDFs from DH shared secrets, blind signatures, or vanity crypto), and
I would argue that the entire purpose of this group is to avoid the
need for polyfilling (which you can already do today - see, for
example, SJCL)
>
>
>
> From: Acar, Tolga [mailto:tolga.acar@intel.com]
> Sent: Monday, November 26, 2012 4:45 PM
> To: Mike Jones; Stefan Xenon; public-webcrypto-comments@w3.org;
> sleevi@google.com
>
>
> Subject: RE: RSA blind signatures
>
>
>
> Although I, too, would like to work on and use a bigint API in js, I am much
> less inclined to augment the web crypto API with a general purpose bigint
> API that looks more like math (group operations in particular) than crypto
> library. If there is interest in a bigint API in js, and it looks like there
> is, that should come under separate cover instead of being mixed with the
> Web Crypto API. So, what does that â€œseparate coverâ€