Cryptographic transformations are exposed via the - CryptoOperation interface, which defines a common set of - methods and events for dealing with initialization, processing data, and completing the - operation to yield the final output. In addition to operations such as signature + CryptoOperation interface, which defines a common set + of methods and events for dealing with initialization, processing data, and completing + the operation to yield the final output. In addition to operations such as signature generation and verification, hashing and verification, and encryption and decryption, - the API provides interfaces for key generation, key derivation, and key discovery. + the API provides interfaces for key generation, key derivation, key import and export, + and key discovery.
@@ -173,7 +174,7 @@Using the Web Cryptography API, such an application could locate suitable client keys, - which may have been previously generated via the user-agent or pre-provisioned + which may have been previously generated via the user agent or pre-provisioned out-of-band by the web application. It could then perform cryptographic operations such as decrypting an authentication challenge followed by signing an authentication response.
@@ -185,14 +186,14 @@If a user did not already have a key associated with their account, the web application could direct the user agent to either generate a new key or to re-use an existing key of - the user's chosing. + the user's choosing.
- When exchanging documents that may contain sensitive or personal information, the + When exchanging documents that may contain sensitive or personal information, a web application may wish to ensure that only certain users can view the documents, even after they have been securely received, such as over TLS. One way that a web application can do so is by encrypting the documents with a secret key, and then wrapping that key @@ -208,7 +209,7 @@
- A web application may wish to accept electronic signatures on documents, in leiu of + A web application may wish to accept electronic signatures on documents, in lieu of requiring physical signatures. An authorized signature may use a key that was pre-provisioned out-of-band by the web application, or it may be using a key that the client generated specifically for the web application. @@ -236,7 +237,7 @@
In addition to a number of web applications already offering chat based services, the - rise of WebSockets and RTCWEB allow a great degree of flexibility in inter-user-agent + rise of WebSockets and RTCWEB allows a great degree of flexibility in inter-user-agent messaging. While TLS/DTLS may be used to protect messages to web applications, users may wish to directly secure messages using schemes such as off-the-record (OTR) messaging.
@@ -311,7 +312,7 @@ security vulnerabilities being introduced in the implementations. Because of this, the specification has attempted to focus on the common functionality and features between various platform-specific or standardized cryptographic APIs, and avoid features and - functionality that is specific to one particular implementation. + functionality that are specific to one particular implementation.Chief among the implementation-specific APIs that this specification avoids is key @@ -324,7 +325,7 @@ Additionally, rather than designing an API around cryptographic providers or modules, the API is focused specifically around keys and opaque key handles, which may or may not expose the underlying raw cryptographic keying material to the application. The - intent behind this is to allow an API that is generic enough to allow conformant user + intent behind this is to allow an API that is generic enough to allow conforming user agents to expose keys that are stored within secure elements, if desired, but in such a manner that rich web applications will not have to be coded with specific knowledge of the key storage mechanism or its implementation details. Although the API does not @@ -429,16 +430,16 @@
name
@@ -584,35 +585,35 @@
idextractabletemporaryalgorithmalgorithm used to generate the key.
+ The Algorithm used to generate the key.
keyUsageArray of KeyUsages that
indicate what CryptoOperations may be used with this
key.
startDate
The effective start date for the validity of the key. This is not enforced by the
Web Cryptography API, and is provided for informative purposes only. May be
- null, indicating that the start date is not known or undefined.
+ null, indicating that the start date is unknown or undefined.
@@ -621,12 +622,12 @@
endDate
- The effective start date for the validity of the key. This is not enforced by the
+ The effective end date for the validity of the key. This is not enforced by the
Web Cryptography API, and is provided for informative purposes only. May be
- null, indicating that the start date is not known or undefined.
+ null, indicating that the end date is unknown or undefined.
@@ -635,7 +636,7 @@
userAttributesalgorithmalgorithm returns the
+ On getting, the algorithm attribute returns the
normalized algorithm of the algorithm used
- to initialize the CryptoOperation
+ to initialize the CryptoOperation.
resultresult attribute returns the
algorithm-specific result for the current
- CryptoOperation
+ CryptoOperation.
On getting, if the readyState
- is UNINITIALIZED (init has not been called), then the result
- attribute MUST return null.
+ is UNINITIALIZED (init() has not been called), then the result
+ attribute MUST return null.
On getting, if an error in performing the operation has occurred, then the
- result attribute MUST return null.
+ result attribute MUST return null.
The CryptoOperation can be in any one of
- four states. This state is tracked internal to the
+ five states. This state is tracked internal to the
CryptoOperation and may be used to
determine what methods may be called.
"processing"CryptoOperation has completed initialization as is ready to process
+ The CryptoOperation has completed initialization and is ready to process
data. More data to be processed may be supplied via
processData(), or the
operation may be concluded by calling
@@ -815,9 +816,9 @@
CryptoOperation is in the midst of performing the necessary finishing
steps to compute the final result,
- as a result of calling the complete
+ as a result of calling the complete()
method. No further data may be provided via the
- processData
+ processData()
method.
"complete""initializing".
init() method, but continue processing the steps in this
+ Return from the init() method, but continue processing the steps in this
algorithm.
processData() method, but continue processing the steps in
+ Return from the processData() method, but continue processing the steps in
this algorithm.
output
process.
+ Fire an event called progress.
completing.
complete() method, but continue processing the steps in
+ Return from the complete() method, but continue processing the steps in
this algorithm.
process.
+ Fire an event called progress.
The createSigner method
returns a new CryptoOperation
@@ -1361,7 +1362,7 @@
The createVerifier method
returns a new CryptoOperation
@@ -1414,9 +1415,9 @@
- The digest method returns
+ The createDigester method returns
a new CryptoOperation
object that will digest data using the specified
Algorithm.
@@ -1524,13 +1525,6 @@
- The getRandomValues method was originally proposed in the - WHATWG and is supported by Firefox, - Google Chrome, and Safari. -
-
The getRandomValues
method generates cryptographically random values. It must act as follows:
@@ -1540,13 +1534,13 @@
If array is not of an integer type (i.e., Int8Array, Uint8Array,
Int16Array, Uint16Array, Int32Array, or Uint32Array), throw a
- TypeMismatchError and abort these steps.
+ TypeMismatchError and terminate this algorithm.
- If array is longer than 65536, throw a QuotaExceededError
- and abort these steps.
+ If the length of array is greater than 65536, throw a
+ QuotaExceededError and terminate this algorithm.
This describes the SHA-1 and SHA-2 families, as specified by - [SP 180-3]. + [FIPS 180-3].
+ The getRandomValues method
+ in the Crypto interface was originally proposed by Adam Barth to the
+ WHATWG.
+