Re: W3C Web Crypto - bugs to be fixed for next version : a proposal

Virginie,

The list looks good to me, though I do not think there should be any
prohibition on the editors addressing the bugs in the first list before
Last Call, just that we will not delay Last Call for any of these.

Do we also have open "Issues" that are not associated with any specific bug
? Should we also classify those in a similar way ?

...Mark


On Mon, Jan 6, 2014 at 8:30 AM, GALINDO Virginie <
Virginie.GALINDO@gemalto.com> wrote:

>  Hi all,
>
>
>
> As part of our previous call, I had the action to bring to the WG a straw
> man proposal for listing bugs to be fixed for next version of the Web
> Crypto API. The next version will go for Last Call.
>
>
>
> My understanding is that the following bugs are editorial ones or
> clarifications with low impact. I suggest we park them and address them *
> *after** we go for Last Call.
>
> *Bug 24172* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24172> -
> Parameters listed for importKey() should include the hash
>
> *Bug 23242* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23242> -
> Registered algorithms table does not list wrapKey/unwrapKey
>
> *Bug 23504* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23504> - IDLs
> for DH and ECDH
>
> *Bug 22548* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=22548> -
> Specify the "normalization" rules for reflecting keyUsage
>
> *Bug 23833* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23833> -
> Remove sequence IDL keyword from parameters that take CryptoOperationData
>
> *Bug 22571* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=22571> -
> Invalid IDL - Dictionary members as attributes
>
> *Bug 22639* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=22639> -
> Clarification on "raise an error" in RSAES-PKCS1-v1_5
>
> *Bug 23013* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23013> -
> extractable and keyUsages under specified for Asymmetric algorithms
> (duplicated with *Bug 23695*<https://www.w3.org/Bugs/Public/show_bug.cgi?id=23695>- Clarify how "extractable" applies to keypairs)
>
> *Bug 23786* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23786> -
> Please specify a mapping between WebCrypto AlgorithmIdentifiers and pkcs-1
> ones
>
> *Bug 23017* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23017> -
> Specify numeric algorithm parameters with [EnforceRange] (duplicated with
> *Bug 23779* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23779> -
> Integral Algorithm dictionary members use EnforceRange inconsistently)
>
> *Bug 23097* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23097> -
> Underspecified behavior of verify() with regards to truncated signature
> (truncation will be specified)
>
> *Bug 23159* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23159> -
> Inconsistent "length" property when generating keys (bits vs bytes)
>
> *Bug 23499* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23499> - Add
> a note to AES-CBC/AES-CFB and add AES-PSM?
>
> *Bug 23655* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23655> -
> Clarification: is BigInteger [] considered zero? ([] == 0x00)
>
> *Bug 23051* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23051> -
> Attributes on KeyPair should be readonly
>
> *Bug 23762* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23762> -
> Importing rich key formats doesn't play well with default arguments
> (proposed resolution, key usage is a mandatory attribute)
>
> *Bug 23728* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23728> -
> CryptoOperationData can be mutated during operation (proposed resolution,
> clarify to make a copy)
>
> *Bug 22992* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=22992> -
> Invalid IDL for HmacKeyParams dictionary
>
> *Bug 23098* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23098> -
> Specify algorithm normalization when reflected to key.algorithm (are
> generation parameters dropped?)
>
> *Bug 22598* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=22598> -
> Methods do not contain the test for their own key usage.
>
> *Bug 23662* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23662> -
> InvalidAlgorithmError is unspecified
>
> *Bug 23660* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23660> -
> Algorithm normalizing rules issues
>
> *Bug 23501* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23501> -
> PBKDF2 Parameter Warning?
>
> *Bug 23496* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23496> -
> Informative note about developer expectation re user access to decrypted
> data?
>
> *Bug 23043* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23043> -
> derivedKeyType is unreferenced
>
> *Bug 22546* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=22546> - Make
> AesCtrParams.counter an ArrayBufferView (seems to be fixed now)
>
> *Bug 22977* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=22977> - The
> text for verify references CryptoOperation (which no longer exists)
>
> *Bug 22860* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=22860> - The
> "registration" table for RSASSA-PKCS1-v1_5 is missing Import/Export
>
> *Bug 18925* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=18925> -
> Highlight algorithm-specific security considerations
>
>
>
> The following bugs require a technical decision or further discussions. I
> am suggestion that we fix the 15 following bugs **before** we go for Last
> Call.
>
> *Bug 19416* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=19416> -
> KeyUsage should be explicitly spelled out as an enforced parameter
>
> *Bug 24056* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24056> -
> Algorithms supporting encrypt/decrypt should also support wrap/unwrap
>
> *Bug 22677* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=22677> -
> wrapKey requires encrypt key usage
>
> *Bug 20611* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=20611> -
> Specify the text encoding for JWK key format
>
> *Bug 23954* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23954> -
> Please specify RsaOaepParams label semantics
>
> *Bug 23498* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23498> -
> Should the nonce, IV, and associated data be separated?
>
> *Bug 19705* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=19705> -
> Default value of keyUsage is not very useful
>
> *Bug 22570* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=22570> -
> AES-GCM should provide distinct inputs/outputs for the tag
>
> *Bug 21435* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=21435> -
> Specify whether algorithm parameters are required for AES CBC & CTR
> importKey
>
> *Bug 23831* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23831> - add
> HMAC-SHA1 to the list of recommended algorithms
>
> *Bug 23445* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23445> - typo
> with BigInteger?
>
> *Bug 23500* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23500> - Raw
> AES access?
>
> *Bug 23729* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23729> - Key
> usages future compatibility
>
> *Bug 23503* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23503> -
> Should algorithms (ECC in particular) be extensible?
>
> *Bug 23495* <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23495> -
> Should an informative note mention that entropy is expected? (and an error
> defined ?)
>
>
>
> To all,
>
> what do you think about that prioritization ? If you agree, please feel
> concerned by those bugs and suggest solution to the editors (they need you,
> you remember !).
>
>
>
> Editors,
>
> Note that I have been created this list based on F2F meeting minutes and
> my understanding when reading bugs, so please do not hesitate to correct if
> you disagree with my categorization.
>
>
>
> Regards,
>
> Virginie
>
> ------------------------------
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus
>

Received on Tuesday, 7 January 2014 17:27:18 UTC