r12 - 24 Aug 2005 - 13:19:12 - HeikkiToivonenYou are here: OSAF >  Projects Web  >  DevelopmentHome > SecurityFramework > CryptographicRequirements

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
  • DONE denotes items that have already been implemented
  • PICK 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. DONE Must use standards and de facto practices where possible
  4. DONE Must avoid patented technologies
  5. DONE Must reuse existing open source cryptographic libraries
    1. DONE Changes should be made in such a manner that they can be integrated into the external crypto project in order to avoid forking
  6. DONE Solutions must be cross platform, i.e. work on the major platforms on which Chandler is to be released.
  7. PICK Must be about as easy to use as username/password
  8. PICK Must be at least as secure as username/password
  9. DONE Should be about as easy for Chandler developers as username/password
    1. DONE Should have minimal Python API for Chandler developers
  10. Must have adequate performance
  11. DONE Should standardize on a single crypto library that is suitable for all cryptographic needs in Chandler
    1. Strong identity
    2. DONE SSL with server and client authentication
    3. PICK 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. DONE 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. PICK Must be able to create and use self signed X.509 certificates
  13. DONE Should be able to use certificates signed by "standard trusted CAs"
  14. PICK Users should be able to revoke certificates
  15. DONE Users must be able to stop trusting certificates
  16. DONE 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. PICK User must be able to create new keys and certificates
    • For example if they loose the password to their private key
  20. PICK Creation of new keys and certificates must be easy, ideally single click and automatically at install time
  21. DONE 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. DONE 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. DONE Must support secure communication with a WebDAV server
    1. Should support Chandler to act as a secure WebDAV server
  27. DONE 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
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r12 < r11 < r10 < r9 < r8 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.