DOMCrypt 'window.mozCrypto' Specification
- DRAFT
- Version 0.3
- Updated 2011-07-13
- Author
- David Dahl <ddahl@mozilla.com>
Introduction
This document describes a proposed Javascript Cryptography API available in web browsers to allow any web page script the ability to generate asymmetric key pairs, encrypt, decrypt (asymmetric and symmetric crypto), sign, verify, HMAC, and hash data ( via a variety of algorithms ).
Terms
- DOMCrypt
- A generic label for the entire crypto API originating in the open source project 'DOMCrypt'
- window.cipher
- The now deprecated proposed window property name for this API
- window.mozCrypto
- The temporary window property used to distinguish this new API from the current window.crypto property. The consensus so far is to add this API to the window.crypto property
- window.crypto
- The existing DOM property where this API should be integrated
- Key Pair
- An asymmetric pair of encryption keys. A Public Key which is used by others to encrypted data for you to decrypt with your Private Key. Key pairs are bound to the origin
- Public Key
- The public half of an asymmetric key pair
- Private Key
- The private half of an asymmetric key pair
- Symmetric Key
- an encryption key used for symmetric encryption
Browser Window property WebIDL
- window.mozCrypto
All windows will have this property (in the current implementation) for the time being as this API is hashed out.
The property is namespaced in order to provide future capabilities.
[Supplemental] interface Crypto { readonly attribute CryptoPk pk; readonly attribute CryptoSym sym; }; [Constructor(in DOMString algorithm)] interface CryptoHash { DOMString createHash(DOMString plainText); }; [Constructor(in DOMString algorithm)] interface CryptoHmac { DOMString createHMAC(DOMString plainText, DOMString key); boolean verifyHMAC(DOMString plainText, DOMString key); }; interface PKCryptoPublicKey { readonly attribute DOMString pubKey; readonly attribute DOMString algorithm; readonly attribute integer created; }; interface PKCryptoMessage { attribute DOMString cryptoMessage; attribute DOMString algorithm; }; [Callback=FunctionOnly, NoInterfaceObject] interface GenerateKeypairCallback { void onsuccess(DOMString pubKey); }; [Callback=FunctionOnly, NoInterfaceObject] interface GetPublicKeyCallback { void onsuccess(DOMString pubKey); }; [Callback=FunctionOnly, NoInterfaceObject] interface PKEncryptCallback { void onsuccess(PKCryptoMessage message); }; [Callback=FunctionOnly, NoInterfaceObject] interface PKDecryptCallback { void onsuccess(DOMString plainText); }; [Callback=FunctionOnly, NoInterfaceObject] interface PKSignCallback { void onsuccess(DOMString signature); }; [Callback=FunctionOnly, NoInterfaceObject] interface PKVerifyCallback { void onsuccess(boolean verified); }; interface CryptoPk { attribute DOMString algorithm; void generateKeypair(GenerateKeypairCallback callback); void getPublicKey(GetPublicKeyCallback callback); void encrypt(DOMString plainText, DOMString pubKey, PKEncryptCallback callback); void decrypt(PKCryptoMessage message, PKDecryptCallback callback); void sign(DOMString plainText, PKSignCallback callback); void verify(DOMString signature, DOMString pubKey, DOMString plainText, PKVerifyCallback callback); }; // Use JWE as the crypto object?, or something like the following: interface SymCipherObject { attribute DOMString cipherString; attribute DOMString algorithm; attribute DOMString symKeyID; // What is missing here? }; [Callback=FunctionOnly, NoInterfaceObject] interface SymEncryptCallback { void onsuccess(SymCipherObject cipherObject); }; [Callback=FunctionOnly, NoInterfaceObject] interface SymDecryptCallback { void onsuccess(DOMString plainText); }; interface CryptoSym { attribute DOMString algorithm; void encrypt(DOMString plainText, DOMString symKeyID, SymEncryptCallback callback); void decrypt(DOMString cipherText, DOMString symKeyID, SymDecryptCallback callback); };
Notes
- Each origin will only have access to the asymmetric private key generated for it. This will minimize the need for any kind of access control dialog for key usage.
- The configuration object should be removed from the IDL as we move to a set of keys per domain
References
- DOMCrypt: http://domcrypt.org
- DOMCrypt Mozilla bugs:
- DOMCrypt WebKit bug:
- WHAT-WG mailing list thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html
- W3C mailing list thread: http://lists.w3.org/Archives/Public/public-web-security/2011Jun/0000.html
- Mailing lists summarized http://etherpad.mozilla.com:9000/DOMCrypt-discussion
Meetings
- 2011-07-14, at Mozilla, Mountain View, CA Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14