'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
1.2 List of Comments per Category
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
'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
1.2 List of Comments per Category
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
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
27139: Unreferenced ECPoint typedef in idl |
First recorded: 2014-10-23 |
Last modified: 2014-10-27 |
Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/f4f845756989 |
Review Status: Working Group
addressed proposal. Reviewer is
satisfied.
|
27198: Broken link to "JSON Web Key" |
First recorded: 2014-10-30 |
Last modified: 2014-10-30 |
Last modification: https://dvcs.w3.org/hg/webcrypto-api/rev/dde94af18a97 |
Review Status: Working Group
addressed proposal. Reviewer is
satisfied.
|