Cryptographic Requirements

This document is meant to list the cryptographic requirements of Chandler in the Canoga timeframe. Some of this is obvious, much is special requirements for a 3rd party cryptographic library we would need to adopt. Most of these requirements arise from secure sharing, but cryptography will be used elsewhere as well, for example connecting to mail servers over SSL.

• Must denotes items that seem mandatory and non-negotiable
• Should denotes items that are important, but where there might be room for negotiation
• denotes items that have already been implemented
• denotes items that are no longer relevant due to changed plans

1. Must be implementable in Canoga timeframe
   • See CryptoSchedule for a finer grained schedule.
2. Must first and foremost support Canoga, and not some other project or later version of Chandler
   • Where possible, consideration for other projects and later Chandler versions can be made but this must not cause Canoga schedule to slip
3. Must use standards and de facto practices where possible
4. Must avoid patented technologies
5. Must reuse existing open source cryptographic libraries
   1. Changes should be made in such a manner that they can be integrated into the external crypto project in order to avoid forking
6. Solutions must be cross platform, i.e. work on the major platforms on which Chandler is to be released.
7. Must be about as easy to use as username/password
8. Must be at least as secure as username/password
9. Should be about as easy for Chandler developers as username/password
   1. Should have minimal Python API for Chandler developers
10. Must have adequate performance
11. Should standardize on a single crypto library that is suitable for all cryptographic needs in Chandler
    1. Strong identity
    2. SSL with server and client authentication
    3. Encrypted and signed messaging for sharing
       • When direct SSL conection is not available due to firewalls or other party not being online at the same time, Chandler must encrypt and sign the message and send it over XMPP or email, and be able to receive such a message. Note that it is specifically not a requirement to be able to send and receive arbitrary S/MIME messages or secure arbitrary XMPP messages.
    4. Should be able to support the suggestions from Practical Cryptography for key lengths, ciphers etc.
    5. Should enable signed parcels
       • Note that signed parcels are not a Canoga requirement, but the chosen cryptographic library should be able to support them so that once we implement this we do not need a second library.
12. Must be able to create and use self signed X.509 certificates
13. Should be able to use certificates signed by "standard trusted CAs"
14. Users should be able to revoke certificates
15. Users must be able to stop trusting certificates
16. Must use the Chandler repository instead of normal files.
17. Private key must be protected by password
18. Chandler repository must not allow sharing of certain data, like private keys and passwords
    1. Exception? Chandler should automatically replicate the "me" contact along with "me" certificate(s) and private key(s) when the user has several computers.
19. User must be able to create new keys and certificates
    • For example if they loose the password to their private key
20. Creation of new keys and certificates must be easy, ideally single click and automatically at install time
21. Must be able to verify thumbprints of certificates
22. Must document the used cryptographic APIs
    • Note: It is expected that most APIs are already documented, and they may not require additional documentation.
23. Must create HOWTO documents for all the cryptographic operations that Chandler will do
    • For example, how to create an X.509 certificate, how to use the cryptographic APIs to make an SSL server and client, and so forth.
    • Even when the crypto libraries have API documentation, they often lack documentation on how to do certain things using the APIs, like in what order to call functions and what would be acceptable values.
24. Chandler repository should have a new data type for X.509 certificates
25. Chandler repository contact items should have a new property that links it to certificate(s)
26. Must support secure communication with a WebDAV server
    1. Should support Chandler to act as a secure WebDAV server
27. Must ship same list of root certificates as Mozilla (or as close as possible)
    1. May ship with additional higher education root certificates
28. Must be possible for users to install/deinstall root certificates

Specifically NOT Canoga Requirements (may be Westwood requirements - need clarifications):

1. Generic S/MIME support
2. Generic encrypted XMPP messaging
3. Multiple identities (=multiple certificates per contact)
4. Smart card support (which specifically, and for what purpose?)
5. Shibboleth
6. Kerberos
7. PGP
8. Bridge CA support
9. CRL support
10. OSCP support
11. Use of platform certificate store instead of, or in addition to, Chandler certificate store
12. SASL