RE: (Minor) New version published

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?

-----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 Monday, 27 August 2012 10:05:22 UTC