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

Good morning, I would like to help as need and not sure if it was already suggested, but why not to move webcrypto spec to GitHub like Mike did with webappsec https://github.com/w3c/webappsec? I think that would make easy for people outside to contribute.

Thoughts?

-- 
abstractj

JBoss, a division of Red Hat


On January 6, 2014 at 2:33:39 PM, 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 
> - Parameters listed for importKey() should include the hash 
> Bug 23242 
> - Registered algorithms table does not list wrapKey/unwrapKey 
> Bug 23504 
> - IDLs for DH and ECDH
> Bug 22548 
> - Specify the "normalization" rules for reflecting keyUsage 
> Bug 23833 
> - Remove sequence IDL keyword from parameters that take CryptoOperationData 
> Bug 22571 
> - Invalid IDL - Dictionary members as attributes
> Bug 22639 
> - Clarification on "raise an error" in RSAES-PKCS1-v1_5
> Bug 23013 
> - extractable and keyUsages under specified for Asymmetric 
> algorithms (duplicated with Bug 23695 
> - Clarify how "extractable" applies to keypairs)
> Bug 23786 
> - Please specify a mapping between WebCrypto AlgorithmIdentifiers 
> and pkcs-1 ones
> Bug 23017 
> - Specify numeric algorithm parameters with [EnforceRange] 
> (duplicated with Bug 23779 
> - Integral Algorithm dictionary members use EnforceRange inconsistently) 
> Bug 23097 
> - Underspecified behavior of verify() with regards to truncated 
> signature (truncation will be specified)
> Bug 23159 
> - Inconsistent "length" property when generating keys (bits 
> vs bytes)
> Bug 23499 
> - Add a note to AES-CBC/AES-CFB and add AES-PSM?
> Bug 23655 
> - Clarification: is BigInteger [] considered zero? ([] == 0x00) 
> Bug 23051 
> - Attributes on KeyPair should be readonly
> Bug 23762 
> - Importing rich key formats doesn't play well with default arguments 
> (proposed resolution, key usage is a mandatory attribute)
> Bug 23728 
> - CryptoOperationData can be mutated during operation (proposed 
> resolution, clarify to make a copy)
> Bug 22992 
> - Invalid IDL for HmacKeyParams dictionary
> Bug 23098 
> - Specify algorithm normalization when reflected to key.algorithm 
> (are generation parameters dropped?)
> Bug 22598 
> - Methods do not contain the test for their own key usage.
> Bug 23662 
> - InvalidAlgorithmError is unspecified
> Bug 23660 
> - Algorithm normalizing rules issues
> Bug 23501 
> - PBKDF2 Parameter Warning?
> Bug 23496 
> - Informative note about developer expectation re user access 
> to decrypted data?
> Bug 23043 
> - derivedKeyType is unreferenced
> Bug 22546 
> - Make AesCtrParams.counter an ArrayBufferView (seems to be 
> fixed now)
> Bug 22977 
> - The text for verify references CryptoOperation (which no longer 
> exists)
> Bug 22860 
> - The "registration" table for RSASSA-PKCS1-v1_5 is missing 
> Import/Export
> Bug 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 
> - KeyUsage should be explicitly spelled out as an enforced parameter 
> Bug 24056 
> - Algorithms supporting encrypt/decrypt should also support 
> wrap/unwrap
> Bug 22677 
> - wrapKey requires encrypt key usage
> Bug 20611 
> - Specify the text encoding for JWK key format
> Bug 23954 
> - Please specify RsaOaepParams label semantics
> Bug 23498 
> - Should the nonce, IV, and associated data be separated?
> Bug 19705 
> - Default value of keyUsage is not very useful
> Bug 22570 
> - AES-GCM should provide distinct inputs/outputs for the tag 
> Bug 21435 
> - Specify whether algorithm parameters are required for AES 
> CBC & CTR importKey
> Bug 23831 
> - add HMAC-SHA1 to the list of recommended algorithms
> Bug 23445 
> - typo with BigInteger?
> Bug 23500 
> - Raw AES access?
> Bug 23729 
> - Key usages future compatibility
> Bug 23503 
> - Should algorithms (ECC in particular) be extensible?
> Bug 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 Wednesday, 8 January 2014 07:37:02 UTC