Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14

From MozillaWiki
Jump to: navigation, search

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