r8 - 07 Feb 2006 - 15:25:18 - LisaDusseaultYou are here: OSAF >  Projects Web  >  DevelopmentHome > SecurityFramework > PkiSharingWithWebDav

PKI and Sharing via WebDAV Server

Work in progress -- this page is still being drafted?

The latest idea (but the first to be implemented) on how sharing happens in Chandler is to use a Chandler WebDAV server hosted on some server that is always on the net.

The security principles here should be so that all communications between the server and client are over SSL (mutually authenticated where possible), and data is encrypted on the server.

Sharing between Chandler users

When user A decides to share something with user B via the WebDAV server, Chandler encrypts and signs the data to user A and B and sends it to the server.

When any user tries to connect to the URL, the server could decide to not finish SSL handshake if the client certificate is not what the server expects, meaning the attempt to get at the resource would fail. See next section how to continue from here.

Supposing the client presented the proper client certificate, it can then download the resource. Once downloaded, it needs to decrypt the data before being able to do anything about it. Of course, if the data was not originally encrypted to this public key it won't work.

To change with whom you share, encrypt to different list of users.

Sharing from Chandler user to non-Chandler user

In this case the flow is changed from the image above with steps 3 and forward. Substitude a non-Chandler user to Chandler B above, typically someone with a web browser.

  1. Chandle user sends resource he wishes to share to server, encrypted and signed to self.
  2. Chandler sends email to non-Chandler user with the URL to access the resource on the WebDAV server.
  3. Non-Chandler user tries to access resource with web browser: server won't give access because there is no client cert or wrong client cert.
    • Server offers to create a client cert for user. User says ok, gets client cert installed in browser. Server remembers cert.
    • There are some web based products that do this, need to find more info about them.
  4. Non-Chandler user gets in touch with Chandler user, says could not connect but now has client cert.
  5. Chandler user gets a list of certs that have tried to access URL, calls non-Chandler user to have him read his client cert fingerprint. Chandler user allows access to cert with matching fingerprint and tells non-Chandler user to try again. This is similar to Greenpass. (Behind the scenes, Chandler re-encrypts data to both users and sends it to server.)
  6. non-Chandler user tries again, SSL handshake works, get's encrypted data.
    • Now what? Is there support in browsers to do decryption? Or would we need a Java plugin?
    • Mozilla does not seem to have support built in, but it could perhaps be added by modifying this interface: http://lxr.mozilla.org/seamonkey/source/dom/public/idl/base/nsIDOMCrypto.idl

Weakened security options

  • Do not encrypt data on the server.
    • Easier to share data, won't be lost if password to private key lost, or private key lost.
  • Do not require client certificate.
    • Easy to get data, need only URL.
    • Not possible to encrypt shareable data on server.
  • We could also make it so that one would not be able to edit the data without client certificate, but would be able to view.

-- HeikkiToivonen


Discussion

  • The storage server doesn't necessarily need to know anything about certs and keys -- it could simply offer the file as publicly readable. To most clients who download it the encrypted contents ensure that they can't read it anyway.
  • If the WebDAV server doesn't have to be modified (and extensions to WebDAV) to accept or handle certs in anyway, then that would simplify the problem -- similar to what RSafe attempted.
  • There are obvious tradeoffs to time spent developing the system, time maintaining (IT), usability and interoperability

-- LisaDusseault - 18 Aug 2004

  • I think the WebDAV server would need to know nothing about creating certificates, but it would need to redirect users without client certificates to an auxilixary server that could create the certificate. The auxiliary server could then redirect the user back to the WebDAV server, which would now get to see the user's certificate and store information about it.
  • Checking client certificates per URL is something that this design calls for, and it seems like that would need to be developed.

-- HeikkiToivonen - 19 Aug 2004

PageInfo
PageType DevDocPage
MaintainedBy HeikkiToivonen
PageStatus Work in progress -- this page is still being drafted?
Trash.CommentsWelcome2 Feel free to contribute comments?, either by adding to the Comments Welcome section of this page, or by posting to the dev list, or by sending mail directly to the person listed as maintaining the page.
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r8 < r7 < r6 < r5 < r4 | 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.