AddonSDKCryptoAPI
Status
| Addon SDK Crypto API | |
| Stage | Draft |
| Status | ` |
| Release target | TBD |
| Health | OK |
| Status note | There is a prototype API in bug 649154 which will be used to influence this design. Currently creating a design document and diagram(s). |
Team
| Product manager | Ben Adida |
| Directly Responsible Individual | Dan Mills |
| Lead engineer | David Dahl |
| Security lead | Brian Smith |
| Privacy lead | Brian Smith |
| Localization lead | TBD |
| Accessibility lead | N/A |
| QA lead | Juan Beccera |
| UX lead | N/A |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
Open issues/risks
- Need to create a platform API that is thread safe
- Need to create a ChromeWorker and JSM as the "internal API"
- keeping this work off of main thread
- need to keep e10s (mobile Firefox and desktop) in mind with this implementation
- Need to expose this internal API via an AddonSDK API
Stage 1: Definition
1. Feature overview
The Mozilla Identity project will need a very high-level, chrome-privileged API to generate keypairs, sign and verify data. Ideally, this API will also provide PublicKey encrytpion, symmetric encryption hashing and HMAC. The initial Identity-in-the-browser effort for Firefox itself will use the Addon SDK to iterate the UX and functionality. An API like this will also be useful in other ways to Addon developers. This project is the Addon SDK's integration with the DOMCrypt API: Privacy/Features/DOMCryptAPISpec/Latest
2. Users & use cases
Labs will need to create prototype Addons that handle generateKeypair(), sign() and verify() in order to support Identity in the browser.
A addon author needs to allow users to easily sign or encrypt then verify or decrypt data that is submitted to a service or exchanged between users online.
3. Dependencies
4. Requirements
`
Non-goals
Anything resembling a low-level crypto API.
Stage 2: Design
5. Functional specification
The spec will follow closely with the DOMCrypt API, which is content-focused. In this case we want essentially the same API for the Addon SDK: Privacy/Features/DOMCryptAPISpec/Latest
The basic idea is an Addon SDK API for key generation, signing and verification.
Let's cal the API 'crypto'. We will start with the functionality required by Identity.
[Supplemental]
interface Crypto {
readonly attribute CryptoPk pk;
};
[Callback=FunctionOnly, NoInterfaceObject] interface GenerateKeypairCallback {
void onsuccess(DOMString pubKey);
};
[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(DOMString ID, GenerateKeypairCallback callback);
void getPublicKey(DOMString ID, GetPublicKeyCallback callback);
void sign(DOMString plainText, PKSignCallback callback);
void verify(DOMString signature, DOMString pubKey, DOMString plainText, PKVerifyCallback callback);
};
6. User experience design
There *may* be a single prompt (to ask for an initial passphrase or an occasional re-typing of this passphrase) that UX will need to give input on. TBD. This is based on current prototype designs, and may not be an issue at all.
Stage 3: Planning
7. Implementation plan
Implementation plan is being worked on now (July 6 2011)
8. Reviews
Security review
TBD
Privacy review
TBD
Localization review
TBD
Accessibility
TBD
Quality Assurance review
TBD
Operations review
`
Stage 4: Development
9. Implementation
Much of this implementation will be guided by what has been implemented in the DOMCrypt project. There will be newer, cleaner platform APIs written to avoid the use of js-ctypes.
The basic design will be to create a JSM that makes all calls to crypto APIs off main thread via a ChromeWorker. The AddonSDK's API will import this JSM and require callbacks of the Addon author for all operations.
Stage 5: Release
10. Landing criteria
`
The basic idea is an Addon SDK API for key generation, signing and verification.
Let's cal the API 'crypto'. We will start with the functionality required by Identity.
[Supplemental]
interface Crypto {
readonly attribute CryptoPk pk;
};
[Callback=FunctionOnly, NoInterfaceObject] interface GenerateKeypairCallback {
void onsuccess(DOMString pubKey);
};
[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(DOMString ID, GenerateKeypairCallback callback);
void getPublicKey(DOMString ID, GetPublicKeyCallback callback);
void sign(DOMString plainText, PKSignCallback callback);
void verify(DOMString signature, DOMString pubKey, DOMString plainText, PKVerifyCallback callback);
};
" contains strip markers and therefore it cannot be parsed sufficiently.Feature details
| Priority | P2 |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | Mozilla Identity |
| Secondary roadmap | ` |
| Feature list | Jetpack |
| Project | ` |
| Engineering team | Jetpack |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | sec-review-needed | bsmith |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
