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

Mark,

Agree on the idea that editorial/low-importance bugs can be fixed but should not prevent us from going to Last Call.
I guess my recent spamming wave shows that I am trying to answer your question related to open issues. Thanks for raising that !

Lets make a status on the issues and bugs during our next call, next Monday.

Regards,
Virginie



From: Mark Watson [mailto:watsonm@netflix.com]
Sent: mardi 7 janvier 2014 18:27
To: GALINDO Virginie
Cc: public-webcrypto@w3.org
Subject: 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<mailto: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


________________________________
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