The World Wide Web Consortium or W3C as it is commonly known was founded in 1994 by the original architect of the World Wide Web, Tim Berners-Lee. It is a consortium of international companies that are involved with the Web and the Internet.The W3C’s purpose is to develop open standards and make recommendations to ensure that the Web continues to evolve in a single direction instead of becoming splintered among various factions competing against one another.
Encryption and decryption
The specifications also describe an API that could be used by applications to create and/or manage the keys that would be necessary to perform the above operations. It is proposed that there could be a broad range of uses for this API, ranging from:
The Web Cryptography API that the W3C proposes would define a low-level interface that would interact with cryptographic key material. This would be managed by a user agent. Regardless of what platform this agnostic API would be used on, it would be capable of providing a common set of interfaces that would allow rich web applications to perform cryptographic functions without having to require access to the raw keying material.
The cryptographic transformations would be exposed by the SubtleCrypto interface. This interface defines a group of methods for performing commonly used cryptographic operations. Along with common operations such as hashing and verification, signature generation and verification, and encryption and decryption, the API also would provide interfaces for:
There are numerous applications that the Web Cryptography API would be suited.
Many web applications rely on multi-factor authentication to verify the identity of a user. Instead of having to use transport-layer authentication to authenticate a user’s access to secret keying material, the web application can be capable of providing authentication within itself. This in turn would provide a richer user experience.
With the Web Cryptography API, the application would locate suitable client keys that were previously created by the user agent (software that acts on the behalf of the user) or pre-provisioned by the web application. If the user does not have a key already associated with their account, the application would be able to give the user agent the option of generating a new key or re-use an existing key. This multi-factor authentication process could be strengthened by binding it to the TLS session from which the user is authenticating through deriving a key based on the underlying transport.
The Web Cryptography API can be used to limit the viewing of sensitive or confidential documents from within a web application, even if they have been securely received. The web application would use the API to encrypt the documents with a secret key that would be wrapped with public keys that are associated with those who are authorized to view the documents. When a user navigates to the web application, they would receive the encrypted document and be instructed to use their private key to unwrap the encryption key. They would then be able to decrypt and read the document.
There are instances where a web application may want to allow users the ability to protect the confidentiality of their documents or data that is stored with a remote service provider, before uploading to their service. With the Web Cryptography API, the user would:
Instead of requiring a written signature, many web applications choose to accept electronic signatures for documents. With the Web Cryptography API, the user would be directed to choose a key, which can be generated specifically for the application or be pre-provisioned. The application could then perform a signing operation using that key to prove that the user has accepted the document.
Often a web application may cache data locally, but wants to ensure that this data will not be compromised if an offline attack occurs. The Web Cryptography API allows the application to use a public key from within itself to verify the contents of the data cache. This allows the client to ensure that the data in the cache has not been compromised.
The Web Cryptography API can be used for off-the-record (OTR) and other message signing schemes by performing key agreement. The sender and receiver would negotiate shared encryption keys and message authentication code (MAC) keys. This would allow messages to be encrypted and decrypted to prevent tampering.
It is recommended that vendor-specific proprietary extensions not be used with Web Cryptography API specifications. This reduces the API’s interoperability and breaks up the user base because only users of the specific user agents would be able to access that particular content. When a vendor-specific extension cannot be avoided, they should be prefixed by vendor-specific strings. This will help avoid clashes with future versions of the API’s specifications.
W3C’s specification for the Web Cryptography API focuses on the common functionality and features that exist between various platform-specific and standardized cryptographic APIs, instead of those where functionality and features are known only to a few implementations. With this API, developers do not need to care about implementing underlying key storage as it allows a level of abstraction for generating keys, management and exchange.
This scope; however, does not dictate a mandatory set of algorithms that need to be implemented. This is because the underlying cryptographic implementations will vary between the conforming user agents based on local policy, government regulations, security practices or concerns regarding intellectual property. The API does not specifically address particular types of key store when provisioning keys.
Because of the issue of not providing an explicit storage mechanism, it is assumed that CryptoKey objects will be stored to mechanisms available to or to the actual current execution environment. To prevent hostile applications from misusing the Web Cryptographic API CryptoKey objects should not be shared between two origins.
It is advisable that application developers do not invent new cryptographic protocols for use with the Web Cryptographic API. It has been designed to work with existing protocols for the best performance. It is not recommended to use fingerprinting or super-cookies with the API because of the risk of malicious applications interfering with user agents or devices.
From Cryptomathic's perspective, supporting standardized JS libraries offers the opportunity to harmonize the client-side of solutions that secure e-commerce, such as remote digital signing solutions. The library would be leveraged allowing for quicker and simpler standardization.