RE: (Minor) New version published

Ryan [regarding using sign/verify for HMAC]> Yes. Is this a concern?

No, I was just making sure.

Ryan [regarding KeyFormat as an enum]> I don't think an enum is necessarily at odds with extensibility. An update to this spec can extend the valid identifiers for the types used and defined here. Any unsupported type has a well-defined failure handling (in so much as it's converted to the empty string).

What if an implementer wanted to support an additional format? Wouldn't not returning an error for that new value make them non-compliant with the spec? If so, that would require W3C to maintain a registry of valid KeyFormat values over time, something I got the impression that W3C avoids.

Ryan [regarding importKey]> "key" is the raw data to be imported, the format corresponding to the KeyFormat "format"

That makes sense. So how is the resulting Key object returned to the caller? (Same question for how the exported ArrayBuffer is returned by exportKey.)

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Tuesday, August 28, 2012 12:50 PM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org
Subject: Re: (Minor) New version published

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?

Yes. The risk is DoS in terms of CPU usage, or, for some implementations that may store keys in secure elements, DoS in terms of key storage.

It was mostly raised based on past experience with implementations'
handling of <keygen>

>
> Regarding enum KeyUsage: did you intend HMAC keys to use "sign" and "verify" as well?

Yes. Is this a concern?

>
> 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.

I don't think an enum is necessarily at odds with extensibility. An update to this spec can extend the valid identifiers for the types used and defined here. Any unsupported type has a well-defined failure handling (in so much as it's converted to the empty string).

>
> 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?

"key" is the raw data to be imported, the format corresponding to the KeyFormat "format"

So, as presently specified, importKey/exportKey don't have good semantics for wrap/unwrap (which may or may not need to be separate
operations)

I raised ISSUE-35 to track this.

>
> 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.)

Agreed.

I raised ISSUE-36 to track 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 Tuesday, 28 August 2012 21:42:45 UTC