- From: Ryan Sleevi <sleevi@google.com>
- Date: Tue, 28 Aug 2012 12:52:36 -0700
- To: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
- Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Mon, Aug 27, 2012 at 2:59 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com> wrote: > First, thanks for writing this up. A few comments follow (these are in addition to the comments I sent on the other threads). > > I'm not sure I understand the second paragraph of 5.1. Is this simply warning against the possibility of a local DoS by an application requesting too many expensive operations, or something more? > > Regarding enum KeyUsage: did you intend HMAC keys to use "sign" and "verify" as well? > > For import/export, why is KeyFormat an enum? My understanding is that this would preclude implementations from implementing other formats. I think we should let this be free-form for the same reasons that we allow arbitrary algorithm extensibility. > > Why does importKey take a key as a parameter? Is that the (optional) wrapping key? Correspondingly, how do I specify a wrapping key to exportKey? > > How is deriveKey supposed to work, specifically with regard to the optional derivedKeyType parameter? For instance, if I specify the derivedKeyType as RSA, what happens? (You may see where this is going - as I've mentioned before, existing KDFs are basically just deterministic random bit sequence derivers - turning this bit sequence into a key takes a lot of work and not all native APIs expose this.) > > Where possible, can we reuse names from ASN.1 modules for algorithm parameters? E.g. use publicExponent instead of exponent for RSA, following RFC 3447. I can do a pass through the others to pick specific names if you like. > > Why do you require ASCII names for algorithms (in the normalization rules), instead of allowing UTF-8 or something else which would support non-English algorithm names? Trying to avoid case-sensitive comparisons, without having to have the full overhead of a locale-aware case-insensitive comparison. This admittedly continues the bias towards ASCII within the DOM, but I think it's a fair argument to be made. > > -----Original Message----- > From: Ryan Sleevi [mailto:sleevi@google.com] > Sent: Wednesday, August 22, 2012 2:11 PM > To: public-webcrypto@w3.org > Subject: (Minor) New version published > > As per our conference call, all of the ISSUE-XX/ISSUE-YY pseudo-issues have been filed as proper issues in the issue tracker. > > As a reminder for everyone reviewing, please be sure to raise concerns on the mailing list, rather than waiting for our next conference call. > Directly filing an ISSUE is an alternative, since it will also mail the list, and we can make sure to track the discussion and resulting text. > > We don't need to immediately begin discussing ISSUEs, but I want to make sure that everyone's objections and concerns are properly captured as we move forward. > >
Received on Tuesday, 28 August 2012 19:53:04 UTC