Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
From MozillaWiki
Contents
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)
- HASH, HMAC, then PublicKey API
- How to handle key material, if at all
- Use Key IDs in place of handling any kind of private or symmetric key material
- What to begin with?
- 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
- String encoding and decoding will be the API consumer's job
- 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
- PGP, s/mime, etc support?
- 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
- Begin with AES 256
- Hash and HMAC APIs should be synchronous
- Fast operations
- Makes for a simpler interface