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). |
{{#set:Feature name=Addon SDK Crypto API
|Feature stage=Draft |Feature status=` |Feature version=TBD |Feature health=OK |Feature 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 | ` |
{{#set:Feature product manager=Ben Adida
|Feature feature manager=Dan Mills |Feature lead engineer=David Dahl |Feature security lead=Brian Smith |Feature privacy lead=Brian Smith |Feature localization lead=TBD |Feature accessibility lead=N/A |Feature qa lead=Juan Beccera |Feature ux lead=N/A |Feature product marketing lead=` |Feature operations lead=` |Feature 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
` {{#set:Feature open issues and 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
|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 |Feature users and 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. |Feature dependencies=bug 649154 bug 665057 |Feature requirements=` |Feature non-goals=Anything resembling a low-level crypto API. |Feature functional spec=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);
};
|Feature ux 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. |Feature implementation plan=Implementation plan is being worked on now (July 6 2011) |Feature security review=TBD |Feature privacy review=TBD |Feature localization review=TBD |Feature accessibility review=TBD |Feature qa review=TBD |Feature operations review=` |Feature implementation notes=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. |Feature landing criteria=` }}
Feature details
| Priority | P2 |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | Mozilla Identity |
| Secondary roadmap | ` |
| Feature list | Jetpack |
| Project | ` |
| Engineering team | Jetpack |
{{#set:Feature priority=P2
|Feature rank=999 |Feature theme=` |Feature roadmap=Mozilla Identity |Feature secondary roadmap=` |Feature list=Jetpack |Feature project=` |Feature 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 | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=sec-review-needed |Feature security health=Assigned |Feature security notes=bsmith |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}