Obsolete:MNET 1.0 technotes

Establishing trust relationships

The community hub is formed by Moodle installations establishing P2P-style trust relationships. Once those relationships have been established, each Moodle can offer services from other trusted nodes, and use the offered services.

We need to define key infrastructure for managing the trust relationships, probably using a public key encryption scheme. Currently looking at...

Core encryption/signing infrastructure

• Using GPG via
  • Crypt_GPG - a proposed PEAR package, wraps around the gpg binary. We are lucky and v0.20 is offered under LGPL, though it depends on PHP5 for its error handling (easy to fix).
  • TinyPHP or something similar. See DIY risks.
• Using PHP's one mcrypt functions. See DIY risks.

DYI risks: we are not actually crypto developers, so if we go out an implement message signing ourselves there is a good chance we will miss a subtle point and have trouble.

Key generation and storage

Moodle installations should be able to generate keys or load preexisting keys. GPG tends to want the key as a file, so the root of moodledata is a reasonably good place for it. Unfortunately, it is also often world-readable.

Note that the key handling will never be as secure as personal GPG keys can be. The keys and the encryption machinery have to be accessible by www-data. So in most cases any user with shell access to the server can impersonate your Moodle install.

Key exchange mechanisms

• Each Moodle can publish its GPG public key openly in a standard url.
• Optionally, public keys can be exchanged out-of-band and loaded manually
• We do not want these keys to show up on established GPG keyrings, and it is probably overkill to establish a moodle keyring. When trusting a web app like Moodle, the URL itself is an important point of trust.