DOMCrypt meeting report

A meeting was held at Mozilla in Mountain View on 2011-07-14

The attendees were

• Dan Veditz, Mozilla
• Brian Smith, Mozilla
• Jonas Sicking, Mozilla
• David Dahl, Mozilla
• Adam Barth, Google/WebKit

Summary

• DOMCrypt is a high-level API that should be usable by web developers after a short period of study.
• DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing". \
• HASH and HMAC methods may be implemented first
• The Public Key API is the most useful, so it should be implemented before the symmetric encryption API.
  • Keypairs must be generated on a per-origin basis.
  • The Keypair for a specific origin cannot be used in another origin.
• No private or wrapped key material will be accessible to content scripts.
• Each implementation will provide a mechanism to clear keys.
• A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data.
• The returned encrypted object format will be a raw ArrayBuffer
• The public key format will be a raw ArrayBuffer
  • We agreed to "have all the inputs and outputs 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"
• HASH and HMAC methods should be synchronous to make them simpler
  • HASH and HMAC methods should be constructors
• We may implement the HASH and HMAC APIs first then the PublicKey API

More details

• Discuss problems with the API as specified
  • What to begin with?
    • HASH, HMAC, then PublicKey API
      • (symmetric API is not as important and more complicated to implement for the time being)
  • How to handle key material, if at all
    • Use Key IDs in place of handling any kind of private or symmetric key material
• How high-level is this API?
  • High-level enough that it will be difficult to use it incorrectly
• DOMCrypt API will not allow for server-side decryption of data
  • Future key export or key derivation may allow this operation
• Array buffers as input and output types
  • String encoding and decoding will be the API consumer's job
    • A 'jQuery for DOMCrypt' can be imagined as a pre and post-processor
• Support of existing crypto standards
  • PGP, s/mime, etc support?
    • Not a focus or required at this time.
  • An API for new apps makes this simpler, more "webby" and easier to implement
• Keypair per origin
  • KeyIDs are used to specify the key to use to decrypt data
  • Key material is never accessible to content
  • Mechanism to clear keys is needed
• Configuration of Algorithms
  • Begin with AES 256
    • Add an algorithm property/argument as needed
• Hash and HMAC APIs should be synchronous
  • Fast operations
  • Makes for a simpler interface