Privacy/Features/DOMCryptAPISpec/Latest

DOMCrypt Specification

DRAFT

Version 0.4

Updated 2011-07-26

Author

David Dahl <ddahl@mozilla.com>

Author

Adam Barth <adam@adambarth.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 ).

W3C Web Cryptography Working Group Charter

• The W3C is using the DOMCrypt API as the "strawman" API
  • http://www.w3.org/2011/11/webcryptography-charter.html

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 (used in the extension code and the current Gecko patches). 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

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 CryptoSign sign;
};

[Constructor(DOMString algorithm)]
interface CryptoHash {
  void append(ArrayBuffer data);
  ArrayBuffer finish();
};

[Constructor(DOMString algorithm, ArrayBuffer key)]
interface CryptoHmac {
  void append(ArrayBuffer data);
  ArrayBuffer finish();
};

callback interface GenerateKeypairCallback {
  void onsuccess(ArrayBuffer keyID, ArrayBuffer pubKey);
};

callback interface GetPublicKeyCallback {
  void onsuccess(ArrayBuffer pubKey);
};

callback interface PKEncryptCallback {
  void onsuccess(ArrayBuffer message);
};

callback interface PKDecryptCallback {
  void onsuccess(ArrayBuffer plainText);
};

interface CryptoPk {
  void generateKeypair(DOMString algorithm, GenerateKeypairCallback callback, boolean signingKeypair);
  void getPublicKey(GetPublicKeyCallback callback);
  void encrypt(ArrayBuffer plainText, ArrayBuffer keyID, PKEncryptCallback callback);
  void decrypt(ArrayBuffer message, ArrayBuffer keyID, PKDecryptCallback callback);
};

callback interface SignCallback {
  void onsuccess(ArrayBuffer signature);
};

callback interface VerifyCallback {
  void onsuccess(boolean verified);
};

interface CryptoSign {
  void sign(ArrayBuffer keyID, ArrayBuffer plainText, PKSignCallback callback);
  void verify(ArrayBuffer signature, ArrayBuffer pubKey, ArrayBuffer plainText, PKVerifyCallback 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.
• All the inputs and outputs should be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful

Possible Additions

One possible addition we might consider is providing the web site with a secure mechanism having the user confirm a transaction. For example, a bank web site might wish to have the user sign a statement authorizing the transfer of funds from one account to another. Unlike the DOMCrypt APIs described above, this API involves interacting with the user to achieve non-repudiation:

 
supplemental interface CryptoSign {
  void signWithUserConfirmation(in ArrayBuffer keyID, in DOMString description, in ArrayBuffer data, in PKSignCallback callback); 
};

The signWithUserConfirmation method causes the user agent to display some user interface element containing the human-readable description. If the user confirms the description, the user agent with sign both the human-readable description and the binary data with the key designated by the keyId and supply the signature to the caller via the callback. There are still many details to work out, such as the format of the signed message, but this description is a starting point for discussion.

to deploy this feature to production level, we have to consider following issues.

• is passphase of private key safely entered?. means the confirmation screen need anti-keylogger mechanism.
• is browser sandbox safe? even on the user environment is compromized. (virus-infected?)
• co-operatable with requirements of security compliances (PCI, ISO27001...)

References

• DOMCrypt: http://domcrypt.org
• DOMCrypt Mozilla bugs:
  • https://bugzilla.mozilla.org/show_bug.cgi?id=649154
  • https://bugzilla.mozilla.org/show_bug.cgi?id=657432
• DOMCrypt WebKit bug:
  • https://bugs.webkit.org/show_bug.cgi?id=62010

• WHATWG 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