RE: (Minor) New version published

> It is a valid question though - whether extending an enum "breaks" the spec. I wouldn't think so, because it would be the exact same thing "we" (as in W3C WG) might do if we defined version 2 of the API, and if it was "compatible" with version 1 of the API. As long as the defined handling for the existing definitions behaves correctly, I wouldn't think extending would break things.

[WEBIDL] section 3.5 ("Enumerations") says the following:

The behavior when a string value that is not one a valid enumeration value is used when assigning to an attribute, or passed as an operation argument, whose type is the enumeration, is language binding specific. 

Note: In the ECMAScript binding, assignment of an invalid string value to an attribute is ignored, while passing such a value as an operation argument results in an exception being thrown.


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

On Tue, Aug 28, 2012 at 2:41 PM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com> wrote:
> 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.

My understanding is that specs are regularly extended - publicly or privately, depending on the org doing the extending.

For example, this spec itself proposes extending the Window object such that it implements/exposes the Crypto interface.

It is a valid question though - whether extending an enum "breaks" the spec. I wouldn't think so, because it would be the exact same thing "we" (as in W3C WG) might do if we defined version 2 of the API, and if it was "compatible" with version 1 of the API. As long as the defined handling for the existing definitions behaves correctly, I wouldn't think extending would break things.

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

KeyOperation.result , as appropriate to the algorithm/format of export.

I've created ACTION-42 to add more normative text describing these exact operations, including state transitions, the population of result, and the handling of unsupported/unknown formats/algorithms.

>
> -----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, 4 September 2012 09:06:05 UTC