'Web Cryptography API' Disposition of Comments

This is the Disposition of Comments for the (proposed) 11 December 2014 Candidate Recommendation of the Web Cryptography API specification. This document lists the comments received during the Last Call period and the extent to which the Web Cryptography Working Group believes they have been addressed.

1. Overview of Comments

Total number of comments: 58

1.1 Reaction of the Working Group and (dis)satisfaction of the Reviewer

-	Reviewer satisfied	Reviewer not satisfied
WG addressed comment	43	0
WG rejects comment	9	0

1.2 List of Comments per Category

The reviewer is not satisfied with the response of the Working Group. Note that if a reviewer did not respond after two weeks, we assumed they were satisfied by the Working Group resolution.

Total number: 0.

Note that there were two formal objections, both of which have been resolved.

The first https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607 formal objection required the lack of security guidelines for developers by Rich Salz (Akamai, but formal objection as an individual). It was resolved by writing security guidelines (given by this draft RFC) and then sending the guidelines to the CFRG (The Internet Research Task Force's Crypto Forum Research Group). The CFRG may maintain the document, in which case then Web Cryptography API will link to it. The reviewer was satisfied with this response by the Working Group.
The second formal objection was over the extractability of private key material. Although the use-cases were not traditional Web use-cases as "end to end" encryption with a possibly malicious server is not handled by the Web Security Model, the use-case was accepted by some members of the Working Group as valid but also as under the scope of the Web Application Security Working Group, not the Web Cryptography Working Group. While the original non-W3C member reviewer who raised the formal objection did not respond, a second non-W3C member reviewer who also (Tom Lowenthal) accepted the response.
The reviewer is satisfied with the response of the Working Group.

Total number: 58 (100%).

25198 25345 25380 25381 25382 25383 25386 25387 25388 25389 25390 25419 25420 25422 25431 25432 25433 25436 25465 25466 25468 25469 25557 25558 25569 25570 25571 25577 25607 25618 25619 25620 25621 25622 25623 25624 25625 25626 25627 25658 25659 25661 25706 25710 25711 25717 25718 25721 25741 25799 25815 25816 25819 25820 25826 25839 25842 25857
The Working Group declined to implement the change which the reviewer requested.

Total number: 9 (15.52%).

25345 25387 25388 25557 25569 25622 25706 25721 25819

In detail:
1. Set window.crypto and all properties of window.crypto writable to false was not implemented as it as the precise attacks the reviewer was trying to prevent are out of scope for the WebCrypto API but instead are issues with the Web Security Model and thus in scope for the Web Application Security Group.
2. BigInteger was a request for ECMA TC39 to look at BigInteger. However, given it is just a "typedef" shorthand and not adding a new type to ECMAScript (which the Working Group had debated and eventually decided not to do). Adding new types to ECMAScript is currently considered to be in the scope of TC39, not the Web Cryptography Working Group
3. Boolean arguments was eventually resolved not to be implemented after, considering the options, the reviewer felt the Working Group had indeed made "probably the best option".
4. Spec should allow returning NotSupportedError for reasons other than failed Algorithm normalization was not implemented as other changes had rendered the request obsolete.
5. Suggest adding recommended algorithms to Section 18.2 was not supported as algorithm security guidelines are given in the proposed CFRG note and that no other Working Group members supported adding recommended algorithms. Note there is considerable debate around the term "recommended algorithm" in the cryptographic community as the precise kind of algorithm is very dependent on the wider context of the surrounding protocol.
6. Use RangeError instead of QuotaExceededError was not implemented as a quota (a fixed resource) was viewed as more suitable for describing an entropy pool and this error is used by browsers already since 2011.
7. Incomplete Key Generation Definitions was not implemented "based on the fact that this request is about giving guidance to implementers and users (and not adding a feature) combined with the fact that no reference related to robust random generation can be pointed to and agreed on."
8. Extractable keys should be disabled by default
9. Example of how deriveKey works was not implemented as no contribution neither comment was made to tha proposal" for an additional example.
The Working Group has addressed the proposal of the reviewer.

Total number: 43 (74.14%).

25198 25380 25381 25382 25383 25386 25389 25390 25419 25420 25422 25431 25432 25433 25436 25465 25466 25469 25558 25570 25571 25577 25618 25620 25621 25623 25624 25625 25626 25627 25658 25659 25661 25710 25711 25717 25718 25741 25799 25815 25816 25820 25857

1.3 Non-editorial Changes in the Draft

To implement answers to the reviews, the Working Group made a decision around a non-editorial change to the specification (extension mechanisms) and noted two possible dependencies that were necessary to resolve requests. Nevertheless, the Working Group believes that these decisions do not invalidate previous reviews of the draft or implementation experiences, since no new concept was introduced, and no existing concept was modified. The largest change was the implementation of an extensibility mechanism, and interoperability will be done during Candidate Recommendation, and a decision on the way forward with the numerious requests for "non-NIST" elliptic curves was found. The latter two decisions essentially note that dealing with these requests requires work in the Candidate Recommendation phase and requires a possible dependency on CFRG to be resolved.

Total number: 3

Extension mechanism: As given in this message: "Extension specifications will be explicitly listed in the specification - list to be updated with Errata. No longer possible to completely override existing algorithms. New hash algorithms can be added. EC curve extensibility intended to allow a variety of new curves, not just those that align with NIST ones."
Adding new elliptic curves: The Working Group also had a discussion of how to add additional elliptic curves, resulting in the following decision as given in this message: "The WG will not decide which additional curve to integrate before IETF/CFRG share its recommendation. Once this recommendation shared, based on timing constraint, algorithm maturity, the WG will make decision about integrating the curves, in accordance with the extensible mechanism the WG will decide, according to bug 25618. In case IETF/CFRG does not share recommendation before the Web Crypto API move to Proposed Recommendation, there will be no curve added. The Web Crypto will exit Last Call without any mention to those algorithms, without any provisioned place holder, but an editorial note stating that 'some new curves may be added if IETF/CFRG issue recommendations and that curves description are mature and complete enough to be referenced in our deliverables before we move to Proposed Recommendation. In that special case, the specification would go back to Last Call. If IETF/CFRG does not give any recommendation before we move to Proposed Recommendation, we will not integrate any new curve in our Web Crypto API current specification, and this will be done in the next version of our deliverables. A liaison will be sent to IETF/CFRG exposing that situation. Note that this resolution does not prevent anyone to share with the Working Group some draft describing NUMS or 25519 curves, in line with the extension mechanism to be described in bug 25618 [0]. This resolution prevents someone asking to make decision about formal endorsement of a new curve, between the exit to Last Call and the move to Proposed Recommendation milestones, if the IETF/CFRG has not yet issued its own recommendation." Clarity over whether a new Last Call or simply an edit to Candidate Recommendation would be useful.
Browser interoperability we defined during CR: Based on the exchanges related to this bug, the Working Group will "move forward is to define a browser profile after interoperability testing is conducted with different implementations. This browser profile should describe the exact behavior of the browser in case part of the algorithms are not available, or partially available, or disabled by the user. As such it is required to treat that bug once implementations have been demonstrated, which means after the call for implementation."

2. Detailed Description of Comments

25198: Turn KeyFormat into an enum

First recorded: 2014-03-28

Last modified: 2014-10-30

Last modification: KetFormat: https://dvcs.w3.org/hg/webcrypto-api/rev/c837a411bbb3 KeyType: https://dvcs.w3.org/hg/webcrypto-api/rev/859e993ccd8b KeyUsage: https://dvcs.w3.org/hg/webcrypto-api/rev/c0b3b769b9df Remove redundant checks for KeyUsage: https://dvcs.w3.org/hg/webcrypto-api/rev/be842bc4f511 Remove redundant checks for KeyFormat: https://dvcs.w3.org/hg/webcrypto-api/rev/42b6c67b5954

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25345: Set window.crypto and all properties of window.crypto writable to false

First recorded: 2014-04-15

Last modified: 2014-04-15

Note that dealing with XSS attacks is within the domain of the WebAppSec WG, as pointed out in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721

Review Status: Change declined. Reviewer is satisfied.

25380: Typo in message for InvalidStateError

First recorded: 2014-04-17

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/ef1d2658a6cb

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25381: Dead link to DOMException

First recorded: 2014-04-17

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/be3018091622

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25382: What error is returned when key mismatches operation?

First recorded: 2014-04-17

Last modified: 2014-09-24

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/07185a01188e

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25383: UnknownError, DataError are also defined by Indexed DB spec

First recorded: 2014-04-18

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/15278b55b058

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25386: Arrays and iterables

First recorded: 2014-04-18

Last modified: 2014-06-17

Last modification: Looks good, thanks. I missed the [[usages]] refactoring in the above commit and assumed it wasn't made.

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25387: BigInteger

First recorded: 2014-04-18

Last modified: 2014-05-12

Last modification: (In reply to Anne from comment #5) > The main problem I think is that you want a bigint, and are inventing one on > top of a Uint8Array. Ideally there would at least be some coordination with > TC39 so that they know this is going on. This isn't really accurate, for the reasons explained on https://github.com/w3ctag/spec-reviews/issues/3#issuecomment-41630590 This WG has spent a lot of time debating BigInteger - whether it's a first class type or not. You can see in the archives a previous proposal by Microsoft during the eBay/PayPal F2F that demonstrated a number of problems with trying to describe BigInteger for cryptographic operations. As explained during the W3C TAG review, the typedef here is to annotate a binary format (akin to the ASN.1 DER-encoding of SPKI/PKCS#8) If you're performing cryptographic operations using these, then we've failed as a WG.

Review Status: Change declined. Reviewer is satisfied.

25388: Boolean arguments

First recorded: 2014-04-18

Last modified: 2014-05-12

Last modification: Closing, per Comment 6

Review Status: Change declined. Reviewer is satisfied.

25389: Define octet string

First recorded: 2014-04-18

Last modified: 2014-09-24

Last modification: Fair. I think there's an open bug on IDL.

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25390: Use [Exposed] in IDL

First recorded: 2014-04-18

Last modified: 2014-10-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/810285715051

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25419: ECDH importKey for SPKI handles errors differently than all other key types, notably ECDSA

First recorded: 2014-04-22

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/d1693395d37e

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25420: Allow errors to be returned from exportKey()

First recorded: 2014-04-23

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/3bc402e6c907

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25422: Allow errors to be returned from digest()

First recorded: 2014-04-23

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/3bc402e6c907

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25431: Error names allow RSAES-PKCS1-v1_5 oracle attack against wrapped keys

First recorded: 2014-04-23

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/e78209123956

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25432: Section 14 typos

First recorded: 2014-04-23

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/816f8e52efa6

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25433: Wrong operations in registered algorithms table

First recorded: 2014-04-23

Last modified: 2014-09-24

Last modification: Fixed under bug 25625.

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25436: Handling of CryptoOperationData needs to be defined

First recorded: 2014-04-24

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/71498804a64d

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25465: ECDSA importKey for JWK should specify how to handle when "alg" conflicts with "crv"

First recorded: 2014-04-25

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/d49793c63670

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25466: ECDSA and ECDH importKey do not perform consistency checks of the namedCurve

First recorded: 2014-04-25

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/e0cd6df0a473

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25468: "CONCAT" KDF only supports deriveBits, not deriveKey

First recorded: 2014-04-25

Last modified: 2014-09-22

Last modification: The table lists methods, not operations. This should be fixed with the fix to 25625.

Review Status: Reviewer is satisfied.

25469: PBKDF2 section still mentions "password" field in an editor note

First recorded: 2014-04-25

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/0841c24aa2ee

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25557: Spec should allow returning NotSupportedError for reasons other than failed Algorithm normalization

First recorded: 2014-05-05

Last modified: 2014-09-29

Last modification: Go for it. This bug predates many changes in the spec which, as you rightly point out, have rendered it obsolete.

Review Status: Change declined. Reviewer is satisfied.

25558: Editorial nits

First recorded: 2014-05-05

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/ca21c15aed40

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25569: Suggest adding recommended algorithms to Section 18.2

First recorded: 2014-05-06

Last modified: 2014-10-22

Last modification: Closing according to Chair's proposed resolution.

Review Status: Change declined. Reviewer is satisfied.

25570: Need to register RS1 in Section 21.1

First recorded: 2014-05-06

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/858becd55b52

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25571: Add JOSE mappings for RSA in A.1

First recorded: 2014-05-06

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/858becd55b52

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25577: The interface name "Key" is very generic

First recorded: 2014-05-06

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/4673a7019d7f

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25607: Need to advise authors about security considerations

First recorded: 2014-05-08

Last modified: 2014-09-26

Last modification: *** Bug 18925 has been marked as a duplicate of this bug. ***

Review Status: Reviewer is satisfied.

25618: Extensibility: Offer spec-blessed ways to extend the algorithms and curves, rather than monkey-patching the spec

First recorded: 2014-05-09

Last modified: 2014-10-22

Last modification: Based on the meeting discussion and comment#61, the remaining issue here is to delegate decoding of the private key data structure to extensions specifications for ECDSA and ECDH. This is fixed in: https://dvcs.w3.org/hg/webcrypto-api/rev/b71fc3eaf6db https://dvcs.w3.org/hg/webcrypto-api/rev/be599c620546

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25619: Provide (non-normative) explanations for terminology like cryptographic provider

First recorded: 2014-05-09

Last modified: 2014-10-14

It seems cryptographic provider has been defined adequately in the spec now: "an abstraction for a specific implementation of a set of algorithms. The operating system or library may come with a default provider, and users are frequently allowed to add additional providers, reconfigure the set of enabled algorithms, or otherwise customize how cryptographic services are provided. While it is assumed that most user agents will be interacting with a cryptographic provider that is implemented purely in software, it is not required by this specification. As a result, the capabilities of some implementations may be limited by the capabilities of the underlying hardware, and, depending on how the user has configured the underlying cryptographic library, this may be entirely opaque to the User Agent."

Review Status: Reviewer is satisfied.

25620: Provide informative text regarding the origin-based security model of the API

First recorded: 2014-05-09

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/7a79e816e31b

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25621: Provide better explanation for the concerns of Section 6

First recorded: 2014-05-09

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/7a79e816e31b

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25622: Use RangeError instead of QuotaExceededError

First recorded: 2014-05-09

Last modified: 2014-06-02

Last modification: I'm going to close this as WontFix, for two reasons: 1) This is documenting an existing, implemented behaviour in a number of UAs that dates back to 2011 2) The choice of Quota over Range was made to prevent callers from draining the entropy pool, which is a concept specific to certain cryptographically strong random number generators. In this regard, Quota (as in, a fixed resource) seems more appropriate than Range (as in, exceeding an index)

Review Status: Change declined. Reviewer is satisfied.

25623: Typographic: Web IDL is two words, not one

First recorded: 2014-05-09

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/a825382f981b

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25624: Update Promise-using language to reflect the addition of Promises to ES6

First recorded: 2014-05-09

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/dfa57faee835

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25625: Provide a better explanation for the (informative) table in Section 18.1

First recorded: 2014-05-09

Last modified: 2014-09-26

Last modification: In the absence of comments, I propose we leave things as they are, with the additional explanation I have already provided.

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25626: Convert the various KeyAlgorithm interfaces into Dictionaries

First recorded: 2014-05-09

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/309495c2794e

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25627: Indicate that Key objects have internal state, and that the attributes they expose are reflections of that internal state

First recorded: 2014-05-09

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/2010be10bb87

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25658: Need normative reference for ArrayBufferView type

First recorded: 2014-05-12

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/193c854a9ac7

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25659: AES-CBC mode does not describe concretely how padding is added

First recorded: 2014-05-12

Last modified: 2014-10-07

Last modification: (In reply to Mark Watson from comment #6) > https://dvcs.w3.org/hg/webcrypto-api/rev/54a835eaad42 Note that a typo was introduced in this commit "methods are supported" -> "methods areA supported"

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25661: Allow algorithms to be implemented "as if", rather than strict adherance

First recorded: 2014-05-12

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/8db968b4673c

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25706: Incomplete Key Generation Definitions

First recorded: 2014-05-14

Last modified: 2014-10-22

Last modification: Closing per Chair's proposed resolution.

Review Status: Change declined. Reviewer is satisfied.

25710: No Key Deletion

First recorded: 2014-05-14

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/7a79e816e31b

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25711: Not clear if keys persist across sessions

First recorded: 2014-05-14

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/7a79e816e31b

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25717: Provide informative text noting when a parameter in an SPKI/PKCS8/JWK is ignored

First recorded: 2014-05-14

Last modified: 2014-09-24

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/2b4dc0a89244

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25718: Support RSA-OAEP with the SHA-2* family of algorithms in JWK

First recorded: 2014-05-14

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/a4cb70fcc0bb

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25721: extractable keys should be disabled by default

First recorded: 2014-05-15

Last modified: 2014-10-22

Last modification: Closing per Chair's resolution.

Review Status: Change declined. Reviewer is satisfied.

25741: RSA-OAEP is under-specified when the parameters define an operation not supported by the key size

First recorded: 2014-05-16

Last modified: 2014-10-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/5e7ba79bdf36

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25799: supercookies

First recorded: 2014-05-19

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/7a79e816e31b

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25815: Spec encourages unsafe handling of secret data for JWK import of RSA/ECC keys

First recorded: 2014-05-19

Last modified: 2014-10-22

Last modification: Import Key: Normalize on DataError. Only AES-CMAC needs changes: https://dvcs.w3.org/hg/webcrypto-api/rev/4fcabd0b818a Generate Key: Normalize on OperationError excepy usages validation which is SyntaxError: - fix one instance where usages validation was specified twice (ECDH). The second was unreachable and invalid: https://dvcs.w3.org/hg/webcrypto-api/rev/3d94cb8ef334 - fix one instance of parameter validation which was not returning OperationError (HMAC): https://dvcs.w3.org/hg/webcrypto-api/rev/1e509576870d The issue referred to in this bug does not affect Export Key.

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25816: DH import of PKCS8 uses OperationError instead of DataError for privateKeyInfo parse failure

First recorded: 2014-05-19

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/02122907368e

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25819: Example of how deriveKey works

First recorded: 2014-05-19

Last modified: 2014-10-22

Last modification: Closing per Chair's proposal.

Review Status: Change declined. Reviewer is satisfied.

25820: Should empty key usages be allowed when creating keys?

First recorded: 2014-05-20

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/c69386c630c6 [Leaving bug open in case there are comments]

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25826: The "hash attribute of the algorithm attribute of key" is invalid. There is no hash attribute in the algorithm attribute of key.

First recorded: 2014-05-20

Last modified: 2014-05-20

Last modification: As noted in the prose, the Algorithm for RSA keys - eg: those created via importKey, generateKey, or unwrapKey - is an RsaHashedKeyAlgorithm, which is-a KeyAlgorithm, which has a hash attribute. This is being further clarified as part of Bug 25626, so either this could be treated as a Duplicate (same root ambiguity) or as an Invalid (as it's already specified in prose the type of KeyAlgorithm on such objects)

Review Status: Reviewer is satisfied.

25839: Curve25519 Named Curve

First recorded: 2014-05-20

Last modified: 2014-10-23

We have in principle agreed to adopt the draft and did a call with Trevor Perrin to discuss. http://lists.w3.org/Archives/Public/public-webcrypto/2014Aug/0102.html As is in-line with the results of our call for consensus that called for CFRG liaisoning and then putting separate curves in separate documents (as Richard agreed to). Thus, we can put it as an "Editor's Draft" in W3C space. However, yes, we can also do a separate call out for consensus on the document as a Working Draft. Will ping Virginie to send out that call for consensus. We do not, to my knowledge, have a separate NUMS Editor's Draft. Of course, one can be created at any time and the WG can be alerted. However, note we are definitely in the resolved with "LATER" category with the production and adoption of the Curve 25519 draft and errata-extensibility mechanism for this long-standing bug.

Review Status: Reviewer is satisfied.

25842: Web developers given enough crypto rope to shoot selves in foot

First recorded: 2014-05-20

Last modified: 2014-05-21

Last modification: DJB's NaCL library, while useful, is not suitable for generalized use cases. That is, it makes a specific set of tradeoffs and choices that are specific to the program it tries to solve. It's not alone in this. Other "high level" libraries make equally acceptable trade-offs - such as SJCL or KeyCzar. Finally, some libraries limit their cryptography to those specific to the problems they're trying to solve - like OTR or Pond, for which there is low-level cryptography involved, but it's conceptually abstracted away. Our charter makes it clear what our goals are, but perhaps more usefully, you can review the discussion around ISSUE 7 ( http://www.w3.org/2012/webcrypto/track/issues/7 ), which recorded a decision that goes back as far as summer of 2012 that a 'high level' API is not part of the deliverables. For what it's worth, of significantly more interest to the "Webby", "REST-y" community is something like the products of the IETF JOSE group - https://datatracker.ietf.org/wg/jose/charter/ - which provides for JSON-based signing and encryption, and which WebCrypto can be used to implement a high-level API abstraction for. Finally, the choice of a low-level API is additionally motivated by the reasons described at http://extensiblewebmanifesto.org/ , which includes a goal of standardizing "new low-level capabilities and building new features in terms of them", in part to "Allow browser vendors and library authors to iterate on libraries that provide developer-friendly, high-level APIs."

Review Status: Reviewer is satisfied.

25857: Extractability is not always specified when importing keys (in particular public keys)

First recorded: 2014-05-21

Last modified: 2014-09-24

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/81b4435a540d

Review Status: Working Group addressed proposal. Reviewer is satisfied.

'Web Cryptography API' Disposition of Comments for Comments received after Last Call

This is the Disposition of Comments received after Last Call and up to 27 November 2014 on the Last Call of the Web Cryptography API specification. This document lists the comments received during this post-Last Call period and the extent to which the Web Cryptography Working Group believes they have been addressed. Comments received after November 27th will be dealt with during the Candidate Recommendation phase and will be noted during transition to Proposed Recommendation.

1. Overview of Comments

Total number of comments: 37

1.1 Reaction of the Working Group and (dis)satisfaction of the Reviewer

-	Reviewer satisfied	Reviewer not satisfied
WG accepted comment	26	0
WG rejects comment	7	0

1.2 List of Comments per Category

The reviewer is not satisfied with the response of the Working Group. Note that if a reviewer did not respond after two weeks, we assumed they were satisfied by the Working Group resolution.

Total number: 0.
The reviewer is satisfied with the response of the Working Group.

Total number: 37 (100%).

25857 25912 25972 25985 25992 26011 26080 26178 26214 26300 26301 26311 26315 26320 26322 26331 26348 26380 26411 26412 26413 26458 26465 26536 26674 26741 26866 26895 26902 26903 26905 26911 26950 27137 27139 27187 27198
The Working Group declined to implement the change which the reviewer requested.

Total number: 7 (18.92%).

26080 26178 26320 26348 26411 26458 26950

In detail:
1. Remove unsafe named curves from Web Crypto API is addressed by the extension mechanism and the Working Group's consensus on the CFRG decision on what the reviewer would call "safe" curves. Thus, the removal of ECDH and ECDSA was not implemented. Furthermore, the reviewer did accept that NIST-approved curves using in ECDH and ECDSA were needed for many users.
2. ECMAScript standard library was a request to see how this library could be used better within ECMAScript and server-side libraries like node.js. However, outreach had already been done to ECMA and no further action could be taken.
3. RsaHashedKeyAlgorithm inherits from RsaKeyAlgorithm was not implemented as there was no difference that would be caused by the reviewer suggestion.
4. Allow JWK for PBKDF2 was viewed as out of scope has the IETF JOSE WG did not explicitly allow JWK for PBKDF2, and it would be straightforward for a developer to write the shim themselves.
5. Caller can't force JWK to be distinguished as public or private key was not implemented insofar as lack of support was intentional ("because in many cryptographic libraries and implementation, this isn't possible/easy/reliable") and users who needed this could do it above the API level.
6. Are all the API methods really returning Promise, or can the return value be specified more precisely? was not implemented because specifying the return value more precisely could prevent the implementation of various cryptographic protocols.
7. Default HMAC keys should be output length, not block length was not implemented insofar as the reviewer agreed the original design was correct.
The Working Group has addressed the proposal of the reviewer.

Total number: 26 (70.27%).

25857 25912 25992 26011 26214 26300 26301 26311 26315 26322 26331 26380 26413 26465 26536 26674 26741 26895 26902 26903 26905 26911 27137 27139 27187 27198

1.3 Non-editorial Changes in the Draft

To implement the comment, the Working Group made a non-editorial change to the specification. Nevertheless, the Working Group believes that the change does not invalidate previous reviews of the draft or implementation experiences, since no new concept was introduced, and no existing concept was modified.

Bug 25972: Please require a secure origin (brought up after Last Call) is still under debate as it is also currently being discussed in the TAG and may require a non-editorial change the API in the future if secure origins are normatively required.

Total number: 0.

2. Detailed Description of Comments

25857: Extractability is not always specified when importing keys (in particular public keys)

First recorded: 2014-05-21

Last modified: 2014-09-24

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/81b4435a540d

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25912: DOMException.prototype.message is up to implementations

First recorded: 2014-05-29

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/52cea848d2e6

Review Status: Working Group addressed proposal. Reviewer is satisfied.

25972: Please require a secure origin

First recorded: 2014-06-04

Last modified: 2014-10-22

Last modification: (In reply to Ryan Sleevi from comment #21) > (In reply to Ehsan Akhgari [:ehsan] from comment #20) > We'll have to disagree there. The entire point is that, without an > authenticated origin, you *cannot* have secure key storage for any > meaningful definition of secure. An attacker in a privileged position can > > a) postMessage the Key object (structured clonable) to an origin of their > choosing for later use at a time of their choice, able to fully decrypt or > forge any messages > b) force the UA into a downlevel form such that it re-generates the key in > an insecure way (this is the problem with the "TOFU" model, in that it > trivially falls apart) > > For an *unauthenticated* origin, everything WebCrypto provides can be met > via polyfill, which is what I mentioned in my previous message. It's > precisely because of this that it's entirely uninteresting to implement (as > an unnecessary surface of the web platform). > I agree that if the goal is for something to be "secure" in a meaningful and unqualified sense, then an authenticated origin is needed. But what if your goals are more modest than that ? What if confidentiality against passive monitoring is of value to you without confidentiality against active attackers ? I get that your opinion is that such a limited form of confidentiality is without value. But that opinion must be based on assumptions about the likely attackers and the value of the information to which the confidentiality applies. Those assumptions may not hold for all use-cases and you should not impose them on others.

Review Status: Reviewer is satisfied.

25985: WebCrypto should be inter-operable

First recorded: 2014-06-05

Last modified: 2014-08-13

Last modification: During its 28th of July call, the Web Crypto WG has agreed to the following resolution : RESOLUTION: Leave the bug open; expect to resolve it after testing phase by developing one or more profiles. See minutes of the meeting for more detail http://www.w3.org/2014/07/28-crypto-minutes.html Virginie chair of the web crypto wg

Review Status: Reviewer is satisfied.

25992: editorial

First recorded: 2014-06-05

Last modified: 2014-06-16

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/5306e01d0561

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26011: Add importKey/exportKey marks for PBKDF2

First recorded: 2014-06-07

Last modified: 2014-09-24

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/0d1cdb9d2360

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26080: Remove unsafe named curves from Web Crypto API

First recorded: 2014-06-12

Last modified: 2014-08-13

Last modification: As per decision from the Web Crypto WG, based on team feedbacks and bug reviewer feedbacks, this bug is resolved as WONTFIX. Virginie chair of web crypto wg

Review Status: Change declined. Reviewer is satisfied.

26178: ECMAScript standard library

First recorded: 2014-06-23

Last modified: 2014-10-22

Last modification: In the absence of further comments I'm closing this as WONTFIX. If you object, please reopen.

Review Status: Change declined. Reviewer is satisfied.

26214: Define consistent error when calling exportKey() with unsupported key format

First recorded: 2014-06-26

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/5b2b1e7a8d4c https://dvcs.w3.org/hg/webcrypto-api/rev/939143e3319f

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26300: Normalization: "If alg is an IDL object" is confusing

First recorded: 2014-07-09

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/920b0cf25715

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26301: Normalization: Should throw instead of returning an Error instance

First recorded: 2014-07-09

Last modified: 2014-10-22

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/4c8aa1eee8c8

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26311: Algorithm names should be enforced to be ASCII and normalized to lowercase

First recorded: 2014-07-11

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/08636b084b31

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26315: ECDSA/ECDH: "namedCurve ASN.1 type" is ambiguous

First recorded: 2014-07-12

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/dbdc7abe4e32

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26320: RsaHashedKeyAlgorithm inherits from RsaKeyAlgorithm

First recorded: 2014-07-12

Last modified: 2014-10-22

Last modification: As per comment#6 there is no visible difference between the current specification and combining the dictionary definitions.

Review Status: Change declined. Reviewer is satisfied.

26322: Definitions "algorithm" and "usages" properties of CryptoKey make no sense

First recorded: 2014-07-13

Last modified: 2014-11-08

Last modification: > I'm definitely concerned here to understand what "security bugs" you see? In our case, Firefox extensions touching these objects would end up seeing page-modified values, which is likely to be a problem. > there is a 'canonical' internal slot that contains the true value Yes, but the canonical getter doesn't actually return that value, after the first time it's called. The security proxies in Gecko that are used by extensions ensure that when getting a property on a Web IDL object the canonical getter is invoked. This guarantees that the correct thing is returned in cases when the getter just returns the value of an internal slot (as it does with DOM nodes, say). In the case of CryptoKey this will mean invoking the canonical getter, which then returns the value it's cached, which is an array that it's potentially handed out to untrusted script before and that the untrusted script may have modified. > and follows all the normal "You can mess with this object in weird > ways if you're weird" You can mess with it in ways in which you can't mess with Web IDL objects, because the array itself does not have internal state. > Yes, it means that an object may 'lie' to an user Yes, and if the "user" is a privileged browser extension that constitutes a security bug. > However, an object can be made to lie many ways (Prototypes being the > canonical way Our security wrappers ensure that the canonical prototype chain is walked. > but WebRTC at least is an example of a similar problem Where, exactly? I see nothing along these lines in the WebRTC IDL. > and the sequence situation with CSP(3?) seems similar You mean CSP 2? The IDL for that was just proposed; no one implements it yet. It's explicitly punting on the arraylike bits for now until they can be sorted out. In fact, the only case in which I see something similar in Gecko is the Gamepad API, but we return frozen arrays there. In any case, us freezing the array is likely temporary until https://bugzilla.mozilla.org/show_bug.cgi?id=946906 is fixed. Just thought you'd want a heads-up that we plan to do it at least until then...

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26331: Usage Intersection is defined as operating on arrays, rather than sequences

First recorded: 2014-07-14

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/b70e27d42387

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26348: Allow JWK for PBKDF2

First recorded: 2014-07-16

Last modified: 2014-09-22

Last modification: I think we should live with the existing text here. If necessary the script can extract the raw key from the JWK itself and import that.

Review Status: Change declined. Reviewer is satisfied.

26380: importKey doesn't define handling of keyData in some cases

First recorded: 2014-07-17

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/1af2d5aa1b2d

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26411: Caller can't force JWK to be distinguished as public or private key

First recorded: 2014-07-22

Last modified: 2014-09-22

Last modification: The discussion here points towards 'won't fix'. Any objections ?

Review Status: Change declined. Reviewer is satisfied.

26412: Asymmetric algorithms do not specify how to compute usages/extractability during importKey

First recorded: 2014-07-22

Last modified: 2014-09-25

Last modification: [[extractable]] is addressed by Bug 25857. [[usages]] is set in the importKey method procedures.

Review Status: Reviewer is satisfied.

26413: Inconsistent handling of usages parameter between importKey and generateKey

First recorded: 2014-07-22

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/d461dd0a2bdd https://dvcs.w3.org/hg/webcrypto-api/rev/13846e3198f6 https://dvcs.w3.org/hg/webcrypto-api/rev/ac6406fe7075

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26458: Are all the API methods really returning Promise<any>, or can the return value be specified more precisely?

First recorded: 2014-07-29

Last modified: 2014-09-22

Last modification: Based on Comment #5 I'd suggest won't fix for this. Any objections ?

Review Status: Change declined. Reviewer is satisfied.

26465: Algorithm normalization doesn't allow arbitrary operations for AlgorithmIdentifier fields

First recorded: 2014-07-30

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/417ccc8bf5ae

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26536: Length property of HmacDerivedKeyParams seems redundant

First recorded: 2014-08-07

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/dc8073493900

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26674: Use required dictionary entries instead of hacks with nullable

First recorded: 2014-08-26

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/2616605d14ae

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26741: Reject invalid EC public keys

First recorded: 2014-09-05

Last modified: 2014-10-30

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/e4b4b28e81af https://dvcs.w3.org/hg/webcrypto-api/rev/59c5870bf638

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26866: Add "required" to dictionary members; drop

First recorded: 2014-09-19

Last modified: 2014-09-19

Last modification: *** This bug has been marked as a duplicate of bug 26674 ***

Review Status: Reviewer is satisfied.

26895: Use BufferSource typedef

First recorded: 2014-09-24

Last modified: 2014-10-27

Last modification: This was renamed BufferSource in WebIDL since this bug was filed. https://dvcs.w3.org/hg/webcrypto-api/rev/7dd14c51e4b7

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26902: RSA SSA/PSS validation of use field during JWK import is wrong

First recorded: 2014-09-25

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/78ac4869f186

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26903: Parameter validation errors should return SyntaxError not DataError

First recorded: 2014-09-25

Last modified: 2014-10-30

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/b8f161c372a5 There is one common case where SyntaxError is used which I have left as a SyntaxError. This is the case where incorrect usages are supplied. That is, recognized usage values, but incorrect for the type of key being generated, imported or unwrapped. It doesn't seem right to call this a TypeError, since as far as the usages data type is concerned the information is correct. Please re-open if you disagree.

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26905: PBKDF2 should support usage value of deriveBits

First recorded: 2014-09-25

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/d3f5c9c71fb3

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26911: Attempting to use a EC key with mis-matched curve should be InvalidAccessError

First recorded: 2014-09-26

Last modified: 2014-09-26

Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/fe69c74e7042

Review Status: Working Group addressed proposal. Reviewer is satisfied.

26950: Default HMAC keys should be output length, not block length